Un agent manque de contexte, on ajoute un document. Il oublie une règle, on ajoute une vérification. Une tâche revient souvent, on crée une commande. Ces réponses peuvent être utiles. Au fil des ajouts, il devient pourtant difficile de savoir ce qui aide encore, ce qui se contredit et ce qui coûte plus qu’il n’apporte.
Organiser une usine agentique demande donc aussi de savoir simplifier. L’objectif est de permettre aux agents de contribuer au produit dans des conditions que l’équipe comprend et maîtrise.
Notre expérience porte ici sur les agents de construction logicielle. Les principes d’accès, de contrôle et de responsabilité concernent aussi d’autres usages, mais leur mise en œuvre doit être adaptée au travail confié.
Partir de la tâche et de ses limites
Avant de choisir une orchestration, on peut décrire ce qu’un agent doit accomplir. Quelle modification attend-on ? De quelles informations a-t-il besoin ? Comment saura-t-on qu’il a terminé ? À quel moment doit-il demander un arbitrage ?
Une tâche clairement délimitée permet souvent de commencer avec une organisation simple. Si l’agent échoue, il devient plus facile d’en examiner la cause : manque d’information, accès insuffisant, outil inadapté, consigne ambiguë ou capacité du modèle.
La réponse n’est pas toujours un agent supplémentaire. Un contrôle automatique peut suffire à détecter une erreur récurrente. Un exemple dans la spécification peut lever une ambiguïté. Une question humaine peut résoudre un désaccord que plusieurs agents ne feront que reformuler.
Donner accès au contexte utile
Le contexte comprend l’intention produit, les décisions déjà prises, les contraintes techniques et l’état du travail. Tout charger dans chaque conversation peut rendre l’ensemble coûteux et difficile à maintenir.
Une organisation plus utile distingue les règles communes, les informations propres au produit et les éléments nécessaires à la tâche. L’agent doit pouvoir retrouver la source pertinente, et l’équipe doit savoir laquelle fait foi lorsque deux documents se contredisent.
Les skills peuvent regrouper des instructions et des ressources pour une activité récurrente. Les commandes facilitent le déclenchement de certaines opérations. Les connexions à des outils donnent accès à des données ou à des actions. Chacun de ces éléments mérite une fonction précise et un responsable de son entretien.
L’enjeu devient visible lorsqu’on reprend une session : que reste-t-il à faire, qu’a-t-on vérifié, qu’a-t-on décidé ? Une note de progression exacte peut éviter davantage de reprises qu’une nouvelle couche d’orchestration.
Définir les accès avec les actions possibles
Un agent qui peut lire un dépôt, exécuter des tests et proposer une modification n’a pas besoin des mêmes droits qu’un agent autorisé à déployer. Les accès doivent correspondre à la tâche et aux conséquences possibles.
Une information reçue d’un document ou d’un outil peut contenir des instructions malveillantes. Elle doit être traitée comme une donnée à examiner, et non comme une nouvelle autorisation. Les recommandations de l’OWASP sur les agents IA couvrent notamment ces risques d’injection et la limitation des permissions.
La validation humaine a elle aussi besoin d’être conçue. Si une personne reçoit des demandes trop nombreuses ou mal expliquées, elle peut finir par les approuver mécaniquement. Il faut lui montrer ce qui va changer, ce que l’action engage et les éléments qui permettent de décider.
Ajouter des contrôles qui apportent une preuve différente
Un test, une revue de code et un essai dans le navigateur ne détectent pas les mêmes défauts. Une bonne combinaison dépend du produit. Répéter plusieurs fois la même analyse peut coûter cher tout en conservant les mêmes angles morts.
Sur notre pratique de construction, les revues ont aussi montré qu’un constat doit être trié avant d’être corrigé. Certains bloquent la livraison. D’autres sont discutables, déjà couverts ou extérieurs au sujet. Les traiter tous immédiatement peut agrandir le chantier et créer de nouvelles régressions.
Le temps passé à examiner les rapports fait partie du coût de l’usine. Il faut regarder les erreurs détectées, les faux signaux et les reprises évitées. Une chaîne qui produit davantage de rapports qu’une équipe ne peut en comprendre demande à être revue.
Paralléliser lorsque les chantiers le permettent
Plusieurs agents peuvent avancer sur des sujets distincts. Cela suppose des espaces de travail isolés, des périmètres suffisamment clairs et une manière d’intégrer les résultats.
Lorsque les tâches dépendent fortement les unes des autres, la coordination peut annuler une partie du bénéfice. Deux agents qui modifient simultanément une même décision de conception ajoutent des divergences qu’il faudra ensuite résoudre.
Les travaux d’Anthropic sur les environnements de développement de longue durée, publiés en mars 2026, illustrent l’influence de l’environnement et de la répartition du travail sur les résultats. Ils décrivent une expérimentation d’ingénierie, pas un nombre idéal d’agents à reproduire.
Entretenir l’usine comme une partie du produit
Un changement de modèle peut rendre un dispositif moins utile. Une nouvelle contrainte peut exiger un contrôle supplémentaire. Une règle héritée d’un incident peut devenir trop générale.
L’équipe doit pouvoir faire ces changements sans perdre ce qui fonctionnait. Quelques tâches représentatives, rejouées avant et après une évolution, aident à comparer les résultats, les coûts et la charge de vérification. Les incidents réels enrichissent cet ensemble.
Chez The Spark, on construit cette organisation progressivement avec les équipes, à partir de leurs produits. Notre offre Repenser votre organisation relie l’usine agentique aux responsabilités et au cycle de vie du produit. Pour voir comment ces éléments se rejoignent dans une réalisation, le retour d’expérience sur The Playground en donne un exemple concret.