Études & Réflexions › Entreprise pilotée par des agents IA : ce que les threads ne disent pas

Depuis quelques mois, un genre de publication revient régulièrement sur les réseaux professionnels : le dirigeant qui a délégué son entreprise à des agents IA et qui, désormais, dort pendant qu'elle tourne. Le format est efficace, une capture d'écran, une punchline sur la fin du travail, un chiffre présenté sans méthode. Je ne vais pas démonter ces publications une par une, ce n'est pas l'objet de cet article.

Je pilote depuis plusieurs mois une activité de conseil en m'appuyant au quotidien sur un écosystème d'agents IA spécialisés, pas en démonstration ponctuelle mais en pratique continue. Cette expérience ne ressemble pas au récit qui circule. Ce qui suit décrit ce que je fais réellement, avec ce que ça permet et ce que ça coûte.

Le fantasme et la réalité opérationnelle

Le fantasme du pilote automatique repose sur une confusion entre deux choses différentes : déléguer l'exécution d'une tâche et déléguer la responsabilité de son résultat. La première se fait très bien avec des agents IA. La seconde ne se délègue pas, elle se vérifie.

Dans mon organisation, un humain et plusieurs agents spécialisés se partagent le travail, chacun avec un périmètre défini, coordonnés par un canal commun et une doctrine de fonctionnement versionnée comme du code. Ce n'est pas un pilote automatique, c'est une chaîne de production où chaque maillon peut se tromper, y compris, et surtout, en se déclarant lui-même correct.

C'est exactement ce que pointe Anthropic dans sa propre documentation sur la construction d'agents : la difficulté ne vient pas d'abord du modèle, elle vient de l'absence d'organisation et de gouvernance autour de lui. Un agent puissant sans cadre de vérification n'est pas un collaborateur fiable, c'est un générateur rapide d'affirmations plausibles.

Ce que la doctrine appelle le faux-done

Le terme que j'utilise en interne pour désigner ce risque est le faux-done : un agent annonce qu'une tâche est terminée, dans un langage clair et assuré, alors que le travail réel ne le confirme pas.

Les formes concrètes sont banales une fois qu'on les a vues une première fois. Un statut « fait » sur une tâche que l'historique de version ne montre nulle part. Un service annoncé actif qui ne traite plus rien depuis un moment. Une suite de tests qui passe au vert parce qu'elle valide un état vide plutôt que le comportement attendu. Rien de tout cela n'est de la malveillance : c'est la conséquence directe de la capacité d'un modèle de langage à produire un compte rendu cohérent et confiant, indépendamment de ce qui s'est réellement passé.

Ce risque n'est pas théorique. Plusieurs cas de ce type ont été observés et documentés dans cette organisation, sur des sujets sans rapport entre eux. Ce ne sont pas des scénarios hypothétiques évoqués par prudence, ce sont des incidents réels, chacun suivi d'une correction.

La réponse n'est pas de faire moins confiance aux agents, c'est de ne jamais confondre un statut annoncé avec un fait vérifié. C'est le même principe que j'applique quand j'évalue la fiabilité d'une sortie de modèle dans un processus de gestion, développé plus en détail dans l'article sur la fiabilité de l'IA dans un processus de gestion.

Une garde qu'on sabote soi-même pour vérifier qu'elle marche

Le point le plus contre-intuitif de ma pratique est probablement celui-ci : chaque nouvelle garde, chaque nouveau contrôle automatisé ajouté au système, est volontairement mis en échec une fois avant d'être considéré comme fiable.

La logique est simple. Une garde qui n'a jamais rien détecté n'a pas forcément toujours réussi, elle n'a peut-être simplement jamais été mise à l'épreuve. Introduire délibérément, une fois, le défaut exact que le contrôle est censé repérer, et vérifier qu'il le repère effectivement, est la seule manière de savoir si on peut lui faire confiance ou si on a construit un système qui se contente d'être toujours d'accord avec ce qu'on lui montre.

C'est un principe emprunté à une pratique ancienne du développement logiciel, celle du test qui doit d'abord échouer pour prouver qu'il teste réellement quelque chose. Appliqué à la gouvernance d'agents IA, il devient un réflexe permanent plutôt qu'une étape ponctuelle, précisément parce que le faux-done, lui, est permanent.

Ce que ça permet réellement

Je ne veux pas donner l'impression que le résultat n'est que du contrôle. Une délégation bien structurée permet de mener plusieurs livrables en parallèle sur un même créneau de travail, un volume qu'une équipe réduite n'absorberait pas au même rythme sans délégation.

