Avant que le code rédigé par un agent ne soit déployé en production, les conditions suivantes doivent être rigoureusement réunies : la suite de tests réussit, le linting et la vérification des types passent sans erreur, le diff correspond exactement à la taille et au périmètre spécifiés dans le plan, le projet compile sans accroc, un scan de sécurité ne signale aucune nouvelle faille et un relecteur humain a examiné puis validé le diff. Chacun de ces contrôles constitue une porte de vérification (verification gate) : un jalon bloquant qui doit être franchi avec succès avant que le travail ne progresse vers la phase suivante. Une porte supplémentaire intervient avant même qu'une seule ligne de code ne soit écrite : l'approbation humaine du plan. C'est elle qui permet d'économiser le plus d'argent, car un plan rejeté dès le départ coûte exactement zéro en temps d'exécution. Cet article définit ce que sont ces portes, recense celles qui comptent réellement pour le code d'agent et détaille leur fonctionnement au sein d'Ivy Tendril.

Ce qu'est une porte de vérification

Une porte est une condition impérative attachée à la transition entre deux étapes d'un processus. Une tâche en phase N ne peut basculer en phase N+1 tant que cette condition n'est pas remplie. La condition doit être évaluée de façon rigoureusement identique à chaque exécution, et son verdict doit être archivé pour pouvoir être audité ultérieurement.

Trois critères fondamentaux distinguent une véritable porte d'une simple suggestion :

Elle est bloquante. Une porte qui échoue interrompt net la transition. Un contrôle dont l'échec n'est qu'indicatif est un rapport d'information, pas une porte.
Elle est automatisée ou explicite. Soit un programme l'évalue formellement (tests, linter, build), soit une personne désignée consigne une décision traçable (revue de code). L'idée vague que « quelqu'un a sans doute regardé » ne relève d'aucune de ces catégories.
Elle possède un circuit d'échec bien défini. En cas d'échec à la porte, le travail est renvoyé vers une destination précise : vers l'agent pour correction, vers l'étape de planification ou vers un ingénieur. Le travail qui échoue à un contrôle et stagne dans un angle mort représente la première cause d'abandon et de perte du travail des agents.

Le code écrit par des développeurs humains franchit lui aussi des portes : l'intégration continue et la revue de pull requests. La différence majeure avec les agents tient au volume. Quand un seul ingénieur peut ouvrir vingt pull requests par jour, la revue humaine devient le goulot d'étranglement le plus sévère. Les portes préalables doivent donc éliminer le maximum de scories avant même qu'un être humain ne commence à lire le diff. L'article Modèles d'orchestration pour agents de code décrit comment la vérification s'articule avec les files d'attente, l'isolation et la gestion des coûts.

Les portes indispensables pour le code généré par des agents

Porte	Ce qu'elle contrôle	Ce que signifie généralement un échec
Approbation du plan	Un humain a lu le plan et validé la stratégie et son périmètre	La tâche était sous-spécifiée ou l'approche retenue est erronée
Tests	Les tests existants passent ; les nouveaux comportements sont testés	L'agent a causé une régression ou a omis de couvrir ses modifications
Lint et vérification des types	Le code respecte les standards du projet et compile	Non-respect des règles, code inutilisé ou erreurs de typage introduites pour faire passer les tests
Taille et périmètre du diff	Les fichiers touchés correspondent au plan ; le diff reste lisible	L'agent a modifié des fichiers hors plan ou refactorisé du code non lié
Compilation (Build)	Le projet complet compile correctement depuis la branche	Quelque chose fonctionne de manière isolée mais échoue une fois assemblé
Scan de sécurité	Absence de nouveaux secrets, dépendances vulnérables ou motifs à risque	L'agent a introduit une clé d'API, une dépendance suspecte ou un appel non sécurisé
Approbation du diff	Un humain a analysé le diff et validé sa mise en œuvre	Tout ce que les contrôles automatisés ne peuvent juger : l'intention métier, la lisibilité, l'architecture

