Une équipe qui code avec des agents : ce qui change dans la revue, les tests et les accès

---

title: "Une équipe qui code avec des agents : ce qui change dans la revue, les tests et les accès" seoTitle: "Coder avec des agents : revue, tests, accès" description: "Quand chaque développeur pilote un ou deux agents, le volume de code produit double ou triple en une semaine. La revue devient le goulot, les tests perdent leur valeur de preuve et la question des accès cesse d'être théorique. Voici ce qu'une équipe de deux à cinq personnes doit changer pour continuer à livrer un produit dont elle répond." seoDescription: "Revue, tests et accès quand ce sont des agents qui écrivent le code : ce qu'une équipe de deux à cinq personnes doit changer pour continuer à livrer." date: "2026-09-30" author: "Équipe Raicode" tags: ["IA", "développement", "qualité", "architecture"] category: "IA & Automatisation" keywords: ["coder avec des agents IA", "revue de code IA", "tests code généré par IA", "accès agent IA dépôt", "Claude Code en équipe", "sécurité agent de codage", "qualité code généré", "équipe développement IA"]

Le basculement ne se voit pas le jour où l'équipe adopte un agent de codage. Il se voit trois semaines plus tard, quand la personne qui relit les pull requests le lundi matin en trouve onze au lieu de trois, que chacune fait entre 400 et 900 lignes, et qu'aucune ne contient d'erreur évidente. Tout compile, tout est testé, tout est cohérent. Et pourtant la relectrice met deux heures par PR au lieu de vingt minutes, parce qu'elle ne peut plus s'appuyer sur ce qui rendait la revue rapide : deviner l'intention de l'auteur.

C'est le vrai changement. Le coût d'écrire du code s'est effondré ; le coût de le comprendre, non. Une équipe de trois développeurs qui pilotent chacun un ou deux agents produit le volume d'une équipe de dix, avec la capacité de relecture de trois. Si rien d'autre ne change, le goulot se déplace simplement d'un cran, et la qualité se dégrade à l'endroit exact où personne ne regarde. Ce qui suit est ce qu'on voit fonctionner dans des équipes de deux à cinq personnes qui livrent un vrai produit à de vrais clients — pas un programme de transformation, trois changements de process.

Le code plausible n'est pas le code compris

Un développeur pressé écrit du code approximatif qui a l'air approximatif. Les noms sont bâclés, la structure trahit l'hésitation, le commentaire « TODO: vérifier ça » est resté. Ces signaux sont précieux : ils indiquent au relecteur où poser les yeux.

Un agent écrit du code uniformément propre. Les noms sont bons, la structure est cohérente, les cas d'erreur sont gérés, les commentaires sont pertinents. Rien ne signale la partie où il a comblé un trou de spécification par une supposition. Le bug de tenant leak et la fonction utilitaire parfaite ont exactement la même apparence.

Deuxième effet, plus insidieux : la question « pourquoi as-tu fait ça comme ça ? » n'a plus de réponse fiable. Vous pouvez la poser à l'agent, il produira une justification convaincante — construite après coup, à partir du code, sans accès à ce qui s'est réellement passé pendant la génération. La revue de code repose depuis trente ans sur un dialogue entre deux personnes qui ont toutes les deux un modèle mental du système. Quand l'une des deux n'existe pas, il faut reconstruire ce modèle ailleurs.

La revue : relire des décisions, pas des lignes

Le réflexe qui ne marche pas est d'essayer de relire plus vite. À volume triplé, une équipe qui garde la même revue dilue son attention et finit par approuver au jugé.

La règle qui structure tout le reste : celui qui a piloté l'agent est l'auteur. Pas « l'agent a écrit ça, dis-moi si c'est bon » — mais « voilà ce que j'ai écrit, avec l'aide d'un agent ». En pratique, cela veut dire qu'avant d'ouvrir la PR, la personne a relu l'intégralité du diff, a supprimé ce qu'elle ne comprend pas ou ne veut pas défendre, et sait expliquer chaque décision non triviale. Ce test — « peux-tu expliquer cette partie sans relire le fichier ? » — est le filtre le plus efficace que nous connaissions. Il coûte vingt minutes à l'auteur et en économise deux heures au relecteur. Une équipe qui ne le tient pas ne fait pas de la revue de code, elle fait de la relecture de sortie de modèle.

Deuxième règle : la taille de la PR est un choix, pas une conséquence. Un agent produira volontiers 900 lignes d'un coup parce que rien ne l'en empêche. C'est à l'humain de borner le périmètre en amont — une PR, un changement, une intention. Concrètement, on découpe la demande avant de lancer l'agent, pas le diff après. Trois PR de 200 lignes se relisent en quarante minutes ; une PR de 900 lignes ne se relit pas, elle s'approuve.

