De développeur à gestionnaire : diriger une équipe de codeurs IA

Une question d’un client

Un client m’a posé cette question hier : « Depuis que je code avec des agents, est-ce que ça vaut encore la peine de centraliser mon code ? Et est-ce que ça vaut encore la peine de réviser chaque ligne ? »

Question légitime. Quand un agent peut renommer un symbole dans 400 fichiers en 12 secondes, on pourrait conclure que la duplication ne coûte plus rien et qu’on peut relâcher le DRY. Et réviser chaque ligne que l’agent écrit ? Ça, clairement, ça ne tient plus la route passé la deuxième pull request.

Mais j’ai poussé back sur la première moitié. Le DRY compte encore, voire plus qu’avant. Les agents écrivent plus vite, ce qui veut dire qu’ils propagent aussi plus vite la même erreur de design : le même bug se retrouve cloné à sept endroits avant le dîner, le même helper à moitié correct se retrouve dupliqué dans trois modules. La duplication sauvage casse toujours la maintenabilité. La seule chose qui a changé, c’est comment on fait respecter le DRY : pas en lisant le diff, mais en le mesurant.

Ce que Uncle Bob vient d’admettre

Le timing était troublant. La veille de cette rencontre, Uncle Bob — l’auteur de Clean Code, celui qui a bâti sa carrière sur l’artisanat logiciel — avait publié ceci sur X :

« Je ne révise plus le code écrit par les agents. Je mesure des choses comme la couverture de tests, la structure des dépendances, la complexité cyclomatique, la taille des modules, le mutation testing, etc.

On peut inférer beaucoup sur la qualité du code à partir de ces métriques. Le code lui-même, je le laisse à l’IA.

Les humains sont lents à écrire du code. Pour être productifs, nous, les humains, devons nous détacher du code et gérer depuis un niveau plus haut. »

Quand la personne qui a littéralement écrit le livre sur la révision de code arrête de réviser le code, c’est que quelque chose a basculé.

Ce que j’ai dit au client

Ma réponse a été simple : puisqu’on n’est plus hands-on dans le code — exactement ce que décrit Uncle Bob — il faut compenser avec des métriques. Beaucoup de métriques.

• Mesurer, pas lire. Brancher un SonarQube, ou un équivalent. Exiger une couverture de tests au-dessus de 98 %. Suivre la complexité cyclomatique. Surveiller la taille des modules. Rouler du mutation testing. Les métriques attrapent ce que vos yeux survolent désormais.
• Faire respecter le DRY avec une métrique de duplication. Exactement le point d’Uncle Bob : ne pas lire pour trouver la duplication, la mesurer. Sonar rapporte un ratio de lignes dupliquées, PMD/CPD signale le copier-coller entre fichiers. Fixer un seuil dur dans le CI. Les agents sont assez rapides pour cloner le même snippet dans une dizaine de fichiers avant que quiconque s’en rende compte, et chaque clone est un bug futur à corriger N fois au lieu d’une.
• Poser des questions pointues. « Pourquoi cette classe fait 400 lignes ? Qu’est-ce qui casse si j’enlève cette couche ? Où est le test qui prouve le cas limite ? » L’agent répond honnêtement quand on le confronte, mais ne signale presque jamais la faiblesse de lui-même.
• Posséder l’architecture. L’agent produit du code. Vous possédez les dépendances entre modules, les bounded contexts, la forme du domaine, ce qui appartient ou non à ce service. C’est là que le jugement humain compose encore.

Analogie bonus : on gère maintenant une équipe offshore

Voici le modèle mental sur lequel je reviens tout le temps — je ne l’ai pas partagé avec le client, mais je pense qu’il donne toute sa netteté à l’exercice.

Travailler avec un agent de code, c’est comme gérer une équipe de développement offshore. L’agent est rapide, infatigable, empressé de plaire — et un peu sycophante. Il ne vous dira jamais, sans qu’on lui demande, que l’architecture qu’il vient de produire est un fouillis. Il ne va jamais pousser back sur une exigence qui n’a pas de sens. Il va joyeusement ajouter une septième couche d’indirection parce que vous avez vaguement demandé de la « flexibilité ».

On ne gère pas ce genre d’équipe en lisant chaque commit. On la gère en posant les bonnes questions, en imposant des quality gates non négociables, et en faisant plus confiance aux chiffres qu’au feeling. C’est exactement pour ça que les métriques ci-dessus cessent d’être un « nice to have » et deviennent le métier lui-même.

La nouvelle boucle

Le quotidien ressemble moins à écrire du code et plus à ceci :

1. Définir le changement voulu, en termes de comportement et de contraintes architecturales.
2. Laisser l’agent produire le diff.
3. Regarder les métriques, pas le diff — couverture, complexité, frontières de modules, graphe de dépendances.
4. Là où une métrique se dégrade, poser une question pointue à l’agent et lui faire corriger son propre travail.
5. Répéter jusqu’à ce que les métriques soient au vert et que l’architecture ait encore du sens.

Vous êtes plus lent que l’agent pour le code. Mais l’agent est plus lent que vous pour le jugement. Passez votre temps là où votre avantage se trouve.

Conclusion

Le DRY compte encore. La centralisation compte encore. La revue de code compte encore. Ce qui a changé, c’est comment on fait respecter tout ça : pas en lisant chaque ligne, mais en mesurant. L’artisanat n’a pas disparu ; il a juste monté d’un étage. On est passés d’écrire le code à piloter l’équipe qui l’écrit. Ceux qui vont prospérer dans les prochaines années sont ceux qui vont apprendre à bien gérer.