L'orchestration d'agents IA est prête pour la production lorsque huit conditions sont remplies : les agents s'exécutent dans des espaces de travail isolés, chaque modification passe une vérification automatisée, un humain valide le travail à des points de contrôle stricts, les coûts sont attribués par unité de code fusionnée, les instructions des agents sont des fichiers versionnés, l'orchestrateur n'est pas inféodé à un fournisseur de modèles unique, la résidence des données est maîtrisée, et une exécution interrompue dispose d'un mécanisme de récupération clair. Un projet pilote n'a besoin d'aucun de ces garde-fous pour paraître impressionnant. La production exige les huit, car chacun correspond à un mode de défaillance qui ne se manifeste qu'à grande échelle. Cet article détaille cette checklist, illustre les réponses non satisfaisantes et vous explique comment tester chaque critère sur vos architectures actuelles.

La checklist

#	Exigence	La question à poser	Une réponse défaillante
1	Isolation de l'espace de travail	Où écrit chaque agent ?	« Directement dans la copie locale du dépôt »
2	Vérification automatisée	Qu'est-ce qui doit réussir avant qu'un humain n'examine le code ?	« Le relecteur lance la suite de tests »
3	Points de contrôle humains	Où exactement une personne prend-elle une décision ?	« Les relecteurs vérifient les pull requests »
4	Imputation des coûts	Combien a coûté la dernière modification fusionnée ?	« On regarde la facture mensuelle d'API »
5	Instructions versionnées	Où sont stockées les instructions de l'agent ?	« Dans un prompt copié-collé dans le chat »
6	Portabilité entre fournisseurs	Que se passe-t-il si le modèle est déprécié ?	« On réécrira nos prompts »
7	Résidence des données	Qui détient une copie du code source ?	« C'est le fournisseur de l'outil qui gère ça »
8	Reprise sur erreur	Que se passe-t-il si une exécution plante à mi-chemin ?	« Quelqu'un s'en aperçoit et nettoie »

L'ordre est primordial. Les critères 1 à 3 garantissent la rigueur et l'exactitude : sans eux, l'augmentation de la cadence génère des anomalies plus vite que la relecture humaine ne peut les détecter. Les critères 4 à 6 assurent la pérennité : sans eux, le système fonctionne à l'aveugle, sans audit possible ni possibilité de migration. Enfin, les critères 7 et 8 sont les questions que poseront inévitablement l'équipe de sécurité et l'ingénieur d'astreinte, le plus souvent après le déploiement.

1. Isolation de l'espace de travail

Deux agents qui éditent simultanément le même répertoire de travail vont entremêler leurs écritures, et le diff produit n'appartiendra à aucun des deux plans. L'unité d'isolation optimale est le git worktree : un répertoire de travail distinct doté de sa propre branche et de son propre index, tout en partageant la base d'objets du dépôt principal. La création d'un worktree est une simple extraction (checkout), et non un clone : cela prend une fraction de seconde au lieu du temps nécessaire pour retélécharger tout l'historique.

# Un répertoire et une branche par plan.
git worktree add ../work/plan-4812 -b plan/4812
git -C ../work/plan-4812 status --short
git worktree remove ../work/plan-4812

Les conteneurs procurent une barrière plus étanche lorsque l'agent exécute du code non fiable, et le modèle de sécurité de Docker précise les garanties effectives de cette frontière. Pour un agent de confiance intervenant sur votre propre code, un worktree constitue le compromis idéal : une isolation stricte par plan sans le délai de démarrage d'un conteneur sur le chemin critique. Git worktrees pour agents IA parallèles explore les pièges fréquents, notamment les hooks partagés et les sous-modules qui déstabilisent souvent les équipes.

Pour tester : Lancez deux plans modifiant le même fichier et vérifiez qu'ils produisent tous deux des diffs propres et étanches.

2. Vérification automatisée avant intervention humaine

Un relecteur qui passe du temps sur un diff qui ne compile même pas voit son temps gaspillé. Les tests, le linting, la vérification des types, la compilation et la vérification du périmètre (scope check) par rapport au plan doivent s'exécuter dans le worktree de l'agent et joindre leurs résultats à la proposition. C'est le principe même de l'intégration continue, appliquée par plan plutôt que simplement par branche.

Deux contrôles sont spécifiques au code généré par des agents. Le contrôle de périmètre compare les fichiers modifiés à ceux annoncés par le plan : en effet, un agent chargé de corriger une vérification de valeur nulle a parfois tendance à reformater tout le fichier et à renommer des variables sans raison. Le scan de sécurité recherche les vulnérabilités répertoriées dans l'OWASP Top 10 for LLM Applications : manipulation non sécurisée des sorties, paquets malveillants injectés dans la chaîne logistique, ou clés d'API divulguées. Vérifications automatiques pour le code généré par IA détaille les barrières qui doivent être bloquantes et celles qui doivent rester purement informatives.

Pour tester : Demandez quel pourcentage de modifications d'agents parvient aux relecteurs avec des tests en échec. Si personne ne peut y répondre, la barrière de contrôle n'existe pas.