Troisième règle : la revue se hiérarchise. Tout le diff n'a pas la même valeur. Sur les projets que nous reprenons, la répartition qui tient est celle-ci :

• Lecture ligne à ligne, systématique : tout ce qui touche à l'authentification et aux autorisations, à l'isolation entre clients, à l'argent (facturation, quotas, compteurs d'usage), aux migrations de schéma, et à toute opération destructive ou non réversible. Ce sont les endroits où une erreur ne se rattrape pas en production.
• Lecture d'architecture : les frontières entre modules, les signatures publiques, les dépendances ajoutées. Un agent ajoute une bibliothèque sans état d'âme ; c'est vous qui la maintiendrez trois ans.
• Lecture rapide, appuyée sur les tests : le reste — écrans, formatage, transformations de données, appels d'API internes.

Cette hiérarchie n'est pas nouvelle. Ce qui est nouveau, c'est qu'elle devient obligatoire : sans elle, l'attention se répartit uniformément sur un diff trois fois plus gros, et la partie critique reçoit trois fois moins de vigilance qu'avant. Les défauts que cela laisse passer sont exactement ceux que nous décrivions dans ce qu'il faut reprendre dans un MVP codé par IA — à ceci près qu'en équipe, ils arrivent plus vite et se diluent dans un historique que plus personne ne relit.

Les tests : qui détient la vérité quand la machine écrit aussi les tests

C'est le point où le plus d'équipes se font avoir, et il est simple à énoncer : un test écrit par l'agent qui a écrit le code ne prouve rien. Il décrit le comportement obtenu, pas le comportement voulu. Si l'agent a mal compris la règle métier, il l'a mal comprise deux fois — dans l'implémentation et dans l'assertion — et le test passe au vert en confirmant l'erreur.

Le symptôme est facile à reconnaître : la couverture monte à 85 %, la suite compte 600 tests, et les bugs remontés par les clients ne sont jamais couverts. Ce n'est pas un problème de quantité. La couverture de code, déjà médiocre comme indicateur, devient franchement trompeuse quand elle est gratuite à produire.

Trois pratiques rétablissent la valeur de preuve :

L'assertion vient de l'humain. Pour toute règle métier qui a une conséquence — un calcul de prix, un droit d'accès, une limite d'usage, une règle de facturation — c'est un humain qui écrit l'énoncé du test avant de lancer l'agent : « pour un compte au forfait Pro ayant consommé 4 800 crédits sur 5 000, une requête de 300 crédits doit être refusée avec l'erreur quota_exceeded, et aucun crédit ne doit être débité ». L'agent implémente et fait passer. L'inversion de l'ordre est tout le sujet : la vérité est posée avant, par quelqu'un qui répond du produit.

Des jeux de données réels, figés. Une poignée de cas issus de la production — anonymisés — stockés comme fixtures, avec la sortie attendue validée une fois par un humain. Les agents excellent à faire passer des tests unitaires et échouent beaucoup plus souvent sur des données vraies, qui contiennent les valeurs nulles, les encodages bizarres et les cas limites que personne n'imagine. C'est encore plus vrai pour tout ce qui touche à un LLM en production : le jeu d'évaluation ne vaut que si personne ne peut soupçonner qu'il a été fabriqué pour passer.

Une vérification croisée bon marché. Avant d'approuver une PR sur du code critique, on casse volontairement une ligne de l'implémentation et on relance la suite. Si rien ne rougit, le test ne teste rien. L'opération prend deux minutes et détecte la majorité des tests tautologiques. Les outils de mutation testing automatisent cela, mais le geste manuel sur trois ou quatre fonctions sensibles suffit largement à l'échelle d'une petite équipe.

Les accès : le périmètre qu'on ouvre, et celui qu'on n'ouvre pas

Un agent de codage est un processus qui lit votre dépôt, exécute des commandes et sort sur le réseau, avec les droits de la session qui l'héberge. La question n'est pas de savoir s'il est malveillant — il ne l'est pas. C'est de savoir ce qui se passe le jour où il se trompe, ou le jour où le contenu qu'il lit contient des instructions qui ne viennent pas de vous : une issue GitHub, une dépendance, un fichier de données client. Le mécanisme est celui de la prompt injection que nous décrivions pour les LLM exposés aux clients, appliqué cette fois à un processus qui a accès à votre code et à votre shell.

Le périmètre minimal qui tient, pour une équipe qui livre un SaaS :

