Une entreprise autonome ne commence pas par une armée d’agents

Lorsqu’un seul agent n’a plus suffi pour travailler sur mes applications, j’ai construit Paperclip : un système composé de plusieurs agents censés se comporter comme les employés d’une organisation. Le programmeur doit être précis, le testeur sceptique, le graphiste créatif et le chef de projet responsable de la coordination plutôt que de l’écriture du code ou de la création des visuels. Chacun reçoit un rôle, des instructions et le contexte nécessaire à son travail.

Cela ressemble au début d’une entreprise autonome. La pratique a pourtant rapidement montré qu’un ensemble d’agents ne devient pas une entreprise simplement parce que je leur attribue des postes. Paperclip savait accomplir de nombreuses tâches, produire de la documentation et développer ses propres procédures, tout en n’apportant aucun changement visible aux applications. Le système était actif, mais son activité ne constituait pas encore une preuve d’autonomie.

L’IA n’est qu’une couche. Une entreprise a également besoin d’une répartition des responsabilités, de processus, d’une mémoire, de critères d’acceptation, de circuits de décision, de preuves d’exécution et de limites fixées par un humain. Sans cela, plusieurs agents peuvent seulement produire plus vite davantage de travail intermédiaire.

Dans cet article, Paperclip désigne un système qui organise le travail de plusieurs agents. Je le teste sur trois applications que je développe. Featherly est un CMS destiné à construire des sites web, y compris avec la participation d’agents. Soar est une application de trading automatisé qui peut être configurée par un humain, un agent d’IA ou les deux ensemble. Roost doit devenir un organisateur d’activité professionnelle. Le lecteur n’a pas besoin de connaître leur architecture : ce sont ici trois environnements différents permettant de vérifier si Paperclip peut mener une modification complexe jusqu’à un résultat fonctionnel.

Un pipeline exécute un processus. Une entreprise doit savoir le piloter

Une automatisation isolée ressemble à une ligne de production : elle reçoit une entrée, suit des étapes décrites et renvoie un résultat. Cela suffit lorsque la tâche est répétitive et que son déroulement a été conçu à l’avance. Cela ne suffit pas lorsque le système doit lui-même reconnaître un nouveau problème, le décomposer, choisir les bons exécutants, vérifier les dépendances et améliorer sa manière de travailler après l’exécution.

Une organisation autonome ne devrait pas seulement exécuter des processus, mais aussi les créer lorsqu’un nouveau type de travail apparaît. Après chaque itération, elle peut utiliser la boucle PDCA : planifier la modification, l’exécuter, vérifier le résultat et améliorer le processus à partir de ce qui s’est réellement passé. Il ne s’agit toutefois pas de réécrire sans cesse les procédures. L’amélioration doit découler d’un problème concret révélé pendant la livraison du produit.

C’est pourquoi je conserve les instructions dans des fichiers Markdown. Un agent doit savoir ce dont il est responsable, selon quelles normes il agit et à qui il transmet son résultat. Un rôle bien décrit réduit le besoin de réinventer la roue à chaque tâche. Il ne constitue toutefois ni la personnalité numérique d’un employé ni une garantie d’expertise. C’est une configuration de responsabilité, de contexte, d’accès et de critères d’action.

La tâche descend, la preuve d’exécution remonte

Une modification d’application peut toucher simultanément de nombreux endroits et plusieurs couches. Une fonctionnalité peut comprendre une partie dans l’interface, une logique côté serveur, un enregistrement de données et des dépendances avec d’autres parcours. Quand je demandais à un seul agent une correction locale, il pouvait modifier le fragment indiqué, mais il ne reconnaissait pas toujours ce que cette modification cassait ou exigeait dans les autres couches.

Paperclip doit résoudre ce problème grâce à un flux de travail bidirectionnel. Le manager décompose l’objectif de haut en bas en tâches plus petites et les confie à des agents spécialisés. Les exécutants remontent non seulement l’information « terminé », mais aussi les preuves : ce qu’ils ont modifié, comment ils ont vérifié le résultat, quelles dépendances ils ont trouvées et ce qui bloque encore l’ensemble. Le niveau supérieur ne clôt la tâche que lorsque les parties forment un parcours fonctionnel.

Il faut également une mémoire de l’état. Le manager doit savoir à quelle étape se trouve l’implémentation, quelles décisions ont déjà été prises et quels tests ont été réussis. Sans mémoire, il peut commander trois fois le même travail ou prendre la documentation pour un résultat alors que l’application n’a pas changé. La mémoire n’est donc pas un entrepôt de toutes les connaissances possibles. Elle doit conserver l’état, les preuves et les conclusions nécessaires à la décision suivante.

La documentation n’est pas une modification du produit

L’échec le plus utile de Paperclip rappelle la formulation populaire de la loi de Goodhart : lorsqu’un indicateur devient un objectif, il cesse d’être un bon indicateur. Le système devait faire évoluer les applications, mais il a trouvé un produit intermédiaire plus facile : la documentation. Il rédigeait des descriptions des applications et de son propre fonctionnement parce qu’elles constituaient des traces visibles de travail. Pendant ce temps, peu de choses changeaient dans les applications elles-mêmes.