3. Des points de contrôle humains à deux moments précis

Zéro point de contrôle signifie qu'un agent pousse directement sur la branche principale et que les erreurs sont découvertes par vos collègues ou vos utilisateurs. Dix points de contrôle signifie valider manuellement chaque appel d'outil ou chaque lecture de fichier, ce qui transforme l'humain en goulot d'étranglement et pousse les relecteurs à valider par pur réflexe.

Deux points de contrôle positionnent l'arbitrage humain là où il a le plus d'impact. L'étape du plan est le moment où un malentendu coûte le moins cher à rectifier : aucun code n'a encore été produit et le plan ne fait qu'une page de texte. L'étape du diff est le moment où l'exactitude de la solution est confirmée au vu des résultats de vérification. Qu'est-ce qu'une software factory décrit l'enchaînement complet.

Pour tester : Demandez à votre équipe de nommer les deux moments précis où une personne tranche. Si la réponse décrit une succession floue d'activités plutôt que deux jalons clairs, vous n'avez pas de points de contrôle, seulement une surveillance manuelle permanente.

4. Imputation des coûts par modification fusionnée

La facture mensuelle globale de vos API de modèles ne fournit aucune indication exploitable. L'indicateur clé à surveiller est le coût par pull request fusionnée : l'ensemble des dépenses sur la période (y compris les plans rejetés ou abandonnés) divisé par le nombre de pull requests effectivement intégrées. Le travail rejeté fait partie intégrante du coût du travail accepté.

Analysez ce chiffre en parallèle du taux de rejet (denial rate), c'est-à-dire la part des pull requests fermées sans être fusionnées. Chacune de ces métriques peut être artificiellement améliorée au détriment de l'autre, ce qui explique pourquoi les métriques DORA sont toujours suivies par paires. Mesurer le débit des agents de code IA définit chaque indicateur et analyse ce que révèlent des chiffres anormaux.

Pour tester : Demandez le coût par PR fusionnée pour le mois dernier. Si ce chiffre ne peut être calculé qu'à la main à partir d'une facture brute, c'est qu'il n'est pas piloté.

5. Les instructions sous forme de fichiers versionnés

Le comportement d'un agent consigné dans un prompt copié-collé dans une interface de chat ne peut être ni relu, ni comparé par diff, ni restauré à une version antérieure. Les instructions doivent résider dans le dépôt, pour les mêmes raisons que la configuration selon les principes de The Twelve-Factor App : toute modification devient un diff dans une pull request qu'un ingénieur senior peut valider ou refuser.

// Les instructions et la mémoire sont des fichiers lus par l'orchestrateur,
// et non des chaînes encodées en dur dans le binaire. Une convention apprise
// le lundi est appliquée par tous les agents et tous les développeurs dès le mardi.
interface Promptware {
  program: string; // Program.md - instructions de l'étape
  memory: string[]; // Memory/    - apprentissages sur la base de code
  tools: string[]; // Tools/     - autorisations et outils alloués
  logs: string[]; // Logs/      - journal d'exécution immuable
}

Le danger majeur est la dérive incontrôlée (drift) : un agent habilité à modifier ses propres instructions peut aussi les dégrader, par exemple en ajoutant « réessayer les tests échoués jusqu'à trois fois » après un test instable. Le versioning constitue le verrou de sécurité indispensable, car l'ajustement apparaît sous forme de diff visible lors de la relecture. Promptware : les agents qui améliorent leurs propres instructions traite de ce risque ainsi que de la surcharge mnésique.

Pour tester : Lancez git log sur le dossier hébergeant les instructions de vos agents. Si l'historique est vide, vos instructions échappent aux règles élémentaires de l'ingénierie logicielle.

6. Portabilité entre modèles et agents

Les modèles de langage sont dépréciés selon le calendrier du fournisseur, pas le vôtre. Un orchestrateur qui dépend étroitement d'un seul prestataire transforme chaque avis d'obsolescence en un chantier de migration critique. La couche stratégique qui doit vous appartenir en propre est le workflow : les étapes, les barrières, les points de contrôle et la mémoire. Le moteur d'exécution sous-jacent doit pouvoir être permuté par plan, et l'accès aux outils doit s'appuyer sur un standard ouvert tel que le Model Context Protocol, plutôt que sur une intégration propriétaire par agent.

Cette indépendance permet aussi un routage économique : une étape de tri initiale ne nécessite pas un modèle de pointe coûteux ; un plan d'architecture complexe en aura besoin. Ce type d'arbitrage n'est envisageable que si le changement de modèle relève de la simple configuration et non de la réécriture logicielle.

Pour tester : Changez le modèle sur un plan précis et lancez l'exécution. Si cette modification réclame d'éditer du code d'infrastructure, vous avez une dépendance technique rigide, pas une architecture configurable.

7. Maîtrise de la résidence des données

