J'ai récemment eu une discussion avec un collègue autour d'un constat qui nous dérangeait tous les deux : les développeurs et les développeuses n'ont jamais produit autant de code. Et pourtant, bien des équipes ne livrent pas plus de valeur qu'avant. Il m'a fallu un moment pour mettre le doigt sur ce qui m'agaçait vraiment dans cette situation. Ce n'est pas l'IA le problème. C'est ce qu'on a abandonné pour lui faire de la place.
Ça fait plus de vingt ans qu'une partie de notre industrie investit pour rapprocher les humains qui construisent du logiciel. Dès 2001, le manifeste Agile posait que le dialogue en face à face est la méthode la plus efficace pour transmettre l'information, la même année où le terme shift left faisait son apparition. Pair programming, mob programming, revues de code en continu : ce ne sont pas toutes les équipes qui ont adopté ces pratiques. Elles demandaient un effort réel et le télétravail les avait déjà fragilisées.
Mais les équipes qui avaient fait cet investissement en récoltaient les fruits : moins de silos, une connaissance qui circule, des problèmes détectés tôt. Puis l'IA est arrivée et, en quelques mois, ces mêmes équipes ont vu chaque personne retourner dans son coin avec son assistant personnel. Les silos qu'elles avaient mis des années à défaire sont revenus. Personne ne nous a forcés à ça. On l'a fait nous-mêmes.
Je veux être clair dès le départ : ceci n'est pas un article contre l'IA. Je l'utilise tous les jours et je ne reviendrais pas en arrière. C'est un article sur un réflexe humain qui me fascine autant qu'il m'inquiète : celui de jeter des pratiques éprouvées dès qu'un nouvel outil arrive, sans se demander quel problème ces pratiques réglaient.
Prenons un moment pour nous rappeler pourquoi ces pratiques existaient.
Le pair et le mob programming n'ont jamais été des façons « d'écrire du code à deux ». Écrire le code, c'était la partie visible, presque anecdotique. La vraie valeur était ailleurs :
On en a déjà parlé sur ce blogue dans Pair et mob programming : pour la sécurité psychologique! et le shift left repose sur la même idée qu'on cultive entre autres dans nos Learning Hours : plus un problème est détecté tôt, moins il coûte cher à corriger.
Les données pointaient dans la même direction. Dragan Stepanović a analysé des dizaines de milliers de pull requests réparties dans une quarantaine de dépôts pour mesurer l'effet de la revue asynchrone sur le débit des équipes. Son constat : les petites PRs multiplient les interruptions et les changements de contexte, et les grosses reçoivent des reviews de surface, le fameux « Looks Good To Me 👍 » après trente secondes de revue. Il en tire une conclusion volontairement provocante : la taille optimale d'une PR serait une ligne de code, reviewée immédiatement. Autrement dit, le pairing.
Soyons nuancés : ce n'est pas de la recherche revue par les pairs et la review asynchrone fait très bien tourner l'open source, où personne ne partage le même horaire. Le signal vaut pour une équipe qui travaille ensemble tous les jours : chaque revue de code qui attend dans une file coûte du débit et du contexte. Ce n'est pas un hasard si les métriques DORA, devenues le standard pour mesurer la performance de livraison logicielle, tournent autour de ces mêmes notions : temps de cycle, débit, stabilité. Ces pratiques n'ont jamais cherché à écrire du code plus vite. Elles cherchaient à amener le travail jusqu'en production.
Gardez cette image de la file d'attente en tête. Parce que si elle coûtait déjà cher avant l'IA, imaginez ce qui arrive quand on multiplie le volume de code qui y entre.
Il y a une grille de lecture que je trouve particulièrement utile ici : la théorie des contraintes d'Eliyahu Goldratt. Tout système de production a un goulot d'étranglement, et le débit du système entier est celui de son goulot. Ce que ça implique est contre-intuitif : accélérer une étape qui n'est pas le goulot n'améliore rien. Le travail s'empile juste plus vite devant le goulot.
« Une heure gagnée à un poste qui n'est pas un goulot est un mirage. » Eliyahu Goldratt, The Goal
Depuis longtemps, écrire du code n'était plus le goulot du développement logiciel. Les données de temps de cycle le montrent : quand on mesure le flux de travail d'une équipe, le travail actif ne représente typiquement que 5 à 15 % du temps de cycle. Tout le reste, c'est de l'attente entre les étapes. Comprendre le problème, s'aligner sur une solution, valider ce qui sort : c'était ça, le goulot. L'IA vient de lever la contrainte « écrire du code »... qui n'était plus la contrainte.
On me répondra, avec raison, que l'IA n'accélère pas seulement l'écriture : elle fait aussi de la revue de code en première passe, résume les PRs, explique le code legacy. C'est vrai, et c'est réellement utile. Chez nous, plusieurs s'en servent pour faire ressortir les code smells et se donner une vue d'ensemble avant de plonger dans une review : un pied dans la porte plutôt que de partir de zéro. Mais le goulot n'a jamais été la lecture du code. C'est la compréhension partagée entre les humains de l'équipe. Une IA qui review une PR raccourcit la file d'attente; elle ne dépose la connaissance dans la tête de personne.
Chez Nexapp, un sondage interne a fait ressortir cet été des enjeux qui revenaient chez plusieurs personnes : surcharge cognitive, anxiété du changement, peur de l'atrophie des compétences. On a lancé une série de Learning Hours pour en discuter entre équipes et les observations de la session sur la charge cognitive se recoupaient toutes. Des équipes de développement qui voient passer en une journée un nombre de PRs ouvertes qu'elles n'avaient jamais vu. Des développeurs et des développeuses qui passent plus de la moitié de leur journée en review. Un collègue resté presque seul pendant les vacances a ouvert une cinquantaine de PRs en dix jours; les deux qui restaient ont dû absorber tout ça, avec des journées complètes où aucune review ne rentrait parce qu'ils avançaient leurs propres tâches.
Et pendant que ta PR attend, tu ne restes pas les bras croisés : tu fais autre chose avec ton agent. Comme le résumait un collègue : pendant que mon prompt roule, je review la PR d'un autre; mon cerveau passe de A à Y, puis revient à B. Plus de travail en cours, plus de changements de contexte, plus de charge cognitive.
Ce sentiment d'aller plus vite est d'ailleurs documenté comme trompeur. Dans un essai randomisé de METR mené auprès de développeurs et développeuses open source expérimentés sur de vraies tâches, le résultat est frappant :
Les participants étaient 19 % plus lents avec l'IA... tout en estimant avoir été 20 % plus rapides.
Les outils ont évolué depuis, et METR le précise eux-mêmes. La leçon durable est ailleurs : se sentir plus rapide n'est pas synonyme de livrer plus vite.
À l'échelle de l'industrie, les rapports DORA mesurent la même tension. En 2024, l'adoption de l'IA était associée à une baisse du débit de livraison et de la stabilité. En 2025, le débit s'est redressé, mais l'instabilité persiste. Leur lecture : les équipes se sont adaptées à la vitesse, mais leurs systèmes et leurs processus n'ont pas suivi. L'IA amplifie ce que l'équipe fait déjà, en bien comme en mal.
C'est le paradoxe qui a ouvert cet article : on n'a jamais écrit autant de code, et pourtant bien des équipes n'arrivent pas à livrer plus de valeur. L'IA n'a pas éliminé le goulot. Elle a rendu la file d'attente devant lui beaucoup plus longue, et ramené au passage les silos qu'on avait passé des années à défaire.
D'autres équipes ont réglé le goulot autrement : elles l'ont contourné. Rarement de façon assumée; peu de monde annonce fièrement avoir aboli la revue de code. La version qu'on rencontre est plus subtile : l'IA fait la revue en première passe, et l'humain se garde les points critiques. Sur papier, c'est raisonnable. La dérive commence quand la première passe devient la seule, que l'approbation se résume à un coup d'œil sur le résumé généré, et que le code passe de l'agent à la production sans qu'un cerveau humain l'ait réellement traversé.
Laissez-moi vous poser la question qui me trotte dans la tête : qu'est-ce qui est mieux, un développeur qui code sans écrire de tests, ou une IA qui code et écrit ses propres tests sans qu'un humain les valide? Et si une deuxième IA reviewait le travail de la première, est-ce qu'on serait plus avancé?
On peut pousser cette logique jusqu'aux échelles d'autonomie où l'agent choisit lui-même ses tâches et les enchaîne sans qu'un humain initie quoi que ce soit. Fait révélateur : même ceux qui définissent ces échelles préviennent que la supervision doit s'intensifier à mesure que l'autonomie monte, pas diminuer.
Soyons honnêtes : avec de bons standards et une suite de tests robuste, ce code peut très bien fonctionner. Le taux de défauts n'explose pas nécessairement. Ce qui s'accumule est plus sournois que la dette technique classique : une dette de compréhension. Chaque étape déléguée retire une paire d'yeux humains du processus. L'IA code, l'IA teste, l'IA review, et le système fonctionne... jusqu'au jour où il ne fonctionne plus. Là, pas d'explosion spectaculaire. Juste une équipe incapable de raisonner sur son propre système. Avant l'IA, le silo, c'était la connaissance coincée dans une personne. Le silo version IA est pire : la connaissance ne s'est jamais rendue dans une tête humaine.
On me dira qu'on a survécu à toutes les montées d'abstraction, que plus personne ne lit l'assembleur généré par le compilateur. Mais le code que l'IA génère n'est pas une couche d'abstraction stable et éprouvée par des millions d'utilisateurs : c'est votre code de domaine et personne d'autre ne viendra le comprendre à votre place. Et une explication à la demande n'a jamais remplacé une équipe qui comprend son système au moment où la production brûle.
L'aviation vit avec ce paradoxe depuis quarante ans. Le pilote automatique fait voler l'avion pendant la croisière, mais ce sont encore des humains qui décollent, qui atterrissent et qui répondent du vol. Et c'est précisément quand les cockpits se sont automatisés, au début des années 80, que l'industrie a instauré ses pratiques de coordination d'équipage et documenté les « ironies de l'automatisation » (Bainbridge, 1983) : plus le système est autonome, plus la vigilance humaine devient critique et plus les compétences manuelles s'atrophient si on ne les entretient pas. Cette peur de l'atrophie, nos développeurs et développeuses l'ont nommée telle quelle dans notre sondage interne. Elle n'a rien d'irrationnel : c'est un phénomène documenté chez les pilotes.
Conseil : L'humain garde la responsabilité de ce qu'il livre. Les standards et les tests réduisent le risque de défaut, mais ils ne transfèrent ni la responsabilité ni la compréhension à la machine. Si personne dans l'équipe ne peut expliquer un morceau de code en production, ce morceau de code est un risque, peu importe qu'il passe les tests.
Il serait facile de mettre ça sur le dos de la paresse ou de l'engouement. Je pense que la vraie raison est plus intéressante : on avait confondu ces pratiques avec leur résultat visible.
Si vous pensez que le pair programming sert à écrire du code à deux, alors l'IA le rend effectivement obsolète. Elle écrit le code plus vite que n'importe quel binôme. Mais si vous savez que le pairing sert à créer de la compréhension partagée, à reviewer en continu et à faire circuler la connaissance dans l'équipe, alors l'IA ne le remplace pas du tout, parce qu'elle ne fait rien de tout ça. Le code n'était que le sous-produit. La compréhension partagée était le produit.
Autrement dit, on n'a pas abandonné des pratiques devenues inutiles. On a abandonné des pratiques qu'on n'avait jamais complètement comprises. Et je m'inclus là-dedans : il a fallu que je voie les silos revenir pour réaliser à quel point ces cérémonies portaient quelque chose de plus gros que le code qu'elles produisaient.
La bonne nouvelle, c'est que ce diagnostic pointe directement vers la solution. Si la fonction de ces pratiques reste nécessaire, il suffit de changer leur forme.
Chez Nexapp, certaines équipes avaient une pratique qu'on appelait l'Architecture Plan, bien avant l'IA. Avant de coder une tâche, les développeurs et les développeuses se réunissaient au tableau blanc pour dessiner ce qui devait être ajouté, retiré ou modifié, parfois sous forme de diagramme UML, parfois directement dans le code sous forme d'interfaces et de fonctions vides. Un backlog refinement agile, mais au niveau du code. On raffinait le plan technique pour faire sortir les inconnus et les bloquants, et pour décider si un refactor était nécessaire avant de commencer. Le plan se faisait en équipe; l'implémentation, en solo. L'effet le plus visible était sur les revues de code : elles devenaient beaucoup plus rapides, parce que les reviewers connaissaient déjà l'intention.
Avec l'IA, cette pratique n'a pas perdu sa raison d'être. Elle en a gagné une nouvelle. Un exemple vécu : pour une grosse migration de données de Firebase vers une base SQL, un de nos développeurs a monté avec l'IA un plan complet en plusieurs étapes, puis l'a présenté aux collègues qui allaient le reviewer, avant d'écrire une seule ligne de code. Ils ont regardé le découpage ensemble : ce qui s'en venait dans chaque étape, ce qu'ils auraient divisé autrement. L'implémentation a ensuite produit sept ou huit PRs.
Le résultat observé : des reviews beaucoup plus rapides que sur un gros chantier précédent qui n'avait pas eu droit à ce traitement. Les reviewers savaient déjà ce que chaque PR venait faire; il restait à vérifier le comment. La réflexion avait déjà été faite, et elle avait été faite ensemble.
C'est la boucle complète de cet article : le goulot de la revue de code, résolu non pas en enlevant la review, mais en la déplaçant plus tôt, sur le plan plutôt que sur le code. Le shift left appliqué à l'ère des agents. En prime, un plan exprimé en étapes claires, voire en interfaces et en fonctions vides, est exactement le genre de contrainte structurelle qui empêche un agent de dériver pendant l'implémentation.
Le même raisonnement s'applique ailleurs, et nos équipes expérimentent plusieurs formes en ce moment :
Un collègue a résumé le principe mieux que je n'aurais su le faire :
« Si tu demandes de l'attention humaine, il faut que tu démontres de l'effort humain. »
Parce que soyons francs sur les coûts : ces pratiques se paient en temps synchrone d'équipe, la denrée la plus chère qu'on a. Un Architecture Plan, c'est une rencontre avant la tâche. Une mob review, c'est une heure à plusieurs. Mais ce n'est pas du temps ajouté à l'horaire : c'est celui qu'on brûlait déjà en allers-retours de commentaires, en reviews recommencées et en décisions d'architecture contestées trop tard. On le dépense juste plus tôt, et ensemble. Une règle simple aide d'ailleurs à garder l'équilibre : si le reviewer passe plus de temps sur une PR que son auteur n'en a mis, quelque chose ne va pas en amont.
Je ne prétends pas que ces formes précises sont les bonnes pour toutes les équipes. Le point, c'est la démarche : identifier la fonction que la pratique remplissait, puis trouver la forme qui remplit cette fonction dans une équipe où l'IA écrit la majorité du code.
G.K. Chesterton racontait qu'avant de retirer une clôture qui semble inutile, il faut d'abord comprendre pourquoi quelqu'un l'a construite. Nos pratiques de développement sont ces clôtures. Elles ont l'air de simples rituels, jusqu'à ce qu'on les enlève et que le problème qu'elles contenaient revienne s'installer.
L'IA ne sera pas le dernier outil à bouleverser nos façons de travailler. La prochaine fois qu'un outil vous donnera envie de laisser tomber une pratique, posez-vous la question avant de la jeter : quel problème cette pratique réglait-elle? Si le problème a disparu, jetez-la sans remords. Mais si le problème est toujours là, gardez la fonction et changez la forme. Sinon, vous ne faites que retirer la clôture.
L'IA n'a pas tué nos bonnes pratiques. Elle nous a offert une excuse commode pour retomber dans nos vieux réflexes et on l'a saisie. La sortie de crise ne passe ni par moins d'IA, ni par un retour nostalgique aux cérémonies d'avant. Elle passe par des pratiques repensées pour que la compréhension partagée survive à l'automatisation. Nos équipes ont mis dix ans à apprendre que le développement logiciel, c'est humain. Ce serait dommage de désapprendre ça en dix mois.