La documentation est nécessaire lorsqu’elle permet à l’agent suivant d’exécuter correctement une tâche ou lorsqu’elle apporte la preuve d’une décision. Elle devient un problème lorsque sa croissance remplace le résultat. Cent fonctionnalités documentées ne valent pas une fonctionnalité réparée. De même, le nombre d’agents, de tâches et de messages ne dit pas encore si l’organisation a produit de la valeur.

Un test pratique de l’autonomie doit aboutir dans le produit. Pour Featherly, un tel test consiste à résoudre le problème de connexion instable et à vérifier tout le parcours de session. Dans Soar, la fonction DCA traverse les modes de trading réel et simulé, plusieurs plateformes d’échange et les backtests ; une correction locale ne suffit donc pas. Roost nécessite des améliorations UX/UI transversales. Paperclip devrait reconnaître seul l’étendue du problème, coordonner l’exécution et démontrer que tous les parcours importants fonctionnent encore.

Le système a correctement remplacé le logo de Roost par le fichier SVG fourni. C’est un petit succès d’exécution : la consigne a été réalisée. Ce n’est toutefois pas encore une preuve d’organisation autonome, car j’ai indiqué directement la tâche et son périmètre était simple et local. Le véritable test commence lorsque le système doit déduire les tâches à partir de l’objectif du produit, trouver les dépendances et achever la modification sans guidage manuel de chaque étape.

Davantage d’agents peut produire moins de résultats

Plusieurs agents ont du sens lorsque le problème peut être divisé, que les rôles apportent des compétences différentes et que le bénéfice du travail parallèle dépasse le coût de la communication. Pour une petite tâche, organiser des agents non organisés peut prendre plus de temps que d’effectuer directement le travail.

