Oui, quand la relecture IA est une couche parmi d’autres et non la seule barrière. Un relecteur IA peut lire chaque pull request à toute heure et repérer cas oubliés, schémas risqués et code peu clair. Il peut aussi se tromper ou être induit en erreur : une configuration sûre garde donc autour de lui des tests, une protection de branche et une personne pour les changements risqués.
Ce que la relecture IA fait bien, et ce que les personnes font mieux
| Tâche | Relecteur IA | Personne |
|---|---|---|
| Repérer les cas limites oubliés et les petites erreurs | Fort | Bon, mais se fatigue |
| Vérifier chaque changement selon vos règles, à chaque fois | Fort | Varie d’un jour à l’autre |
| Juger si le changement est la bonne décision produit | Faible | Fort |
| Repérer un risque absent du code, comme un contrat ou une échéance | Faible | Fort |
Servez-vous de ce partage pour décider où une personne doit rester impliquée. Les contrôles de routine vont à l’IA. Les décisions de jugement restent aux personnes.
Cinq couches autour de chaque pull request
Aucun contrôle seul ne devrait porter la décision. Une configuration sûre empile des couches qui attrapent chacune ce que les autres manquent, et la pull request doit toutes les franchir dans l’ordre.
- Contrôles automatiques : le lint, le build et les tests donnent un réussi ou échoué que personne ne peut contester.
- Agents relecteurs : des agents distincts lisent le changement et commentent ce qui leur paraît anormal.
- Boucle de correction : les remarques repartent vers un agent correcteur, puis les contrôles et les relecteurs repassent.
- Une personne : quelqu’un que vous avez désigné approuve les changements dans les zones où une erreur coûte cher.
- Protection de branche : votre hébergeur de code impose les contrôles et relectures obligatoires, quoi que dise un agent.
Les risques à prévoir
- Une fausse approbation : le relecteur dit que le changement est bon alors qu’il ne l’est pas.
- Être induit en erreur : un texte caché dans un ticket, un commentaire ou un fichier peut tenter d’orienter le relecteur. L’OWASP place l’injection de prompt en tête de sa liste des risques pour les applications fondées sur des grands modèles de langage.
- Trop d’accès : un relecteur qui peut lire des secrets ou modifier la production peut causer des dégâts s’il est induit en erreur.
- Corriger sa propre copie : un agent qui relit le code qu’il a écrit a tendance à se donner raison.
Une configuration sûre, pas à pas
- Séparez l’auteur des relecteurs. L’agent qui a écrit le changement ne l’approuve jamais, et plusieurs relecteurs valent mieux qu’un seul.
- Laissez les relecteurs commenter, pas modifier. Les remarques reviennent à l’auteur pour correction : chaque changement a ainsi un seul responsable.
- Gardez les contrôles automatiques comme barrière. Tests, vérification des types et contrôles qualité doivent repasser après chaque correction. Sur GitHub, la protection de branche peut exiger des contrôles réussis et des relectures approuvées avant toute fusion.
- Limitez les accès. Faites tourner les agents dans un bac à sable sans secrets de production, avec seulement les droits dont le travail a besoin.
- Choisissez où une personne doit valider, par exemple les zones sensibles du code et la mise en production.
- Gardez une trace. Chaque commentaire de relecture, correction et approbation doit être visible sur la pull request.
Un exemple concret : un endpoint de remboursement
Voici un ticket illustratif, PAY-301, "Ajouter un endpoint de remboursement" : un agent le construit et ouvre une pull request. Voici ce que fait chaque couche.
| Couche | Ce qu’elle a fait | Résultat |
|---|---|---|
| Contrôles automatiques | Lint, vérification des types et tests ont tourné. Un test sur un montant de remboursement négatif a échoué. | Envoyé à l’agent correcteur. Un commit plus tard, la deuxième exécution est passée. |
| Agents relecteurs | Un relecteur a vu que l’endpoint ne vérifie jamais que l’utilisateur a le droit de rembourser ce paiement. Un autre a essayé de le casser et a trouvé qu’un remboursement pouvait dépasser le paiement d’origine. | Deux remarques, écrites en commentaires sur la pull request. |
| Boucle de correction | L’agent correcteur a ajouté la vérification des droits et le plafond du montant. Les contrôles ont repassé et les relecteurs ont lu la nouvelle version. | Les deux remarques closes, tous les contrôles au vert. |
| Une personne | Le changement touche le dossier des paiements, qui figure sur la liste des approbateurs. L’approbateur voit au même endroit les remarques, les corrections et les contrôles réussis. | Approuvé, ou renvoyé avec un commentaire. |
| Protection de branche | Votre hébergeur de code exige toujours ses contrôles et sa relecture. | La fusion n’est permise que parce que tout est passé. |
Remarquez que les relecteurs n’ont jamais modifié le code et qu’aucune couche n’a approuvé seule la modification. Dans un cas comme celui-ci, les deux remarques sont du genre qu’une personne fatiguée survole un vendredi après-midi.
Ce qui se passe dans la boucle de correction
Une remarque part vers un agent correcteur avec le commentaire exact ou le journal d’échec. Il modifie le code, les contrôles repassent et les relecteurs lisent la nouvelle version. Cela se répète jusqu’à ce que tout soit au vert.
Deux garde-fous gardent la boucle honnête. Si une correction ne rapproche plus du vert, ou si le risque du changement augmente, l’exécution s’arrête et demande à une personne au lieu de réessayer. Et un test qui échoue au hasard est relancé et réparé automatiquement : un test instable ne bloque pas un bon changement.
Comment Dutopilot s’y prend
Dans Dutopilot, des membres d’équipe virtuels Dutopilot distincts, qui n’ont pas écrit le code, lisent chaque pull request. Leurs remarques partent vers une étape de correction automatique, puis les tests et les contrôles qualité repassent avant toute fusion. Le code est traité dans un bac à sable isolé, et votre propre protection de branche ainsi que vos relectures obligatoires continuent de s’appliquer à l’identique.
Les personnes décident de l’architecture avant l’écriture du code et de la mise en production, et vous pouvez ajouter des validations où vous le souhaitez. Chaque exécution laisse une trace dans vos pull requests. Voyez quelles étapes demandent l’accord d’une personne pour savoir comment choisir.
Ce que les relecteurs ont le droit de faire
- Ils lisent le changement et le code autour, et écrivent des commentaires. Ils ne poussent pas de code.
- Ils tournent dans un bac à sable fermé, sans secrets de production.
- Ce sont d’autres membres d’équipe virtuels Dutopilot que celui qui a écrit le changement : aucun ne corrige sa propre copie.
- L’avis d’un seul relecteur ne fusionne jamais rien seul. Les validations et la fusion n’interviennent que là où vous les avez choisies, et ce sont les contrôles automatiques et votre protection de branche qui décident.
Ce que vous mettez en place
- La protection de branche sur votre branche principale, avec les contrôles que vous exécutez déjà marqués comme obligatoires.
- Une liste d’approbateurs, et les parties du code, comme les paiements ou la connexion, qui en exigent toujours un.
- Le niveau de rigueur voulu : les types de problème sur lesquels les relecteurs bloquent et ceux qu’ils se contentent de signaler.
Ce que fait votre Forward Deployed Engineer
Chaque client Dutopilot a un Forward Deployed Engineer : un ingénieur de Dutopilot qui travaille avec votre équipe. Il n’écrit pas le code de votre produit. Il adapte la relecture à votre code et à vos habitudes.
- Il règle ce que les relecteurs cherchent dans votre code, comme vos règles de sécurité et vos conventions de nommage.
- Il choisit avec vous les parties du code qui demandent un approbateur désigné.
- Il relit avec vous les résultats du premier mois : ce que les relecteurs ont signalé, ce que les personnes ont signalé ensuite et ce qui est passé.
- Il resserre ou assouplit les approbations selon ce suivi, et continue d’ajuster à mesure que votre code et votre équipe évoluent.
Comment savoir si cela fonctionne
Tenez un suivi simple pendant le premier mois. Pour chaque pull request, notez ce que le relecteur IA a signalé, ce qu’une personne a signalé ensuite et si quelque chose est passé entre les mailles jusqu’à une correction ultérieure. Si vos équipes continuent de trouver de vrais problèmes que l’IA a manqués, resserrez la configuration. Si les remarques de l’IA sont surtout du bruit, ajustez ce que vous lui demandez de chercher avant de lui confier davantage.
Commencez petit, puis élargissez
Commencez par la relecture IA sur une partie du code à faible risque, avec une personne qui valide encore chaque fusion. Après quelques semaines, regardez à quelle fréquence l’IA a trouvé de vrais problèmes et à quelle fréquence elle en a manqué un qu’une personne a repéré. Assouplissez les validations là où le suivi est propre, et gardez-les là où il ne l’est pas.
Questions fréquentes
La relecture par IA doit-elle remplacer la relecture humaine ?
Pas pour les changements coûteux ou difficiles à annuler. Laissez l’IA repérer les problèmes courants pour que vos équipes consacrent leur temps au jugement, par exemple savoir si le changement est le bon.
Un relecteur IA peut-il approuver et fusionner seul ?
Seulement là où vous le choisissez, et seulement pour les changements à faible risque. Les validations et la fusion n’interviennent que là où vous les avez choisies, et l’avis d’un seul relecteur ne fusionne jamais rien seul : les contrôles automatiques et votre protection de branche restent la barrière. Commencez strict et n’assouplissez qu’après avoir vu les résultats.
Et les secrets et les données clients ?
Tenez-les hors de portée du relecteur. Dans Dutopilot, le code est traité dans un bac à sable isolé, nous ne conservons jamais de copie de votre dépôt, et les journaux d’exécution et résultats de contrôle sont supprimés après 90 jours.