• Aucun accès à la production, jamais. Pas de DATABASE_URL de prod dans l'environnement de l'agent, pas de clé API de production, pas de console d'admin. L'agent travaille sur une base de développement remplie de données générées ou anonymisées. Une réplique en lecture seule est acceptable quand il faut vraiment reproduire un comportement, jamais l'instance primaire.
• Des identifiants distincts et révocables. Une clé par agent ou par développeur, jamais le compte de service partagé. Quand quelque chose part de travers, vous voulez pouvoir couper une clé sans arrêter l'équipe, et savoir a posteriori laquelle a fait quoi.
• Les secrets hors du contexte. Le fichier d'environnement est exclu de ce que l'agent lit, et le scan de secrets tourne en CI sur chaque PR. Un secret qui passe dans un contexte d'agent doit être traité comme divulgué : rotation, pas discussion.
• Le dépôt protégé par la CI, pas par la discipline. Branche main protégée, pas de push direct, pas de force-push, revue humaine obligatoire. L'agent ouvre des PR ; il ne merge pas. Cette règle-là n'a rien de spécifique à l'IA, mais elle passe du statut de bonne pratique à celui de garde-fou indispensable dès que le volume de commits triple.
• Les outils connectés, un par un. Un serveur MCP qui expose votre base de données, votre outil de ticketing ou votre plateforme de déploiement élargit le rayon d'action de l'agent d'un coup. Chaque connexion se juge à la question : qu'est-ce que cet outil peut détruire ou divulguer dans son pire cas ? Nous avons détaillé ces arbitrages dans ce que change réellement la connexion d'un LLM aux outils métier ; en contexte de développement, la réponse par défaut est lecture seule, et l'écriture s'ouvre au cas par cas.

Ce qui ne se délègue pas

Il reste un petit noyau de décisions dont un humain répond, quel que soit le volume produit à côté. Ce n'est pas une position de principe sur les capacités des modèles : c'est une question de coût du rattrapage.

Le modèle de données et les migrations. Un mauvais schéma se paie pendant des années et ne se corrige pas par une PR. C'est la décision la plus structurante d'un produit, et la seule dont l'erreur se propage à tout le reste.

Les frontières d'isolation. Qui voit quoi. Sur un SaaS multi-tenant, c'est la faute qui vous coûte votre première fuite de données entre clients — et c'est précisément le type d'erreur qu'un agent commet sans le signaler, parce que le code fonctionne parfaitement tant qu'un seul client l'utilise. Nous l'avons vu sur plusieurs reprises de projets : la requête oublie le filtre sur l'identifiant de compte, les tests passent parce que la base de test ne contient qu'un compte, et le bug se révèle au deuxième client.

Les chemins de l'argent. Facturation, quotas, remboursements, compteurs d'usage. Une erreur ici ne casse rien visiblement ; elle vous fait facturer faux pendant six mois.

La décision de livrer. Personne ne merge parce que la CI est verte. Quelqu'un merge parce qu'il a compris ce qui part en production.

Le reste — écrans, intégrations, transformations, scripts, tests de non-régression, refactorings mécaniques — se délègue très bien, et c'est justement là que le gain de vitesse est réel. Distinguer les deux ensembles est le travail d'arbitrage qui remplace, pour un lead technique, le temps qu'il passait à écrire ce code lui-même. C'est aussi l'exercice que nous menons en premier quand nous intervenons sur la reprise d'un projet IA : établir quelles parties du système personne dans l'équipe ne sait plus expliquer.

Le rythme réel d'une équipe de trois

Pour donner une échelle concrète. Une équipe de trois développeurs qui applique ces règles produit, dans une semaine typique, quelque chose comme quinze à vingt PR au lieu de six à huit. Le temps de revue par personne passe d'environ trois heures à cinq ou six — il augmente, il ne s'effondre pas, parce que la hiérarchisation compense en partie le volume. Le gain net se situe autour de 40 à 60 % de vélocité sur les parties déléguables, et de zéro sur le noyau critique, qui avance exactement à la même vitesse qu'avant.

C'est un résultat moins spectaculaire que ce que promettent les pages d'offre sur le sujet, et beaucoup plus solide. L'équipe qui annonce 3× de vélocité globale a presque toujours arrêté de relire quelque chose, et la facture arrive plus tard, sous forme de dette technique qu'elle n'a pas choisie — la seule qui coûte vraiment cher.

Par où commencer cette semaine

Si vous devez ne changer qu'une chose, changez la règle d'auteur : celui qui lance l'agent relit tout le diff avant d'ouvrir la PR et sait le défendre. Elle ne coûte rien à mettre en place et elle rend visible, dès la première semaine, la part de code que votre équipe ne comprend pas.

Ensuite, dans l'ordre : listez les quatre ou cinq zones de votre dépôt qui exigent une lecture ligne à ligne, et écrivez-les dans le fichier de contribution. Vérifiez que la production est hors de portée des environnements de développement. Et prenez trois tests sur vos règles métier les plus importantes : cassez volontairement le code qu'ils couvrent, et regardez s'ils rougissent. Ce dernier point prend dix minutes et vous dira, mieux que n'importe quel tableau de bord, où en est réellement votre filet de sécurité.

---

Besoin d'aide pour votre projet web ? Contactez Raicode pour en discuter.