La revue de code à l’ère de l’IA

• L’IA n’a pas supprimé la revue de code ; au contraire, elle clarifie la charge de la preuve
• Il faut déployer les changements en joignant des preuves comme une vérification manuelle ou des tests automatisés, puis utiliser la revue pour identifier les risques, l’intention et la responsabilité
• Alors que les développeurs individuels s’appuient sur l’automatisation pour suivre la vitesse de l’IA, les équipes construisent un contexte partagé et un sens des responsabilités via la revue
• Sans preuve de fonctionnement dans la PR, il ne s’agit pas d’un déploiement plus rapide mais simplement d’un déplacement du travail vers l’aval ; seuls les développeurs dotés d’un système de validation réussissent le développement à grande vitesse avec l’IA
• Le goulot d’étranglement de la revue de code s’est déplacé de l’écriture du code vers le fait de prouver que cela fonctionne ; l’IA accélère les tâches mécaniques, mais la responsabilité reste humaine

Évolution de la revue de code à l’ère de l’IA

• Début 2026, plus de 30 % des développeurs seniors déploient majoritairement du code généré par l’IA ; l’IA excelle pour esquisser des fonctionnalités, mais expose davantage aux vulnérabilités, avec notamment 75 % d’erreurs logiques en plus sur la logique, la sécurité et les edge cases
• Les développeurs solo livrent rapidement grâce à la vitesse d’inférence (inference speed) et utilisent leur suite de tests comme filet de sécurité, tandis que les équipes conservent une revue humaine pour le contexte et la conformité
• Bien utilisés, les deux s’en servent comme accélérateur IA, mais la différence dépend de qui valide quoi, et à quel moment
• Si vous n’avez pas vérifié vous-même que le code fonctionne, alors il ne fonctionne pas vraiment
  • L’IA ne fait que renforcer cette règle ; elle n’en dispense pas

Manières dont les développeurs utilisent l’IA dans la revue

• Contrôle LLM ad hoc : avant un commit, coller un diff dans Claude, Gemini ou GPT pour repérer rapidement bugs ou problèmes de style
• Intégration dans l’IDE : utiliser des outils comme Cursor, Claude Code ou Gemini CLI pour des suggestions inline et du refactoring pendant le développement
• Bots de PR et scanners : utiliser GitHub Copilot ou des agents personnalisés pour signaler automatiquement des problèmes potentiels dans les PR, tout en complétant avec des outils d’analyse statique et dynamique comme Snyk pour la sécurité
• Boucle de tests automatisés : générer et exécuter des tests avec l’IA, et définir plus de 70 % de couverture comme condition de merge
• Revue multi-modèles : faire examiner le code par plusieurs LLM pour détecter les biais propres à chaque modèle (par ex. génération avec Claude, audit avec un modèle spécialisé sécurité)

Développeur solo vs équipe : comparaison

• Développeur solo
  • Axe de revue : tests automatisés + vérifications ponctuelles limitées
  • Compromis sur la vitesse : rapidité du temps d’inférence, correction des problèmes via des boucles itératives
  • Outil clé : tests agentiques (ex. boucle Claude Code)
  • Principe : le prouver soi-même (Prove it yourself)
• Équipe
  • Axe de revue : examiner le contexte et la sécurité avec un jugement humain
  • Compromis sur la vitesse : garder de petites PR pour éviter le goulot d’étranglement de la revue
  • Outil clé : combinaison de bots et de politiques (ex. labellisation des PR générées par IA)
  • Principe : partager la preuve avec l’équipe (Share the Proof)

Développeur solo : livrer à la “vitesse d’inférence”

• Les développeurs solo ont tendance à faire confiance à la “vibe” du code généré par l’IA, à ne vérifier que les parties essentielles et à livrer rapidement des fonctionnalités en laissant les tests détecter les problèmes
• Ils ont tendance à traiter les agents de code comme de puissants stagiaires capables de gérer seuls de vastes refactorings
• Déclaration de Peter Steinberger : « Je ne lis plus beaucoup de code. Je regarde le flux, et je ne vérifie qu’occasionnellement les parties critiques »
• Le goulot d’étranglement du développement n’est plus la saisie, mais le temps d’inférence (l’attente de la sortie de l’IA)
• Point d’attention : sans tests solides, le gain de vitesse perçu disparaît
  • Sauter la revue ne supprime pas le travail ; cela revient à le repousser plus loin
  • La clé d’un développement rapide réussi avec l’IA n’est pas la confiance aveugle, mais la mise en place d’un système de validation
• Les développeurs solo responsables utilisent des tests automatisés étendus comme filet de sécurité, avec un objectif de plus de 70 % de couverture
• Les tests indépendants du langage et pilotés par les données jouent un rôle décisif
  • Si les tests sont suffisants, l’agent peut générer, corriger et valider l’implémentation indépendamment du langage
  • Au démarrage d’un projet, l’IA rédige un brouillon de spec.md, puis après validation, répète une boucle rédaction → test → correction
