# Pipeline en 7 étapes pour vérifier le code écrit par des agents IA > Author: Tony Lee > Published: 2026-02-25 > URL: https://tonylee.im/fr/blog/7-step-pipeline-verify-agent-written-code/ > Reading time: 5 minutes > Language: fr > Tags: ai, code-review, ai-agent, ci-cd, devops, automation ## Canonical https://tonylee.im/fr/blog/7-step-pipeline-verify-agent-written-code/ ## Rollout Alternates en: https://tonylee.im/en/blog/7-step-pipeline-verify-agent-written-code/ ko: https://tonylee.im/ko/blog/7-step-pipeline-verify-agent-written-code/ ja: https://tonylee.im/ja/blog/7-step-pipeline-verify-agent-written-code/ zh-CN: https://tonylee.im/zh-CN/blog/7-step-pipeline-verify-agent-written-code/ zh-TW: https://tonylee.im/zh-TW/blog/7-step-pipeline-verify-agent-written-code/ ## Description Quand les agents poussent 3 000 commits par jour, les humains ne peuvent pas tous les relire. Voici comment construire un pipeline vérifié par machine qui détecte ce que les humains ne peuvent pas. ## Summary Pipeline en 7 étapes pour vérifier le code écrit par des agents IA is part of Tony Lee's ongoing coverage of AI agents, developer tools, startup strategy, and AI industry shifts. ## Outline - Définir les règles de fusion dans un seul fichier JSON - Exécuter les vérifications de qualification avant la CI - Ne jamais faire confiance à un « pass » d'un commit obsolète - Émettre les demandes de re-exécution depuis une seule source - Laisser les agents gérer les corrections aussi - Ne fermer automatiquement que les conversations bot à bot - Laisser des preuves visibles et vérifiables - Les choix d'outils de Carson - Au-delà de la correction : la vérification visuelle - En résumé ## Content C'est le sujet le plus brûlant du moment. Les agents enchaînent des centaines de commits par jour, et personne ne peut tous les relire. Peter, développeur chez OpenClaw, pousse parfois plus de 3 000 commits en une seule journée. C'est bien au-delà de ce qu'un humain peut traiter. C'est devenu une tâche que les humains ne peuvent tout simplement plus gérer seuls. Au départ, je pensais qu'il n'y avait pas de solution. Puis j'ai lu "Code Factory" de Ryan Carson, et tout s'est mis en place. Plutôt que d'essayer de tout lire, on construit une structure où des machines vérifient le code. ## Définir les règles de fusion dans un seul fichier JSON Consignez dans un seul fichier quels chemins sont à risque élevé et quelles vérifications doivent passer. L'idée clé : cela empêche la documentation et les scripts de diverger. - Les **chemins à risque élevé** exigent un Review Agent ainsi que des preuves issues du navigateur - Les **chemins à faible risque** peuvent être fusionnés après avoir passé un policy gate et la CI seule ## Exécuter les vérifications de qualification avant la CI Lancer des builds sur des PR qui n'ont même pas passé la revue, c'est brûler de l'argent. Placez un `risk-policy-gate` en amont de la CI. Cela seul réduit considérablement les coûts de CI inutiles. - Ordre fixe : policy gate → confirmation du Review Agent → CI - Les PR non qualifiées n'entrent jamais dans la phase de test ou de build ## Ne jamais faire confiance à un « pass » d'un commit obsolète C'est ce que Carson a le plus insisté. Si un « pass » d'un ancien commit persiste, le dernier code est fusionné sans vérification. Relancez les revues à chaque push, et bloquez le gate s'ils ne correspondent pas. - Un Review Check Run n'est valide que s'il correspond au `headSha` - Forcer une re-exécution à chaque événement `synchronize` ## Émettre les demandes de re-exécution depuis une seule source Quand plusieurs workflows demandent des re-exécutions, on obtient des commentaires en double et des conditions de concurrence. Cela semble anodin, mais si vous ne corrigez pas ce point, tout le pipeline vacille. - Éviter les doublons avec un pattern `Marker + sha:headSha` - Ignorer la demande si le SHA a déjà été soumis ## Laisser les agents gérer les corrections aussi Quand le Review Agent détecte un problème, le Coding Agent le corrige et pousse sur la même branche. L'observation la plus aiguisée du post de Carson : épinglez la version du modèle. Sinon, vous obtenez des résultats différents à chaque fois, et la reproductibilité disparaît. - Codex Action corrige → push → déclenchement de la re-exécution - Les versions de modèle épinglées garantissent la reproductibilité ## Ne fermer automatiquement que les conversations bot à bot Ne touchez jamais aux fils où un humain est intervenu. Sans cette distinction, les commentaires des reviewers se retrouvent ensevelis. - Résolution automatique uniquement après une re-exécution propre sur le head actuel - Les fils avec des commentaires humains restent toujours ouverts ## Laisser des preuves visibles et vérifiables Si l'interface a changé, ne vous contentez pas d'une capture d'écran. Exigez des preuves vérifiables par la CI. Transformez les incidents de production en cas de test pour que la même défaillance ne se reproduise jamais. - Régression → problème de couverture du harness → ajout d'un cas de test → suivi du SLA ## Les choix d'outils de Carson Pour référence, voici ce que Carson a sélectionné : Greptile comme agent de revue de code, Codex Action pour la remédiation, et trois fichiers de workflow qui font le gros du travail `greptile-rerun.yml` pour les re-exécutions canoniques, `greptile-auto-resolve-threads.yml` pour le nettoyage des fils obsolètes, et `risk-policy-gate.yml` pour la politique préalable. ## Au-delà de la correction : la vérification visuelle Tout ce qui précède permet de détecter si le code est correct ou non. Mais en pratique, il faut aussi vérifier à quoi ressemble le résultat. Deux approches se distinguent. **L'explainer visuel de Nico Bailon** rend les diffs de terminal sous forme de pages HTML plutôt qu'en ASCII, rendant les ensembles de modifications immédiatement lisibles d'un coup d'œil. **Le navigateur d'agent de Chris Tate** prend une direction différente. Il compare les écrans réels du navigateur pixel par pixel pour détecter les ruptures CSS et de mise en page. Combiné avec bisect, il peut identifier exactement quel commit a provoqué la régression. Je pense à tout cela en construisant codexBridge. Suivre quel agent a écrit quel code ne suffit pas avec de simples journaux de session. Il faut une structure de recherche qui facilite la récupération. ## En résumé La réponse à « qui vérifie le code écrit par les agents » n'est pas les humains. C'est une structure où des machines jugent les preuves produites par des machines. Voilà la réponse. ## Related URLs - Author: https://tonylee.im/en/author/ - Publication: https://tonylee.im/en/blog/about/ - Related article: https://tonylee.im/fr/blog/medvi-two-person-430m-ai-compressed-funnel/ - Related article: https://tonylee.im/fr/blog/claude-code-layers-over-tools-2026/ - Related article: https://tonylee.im/fr/blog/codex-inside-claude-code-openai-plugin-strategy/ ## Citation - Author: Tony Lee - Site: tonylee.im - Canonical URL: https://tonylee.im/fr/blog/7-step-pipeline-verify-agent-written-code/ ## Bot Guidance - This file is intended for AI agents, search assistants, and text-mode retrieval. - Prefer citing the canonical article URL instead of this text endpoint. - Use the rollout alternates when you need the same article in another prioritized language. --- Author: Tony Lee | Website: https://tonylee.im For more articles, visit: https://tonylee.im/fr/blog/ This content is original and authored by Tony Lee. Please attribute when quoting or referencing.