La revue de code exhaustive est peut-être devenue le nouveau travail administratif des développeurs.
Le raisonnement traditionnel paraît pourtant irréprochable.
Une intelligence artificielle produit le code. Un humain relit chaque ligne. Il vérifie la syntaxe, les conventions, les appels de fonctions, les structures de données et les commentaires. Ensuite seulement, le code peut être accepté.
Cette méthode rassure les responsables techniques. Elle protège les habitudes. Elle donne surtout l’impression que l’humain conserve le contrôle.
Puis arrive un problème très concret : le volume.
Antirez pose une question volontairement provocatrice : comment un développeur pourrait-il relire sérieusement 5 000 lignes de code générées chaque jour ?
Le temps consacré à cette inspection est nécessairement retiré à une autre activité : conception, architecture, sécurité, performance, compréhension du besoin, expérience utilisateur ou recherche des conditions de rupture. (Antirez)
L’IA ne supprime donc pas le travail. Elle révèle les activités dont nous avions mal défini la valeur.
Le code accélère, l’organisation ralentit
Les outils d’assistance au développement permettent déjà de produire certaines fonctions beaucoup plus rapidement.
Dans une expérience contrôlée menée par GitHub auprès de 95 développeurs professionnels, le groupe utilisant Copilot a terminé une tâche de programmation 55 % plus rapidement en moyenne que le groupe sans Copilot.
Ce résultat porte sur un exercice précis et ne peut pas être automatiquement généralisé à tous les projets, mais il illustre clairement l’accélération possible de la production. (GitHub)
Or une chaîne de production ne devient pas plus performante simplement parce que l’une de ses machines accélère.
Si le code est généré cinq fois plus vite, mais que les revues, les validations de sécurité, les tests et les mises en production fonctionnent toujours selon les anciens rythmes, le gain individuel se transforme en embouteillage collectif.
Les travaux de DORA montrent précisément cette tension.
Dans les données étudiées, une augmentation de 25 % de l’adoption de l’IA était associée à une baisse de 1,5 % du débit de livraison et de 7,2 % de la stabilité.
DORA avance notamment l’explication de lots de changements plus volumineux, plus longs à examiner et plus susceptibles de déstabiliser le système. (DORA)
Voilà le paradoxe : les développeurs peuvent avoir le sentiment d’aller plus vite tandis que l’organisation livre moins efficacement.
L’IA amplifie ici une faiblesse ancienne.
Beaucoup d’entreprises mesurent encore l’activité logicielle à travers le nombre de lignes produites, de tickets terminés, de fonctionnalités développées ou de demandes de fusion soumises.
Quand la production devient abondante, ces indicateurs récompensent le volume qui finit par saturer le reste du système.
La revue exhaustive donne une illusion de maîtrise
Relire chaque ligne semble être une méthode rigoureuse.
Pourtant, la rigueur ne consiste pas à consacrer la même attention à chaque détail.
Une faute dans une fonction d’affichage, une erreur dans un système d’autorisation et une incohérence dans un algorithme de calcul financier ne portent pas le même risque.
Les traiter avec un effort identique revient à confondre égalité de traitement et qualité du contrôle.
Les pratiques de revue publiées par Google recommandent de commencer par une vision globale du changement.
Le changement est-il pertinent ?
Est-il correctement décrit ?
Est-il cohérent avec la direction générale du système ?
Le reviewer doit ensuite examiner les parties les plus importantes et les problèmes de conception avant de parcourir le reste du changement.
Une faiblesse architecturale majeure peut rendre inutile l’analyse détaillée de nombreuses lignes qui devront de toute façon être réécrites. (Google Engineering Practices)
Google rappelle également que l’objectif principal d’une revue consiste à améliorer progressivement la santé globale du code, pas à atteindre une perfection abstraite sur chaque modification.
Les données et les faits techniques doivent l’emporter sur les préférences personnelles. (Google Engineering Practices)
La revue ligne par ligne peut facilement dériver vers des débats de style, de nommage ou de préférence personnelle tandis que des interrogations beaucoup plus importantes restent sans réponse.
Le logiciel répond-il au bon problème ?
Le modèle de données est-il cohérent ?
Le système continuera-t-il à fonctionner sous une charge dix fois supérieure ?
Les autorisations sont-elles contrôlées à tous les points critiques ?
Une défaillance partielle peut-elle contaminer tout le service ?
Le changement duplique-t-il une fonction déjà présente ailleurs ?
La revue exhaustive devient alors une cérémonie de contrôle.
Elle produit beaucoup de commentaires visibles, sans nécessairement concentrer l’attention sur les risques décisifs.
Contrôler les idées avant de contrôler la syntaxe
L’approche proposée par Antirez consiste à contrôler les idées contenues dans le logiciel plutôt que de considérer le code comme le seul objet intellectuel du développeur.
Cette proposition ne signifie pas que le code devient sans importance.
Elle suggère une hiérarchie différente du contrôle.
Un système logiciel est d’abord une représentation d’un problème et d’une solution.
Le code matérialise cette représentation dans un langage exécutable.
Une implémentation élégante d’un mauvais modèle reste un mauvais logiciel.
Le premier niveau de contrôle doit donc porter sur le design.
Pourquoi cette architecture a-t-elle été choisie ?
Quelles autres options ont été étudiées ?
Où sont placées les responsabilités ?
Quels compromis ont été acceptés entre simplicité, performance, coût, sécurité et évolutivité ?
Quelles dépendances externes deviennent critiques ?
Quelles décisions seront difficiles à inverser ?
Une IA peut produire des milliers de lignes localement cohérentes tout en construisant progressivement un système globalement incohérent.
Le développeur expérimenté apporte ici quelque chose que le modèle ne possède pas nécessairement : l’histoire du produit, les incidents passés, les contraintes opérationnelles, les usages réels des clients, les compromis déjà refusés et les risques spécifiques à l’organisation.
Cette connaissance contextuelle devient une partie centrale du travail.
Définir les invariants du système
Le deuxième niveau consiste à formaliser les invariants.
Un invariant est une propriété qui doit rester vraie, quelles que soient les modifications apportées au logiciel.
Un compte bancaire ne doit pas créer spontanément de l’argent.
Un utilisateur ne doit pas accéder aux données d’un autre utilisateur sans autorisation.
Une commande payée ne doit pas redevenir impayée à cause d’une répétition de message.
Une opération rejouée après une panne ne doit pas provoquer un doublon.
Une mise à jour partielle ne doit pas laisser les données dans un état contradictoire.
Ces propriétés décrivent mieux la qualité du système qu’une inspection uniforme de sa syntaxe.
L’équipe doit donc demander à l’IA de produire du code, mais également de proposer des tests destinés à attaquer ces invariants.
Elle doit chercher les cas limites, les séquences improbables, les problèmes de concurrence, les erreurs de permission, les dépassements de capacité et les états intermédiaires.
Le rôle humain consiste à déterminer ce qui doit absolument rester vrai.
La machine peut ensuite aider à multiplier les tentatives pour démontrer que cette propriété pourrait devenir fausse.
Remplacer la lecture exhaustive par une validation multicouche
Une gouvernance plus mature du code généré par IA peut s’appuyer sur plusieurs couches complémentaires.
La première est la validation fonctionnelle.
Le logiciel accomplit-il réellement ce qui a été demandé ?
La deuxième est la validation des cas limites.
Que se passe-t-il avec une donnée absente, une valeur maximale, une réponse lente, une interruption réseau ou deux opérations simultanées ?
La troisième est la validation comparative.
L’implémentation peut-elle être comparée à une version de référence, à une bibliothèque reconnue ou à un calcul indépendant ?
La quatrième est la validation de performance.
Comment évoluent la consommation de mémoire, le temps de réponse, les coûts d’infrastructure et la stabilité lorsque le volume augmente ?
La cinquième est la validation de sécurité.
Les dépendances, les entrées, les permissions, les secrets, les flux de données et les configurations doivent être examinés avec des outils spécialisés et des audits proportionnés au risque.
Le Secure Software Development Framework du NIST recommande d’intégrer explicitement les pratiques de sécurité au cycle de développement, car de nombreux modèles de développement ne les traitent pas suffisamment par défaut. (NIST)
L’automatisation ne justifie donc pas une confiance aveugle.
Elle permet plutôt de déplacer une partie du contrôle humain vers la conception des mécanismes de validation.
Un code lisible peut rester dangereux
L’un des risques les plus intéressants du code généré par IA est son apparence de propreté.
Un code bien présenté, correctement nommé et abondamment commenté inspire facilement confiance.
Cette fluidité visuelle peut masquer une faiblesse de raisonnement, une permission oubliée, une condition de concurrence ou une mauvaise compréhension d’une API.
Une étude empirique portant sur 733 extraits attribués à plusieurs assistants de programmation a identifié des faiblesses de sécurité dans 29,5 % des extraits Python et 24,2 % des extraits JavaScript analysés.
Les auteurs précisent la méthode et les limites de leur échantillon, qui ne permettent pas de transformer ces résultats en taux universels pour tout code généré.
Ils montrent néanmoins que la correction fonctionnelle apparente et la sécurité sont deux sujets distincts. (arXiv)
GitHub alerte également sur plusieurs comportements à surveiller dans les demandes de fusion générées par des agents : affaiblissement des contrôles d’intégration continue, suppression ou contournement de tests, duplication de fonctions existantes et code qui passe les tests tout en restant logiquement incorrect dans certaines situations.
GitHub indique que son système de revue Copilot avait déjà traité plus de 60 millions de revues et que plus d’une revue sur cinq sur la plateforme impliquait alors un agent.
Ces chiffres proviennent de GitHub et décrivent son propre écosystème, mais ils donnent une indication de l’échelle atteinte. (GitHub)
Le bon réflexe ne consiste donc pas à admirer la propreté du code.
Il consiste à rechercher les endroits où cette propreté pourrait dissimuler une erreur de modèle.
Documenter le logiciel comme un ensemble d’idées
Antirez propose une autre évolution importante : consacrer davantage de temps à une documentation conceptuelle qui décrit les structures de données, les choix d’architecture, les astuces d’implémentation et les compromis.
Cette documentation ne remplace pas le code.
Elle donne au lecteur le modèle mental nécessaire pour l’interroger.
Un fichier de conception correctement maintenu devrait expliquer :
- l’objectif du composant ;
- son rôle dans le système global ;
- les principales décisions d’architecture ;
- les invariants à respecter ;
- les risques connus ;
- les compromis retenus ;
- les scénarios de défaillance ;
- les éléments qui nécessitent une validation humaine ;
- les zones dans lesquelles une modification est particulièrement dangereuse.
Une personne arrivant sur le projet peut alors comprendre les intentions avant de se perdre dans les détails.
Une IA peut également utiliser cette documentation comme contexte pour produire des modifications plus cohérentes.
Le code décrit comment le système fonctionne aujourd’hui.
La documentation conceptuelle explique pourquoi il fonctionne ainsi et quelles propriétés doivent survivre à ses prochaines transformations.
Le développeur devient ingénieur de systèmes
Cette évolution déplace la valeur professionnelle.
La frappe rapide au clavier perd de son importance relative.
La compréhension du problème, la capacité de modélisation, l’esprit critique, la connaissance du domaine, l’architecture, la formulation des contraintes et la construction de boucles de validation deviennent plus précieux.
Le développeur ne disparaît pas.
Son activité monte d’un niveau d’abstraction.
Il devient la personne capable de :
- transformer un besoin ambigu en problème structuré ;
- choisir les bons compromis techniques ;
- distinguer une optimisation locale d’une amélioration globale ;
- définir les invariants ;
- concevoir les tests capables de mettre le système en difficulté ;
- interpréter les résultats ;
- repérer une architecture qui dérive ;
- organiser le travail de plusieurs agents ;
- décider où l’audit humain reste indispensable.
Le sondage Stack Overflow 2025 rappelle néanmoins que la confiance reste limitée.
Quarante-six pour cent des développeurs interrogés déclaraient se méfier de l’exactitude des outils d’IA, contre 33 % qui leur faisaient confiance.
Les développeurs les plus expérimentés figuraient parmi les plus prudents. (Stack Overflow)
Cette prudence peut devenir productive à condition de ne pas se transformer en relecture mécanique de tout ce qui est généré.
Les débutants ont encore besoin de comprendre le code
Le déplacement du contrôle vers les idées pose un problème particulier pour les développeurs débutants.
Comment évaluer une architecture sans avoir rencontré de mauvaises architectures ?
Comment reconnaître une erreur subtile sans comprendre l’exécution du programme ?
Comment définir un invariant sans expérience des défaillances ?
Comment contrôler une IA sans disposer d’un modèle mental du langage, des structures de données, du système d’exploitation ou du réseau ?
L’apprentissage de la programmation reste donc essentiel.
Écrire soi-même un interpréteur simple, une table de hachage, un serveur, une base de données miniature ou un ordonnanceur apporte une compréhension que la simple approbation de code généré ne produit pas automatiquement.
La formation doit toutefois évoluer.
Demander à un débutant de relire passivement des milliers de lignes générées pourrait être moins utile que lui demander de prédire le comportement d’un système, de formuler ses invariants, de créer des tests contradictoires, d’identifier une mauvaise abstraction et d’expliquer pourquoi une solution échoue.
Le futur développeur devra apprendre à écrire du code et à juger les systèmes qui en produisent.
Les nouveaux KPI du développement
Quand le code devient abondant, compter les lignes produites perd encore davantage de sens.
Les entreprises pourraient suivre des indicateurs plus proches de la valeur réelle :
- le temps nécessaire pour transformer une hypothèse en résultat validé ;
- la proportion de changements qui provoquent un incident ;
- le nombre de défauts découverts après la mise en production ;
- la durée nécessaire pour comprendre et modifier un composant ;
- la quantité de logique dupliquée ;
- la qualité des tests sur les risques critiques ;
- le temps de récupération après une défaillance ;
- l’évolution de la dette architecturale ;
- le coût d’exploitation par transaction ou par utilisateur ;
- la capacité du système à évoluer sans réécriture majeure.
Ces indicateurs déplacent l’attention de l’activité visible vers les résultats obtenus.
Une équipe qui produit moins de lignes, mais construit un système plus simple, plus fiable et plus facile à faire évoluer, crée probablement davantage de valeur qu’une équipe qui alimente en permanence une immense file de revues.
Une innovation de procédé, pas seulement un nouvel outil
Cette mutation illustre directement l’innovation de procédé décrite dans mon livre.
L’IA augmente la vitesse de certaines tâches, mais son effet le plus intéressant apparaît lorsque l’organisation repense entièrement la manière de les exécuter.
Ajouter un générateur de code à un processus inchangé produit surtout plus de code dans les mêmes tuyaux.
Redéfinir le design, les responsabilités, la validation, la documentation et les indicateurs transforme le système de production logiciel lui-même.
J’aborde cette application de l’intelligence artificielle dans mon livre, chapitre 14.
Le saut de performance ne viendra donc pas uniquement d’un modèle capable de coder plus vite.
Il viendra d’une gouvernance capable de contrôler les idées, de tester les résultats et d’auditer les risques.
Dans cette nouvelle organisation, le code devient une matière produite en abondance.
La rareté se déplace vers le jugement, le contexte, la responsabilité et la capacité à concevoir un système juste.
Votre organisation évalue-t-elle encore la qualité d’un développeur au volume de code qu’il produit, ou aux systèmes fiables qu’il sait faire émerger ?
Je démonte volontiers les anciens KPI du travail intellectuel dans mes conférences, ateliers et accompagnements, généralement avant qu’ils ne deviennent des pièces de musée.
Références
- (Antirez) = https://antirez.com/news/169
- (DORA) = https://dora.dev/ai/gen-ai-report/report/
- (GitHub — productivité) = https://github.blog/news-insights/research/research-quantifying-github-copilots-impact-on-developer-productivity-and-happiness/
- (GitHub — revue des agents) = https://github.blog/ai-and-ml/generative-ai/agent-pull-requests-are-everywhere-heres-how-to-review-them/
- (Google Engineering Practices — navigation) = https://google.github.io/eng-practices/review/reviewer/navigate.html
- (Google Engineering Practices — standard) = https://google.github.io/eng-practices/review/reviewer/standard.html
- (NIST) = https://csrc.nist.gov/pubs/sp/800/218/final
- (arXiv) = https://arxiv.org/abs/2310.02059
- (Stack Overflow) = https://survey.stackoverflow.co/2025/ai