• Même les développeurs solo effectuent à la fin des tests manuels et un jugement critique
  • Ils exécutent eux-mêmes l’application, cliquent dans l’UI et utilisent la fonctionnalité
  • Si le niveau de risque est élevé, ils lisent davantage de code et ajoutent des validations supplémentaires
  • Même en développant vite, ils nettoient le code désordonné dès qu’ils le repèrent
• Principe fondamental : la mission du développeur est de livrer du code dont il a lui-même prouvé le bon fonctionnement

Équipe : l’IA déplace le goulot d’étranglement de la revue

• Dans un environnement d’équipe, l’IA est une aide puissante pour la revue de code, mais ne peut pas remplacer le jugement humain nécessaire à la qualité, à la sécurité et à la maintenabilité
• Quand plusieurs ingénieurs collaborent, le coût des erreurs et la durée de vie du code deviennent des facteurs bien plus importants
• Beaucoup d’équipes utilisent des bots de revue IA au début du cycle de PR, mais l’approbation finale reste humaine
• Déclaration de Greg Foster chez Graphite : « Il n’y aura pas d’agent IA qui remplace l’approbation de PR par un véritable ingénieur humain »
• Le plus grand problème concret n’est pas que les relecteurs IA ratent des questions de style, mais que l’IA augmente le volume de code et transfère la charge de revue vers les humains
  • Avec l’adoption croissante de l’IA, la taille des PR a augmenté d’environ 18 %
  • Les incidents par PR ont augmenté d’environ 24 %
  • Le taux d’échec des changements a augmenté d’environ 30 %
• Si la vitesse de production dépasse la capacité de validation, le processus de revue devient le facteur limitant du flux de développement
• Déclaration de Foster : « Déployer du code qu’aucun pair humain n’a lu ou compris est un risque majeur »
• En équipe, comme l’IA produit de gros volumes de sortie, il faut adopter un mode de développement incrémental et découper la sortie de l’agent en commits révisables
• L’approbation finale humaine ne disparaît pas ; elle évolue au contraire pour se concentrer sur les domaines que l’IA manque
  (alignement roadmap, contexte organisationnel et institutionnel que l’IA ne perçoit pas)

Sécurité : les vulnérabilités prévisibles de l’IA

• La sécurité est un domaine où le jugement humain est absolument indispensable
• Des défauts de sécurité sont trouvés dans environ 45 % du code généré par l’IA
• Le taux d’erreurs logiques est 1,75 fois plus élevé que dans le code écrit par des humains
• La fréquence des vulnérabilités XSS est 2,74 fois plus élevée
• Au-delà des problèmes du code lui-même, les outils agentiques et les IDE intégrés à l’IA créent de nouvelles surfaces d’attaque
  • prompt injection, fuite de données, vulnérabilités RCE
• Puisque l’IA élargit la surface d’attaque, une approche hybride est efficace
  • l’IA signale les problèmes, l’humain effectue la validation finale
• Règle : pour le code qui touche à l’authentification, au paiement, aux secrets ou aux entrées non fiables,
  il faut traiter l’IA comme un stagiaire très rapide, et imposer avant merge une revue humaine du modèle de menace et des contrôles via outils de sécurité

Transmission de connaissances via la revue

• La revue de code est un moyen central pour l’équipe de partager le contexte système
• Si l’IA a écrit le code mais que personne ne peut l’expliquer, le coût de l’astreinte augmente
• Soumettre du code généré par l’IA que personne ne comprend vraiment fait s’effondrer le mécanisme de transmission des connaissances qui assure la résilience de l’équipe
• Si l’auteur ne peut pas expliquer pourquoi le code fonctionne, l’ingénieur d’astreinte ne pourra pas déboguer à 2 h du matin
• Cas d’un mainteneur OCaml ayant rejeté une PR de 13 000 lignes générée par l’IA
  • La qualité du code n’était pas forcément mauvaise, mais il manquait la bande passante de revue pour évaluer un changement de cette taille
  • La revue de code généré par l’IA impose une charge cognitive plus forte que celle de code écrit par un humain
• Leçon : l’IA peut produire de grandes quantités de code, mais les équipes doivent maîtriser la taille des changements pour éviter un goulot d’étranglement de revue

Comment utiliser les outils de revue IA

• L’expérience utilisateur vis-à-vis des outils de revue IA est très partagée
• Côté positif : dans certains cas, ils capturent plus de 95 % des bugs tels que les exceptions de pointeur nul, les trous de couverture de tests ou les anti-patterns
• Côté négatif : certains développeurs perçoivent les commentaires de revue IA comme de simples observations génériques sans valeur, un « bruit textuel »
• Leçon : les outils de revue IA demandent une configuration attentive
  • ajustement de la sensibilité, désactivation des types de commentaires peu utiles, définition de politiques d’opt-in et d’opt-out claires
• S’ils sont bien configurés, les relecteurs IA peuvent capturer 70 à 80 % des problèmes faciles, laissant aux humains l’architecture et la logique métier
• Beaucoup d’équipes recommandent des PR petites et empilables, même si l’IA peut générer d’énormes changements d’un seul coup
• Commiter fréquemment les changements et gérer chaque modification comme une unité autonome avec un message clair dans des commits/PR séparés
• Les équipes maintiennent des frontières nettes de responsabilité humaine
• Quel que soit le niveau de contribution de l’IA, la responsabilité finale revient à l’humain
• Maxime pédagogique d’IBM : « Un ordinateur ne pourra jamais être tenu responsable. La responsabilité appartient à l’humain dans la boucle »

