Si vos agents IA échouent, ce n'est pas l'IA — c'est votre organisation
- il y a 4 jours
- 8 min de lecture
Un agent builder m'a écrit la semaine dernière. Son projet d'agent allait être abandonné.
Trois semaines à genoux sur ses prompts. Il a changé de modèle, dans un sens puis dans l'autre ; poussé la fenêtre de contexte de 8K à 200K ; empilé les outils de 3 à 27 ; gonflé le system prompt de 400 à 3 000 mots. L'agent continue de surprendre : tantôt il appelle les mauvais outils, tantôt il se fige en pleine exécution, tantôt il dépasse ses droits et supprime une base de production. Il me demande quoi faire.
Je n'ai pas répondu. Je lui ai demandé la feuille de route que son patron lui avait donnée. Il me l'a envoyée : trois diapos. Une d'objectifs stratégiques, une avec un camembert intitulé « la cartographie IA de l'activité », une de planning.
Je lui ai dit : ce que tu règles, ça n'a jamais été l'IA. Tu crois faire de l'ingénierie de contexte ; en réalité tu combles ce que ton patron n'a pas écrit. Tu crois l'agent idiot ; en réalité toute ton entreprise est incapable de dire clairement « ce que je veux » — tu es juste le premier que cette maladie a frappé. Le taux d'échec des agents est le miroir de la capacité organisationnelle. Si le contexte que vous donnez à vos collaborateurs humains est flou, celui que vous donnez à l'agent l'est forcément plus.
L'armée américaine a nommé cette maladie il y a quarante ans et l'a écrite dans sa doctrine. Tout ce que vous faites aujourd'hui a son paragraphe dans le FM 100-5 de 1982 — sauf que vous croyez résoudre un problème d'IA avec du Python.
Première porte : le commandement par intention se moque de savoir qui exécute
Une erreur d'abord. Beaucoup lisent le mission command (commandement par intention) comme une « délégation bienveillante » : faire confiance à la base. C'est faux. Le FM 6-0, la doctrine de commandement, martèle autre chose, glaçant d'ingénierie : l'intention du commandant doit être de celles que les deux échelons inférieurs peuvent retenir, reformuler, et rappeler sous pression.
Trois propriétés, donc. Transmissible — une phrase comprise deux échelons plus bas. Compressible — sans dépendre d'un épais dossier de contexte. Rappelable sous pression — radio brouillée, chef tombé, soldats dispersés, balles au-dessus de la tête, l'intention démarre encore, à l'identique, dans chaque tête.
Ce n'est pas du management. C'est du design d'interface. On n'écrit pas une spec d'API pour faire plaisir au front ; on l'écrit pour que le front, même remplacé, ne casse pas. L'armée n'écrit pas l'intention pour flatter le soldat ; elle l'écrit pour que, le chef de groupe tombé, le suivant prenne le relais et que ça tourne encore. En 1982, l'armée a sorti la variable « qui exécute » du système de commandement. Le mot même de mission command insiste : le porteur de l'ordre est la mission, pas le commandant, pas le soldat. Remplacez le bout de chaîne par n'importe qui : si l'intention est assez compressée et passe deux échelons, la mission tourne toujours.
Ils n'ont pas fait ça en prévoyant l'IA. Ils l'ont fait parce que le bout de chaîne n'est jamais fiable — blessé, capturé, coupé, remplacé, ou simplement tétanisé. L'armée ne peut pas parier sur un cerveau précis ; seulement sur la robustesse du protocole d'intention. Plus tard, l'armée de l'air pousse le principe : commandement centralisé, contrôle distribué, exécution décentralisée. Selon la ressource, le point optimal de centralisation diffère — satellites et armes nucléaires très centralisés, sections d'infanterie très décentralisées. Sur toute la courbe, la seule constante est cette interface d'intention transmissible, compressible, démarrable.
Deuxième porte : trois échecs de délégation, une seule spec manquante
Ramenez l'interface dans votre entreprise. Embarrassant : la plupart des patrons ne savent pas en écrire la spec de base. Trois échecs que vous connaissez.
Un : déléguer l'exécution, pas l'intention. « Occupe-toi de ça. » L'employé exécute, arrive à trois carrefours, et à chacun craint de se faire réprimander quel que soit le choix — parce que le patron n'a pas dit « ce que je veux ». Il revient demander à chaque pas. L'ordre est délégué, pas la bande passante de décision. Le rythme réel d'un projet, c'est la vitesse à laquelle le patron valide, pas celle à laquelle l'employé produit.
Deux : donner l'objectif, pas les limites. « Le trimestre prochain, plus 30 %. » L'employé tire la marge, sacrifie la conformité, fâche les autres services, presse les clients clés jusqu'à l'os. Le patron s'indigne : comment as-tu pu ? L'employé reste figé : tu n'as jamais dit que c'était interdit. Les « limites par défaut » dans la tête du patron n'ont jamais été écrites.
Trois, le plus destructeur : déléguer puis micro-manager. L'employé avance seul, le patron voit un détail qui lui déplaît et démonte le travail ligne à ligne. À la fin, l'employé ne sait plus ce qu'il fait et revient au mode « décide à ma place ». Déléguer puis reprendre fait plus de mal que ne jamais déléguer : la fois suivante, il ne juge plus seul.
Vous voyez pourquoi le mission command écrit l'interface ainsi : il ne soigne pas le chaos du champ de bataille, il soigne ces trois maladies. « L'intention doit être retenue deux échelons plus bas » correspond exactement à « dis clairement ce que tu veux ». « Exécution décentralisée » correspond à « ne reviens pas micro-manager ».
Comparez. Une bonne intention : « Ce trimestre, non pas maximiser la marge, mais décrocher trois clients vitrines du secteur. La vitesse prime sur la marge, mais on ne touche pas la ligne rouge de la conformité. Effectifs libres, mais ne débauchez pas chez le concurrent X. » Objectif, priorité d'arbitrage, ligne rouge, zone interdite. Lisible une fois, transmissible deux échelons. Une mauvaise intention : « La croissance avant tout. » « Jugez vous-mêmes. » « On met le paquet. » « Objectif : leader du secteur. » Reformulée d'un échelon à l'autre, elle se déforme dès le deuxième relais.
Note de terrain — un responsable IA en grand groupe : « Mon patron me court après sur le ROI de l'IA — alors qu'il n'a même pas su cadrer ses propres N-1. Pour écrire le prompt de l'agent, je dois d'abord deviner ce que veut le patron, puis ce que font ses N-1. L'agent n'est pas idiot ; c'est notre organisation qui l'est. »
Troisième porte : l'agent porte la maladie au niveau du code
Les deux premières portes parlaient d'humains. L'humain n'est pourtant pas le sujet — il n'est que le bout de chaîne utilisé, par défaut, pendant quelques millénaires.
La langue humaine transmet environ 39 bits par seconde. La pensée consciente, environ 10. Ce sont les plafonds physiques mesurés sur 17 langues (Science Advances), recoupés par Caltech. Un grand modèle, lui, sort l'équivalent de plusieurs centaines de bits par seconde. Deux mondes d'ordres de grandeur différents : ce qu'une réunion humaine met trois heures à aligner, deux agents l'alignent en trois secondes, et redemandent la tâche suivante.
L'inefficacité d'une entreprise n'est pas un problème de management, c'est un rapport de bande passante. Un manager ne pilote que 5 ou 6 personnes ; l'info monte et descend une douzaine d'étages ; la décision pourrit en route — ce ne sont pas des défauts de méthode, c'est le plafond physique du cerveau humain. Depuis des millénaires, l'organisation n'a qu'un recours : compresser l'intention en une interface minuscule, puis empiler des relais humains sur le goulot. Le mission command est l'algorithme de compression ; la hiérarchie, le routeur ; rapports hebdomadaires, OKR, points individuels, autant de rustines contre le même problème de bande passante.
Puis l'agent arrive. Les mêmes échecs reparaissent, habillés de code. Objectif sans limites : il vagabonde — c'est le « débrouille-toi » du patron. Outils sans priorité d'appel : il dépasse ses droits — c'est l'employé qui tire des ressources d'un autre service pour son KPI. Plusieurs agents sans règle de coordination : ils se percutent — c'est la guerre entre services. Planification sans contexte suffisant : il hallucine un plan — c'est le nouveau qui devine ce que veut le patron. Correspondance terme à terme. Les quatre échecs de délégation ne sont pas liés au support « humain » ; ils sont liés à « l'interface d'intention mal définie ». Changez le support pour du code : le défaut ne change pas, il éclate plus vite.
L'humain, au moins, masque. Il devine, rattrape, répare en douce avant que le patron ne voie. L'agent, non : il rejoue à 100 fois la vitesse, amplifié 100 fois, chaque trou que votre patron n'a pas comblé. Voilà pourquoi l'agent est un miroir.
Déduisons. L'agent IA ne détruit pas le mission command. Il en est le bout de chaîne parfait, enfin accordé en bande passante, que le mission command attendait depuis quarante ans. Avant, en aval de votre interface d'intention, un humain à 39 bits/s : il fallait compresser, répéter, ajouter de la redondance. Désormais, en aval, une chose à plusieurs centaines de bits/s : l'interface ne change pas — le point optimal de la courbe de centralisation glisse seulement vers le décentralisé. À une condition : que l'interface existe.
Note de terrain — un CEO de startup : « 30 000 € dans un système d'agents, l'équipe s'en sert mal. J'allais accuser l'agent ; j'ai relu mes propres messages et trouvé mon "débrouille-toi" envoyé à mon associé. Le contexte que je donne aux humains est déjà comme ça — qui vais-je accuser ? »
Conclusion : votre interface d'intention
Revenons à l'agent builder. Il croyait régler des prompts, faire de l'ingénierie de contexte, traiter un problème d'IA. Il ne réglait pas l'IA. Il tentait de combler une interface que son patron n'avait jamais écrite — une interface qui tournait tant bien que mal grâce à son supérieur direct, recalibrée à la main quelques fois par semaine, et que l'on a soudain confiée à une machine à plusieurs centaines de bits/s. Toute la dette a basculé d'un coup dans son fichier de prompt. Évidemment qu'il n'en voit pas le bout.
Et une chose inconfortable, pour lui comme pour moi : vos techniques de prompt d'aujourd'hui — ordonner les chunks de RAG, l'ordre des appels d'outils, la compression de mémoire — je ne sais pas lesquelles survivront à l'an prochain. La bitter lesson avale les astuces d'ingénierie l'une après l'autre. Mais « compresser l'intention en une interface démarrable deux échelons plus bas » ne sera pas écrasé : ce n'est pas une méthode technique, c'est une loi physique d'organisation. Du soldat à l'employé, puis de l'employé à l'agent, la loi n'a pas bougé.
Je n'essaie donc pas de rendre votre IA plus forte. Elle est déjà assez forte ; son plafond dépasse depuis longtemps celui de la plupart des organisations — d'où la mort à mi-chemin de tant de projets d'agents : ce n'est pas l'agent qui touche le plafond, c'est l'organisation qui touche le sien d'abord. Réglez d'abord l'interface d'intention. Réglée, l'agent s'y branche tout seul. Mal réglée, dix générations de modèles ne vous sauveront pas. Vous croyez faire de l'ingénierie de contexte IA — vous ne faites que réécrire en Python le devoir que l'armée américaine rendait il y a quarante ans.
FAQ
Pourquoi mes agents IA échouent-ils malgré un modèle puissant ? Parce que le goulot n'est pas le modèle, mais l'interface d'intention — objectif, priorités, lignes rouges — que personne n'a écrite clairement. L'agent amplifie ce flou.
Qu'est-ce qu'une bonne intention au sens du mission command ? Une consigne transmissible, compressible et rappelable sous pression deux échelons plus bas : objectif, arbitrage de priorités, ligne rouge, zone interdite.
Quelle compétence ne sera pas rendue obsolète par les modèles ? Compresser l'intention en une interface que deux échelons inférieurs peuvent démarrer. C'est de la physique organisationnelle, pas une astuce technique.
ECTIME AI Lab est l'unité de recherche et de déploiement en IA appliquée du groupe ECTIME. Nous construisons, livrons et éprouvons des systèmes agentiques en production. Notre axe : la vérification et la gouvernance d'exécution. Nous maintenons des Claude Skills open source pour le GEO/SEO et accompagnons les marques européennes vers une IA non seulement autonome, mais vérifiable et autorisée.
Commentaires