Mais ce type de résultat n'est possible qu'à une condition précise : l'arbitrage humain ne doit jamais être suspendu, il change simplement de forme. Au lieu d'exécuter chaque tâche, je valide, je questionne un statut annoncé, je demande une preuve avant de considérer un sujet clos. C'est ce déplacement, de l'exécution vers l'arbitrage continu, qui rend la vitesse utilisable sans devenir dangereuse. Sans lui, le même volume de travail produirait simplement plus d'erreurs plausibles à la même vitesse, ce que développe bien l'analyse de MIT Sloan Management Review sur la mesure du retour d'un projet IA : la vitesse d'exécution n'a de valeur que rapportée au coût des erreurs qu'elle laisse passer.

Le travail ne disparaît pas, il se déplace

C'est la conclusion que je tire de plusieurs mois de pratique, et elle contredit directement le récit du dirigeant qui dort : déléguer l'exécution à des agents IA ne réduit pas le travail du dirigeant, ça le déplace vers la vérification. Ce déplacement est un travail à part entière, moins visible qu'une tâche exécutée, plus exigeant qu'il n'y paraît, et il ne se délègue pas à l'agent qui a produit le résultat qu'on est en train de vérifier.

MIT Sloan Management Review formule un constat proche dans ses travaux sur la gouvernance des systèmes agentiques à l'échelle : une gouvernance adaptative, intégrée aux flux de travail et aux droits de décision plutôt qu'appliquée en pratiques ponctuelles, est la capacité qui permet de suivre des systèmes qui évoluent vite. C'est très exactement ce que le sabotage volontaire des gardes tente de garantir : que le contrôle reste actif, pas qu'il ait existé un jour.

FAQ

Qu'est-ce qu'une entreprise pilotée par des agents IA, concrètement ?

Ce n'est pas une entreprise sans humain, c'est une entreprise où l'exécution d'une partie des tâches est déléguée à des agents IA spécialisés, chacun avec un périmètre défini, un canal de coordination commun et une doctrine de fonctionnement partagée et versionnée. Le dirigeant ne disparaît pas de la boucle : il arbitre, valide, et surtout vérifie que ce qui lui est rapporté correspond à ce qui a été réellement fait. C'est une organisation, pas un pilote automatique.

Le dirigeant travaille-t-il vraiment moins avec des agents IA ?

Non, et c'est le point le plus mal compris des récits viraux. Le volume de travail d'exécution baisse, c'est réel. Mais un nouveau travail apparaît en remplacement : la vérification. Une tâche annoncée « faite » par un agent n'est pas un fait, c'est une affirmation, et l'écart entre les deux est justement ce qui échappe à un dirigeant qui ne contrôlerait pas. Le temps gagné sur l'exécution se retrouve en grande partie réinvesti dans le contrôle.

Qu'est-ce que le faux-done et pourquoi est-ce un risque spécifique aux agents IA ?

Le faux-done désigne un statut « terminé » annoncé par un agent alors que le travail réel ne le confirme pas : un service annoncé actif qui ne traite plus rien, une suite de tests qui valide un état vide plutôt que le comportement attendu, un correctif annoncé alors que l'historique ne montre aucune modification. Le risque est spécifique aux agents IA parce qu'ils produisent un compte rendu plausible et bien formulé indépendamment de la réalité du travail effectué, ce qui rend l'erreur plus difficile à repérer qu'un simple oubli humain.

Pourquoi saboter volontairement ses propres gardes-fous ?

Parce qu'une garde qui n'a jamais été mise en échec n'a jamais prouvé qu'elle fonctionnait, elle a seulement toujours été d'accord avec ce qu'on lui a montré. La pratique consiste à introduire volontairement, une fois, le défaut que la garde est censée détecter, pour vérifier qu'elle le détecte réellement avant de lui faire confiance en production. C'est le même principe qu'un test qui doit d'abord échouer pour prouver qu'il teste quelque chose.

Quelles limites ce mode de fonctionnement a-t-il aujourd'hui ?

La principale est que la vérification ne se délègue pas au même agent qui a produit le travail : elle demande un regard indépendant, humain ou agent distinct, ce qui a un coût réel et ne se compresse pas indéfiniment. La seconde est que la vitesse d'exécution rendue possible, plusieurs livrables produits en parallèle par exemple, ne vaut que si l'arbitrage humain suit au même rythme. Sans cet arbitrage continu, la vitesse ne fait qu'accélérer la production d'erreurs plausibles.

Brice Béchet

Consultant en pilotage des organisations

Contrôleur de gestion sénior, data scientist et créateur d'effectivo.fr, application de prévision stratégique des effectifs (Anticipez. Simulez. Décidez), j'accompagne les organisations à structurer leurs données et optimiser leur pilotage.

En savoir plus LinkedIn