L'expression « main-d'œuvre IA » est employée par des gens qui n'ont jamais eu à en gérer une. Moi, si. Sur mon propre site, des agents Claude Code en parallèle ont réécrit une bibliothèque de prompts, trié un corpus de blog de 581 articles et exécuté une remédiation SEO en sept lots, et la leçon la plus importante que j'en ai tirée est la suivante : une main-d'œuvre IA n'échoue pas comme des employés. Elle échoue avec assurance, de façon identique et à grande échelle. En construire une consiste moins à lancer des agents qu'à construire les systèmes qui les rattrapent, car la main-d'œuvre ne vaut que ce que valent ses contrôles qualité.
Cet article est le manuel de management que j'aurais aimé avoir avant ma première exécution multi-agents : ce en quoi les agents sont réellement bons dans une structure d'équipe, les trois modes de défaillance dont j'ai personnellement payé le prix, et le système d'exploitation qui a fait passer les agents en parallèle du stade de démo à la façon dont mon vrai travail est livré.
Ce qu'est réellement une main-d'œuvre d'agents
Débarrassée de l'habillage marketing, une main-d'œuvre IA, ce sont des sessions Claude Code en parallèle avec une division du travail. Une session orchestratrice décompose le travail ; des agents exécutants traitent des tranches avec leurs propres fenêtres de contexte ; les résultats remontent via des fichiers ou des sorties structurées. Claude Code prend cela en charge nativement grâce aux subagents, et grâce à la fonctionnalité plus récente agent teams, où les coéquipiers se coordonnent directement. La mécanique d'activation et de configuration des équipes se trouve dans mon guide de configuration des agent teams ; cet article porte sur ce qui se passe une fois la main-d'œuvre en place.
La raison de s'en donner la peine, c'est le débit sur un travail divisible. Quand j'ai reconstruit la couche de profondeur de ma bibliothèque de prompts, le travail représentait des centaines d'entrées, toutes indépendantes : une division du travail parfaite. Six vagues de subagents en parallèle ont rédigé 594 entrées en une seule session. Quand j'ai ensuite audité tout mon blog à la recherche de problèmes d'indexation, des agents de recherche ont chacun pris une tranche du corpus, et des agents de réécriture ont exploité leurs conclusions. Ce projet fonctionne comme un graphe explicite avec des nœuds numérotés et des points d'approbation, et c'est ce qui se rapproche le plus d'une vraie main-d'œuvre que j'aie jamais pilotée : division du travail, passations, suivi des statuts et une file d'escalade pour les décisions qui dépassent le niveau de responsabilité de n'importe quel agent.
Mode de défaillance un : l'uniformité assurée
Voici la leçon coûteuse. Si mon blog a eu besoin d'une réécriture d'urgence de 84 articles, c'est d'abord parce qu'un pipeline par lots antérieur, l'approche de la main-d'œuvre appliquée naïvement, avait généré les articles à partir d'un seul squelette. Chaque article s'ouvrait sur le même schéma de H2. Chaque article se terminait par un bloc de call-to-action identique à l'octet près. Des titres de section recyclés apparaissaient dans des dizaines d'articles. Pris individuellement, chaque article semblait correct. Pris dans leur ensemble, l'uniformité sautait aux yeux.
Une équipe humaine de dix rédacteurs diverge stylistiquement sans même essayer. Une main-d'œuvre d'agents qui reçoit le même brief converge, parce que c'est le même modèle qui applique les mêmes instructions. L'uniformité est la sortie par défaut de l'IA en parallèle, et il faut la combattre par conception : des angles propres à chaque exécutant, des sources de preuves attribuées à chaque exécutant et des contrôles d'unicité explicites au moment de la relecture. Aucune main-d'œuvre humaine n'a besoin d'un système anti-uniformité. Toute main-d'œuvre IA en a besoin.
Mode de défaillance deux : les collisions sur un état partagé
Deux agents qui modifient le même fichier produisent des écrasements silencieux, pas des conflits de merge. La solution est ennuyeuse et absolue : répartissez la propriété avant de lancer quoi que ce soit. Dans mes lots de réécriture, chaque exécutant recevait une liste explicite d'ID d'articles et écrivait des fichiers de sortie nommés par ID. Personne ne partageait une cible. Pour le travail sur du code, les git worktrees donnent à chaque agent un checkout isolé, ce qui est le même principe, imposé par le système de fichiers. Si deux exécutants doivent vraiment toucher une même ressource, cette ressource devient une tâche sérialisée à part entière. Aucun protocole de coordination astucieux ne vaut le fait de ne pas en avoir besoin.
Mode de défaillance trois : exécutants morts et état perdu
Les sessions meurent : limites d'utilisation, réseau, ratés de l'outillage. En plein lot, un workflow peut mourir avec des brouillons en cours. Ce qui a rendu ces morts peu coûteuses, c'est un fichier manifeste mis à jour de façon transactionnelle à l'achèvement de chaque unité de travail, si bien que la reprise consistait à « lire le manifeste, reprendre à partir de PENDING » plutôt qu'à une reconstitution digne d'une enquête. Une main-d'œuvre sans suivi d'état durable parie que rien n'échouera pendant l'exécution, et avec dix exécutants, les probabilités jouent contre vous. C'est autant une question de discipline de mémoire que d'orchestration ; mon système de mémoire à six niveaux explique où cet état devrait se trouver.
Le système d'exploitation : attributions, contrôles, escalade
Ce qui rend réellement la main-d'œuvre digne de confiance, ce sont trois éléments de processus, dont aucun ne relève du génie du prompt :
Des attributions délimitées par les preuves. Chaque exécutant reçoit non seulement une tâche, mais aussi le matériau source précis dans lequel il est autorisé à puiser. Mes agents de réécriture recevaient chacun un angle de preuve attribué, de sorte que l'instruction était « appuie ceci sur ce fichier » plutôt que « écris quelque chose de bien ». Cela réduit l'invention ; cela ne la supprime pas. Un audit ultérieur de ce lot a tout de même trouvé des affirmations sans rien derrière. Les briefs vagues sont la façon dont les agents finissent par inventer.
Des contrôles de vérification qui sont du code, pas des impressions. Chaque exécution par lots sur ce site se termine par un script de vérification déterministe : contrôles de structure, validation des liens par rapport à un index connu, détection des formulations interdites, notation de qualité minimale. Le travail qui échoue n'est pas livré, quelle que soit l'assurance de l'exécutant. Le vérificateur attrape ce que la fatigue de relecture laisse passer à l'article 47 sur 100. Les agents relisent poliment ; les scripts, non.
Une file d'escalade. Les exécutants trouvent des choses hors de leur mandat : un problème de sécurité, un problème de données, une décision qui exige un jugement humain. Sans formation, soit ils agissent dessus (dangereux), soit ils l'abandonnent (du gâchis). Mon fichier d'état du graphe inclut une liste d'escalade explicite où les agents déposent les découvertes auxquelles ils ne doivent pas toucher. Apprendre à une main-d'œuvre ce qu'elle ne doit pas faire s'est révélé aussi précieux que lui apprendre ce qu'elle doit faire.
La question des coûts, en toute honnêteté
Les agents en parallèle multiplient la consommation de tokens, et chaque exécutant relit son propre contexte au fil de son travail. Trois choses gardent mes exécutions économiques : les exécutants reçoivent un contexte léger et limité à leur tâche plutôt que le projet entier ; la taille des lots est réglée pour qu'un exécutant termine bien avant que sa fenêtre ne se dégrade ; et les passes de relecture coûteuses sont réservées au travail qui a franchi le contrôle déterministe bon marché. L'économie du contexte plus en profondeur se trouve dans mon article sur les limites de tokens et l'hygiène du contexte. Le résumé, pour ce qui concerne la main-d'œuvre : le parallélisme vaut son prix sur un travail divisible, et c'est un multiplicateur de gaspillage pour tout le reste.
Par où je commencerais à votre place
Ne commencez pas par un organigramme d'agents spécialisés. Commencez par une tâche divisible que vous comprenez déjà en profondeur : un lot de contenus, un effort de couverture de tests, une migration comportant de nombreuses unités similaires. Partitionnez-la, lancez deux ou trois exécutants avec des attributions délimitées, et construisez le vérificateur avant les exécutants. Gérez les sorties via des fichiers. Quand cette exécution se termine et que le contrôle attrape sa première erreur commise avec assurance, vous comprendrez le modèle de la main-d'œuvre mieux que ne pourrait vous l'apprendre n'importe quel schéma d'architecture, y compris le mien.
Le résumé honnête après quelques mois de cette pratique : les agents n'ont jamais été la partie difficile. La partie difficile, c'est que gérer une main-d'œuvre IA est une vraie compétence faite de composants peu glamour, la conception des attributions, le suivi d'état et la vérification adversariale, et que personne ne vous remet cette compétence avec le feature flag. La progression complète — premier subagent, attributions délimitées, contrôles déterministes, puis pipelines multi-agents — est présentée sous forme de parcours de cours dans mon AI School, construit à partir des exécutions en production décrites ici plutôt que de démos jouets.
