Livrer du code que personne n'a relu ?

Oui, une équipe pourra livrer du code sans qu'un humain ait inspecté chaque ligne. Elle ne pourra pas le faire en renonçant au contrôle. Elle devra au contraire prouver que la modification répond au besoin, respecte les règles du produit et peut être annulée sans mettre les clients en danger. La lecture ligne par ligne reste utile sur les zones sensibles. Elle ne peut plus porter seule la confiance lorsque l'IA produit du code plus vite que l'équipe ne peut le relire.

En 2021, j'ai rejoint une scale-up dont les solutions étaient utilisées chaque jour par des dizaines de milliers de personnes. Certains de ses clients s'appelaient McDonald's, Disney, SNCF ou Total. Chaque ligne que je produisais était revue et challengée par plusieurs développeurs. J'ai réalisé un changement en une journée. Il a ensuite fallu plus d'une semaine et plusieurs cycles de revue pour le fusionner et le rendre disponible sur l'environnement de staging, la version de test avant la production.

Au début, ça m'agaçait. Puis j'ai compris ce que ce délai achetait : une compréhension partagée du changement et une probabilité plus faible de casser un produit déjà utilisé à grande échelle. Ce process correspondait au risque. Mais si un agent peut maintenant produire plusieurs modifications pendant qu'un développeur en examine une, appliquer exactement la même méthode finit par déplacer le problème. Le code attend dans une file de revue et l'attention humaine s'épuise.

La lecture ligne par ligne ne suffit plus

Une revue de code remplit plusieurs fonctions à la fois. Elle cherche des erreurs, transmet de la connaissance et vérifie que la solution correspond aux pratiques de l'équipe. Elle permet aussi à une deuxième personne de comprendre ce qui va entrer en production. C'est beaucoup demander à une seule étape.

Tant que produire du code coûtait cher, la lecture exhaustive restait possible. Le volume de changements était limité par le temps disponible pour les écrire. Les agents ont cassé cet équilibre. Ils peuvent explorer plusieurs pistes, générer les tests et modifier des dizaines de fichiers avant que le responsable ait fini son café. Le coût de production baisse. Celui de la compréhension ne suit pas la même courbe.

Charity Majors pousse cette idée assez loin : l'IA demande davantage de discipline d'ingénierie, pas moins. Elle rappelle aussi que le cerveau humain n'est pas particulièrement doué pour les validations répétitives. Après quelques centaines de lignes, le relecteur reconnaît des formes familières. Il ne prouve pas que les permissions sont justes, que la facturation restera cohérente ou que la migration conservera les données.

Lire reste utile. Confondre lecture et preuve devient dangereux. Une modification peut paraître propre tout en répondant au mauvais besoin. À l'inverse, un changement peu élégant peut être correct, couvert par des tests solides et sans conséquence durable. La revue doit donc commencer par le comportement attendu et le niveau de risque, pas par la première ligne du premier fichier.

Le danger est le code que personne ne sait expliquer

« Personne n'a lu chaque ligne » et « personne ne comprend ce changement » ne décrivent pas la même situation. La première peut devenir acceptable. La seconde ne l'est pas.

Quand un agent ouvre une pull request de 1 500 lignes, c'est-à-dire une proposition de modification du produit, sa taille attire immédiatement l'attention. Le vrai danger apparaît lorsque personne ne peut raconter son parcours : quelle décision produit l'a déclenchée, quelles données changent, quels clients peuvent être touchés et comment l'équipe détectera une erreur. Sans cette carte, la revue ressemble à une visite d'entrepôt dans le noir. On inspecte des cartons sans savoir ce qui devait être livré.

Ce manque de compréhension finit par coûter au business. Les pull requests s'accumulent parce que les développeurs expérimentés deviennent le goulot d'étranglement. Les validations se font plus vite en fin de journée, juste pour vider la file. Puis un incident arrive et l'équipe découvre que l'auteur humain ne maîtrise pas davantage le changement que ses collègues. Le temps gagné pendant la génération est alors payé pendant le diagnostic.

La responsabilité ne peut pas rester chez l'agent. Une personne doit pouvoir expliquer l'intention, les effets visibles et les risques acceptés. Elle n'a pas besoin de réciter le code. Elle doit savoir pourquoi cette modification mérite d'exister et quelles preuves autorisent sa mise en production.

C'est aussi une question de continuité. Si la compréhension reste enfermée dans une conversation avec Claude Code ou Cursor, elle disparaît avec la session. Le dépôt conserve le résultat, mais pas la décision. Pour garder cette compréhension, l'équipe transforme le contexte en critères d'acceptation, tests, description de pull request et signaux observables en production.

Construire une chaîne de preuves avant la fusion

Je commence par comprendre la modification. Ensuite seulement, je cherche les défauts et je vérifie le comportement avec des contrôles exécutables. Tout faire en même temps produit des revues longues, fatigantes et difficiles à transmettre.