Les six premières portes s'exécutent avant toute sollicitation humaine : la porte de plan intervient en amont de l'exécution, tandis que les suivantes s'exécutent dans le worktree de l'agent après génération du code. Deux d'entre elles méritent une attention spécifique.

Les risques propres au code généré par des modèles de langage — traitement non sécurisé des entrées/sorties, ajouts risqués dans la chaîne d'approvisionnement logicielle, fuites d'identifiants — sont documentés dans l'OWASP Top 10 for LLM Applications, qui sert de checklist de référence pour paramétrer la porte de sécurité.

La taille et le périmètre du diff est la porte la plus fréquemment négligée par les équipes, alors qu'elle est bien plus cruciale pour les agents que pour les développeurs. Invité à corriger une simple vérification de nullité, un agent aura parfois tendance à reformater le fichier entier, renommer des variables et modifier trois fonctions appelantes. Au final, une revue rapide de 10 lignes se transforme en un diff illisible de 300 lignes. Une porte de périmètre compare la liste des fichiers et modules modifiés aux prévisions du plan et signale immédiatement tout débordement.

Le scan de sécurité traque les secrets enfouis dans le code, les failles dans les dépendances et les antipatterns. Les agents ayant tendance à reproduire les structures présentes dans le reste du projet, un dépôt comportant une vulnérabilité verra naturellement ce défaut se propager à d'autres endroits si l'on n'y prend garde.

Pourquoi le contrôle du plan évite de gaspiller de l'exécution

Toutes les portes situées en aval de l'exécution partagent un lourd inconvénient : lorsqu'elles échouent, des tokens et de l'argent ont déjà été consommés. Les tests, le linter, le build et le scan vous indiquent que l'exécution s'est mal passée. Seule la porte de plan vous en avertit avant que l'erreur ne coûte quoi que ce soit.

Considérez ce que relèvent les portes aval : un échec aux tests parce que l'agent a mal appréhendé l'exigence fonctionnelle est avant tout un problème de plan. Un dépassement de périmètre parce que l'agent a touché à des composants non mentionnés dans le ticket est un problème de plan. Un échec de build parce que le plan envisageait de modifier un package sans anticiper les impacts sur ses dépendances est un problème de plan. Dans chacun de ces cas de figure, un relecteur prenant deux minutes pour lire un plan textuel aurait identifié le problème, pour un coût d'exécution strictement nul.

C'est la raison pour laquelle le flux de software factory — la dénomination adoptée par Ivy pour désigner la séquence reproductible planifier, exécuter, vérifier et relire — comporte très exactement deux points de contrôle humains et en place un avant même l'écriture de tout code. C'est au point de contrôle du plan que sont arbitrés le périmètre, l'approche technique et l'ordonnancement. C'est au point de contrôle du diff qu'est confirmée la conformité de l'implémentation. Toutes les phases intermédiaires sont entièrement automatisées.

Comment Ivy Tendril orchestre les portes de vérification

Ivy Tendril est une application de bureau local-first (macOS, Windows, Linux) qui prend en charge une tâche depuis sa planification jusqu'à la pull request validée. Les deux points de contrôle humains et les portes automatisées intermédiaires sont gravés dans son cycle de vie. Consultez la documentation de l'application Review pour découvrir l'interface.

