Mainlane, c’est un ingénieur et une équipe d’agents IA. D’où une question légitime : qui vérifie le code écrit par une IA ? Notre réponse : une autre IA — qui ne l’a pas écrit — puis un humain qui décide si le code part en production.
La boucle
- Une session Claude prend une tâche et ouvre une pull request.
- Un relecteur distinct démarre dans une session vierge. Il n’a jamais vu comment le code a été écrit, il lit donc le diff comme le ferait un collègue — sans les présupposés de l’auteur.
- Le relecteur laisse des remarques sur trois niveaux : 🔴 à corriger impérativement, 🟡 à corriger de préférence, 🟢 serait un plus.
- La session auteur les corrige et répond point par point, en terminant par une section « Vérification » : les commandes qu’elle a lancées et ce qu’elles ont affiché.
- Le relecteur vérifie le nouveau head. La boucle se répète jusqu’à ce qu’il n’y ait plus aucune remarque — pas même 🟢.
Deux règles garantissent l’honnêteté du processus. Une remarque ne peut être contestée qu’avec une mesure — un chiffre, une sortie de commande, un mutant qu’un test ne détecte pas — et non avec un « ça va ». Et au bout de cinq tours, la boucle s’arrête et sollicite un humain, pour ne jamais tourner indéfiniment.
La part humaine
Aucun agent ne fusionne. Quand la revue est propre et que la CI est au vert sur exactement le commit qu’a vu le relecteur, la session écrit « prêt à fusionner » et attend. La fusion n’a lieu qu’après l’accord d’une personne, et uniquement pour ce même commit.
Ce qu’elle détecte
Quelques exemples réels tirés du dépôt de ce site :
- Dans la pull request qui ajoutait des contrôles Lighthouse à la CI, le relecteur a remarqué qu’un réglage de build CSS pointait vers le mauvais dossier, si bien que les styles de mise en page disparaissaient discrètement du site. Ni Lighthouse ni le vérificateur d’accessibilité ne l’avaient signalé. Il a aussi repéré un bandeau de langue fixe qui pouvait masquer l’élément ayant le focus pour les utilisateurs au clavier.
- Dans le contrôle de restauration des sauvegardes de la base de données, le test quotidien comparait les données restaurées avec elles-mêmes au lieu de l’export — il n’aurait jamais remarqué des lignes manquantes. La même revue a trouvé un message d’erreur qui pouvait écrire l’adresse e-mail d’un prospect dans les journaux.
- Lors du déploiement de la Content Security Policy, les rapports des extensions de navigateur auraient empêché d’atteindre l’objectif « une semaine sans violation », et les images externes des articles du blog auraient cassé une fois la politique appliquée.
Rien d’exotique. C’est le genre de chose qu’une personne fatiguée laisse passer un vendredi soir.
En chiffres
Fin octobre 2026, la boucle tourne sur huit dépôts, avec 385 pull requests fusionnées et 1 069 revues. L’essentiel du coût vient du travail lui-même : durant la dernière semaine d’octobre, environ trois quarts des tokens servent à l’implémentation et moins d’un dixième à la revue.
Limites
Le relecteur est le même type de modèle que l’auteur, il peut donc partager ses angles morts. Il ne remplace pas une revue humaine des changements importants, et le texte d’une pull request est traité comme des données, jamais comme des instructions. Ce qu’il remplace, c’est l’étape que la plupart des développeurs solo sautent : un second regard sur chaque modification, sans exception.
Si vous voulez le même processus dans votre équipe, c’est l’un de nos services — contactez-nous.