J'ai créé explain-pr-changes, un skill open source à récupérer directement sur GitHub, pour le premier passage. Un skill est une procédure versionnée qui explique à un agent comment accomplir une tâche. Celui-ci récupère la description, les fichiers modifiés et le diff complet, puis reconstruit l'intention, l'ancien parcours, le nouveau parcours, les contrats touchés et les tests qui définissent le comportement. Il reste volontairement en lecture seule et ne cherche pas les bugs. Son rôle est de transformer un mur de code en carte du changement.

Cette lecture sémantique ne valide rien. Elle donne au responsable un point de départ pour poser de meilleures questions. Est-ce que la modification touche l'authentification ? Change-t-elle la forme d'une donnée ? Introduit-elle un appel externe ou une migration ? Le développeur peut alors concentrer son attention sur les branches qui portent le risque au lieu de parcourir chaque fichier avec la même intensité.

Une fois la modification comprise, un agent peut chercher les régressions, les problèmes de sécurité ou les écarts avec les conventions du dépôt. Mais il ne doit pas être le seul à valider le résultat. La documentation de GitHub sur la revue de code par Copilot reconnaît que l'outil peut manquer des problèmes ou produire de faux positifs. La revue humaine reste nécessaire sur les décisions métier et les zones sensibles.

Les contrôles automatiques apportent ensuite des preuves reproductibles. Les tests vérifient les scénarios métier connus. Le typage, le contrôle des erreurs courantes et l'analyse de sécurité attrapent les problèmes répétitifs. Les règles du dépôt empêchent une fusion si un contrôle obligatoire échoue. GitHub permet d'associer modèles de pull request, responsables de zones, branches protégées et contrôles automatiques pour que ces exigences ne dépendent pas de la mémoire du relecteur.

La dernière preuve vient de la production. Un déploiement progressif, des logs exploitables et une possibilité de retour arrière limitent le coût d'une erreur qui aurait traversé les contrôles précédents. Comme je l'explique dans mon article sur l'observabilité, surveiller un système ne consiste pas seulement à savoir qu'il fonctionne. Il faut pouvoir comprendre ce qui arrive lorsqu'il se comporte autrement que prévu.

Décider ce que l'humain doit encore relire

Toutes les modifications ne méritent pas le même niveau de contrôle. Forcer deux développeurs à lire ligne par ligne une correction de texte générée par un agent ne protège pas l'entreprise. Laisser ce même agent modifier seul les permissions ou la facturation revient à prendre un risque difficile à justifier.

Cette grille ne mesure pas le nombre de lignes. Une modification de dix lignes sur une règle de facturation peut exiger plus d'attention qu'une migration mécanique de cinquante fichiers. Le niveau de contrôle dépend de ce que l'entreprise peut perdre : de l'argent, des données, un contrat ou la confiance d'un client.

Pour un dirigeant, demander « quelqu'un a-t-il tout relu ? » ne suffit plus. Demandez aussi qui comprend le changement, quelles preuves montrent qu'il fonctionne et ce qui se passera s'il échoue. Si les réponses tiennent uniquement dans « les tests sont verts », le cadre est trop faible. Des tests écrits par le même agent à partir d'une mauvaise interprétation peuvent valider parfaitement la mauvaise chose.

Une équipe peut réduire progressivement la lecture exhaustive lorsque son système de preuves devient crédible. Elle commence sur des changements petits et réversibles. Elle observe les retours en revue, les corrections après fusion et les incidents. Elle élargit ensuite le périmètre, sans donner la même autonomie aux modifications sensibles. C'est ce type de cadre que je mets en place pour encadrer l'usage de l'IA dans une équipe lors d'une mission de CTO part-time.

Ce qu'il faut retenir

Oui, du code pourra arriver en production sans qu'un humain ait inspecté chaque ligne. Cela ne signifie ni supprimer la revue humaine ni déléguer la responsabilité à un agent. L'équipe doit conserver une compréhension partagée de l'intention, des effets et des risques.

La confiance se déplace vers une chaîne de preuves : lecture sémantique du changement, revue ciblée selon le risque, tests métier, contrôles bloquants, déploiement réversible et observation en production. Plus la conséquence d'une erreur est grave, plus l'intervention humaine reste profonde.

Questions fréquentes

Faut-il relire chaque ligne de code générée par IA ?

Pas pour toutes les modifications. Une équipe peut alléger la lecture exhaustive sur un changement faible risque, bien testé et facile à annuler. Les paiements, les permissions, la sécurité et les migrations de données exigent encore une inspection humaine ciblée et approfondie.

Une IA peut-elle faire seule la revue du code qu'elle a produit ?

Non. Elle peut résumer le changement ou chercher une première catégorie de défauts, mais elle peut partager la même mauvaise compréhension que l'agent qui a écrit le code. Un humain doit rester responsable de l'intention métier et des risques acceptés.

Comment commencer sans fragiliser la production ?

Commencez avec de petites modifications réversibles. Exigez une description du comportement, des tests métier, des contrôles automatiques bloquants et un suivi après déploiement. Étendez l'autonomie seulement lorsque les résultats montrent que les reprises et les incidents n'augmentent pas.

Conclusion

Réservez un échange de 30 minutes pour définir le niveau de contrôle adapté à votre produit et intégrer les agents de développement sans transformer la revue en goulot d'étranglement.