Tu as accéléré le codage. Devine où le goulot d'étranglement s'est déplacé ensuite.

Au cours de l’année dernière, la production de code de ton équipe a augmenté. Les pull requests sont ouvertes plus vite. Le backlog des petites corrections et des modifications de routine a commencé à se résorber plus rapidement qu’avant.

Si le délai de livraison te semble toujours à peu près aussi long qu’avant, c’est ce qui arrive quand on accélère une partie d’un processus sans toucher à ce qui se passe en aval.

Où se trouve réellement le goulot d’étranglement

Point clé : le codage est devenu plus rapide. La révision, la validation et la qualité des spécifications, non. La contrainte n’a pas disparu ; elle s’est simplement déplacée vers la partie du processus qui n’avait jamais été touchée.

Écrire du code a toujours été la véritable contrainte pour une équipe qui livre des logiciels, quelle que soit l’échelle, ce qui explique pourquoi, historiquement, on consacrait autant de temps à la planification et aux spécifications avant de commencer la mise en œuvre. L’IA a supprimé cette contrainte. Ce qu’elle n’a pas touché, ce sont les tâches qui l’entourent : s’assurer que la modification a été révisée correctement, que la bonne personne a donné son accord, et que ce qui est en cours de développement est suffisamment bien spécifié pour que sa réalisation soit effectivement la bonne étape suivante

Ça se manifeste à trois niveaux, généralement dans cet ordre.

1. La file d’attente de révision. Plus il y a de code qui circule, plus il y a de pull requests qui atterrissent chez les mêmes réviseurs, qui étaient déjà à pleine capacité. La charge de travail d’un ingénieur senior peut facilement doubler, voire tripler, alors qu’une grande partie de ce code a été écrit par un modèle plutôt que par un collègue à qui il pourrait aller poser une question.
2. Les validations. Dès que la file d’attente s’engorge, les équipes commencent à chercher des moyens d’accélérer le processus. Une partie de cette pression est salutaire, car elle permet de rationaliser un processus vraiment lent. Mais une autre partie sape discrètement la validation elle-même, qui devient un simple tampon apposé sur un document que personne n’a réellement lu attentivement.
3. Spécifications. Un agent ne peut travailler qu’à partir de ce qu’on lui donne. Un ticket vague qu’un ingénieur humain aurait clarifié lors d’une petite discussion de couloir a tendance à être mis en œuvre à la lettre, ambiguïtés comprises. Les équipes produit et ingénierie se rendent compte qu’elles dépendent désormais de la qualité des spécifications comme jamais auparavant, car il n’y a plus personne pour combler discrètement les lacunes.

Ce qu’il faut mettre en place avant que ça empire

Point clé : la solution, ce n’est pas d’ajouter des processus partout. C’est de définir où une décision humaine est réellement nécessaire et de s’assurer que l’ingénierie ne soit pas la seule fonction à avoir son mot à dire. 

Rien de tout ça n’est inévitable. C’est le signe qu’il manque quelques éléments structurels spécifiques, et ça vaut le coup de les mettre en place de manière réfléchie plutôt que d’attendre que le backlog nous y oblige.

• Détermine où une décision humaine est réellement nécessaire. Toutes les modifications ne nécessitent pas le même niveau de contrôle. Un processus qui achemine les modifications à faible risque vers une revue allégée et réserve une attention particulière à tout ce qui touche à la production, aux données ou au comportement vis-à-vis des clients permet de faire avancer le backlog sans baisser la barre là où ça compte.
• Donne un sens précis à l’approbation. Une approbation qui n’est pas liée à une vérification bien définie — est-ce que ça correspond au cahier des charges ? Est-ce que ça passe les tests qui comptent ? — n’est qu’un nom sur un dossier, pas une vraie décision. Ça vaut le coup d’être clair sur ce qu’un réviseur confirme réellement quand il approuve quelque chose.
• Mets la qualité des spécifications au même niveau que celle du code. Si un agent doit développer directement à partir d’un ticket, celui-ci doit présenter la clarté qu’un développeur humain fournissait autrefois de manière informelle. Ça remplace une conversation qui se déroulait autrefois en coulisses par une conversation qui doit désormais se faire par écrit.
• Implique les personnes qui n’écrivent pas le code. C’est là que la plupart des équipes s’arrêtent. La structure de révision et d’approbation décrite ci-dessus a tendance à être conçue pour les ingénieurs, par les ingénieurs, et les équipes produit, conception et sécurité finissent par être ajoutées après coup, si tant est qu’elles le soient. Un processus qui ne transmet les décisions qu’aux ingénieurs passe complètement à côté des contrôles qui auraient permis de repérer une spécification qui n’aurait jamais dû être livrée, ou une modification qui nécessitait une validation de sécurité qu’elle n’a jamais obtenue.

Ce qu’on a tendance à oublier

Point clé à retenir : ajouter plus de revues aggrave le backlog, ça ne l’améliore pas. Les équipes qui gèrent bien ça transmettent les décisions à la bonne personne, elles ne font pas plus de revues.

Quand une équipe s’en rend compte, son premier réflexe est d’ajouter encore plus de revues. Plus de réviseurs, plus d’approbations obligatoires, plus de processus. En général, ça ne fait qu’aggraver le backlog, car ça crée des frictions partout au lieu d’acheminer les décisions vers ceux qui devraient vraiment les prendre.

Les équipes qui gèrent bien ça ne font pas plus de revues. Elles acheminent mieux les décisions : l’ingénierie s’occupe des décisions d’ingénierie, le produit s’occupe des décisions produit, la sécurité s’occupe des décisions de sécurité, et aucune d’entre elles n’attend dans la même file derrière les autres. Ça ne marche que si le processus lui-même comprend la différence, plutôt que de traiter chaque changement comme une validation d’ingénierie par défaut.

Regarde la démo de Dispatch pour voir comment la plateforme fonctionne concrètement, depuis un ticket reçu jusqu’à une modification déployée, avec tous les points de décision en cours de route.

Foire aux questions (FAQ)

Pourquoi les outils de codage basés sur l’IA ont-ils ralenti les revues au lieu de les accélérer ? 
Ils n’ont pas ralenti les revues. Ils ont augmenté le volume de code à réviser sans augmenter la capacité de l’équipe à le faire, ce qui revient au même.

Est-ce qu’augmenter le nombre de revues de code est la bonne solution pour ce goulot d’étranglement ? 
Pas à elle seule. Augmenter la capacité de revue sans changer la façon dont les décisions sont acheminées ne fait généralement que déplacer le backlog au lieu de le résorber. La solution la plus durable consiste à acheminer chaque type de décision vers la personne qui devrait réellement la prendre.

Pourquoi les spécifications sont-elles plus importantes aujourd’hui qu’avant ? 
Parce qu’un développeur humain travaillant à partir d’un ticket flou comble les lacunes grâce à son jugement et à la discussion. Un agent travaillant à partir du même ticket construit presque exactement ce qui est écrit, ambiguïtés comprises. La qualité des spécifications, qui était auparavant corrigée de manière informelle, doit désormais être explicite.

Qui, à part les ingénieurs, devrait participer à la validation des modifications générées par l’IA ? 
Celui ou celle qui détient le pouvoir de décision, celui ou celle que la modification concerne réellement. L’équipe Produit pour le comportement vis-à-vis des utilisateurs, la sécurité pour tout ce qui touche à l’accès ou aux données, et le design pour tout ce qui concerne l’expérience utilisateur. Faire passer toutes les décisions par l’ingénierie par défaut, c’est passer à côté des contrôles qui comptent le plus pour chacun de ces domaines.