Piloter une flotte d'instances IA

Faire écrire du code par un agent IA, tout le monde sait. Faire travailler ensemble plusieurs agents spécialisés sur un écosystème réel, dans la durée, sans qu'ils se marchent dessus ni dérivent — c'est un autre métier. Ce texte explique les principes qui rendent ça tenable.

Le problème : un seul agent ne passe pas à l'échelle

Un agent unique qui fait tout accumule deux dettes. D'abord un contexte qui gonfle : à mesure qu'il jongle avec le code, la doc, l'infra et la coordination, sa fenêtre d'attention se dilue et sa fiabilité baisse. Ensuite un biais d'initié : il connaît trop bien le projet pour en voir les angles morts — il documente ce qu'il croit vrai plutôt que ce qui est vrai.

La réponse n'est pas un agent plus gros, mais plusieurs agents au périmètre borné, chacun expert de son domaine, coordonnés par des règles explicites.

Principe 1 — des rôles bornés, une autorité claire

Chaque instance a un domaine et une autorité définis : qui tranche l'architecture, qui tient la documentation, qui pilote un produit, qui garde la cohérence transverse. L'humain reste la décision finale absolue. Un directeur arbitre entre les instances ; les autres escaladent vers lui ce qui dépasse leur périmètre.

Ce cadrage n'est pas de la bureaucratie : c'est ce qui évite qu'une instance réécrive unilatéralement le projet. La règle de fond — aucune instance ne modifie une spécification au-delà de la rétro-documentation naturelle pendant un développement — protège l'intention du produit contre la dérive silencieuse.

Principe 2 — une coordination asynchrone et tracée

Les instances ne se parlent pas en temps réel. Elles échangent par messagerie de fichiers (une boîte par instance, un fichier par message, horodaté), relevée et déposée à des moments rituels — réveil, synchronisation, clôture. L'asynchrone force à écrire des messages auto-suffisants et factuels, et la trace écrite vaut décision : ce qui n'est pas consigné n'a pas eu lieu.

La vérité de référence n'est jamais « ce dont je me souviens », mais l'artefact réel : le dépôt versionné, le fichier sur le disque, l'état git. Toute affirmation se vérifie contre lui avant d'être posée.

Principe 3 — la mémoire est un organe, elle s'entretient

Une instance qui dure accumule une mémoire persistante — qui elle est, ses règles de travail, l'état des chantiers. Cette mémoire est rechargée à chaque tour de conversation : elle coûte des ressources en continu, et surtout une information périmée y induit activement en erreur, bien plus cher qu'un simple surpoids.

D'où une hygiène en couches : un audit de cohérence (l'information est-elle encore vraie ? on la recoupe contre le réel), une passe d'optimisation (est-elle bien rangée ? on déduplique, on resserre, on rafraîchit les statuts), et un réflexe de clôture qui ne laisse pas la dette du jour s'accumuler. La distinction est cruciale : corriger le faux et ranger le fouillis sont deux gestes différents, à des cadences différentes.

→ Ce point est développé dans la fiche dédiée « L'hygiène de la mémoire d'un agent ».

Principe 4 — des agents éphémères pour le regard neuf

Pour les tâches où le biais d'initié est un danger — documenter un code, produire une pièce de référence — on n'utilise pas une instance qui « connaît » le projet, mais un agent éphémère à contexte vierge, lancé propre, qui meurt après sa tâche. L'anti-biais devient structurel : chaque exécution naît blanche, lit le code comme un étranger compétent, et ne propage aucune idée reçue. On formalise ces agents comme des types réutilisables (un rôle, des outils, des garde-fous gravés), pas comme des instances vivantes.

Principe 5 — la sécurité par construction (l'airlock)

Quand la production d'une flotte d'agents alimente quelque chose de public — un index interrogeable, une vitrine — le risque n'est plus l'erreur, c'est la fuite. Une documentation exhaustive produite sans frontière expose la configuration réelle (ports, hôtes, chemins, secrets) à quiconque interroge.

Le garde-fou est structurel, pas cosmétique : un sas en défaut-refus (rien ne sort tant que ce n'est pas explicitement projeté et filtré), une liste d'autorisation de ce qui est publiable plutôt qu'une liste d'exclusions (fragile par nature), et un contrôle adverse rejoué à chaque assemblage (« un inconnu pourrait-il attaquer un vrai système avec cette ligne ? »). On démontre la méthode, jamais les secrets.

→ Ce principe est développé dans la fiche dédiée « Documenter sans fuiter — la discipline de l'airlock ».

Ce que la flotte produit, au fond

Bien orchestrée, une flotte d'agents ne remplace pas le jugement : elle le démultiplie. L'humain pose l'intention et tranche ; les instances déroulent, chacune dans sa discipline ; les garde-fous — rôles bornés, mémoire entretenue, coordination tracée, airlock — sont ce qui transforme une collection d'agents puissants mais aveugles en un système qui tient dans la durée. La difficulté n'est pas de faire produire une IA. C'est de faire collaborer plusieurs IA sans perdre le contrôle — et ça, ça se conçoit.