Porte de plan. Un plan débute sous forme de brouillon (Draft). Un développeur en prend connaissance et peut l'étendre (Expand), le scinder (Split) ou le mettre à jour (Update), ou bien consigner des remarques textuelles dans le corps du brouillon pour en déclencher la réécriture. L'exécution de code ne débute jamais sans une validation explicite.
Exécution en isolation. Chaque plan s'exécute au sein de son propre git worktree sur sa propre branche Git, garantissant que la vérification opère sur les seules modifications de ce plan et rien d'autre. L'article Worktrees Git pour agents IA parallèles démontre pourquoi l'isolation physique est le garant de la fiabilité des portes.
Onglets de vérification. À l'issue de l'exécution, l'application Review présente les résultats des tests, du lint et du diff sous forme d'onglets distincts, permettant au relecteur de croiser ces trois perspectives avant de trancher.
Importation CI sur le forfait Pro. Les équipes dont les portes tournent dans leur chaîne d'intégration continue — GitHub Actions ou tout autre exécuteur — peuvent importer ces rapports directement dans l'application Review sur le forfait Pro, évitant ainsi de jongler entre plusieurs outils.
Circuit d'échec. Dès qu'une vérification échoue, le travail est renvoyé à l'agent avec la transcription intégrale de l'erreur. L'agent reçoit le journal d'erreur brut des tests ou du linter — et non un résumé tronqué — et relance sa tâche dans le même worktree. L'interface Jobs diffuse en direct la sortie et les appels d'outils de l'agent au fur et à mesure.
Porte de diff. Tendril n'ouvre la pull request sur GitHub qu'une fois les vérifications techniques réussies et le diff formellement approuvé par un humain. Aucun code n'est poussé sans cette double validation.

Les dépenses sont suivies par plan et par tâche élémentaire (job). Un plan qui a échoué à trois reprises avant de franchir les portes expose clairement le coût de ses réexécutions, fournissant les éléments factuels pour juger si l'approbation du plan initial aurait dû être plus stricte.

Guide de démarrage

Formalisez vos portes actuelles par écrit : la plupart des équipes constatent qu'elles disposent de tests et de revues de code, et qu'un linter s'exécute quelque part sans que personne ne sache s'il bloque réellement les fusions.
Installez Tendril : curl -sSf https://cdn.ivy.app/install-tendril.sh | sh (macOS, Linux) ou irm https://cdn.ivy.app/install-tendril.ps1 | iex (Windows). Voir le guide d'installation.
Faites passer un premier plan à travers l'ensemble du cycle de vie et lisez les onglets de tests et de lint avant d'ouvrir le diff. Notez ce que vous auriez manqué en ne consultant que le diff seul.
Intégrez un contrôle de périmètre à votre revue de plan : la liste des fichiers que l'agent s'autorise à modifier coïncide-t-elle strictement avec les objectifs du plan ?

Tendril est gratuit et son code source est accessible sous licence Functional Source License. L'import des vérifications CI, les outils d'équipe, l'hébergement on-premise et le SSO sont réservés aux forfaits Pro et Enterprise.

Foire aux questions

Les portes de vérification doivent-elles bloquer automatiquement ou simplement informer le relecteur ?

Les tests, le linter, les vérifications de types et le build doivent impérativement être bloquants : aucun relecteur ne devrait perdre son temps sur un diff qui ne compile même pas. Les constats de périmètre et les alertes de sécurité doivent être présentés au relecteur avec la faculté de passer outre manuellement, car des dérogations légitimes peuvent survenir.

Combien de réessais (retries) un agent doit-il obtenir en cas d'échec de vérification ?

Fixez un plafond strict et consignez-le. Les échecs répétés à la vérification trahissent presque toujours une déficience de planification plutôt qu'un problème d'exécution ; mieux vaut renvoyer le sujet à l'étape du plan que de payer pour une cinquième tentative infructueuse. Le suivi des coûts par tâche rend le surcoût de ces réessais immédiatement visible.

La revue humaine du diff conserve-t-elle sa valeur si toutes les portes automatiques sont validées ?

Oui, absolument. Les portes automatisées vérifient uniquement ce qui peut être formalisé et codifié à l'avance. Elles ne peuvent juger si la modification répond véritablement à la finalité du ticket, si le code restera maintenable dans la durée, ni si le plan lui-même était judicieux. C'est précisément pour cela que le contrôle du diff constitue l'une des deux portes humaines non négociables.

Premiers pas avec Ivy Tendril

Prêt pour une orchestration d'agents parallèle au niveau développeur ?

Explorer le code: Découvrez Ivy Tendril sur GitHub (Open Source).
Consulter la documentation: Trouvez des guides d'intégration sur tendril.ivy.app.
Planifier une session d'architecture: Contactez renco@ivy.app pour une consultation technique de 30 minutes.

Portes de vérification : les critères incontournables avant de livrer du code généré par des agents