Le contrat de PR : l’obligation de l’auteur envers le relecteur

• Que l’on travaille seul ou en équipe, une bonne pratique commune consiste à traiter le code généré par l’IA comme un brouillon utile qui doit être validé
• Il existe un cadre simple que les équipes les plus performantes utilisent en commun

• Éléments du contrat de PR

  1/. What/Why : résumer en 1 ou 2 phrases l’intention et la raison du changement
  2/. Preuve de fonctionnement : résultats de tests réussis et étapes de validation manuelle (captures d’écran, logs)
  3/. Risque + rôle de l’IA : indiquer le niveau de risque du changement et la part générée par l’IA (ex. fonctionnalité de paiement = risque élevé)
  4/. Focus de revue : désigner 1 ou 2 zones nécessitant un examen humain (ex. architecture)
• Il ne s’agit pas de bureaucratie, mais d’un dispositif pour respecter le temps du relecteur et clarifier la responsabilité de l’auteur
• Si vous n’êtes pas capable d’écrire cela, c’est que vous ne comprenez pas encore assez votre changement pour demander son approbation à quelqu’un d’autre

Principes clés

• Exiger des preuves, pas des promesses : prendre comme base du « code qui fonctionne », demander aux agents IA d’exécuter le code ou les tests unitaires après génération, vérifier les preuves comme les logs, captures d’écran ou résultats, et ne pas soumettre de PR sans nouveaux tests ni démonstration de fonctionnement
• Utiliser l’IA comme premier relecteur, pas comme arbitre final : traiter la sortie de revue IA comme un avis, faire écrire le code par une IA et le faire relire par une autre, laisser l’humain arbitrer la direction des corrections ; la revue IA doit être au niveau d’un correcteur orthographique, pas d’un éditeur
• Concentrer la revue humaine sur ce que l’IA rate : vérifier l’introduction de vulnérabilités de sécurité, les doublons avec le code existant (défaut fréquent de l’IA), la maintenabilité de l’approche ; l’IA filtre les problèmes simples et l’humain prend les décisions difficiles
• Appliquer un développement incrémental : découper le travail en petites unités pour qu’elles soient faciles à générer par l’IA et à relire par un humain, utiliser de petits commits avec des messages clairs comme points de contrôle, et ne jamais commiter du code qu’on est incapable d’expliquer
• Maintenir des standards de test élevés : les développeurs qui tirent efficacement parti des agents de code conservent de solides pratiques de test et demandent à l’IA de proposer des brouillons de tests afin de générer des tests d’edge cases que les humains oublient facilement

Perspectives : le goulot d’étranglement se déplace

• L’IA fait évoluer la revue de code d’un contrôle ligne par ligne vers une gestion de la qualité de plus haut niveau, mais le jugement humain reste un élément de sécurité indispensable
• Il s’agit d’une évolution du workflow, pas de la disparition de la revue de code
• Le périmètre de la revue ne couvre plus seulement le diff de code, mais aussi la conversation ou le plan entre l’IA et l’auteur
• Le rôle du relecteur humain se rapproche de plus en plus de celui d’un éditeur ou d’un architecte, centré sur les décisions importantes tout en laissant les contrôles routiniers à l’automatisation
• Pour les développeurs solo, la suite est passionnante, mais même avec toujours plus d’outils, les développeurs avisés continuent de « faire confiance, mais vérifier »
• Dans les grandes équipes, on peut s’attendre à un renforcement de la gouvernance IA
  • formalisation de politiques sur la contribution de l’IA et exigence d’une approbation attestant qu’un employé a bien relu
  • apparition de rôles tels que « auditeur de code IA »
  • évolution des plateformes d’entreprise vers un meilleur support du contexte multi-référentiels et de l’application de politiques personnalisées
• Le principe central ne change pas : la revue de code garantit que le logiciel répond aux exigences, est sûr, robuste et maintenable
• L’IA ne change pas ce fondement ; seule la manière d’y parvenir évolue
• Le goulot d’étranglement du développement se déplace de l’écriture du code vers le fait de prouver qu’il fonctionne
• Les excellents relecteurs de code à l’ère de l’IA acceptent ce changement, tout en laissant l’IA accélérer les tâches mécaniques sans relâcher la ligne de responsabilité
• L’IA peut accélérer (accelerate) le processus, mais elle ne doit pas permettre d’abdiquer (abdicate) la responsabilité
• Les ingénieurs accordent de plus en plus d’importance à « la preuve plutôt qu’à la vibe (proof over vibes) »
• La revue de code n’a pas disparu ; elle évolue vers un rôle plus stratégique
• Qu’il s’agisse d’un développeur solo qui déploie à 2 h du matin ou d’un lead d’équipe qui approuve un changement critique de système, un fait demeure : la responsabilité finale du résultat produit par l’IA incombe à l’humain
• Adoptez l’IA, mais gardez l’habitude de revérifier le travail