Chaque copie de votre dépôt qui sort de votre périmètre de contrôle doit être recensée, encadrée contractuellement et ultimement supprimée. Un agent hébergé dans le cloud clone votre dépôt dans l'infrastructure de son éditeur, ce qui implique au moins deux sous-traitants pour votre code : l'éditeur de l'agent et le fournisseur du modèle LLM. Un orchestrateur orienté local (local-first) n'en a qu'un seul, et strictement pour les portions de code envoyées dans les prompts.

Ce n'est pas seulement une exigence technique mais un impératif juridique : cela détermine le nombre d'accords de traitement de données (DPA) qu'un audit RGPD doit valider, et si l'hébergement en Union européenne relève d'une option dans une interface ou d'une renégociation contractuelle lourde. Développement IA local-first passe en revue les exigences que votre RSSI ou vos auditeurs ne manqueront pas de formuler.

Pour tester : Listez l'ensemble des acteurs tiers qui détiennent une copie de votre code durant l'exécution d'un agent. Si la liste est plus longue que prévu, l'audit de sécurité parviendra exactement au même constat.

8. Un mécanisme de reprise sur erreur formalisé

À forte intensité, les échecs sont inévitables : micro-coupure réseau au milieu d'un traitement, agent qui boucle, étape de vérification qui ne répond plus. L'orchestrateur doit apporter une réponse prédéfinie à chaque situation, et cette réponse ne peut en aucun cas être « quelqu'un va s'en rendre compte ».

Échec de vérification : La tâche retourne à l'agent accompagnée de la trace d'erreur exacte (et non d'un vague résumé), puis recommence dans le même worktree jusqu'à atteindre une limite de tentatives.
Exécution abandonnée : Le worktree et sa branche sont nettoyés, afin qu'un plan interrompu ne laisse aucun dossier fantôme qui viendrait faire échouer les exécutions ultérieures.
Boucle infinie ou dérapage des coûts : Un plafond strict de tokens et de temps alloué par plan qui interrompt activement l'exécution au lieu de constater les dégâts a posteriori.
État partiel corrompu : Chaque plan possédant son worktree et sa branche dédiés, abandonner une tentative consiste simplement à supprimer un unique dossier. Rien n'a été altéré dans les espaces partagés.

Pour tester : Interrompez brutalement le processus d'un agent en plein milieu d'un plan. Que reste-t-il sur le disque, et est-ce que le plan suivant est perturbé ?

Comment Ivy Tendril répond à ces huit critères

Ivy Tendril est une application de bureau local-first pour macOS, Windows et Linux conçue pour piloter les agents de développement de la formalisation du plan jusqu'à la pull request validée. Elle implémente nativement un worktree par plan (1), l'exécution des tests, du linting et de l'inspection de diff associés à chaque modification avec import de CI en formule Pro (2), les deux points de contrôle indispensables (3), le suivi des coûts par plan et par tâche (4), des briques de promptware stockées sous forme de fichiers versionnés (5), la prise en charge transparente de n'importe quel agent CLI et modèle par plan (6), le maintien strict du code et des journaux sur votre machine (7), et une stratégie de reprise sur erreur avec sortie détaillée et nettoyage systématique des worktrees (8).

curl -sSf https://cdn.ivy.app/install-tendril.sh | sh

Sous Windows, utilisez irm https://cdn.ivy.app/install-tendril.ps1 | iex. Tendril est gratuit et son code source est accessible sous la Functional Source License ; les fonctionnalités d'équipe, l'hébergement on-premise, le SSO et l'import de vérification CI sont disponibles dans les offres Pro et Enterprise.

Foire aux questions

Quel critère parmi les huit une équipe doit-elle traiter en priorité ?

L'isolation d'abord, puis la vérification, puis les points de contrôle. Les surcoûts et les dérives de contexte sont pénibles ; mais deux agents modifiant le même répertoire de travail produisent des bugs impossibles à attribuer, ce qui est bien plus destructeur et complexe à déboguer.

Cette checklist concerne-t-elle uniquement les agents de code ?

Les modes de défaillance décrits ici, oui. L'isolation, les contrôles de périmètre et la revue de diff existent précisément parce que l'aboutissement est une modification sur une base de code partagée. Un agent qui se contente de lire des données ou qui écrit dans son propre stockage répond à des problématiques différentes.

Combien d'agents peuvent tourner en parallèle avant que cela ne devienne critique ?

Exactement deux. Un seul agent dans un dépôt unique n'a besoin d'aucun de ces dispositifs. Dès qu'un deuxième agent intervient de manière concurrente, l'isolation et le suivi analytique des coûts cessent d'être optionnels, et la capacité de relecture humaine devient le goulot d'étranglement du débit global, bien avant la vitesse brute d'exécution.

Une parallélisation accrue augmente-t-elle indéfiniment la productivité ?

Non. La relecture de code reste intrinsèquement séquentielle. Conformément à la loi d'Amdahl, la part séquentielle fixe le plafond théorique : déployer des agents au-delà de la capacité d'absorption des relecteurs humains augmente les coûts et le taux de rejet, sans générer la moindre fusion supplémentaire dans la branche principale.

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.

Orchestration d'agents IA prête pour la production : La checklist en 8 points pour les CTO