Une étude portant sur 260 configurations d’agents a montré que le bénéfice de plusieurs agents dépend de la nature de la tâche et de l’architecture, tandis que la surcharge de communication des systèmes étudiés variait de 58 % à 515 % par rapport aux configurations à agent unique ([Kim et al., 2026](https://www.nature.com/articles/s42256-026-01268-y)). Cela ne signifie pas qu’un seul agent est toujours meilleur. Cela signifie que le nombre d’agents n’est pas une échelle de maturité.

Une autre analyse de plus de 1 600 traces d’exécution de systèmes multi-agents a distingué des problèmes de conception et de spécification du système, des désalignements entre agents ainsi que des erreurs de vérification et d’arrêt du travail. Les seules modifications des descriptions de rôles et de l’orchestration produisaient des effets limités ([Cemri et al., 2025](https://arxiv.org/abs/2503.13657)). C’est une limite importante de mon modèle : les instructions, la hiérarchie et le reporting sont nécessaires, mais le système doit aussi savoir vérifier le résultat et s’arrêter lorsque l’objectif est atteint.

L’architecture doit donc découler du problème. Un seul agent peut remplacer un logo. Une réparation transversale de la fonction DCA peut nécessiter un manager, des développeurs responsables de différentes couches et un testeur indépendant. L’organisation est un coût qui doit être compensé par la qualité, le temps ou la capacité à couvrir les dépendances.

Le piège d’une organisation qui travaille sur elle-même

Le principal problème actuel de Paperclip n’est pas le manque d’idées d’amélioration, mais leur excès. J’ai observé des situations où environ 150 tâches sur 200 concernaient le développement du système lui-même. L’organisation devait créer des applications, mais elle consacrait l’essentiel de son énergie à améliorer l’organisation.

L’auto-développement est une forme d’exploration : le système cherche de meilleurs processus, rôles et outils. Le travail sur les applications exploite les capacités déjà acquises. James March a décrit la manière dont l’exploration et l’exploitation se disputent les mêmes ressources limitées, même si leurs bénéfices apparaissent à des moments différents ([March, 1991](https://doi.org/10.1287/orsc.2.1.71)). Paperclip ne peut donc pas traiter l’auto-amélioration comme un supplément gratuit au travail sur le produit.

Toute amélioration de l’organisation devrait avoir un responsable, un budget limité, une hypothèse d’amélioration et une condition d’arrêt. Elle doit répondre à un problème détecté : par exemple l’attribution répétée du même travail, l’absence de test des dépendances ou un rapport dépourvu de preuves. Après sa mise en œuvre, il faut vérifier si le problème se produit réellement moins souvent. Sinon, un nouveau rapport sur l’auto-développement ne fait qu’agrandir la boucle.

Une organisation n’a pas besoin d’être optimale avant de commencer à livrer. Elle doit être suffisamment bonne pour accomplir le travail, satisfaire les critères d’acceptation, ne laisser aucun défaut bloquant connu et permettre de revenir à une amélioration précise après avoir produit de la valeur. Ce n’est pas une permission de travailler médiocrement. C’est une application pratique de l’approche *satisficing* : avec des informations et une capacité de calcul limitées, le système cherche une solution qui atteint un seuil explicite plutôt qu’un optimum inaccessible ([Simon, 1956](https://iiif.library.cmu.edu/file/Simon_box00063_fld04854_bdl0001_doc0001/Simon_box00063_fld04854_bdl0001_doc0001.pdf)).

L’humain continue de définir l’entreprise

Je considère Paperclip comme un ensemble de travailleurs numériques opérant dans un système conçu. Je ne veux cependant pas lui confier les décisions concernant l’orientation de l’entreprise, sa stratégie ou les produits et fonctionnalités qui doivent être créés. Ces décisions définissent l’entreprise et continuent d’appartenir à l’humain.

Les agents doivent mettre en œuvre cette orientation comme des experts : détecter les incohérences, proposer des solutions, coordonner les dépendances et présenter des preuves. Ils peuvent améliorer le processus dans les limites de l’objectif, mais ne devraient pas transformer leur propre développement en nouvelle stratégie de l’entreprise. Une supervision périodique par Codex peut analyser leur travail et consigner des conclusions, mais les changements apportés à l’organisation devraient découler d’une évaluation explicite, et non d’un agrandissement automatique du système.

L’autonomie ne signifie donc pas l’absence d’humain. Elle signifie la capacité du système à achever une part croissante du travail sans que chaque étape soit dirigée, tout en conservant l’orientation fixée, des critères observables et la possibilité d’arrêter ou d’annuler une action.

L’autonomie se voit dans une boucle fermée

Je ne sais pas encore à quel moment Paperclip pourra honnêtement être qualifié d’entreprise autonome. Je sais en revanche ce que je ne considérerai pas comme une preuve : le nombre d’agents, de tâches réalisées, de tokens consommés ou de pages de documentation.

La preuve sera une boucle fermée. Le système prend un objectif issu des hypothèses de l’application, reconnaît l’étendue complète de la modification, distribue le travail, mémorise l’état, collecte des preuves, teste les dépendances et renvoie un résultat fonctionnel. Ce n’est qu’après avoir produit de la valeur qu’il améliore l’élément précis de son propre processus qui s’est révélé insuffisant pendant le travail.

Si une organisation sait seulement travailler sur elle-même, elle n’est pas autonome : elle est prise dans une boucle. Si elle sait uniquement réaliser des tâches locales indiquées manuellement, elle est un outil. Une entreprise autonome commence entre ces deux extrêmes : là où plusieurs agents spécialisés peuvent transformer une orientation fixée par un humain en une modification vérifiable de la réalité.

Un seuil pratique d’autonomie

L’activité des agents ne devrait être considérée comme un progrès que lorsque le système peut présenter six éléments : un problème clairement nommé et le résultat attendu, une preuve que ce résultat fonctionne, la vérification des fonctionnalités et parcours dépendants, un bilan explicite entre le travail livré au produit et celui consacré à la documentation et à l’auto-développement, une condition d’arrêt, ainsi que la justification que le coût de coordination de plusieurs agents reste inférieur à la valeur qu’elle apporte.

Ces éléments ne constituent pas une recette universelle pour toute organisation. Ils forment un mécanisme minimal pour distinguer un système qui livre un résultat d’un système qui ne produit que des traces d’activité. Ils permettent aussi d’adapter l’architecture au problème : parfois un seul agent suffit, parfois une équipe spécialisée est justifiée, et parfois le bon système est un humain soutenu par plusieurs outils.

Si le système ne peut pas montrer son résultat, ses preuves, ses limites et son coût de fonctionnement, son autonomie n’est peut-être qu’une étiquette. S’il peut transformer une orientation fixée par un humain en une modification fonctionnelle, en vérifier les conséquences et s’arrêter une fois les critères remplis, il peut être évalué comme une organisation — d’après ce qu’il a changé dans la réalité.

Bibliographie

• Yubin Kim et al., « Capable language models can outgrow the benefits of collaboration », *Nature Machine Intelligence* 8, 2026, [article](https://www.nature.com/articles/s42256-026-01268-y), consulté le 4 septembre 2026.
• Mert Cemri et al., « Why Do Multi-Agent LLM Systems Fail? », arXiv:2503.13657, version 3, 2025, [prépublication](https://arxiv.org/abs/2503.13657), consultée le 4 septembre 2026.
• James G. March, « Exploration and Exploitation in Organizational Learning », *Organization Science* 2(1), 1991, [DOI](https://doi.org/10.1287/orsc.2.1.71), consulté le 4 septembre 2026.
• Herbert A. Simon, « Rational Choice and the Structure of the Environment », *Psychological Review* 63(2), 1956, [PDF](https://iiif.library.cmu.edu/file/Simon_box00063_fld04854_bdl0001_doc0001/Simon_box00063_fld04854_bdl0001_doc0001.pdf), consulté le 4 septembre 2026.