Revue de code

Comment ça marche

La revue de code est une pratique ancienne : avant d’intégrer un changement, un autre développeur le relit. Les agents de code rendent cette pratique indispensable, parce qu’ils produisent beaucoup, vite, et avec une assurance qui ne garantit rien. Un agent peut écrire du code propre qui fait autre chose que ce qu’on voulait, ou ajouter une dépendance inutile, ou laisser une clé d’accès dans un fichier.

La revue se fait en deux temps. Une première passe automatisée : un second modèle, ou le même avec une consigne de relecteur, parcourt le changement et signale les erreurs classiques, les risques de sécurité, les écarts avec la demande. Puis une relecture humaine, centrée sur ce qui compte : est-ce bien ce qu’on voulait, et est-ce qu’on en comprend les conséquences. L’outil de gestion de versions garde la trace de chaque changement et permet de l’annuler.

Un exemple concret

1. La demande : ajouter une remise de 5 % pour les clients qui règlent sous 10 jours.
2. Le changement proposé : 140 lignes dans 4 fichiers, avec des tests qui passent.
3. La passe automatisée signale que la remise s’applique aussi aux avoirs, ce que personne n’avait demandé, et qu’une bibliothèque a été ajoutée pour arrondir les montants alors que le projet en avait déjà une.
4. La relecture humaine confirme les deux points, et repère que la date de paiement est comparée à la date de facture et non à la date d’échéance, comme le voulait le métier.
5. Retour à l’agent avec les trois corrections. Deuxième version acceptée en cinq minutes.

Les tests passaient dès la première version. Ils testaient ce que l’agent avait compris, pas ce que le métier voulait. C’est pour ça que la revue existe.

Ce que ça change pour une équipe

• On peut aller vite sans perdre le contrôle. L’agent produit, la revue filtre. Le rythme reste élevé et les erreurs ne vont pas en production.
• La connaissance ne se perd pas. Relire, c’est comprendre. Une équipe qui relit ce que l’agent produit sait comment ses outils fonctionnent ; une équipe qui accepte tout ne le sait plus.
• Les règles se codifient. Les remarques récurrentes des revues deviennent des consignes pour l’agent, dans le fichier de consignes ou dans des hooks. La revue suivante est plus courte.
• La responsabilité est claire. Celui qui accepte le changement en répond. Ce n’est pas l’IA.

Les limites et les erreurs fréquentes

• La revue de complaisance. Tout accepter parce que les tests passent et que le code a l’air propre. Le code peut être propre et faux.
• Relire trop gros. Un changement de 2 000 lignes ne se relit pas. Demander à l’agent de travailler par petits pas, chacun relu.
• Faire relire par le même modèle avec la même consigne. Il retrouvera les mêmes angles morts. Un autre modèle, ou une consigne de relecteur sévère, change le regard.
• Oublier la sécurité. Secrets, permissions, dépendances, entrées non vérifiées : ce sont les points que l’IA néglige le plus souvent, et que la revue doit chercher en priorité.