Les agents IA butent sur le désordre des entreprises

Microsoft Build 2026 a donné le ton de la saison : les agents IA ne sont plus présentés comme des démos de laboratoire, mais comme une couche normale du travail. Microsoft parle de Microsoft IQ, de Work IQ, de Fabric IQ, de Foundry IQ, de Web IQ. Le vocabulaire est lourd, mais le signal est clair. Le modèle n’est plus vendu seul. Ce qui se vend maintenant, c’est le contexte autour du modèle.

C’est une bonne nouvelle, à condition de la lire à l’envers.

Depuis deux ans, le marché raconte que l’agent IA est une question d’intelligence. Le modèle comprend mieux, raisonne plus longtemps, appelle des outils, planifie ses étapes, corrige ses erreurs. Donc il pourra travailler seul. Or les sources les plus récentes racontent autre chose : les agents progressent, oui, mais ils butent encore sur ce qui est le moins spectaculaire dans une entreprise. Les dossiers mal tenus. Les règles tacites. Les droits trop larges. Les responsabilités floues. Les sorties impossibles à vérifier.

Autrement dit : l’agent IA ne supprime pas le désordre organisationnel. Il le rend exécutable.

Le lancement produit n’est pas le signal

La tentation, devant Build 2026, est de commenter les noms. Scout, Work IQ, Web IQ, agents hébergés, mémoire, grounding, orchestration. C’est le théâtre habituel d’une grande conférence tech. Il compte moins que le déplacement de fond : même Microsoft ne vend plus l’agent comme une intelligence flottante. Il vend une infrastructure de contexte.

Work IQ observe comment le travail se fait dans Microsoft 365 : personnes, documents, réunions, mails, relations entre ces éléments. Fabric IQ donne une base sémantique sur les données structurées. Foundry IQ relie la connaissance interne et le web. Le message implicite est plus intéressant que le communiqué : sans contexte propre, un agent puissant devient un stagiaire pressé avec trop de droits.

Ce n’est pas une critique de Microsoft. C’est presque un aveu utile du marché. Les éditeurs les plus avancés reconnaissent que l’autonomie exige autre chose qu’un modèle. Il faut savoir ce que l’agent a le droit de voir, ce qu’il a le droit de faire, ce qu’il doit demander avant d’agir, quelle preuve il laisse derrière lui, et quel humain reste responsable quand la sortie est fausse.

Pour une PME, c’est la phrase à retenir. L’enjeu n’est pas d’avoir “des agents”. L’enjeu est de savoir quelles parties de l’entreprise peuvent supporter qu’un logiciel observe, raisonne et agisse dedans.

Les benchmarks ont raison, et ils trompent quand même

Le Stanford AI Index 2026 résume bien le paradoxe. L’adoption organisationnelle de l’IA atteint 88 %. Les performances techniques continuent de grimper. Sur OSWorld, un benchmark d’agents qui exécutent des tâches informatiques réelles, le taux de réussite est passé d’environ 12 % à environ 66 %. C’est un progrès massif.

Mais 66 %, c’est aussi un échec sur trois.

La phrase peut sembler injuste : aucun outil humain n’est parfait. Mais un agent n’échoue pas comme un tableur ou comme un salarié. Il échoue en agissant dans un système. Il peut cliquer, écrire, modifier, envoyer, déclencher. L’erreur n’est plus seulement une mauvaise réponse dans une fenêtre de chat. C’est un acte.

METR observe la même frontière dans son rapport de mai 2026. Les agents deviennent capables de réaliser des tâches techniques qui prendraient des dizaines de minutes ou plusieurs heures à un humain expert, surtout quand le progrès est facile à vérifier. Mais le même rapport souligne leurs faiblesses de jugement, de stratégie et de fiabilité. Les entreprises interrogées ne rapportent pas une délégation autonome des décisions de sécurité, de budget, de recrutement ou de direction scientifique. Les agents savent pousser des morceaux de travail. Ils ne savent pas encore porter l’arbitrage.

C’est exactement la distinction que les benchmarks masquent. Ils mesurent une tâche. L’entreprise demande une responsabilité.

Le contexte n’est pas une base documentaire

La réponse facile consiste à dire : donnons plus de documents à l’agent. C’est utile, mais insuffisant.

Un contexte de production n’est pas seulement une base documentaire. C’est un assemblage de règles, de priorités, de versions, de permissions, de exceptions et de personnes qui acceptent d’en répondre. Une procédure PDF de 2023 ne vaut rien si tout le monde applique en réalité la version modifiée par trois mails de 2025. Un CRM ne donne pas le contexte s’il mélange prospects dormants, clients actifs et contacts personnels. Un dossier partagé ne donne pas la vérité si deux fichiers portent le même nom avec des chiffres différents.

Dun & Bradstreet a publié en mai 2026 un chiffre brutal : 97 % des organisations déclarent des initiatives IA actives, mais seulement 5 % estiment que leurs données sont suffisamment prêtes. Le chiffre vient d’un acteur qui vend de la donnée, donc il faut le lire comme un signal de marché, pas comme une vérité gravée. Mais il colle à ce qu’on voit partout : les entreprises achètent de l’intelligence avant de préparer la matière sur laquelle elle doit travailler.

L’agent IA est particulièrement cruel avec cette faiblesse. Un chatbot peut répondre “je ne sais pas” ou halluciner dans son coin. Un agent, lui, doit choisir la source, décider l’action suivante, parfois modifier l’état d’un système. S’il reçoit un contexte contradictoire, il ne ralentit pas forcément. Il tranche. Et c’est souvent là que le problème commence.

La permission est un coût caché

On parle beaucoup du coût des tokens. On parle moins du coût des permissions.

Un agent qui ne peut rien faire n’est qu’un assistant bavard. Un agent utile doit accéder à des outils : messagerie, agenda, fichiers, CRM, ERP, ticketing, base de connaissances, navigateur, dépôt Git, parfois paiement ou signature. Chaque connecteur ajoute de la valeur. Chaque connecteur ajoute aussi un risque.

La question n’est donc pas seulement : l’agent est-il bon ? La question est : que peut-il casser ?

Dans les projets sérieux, la permission devient une architecture. Un agent n’utilise pas le compte complet d’un salarié comme s’il était son double numérique. Il a une identité propre, des droits bornés, des journaux séparés, des limites d’action, des étapes qui demandent validation. Il peut préparer un mail, pas l’envoyer à 3 000 clients sans revue. Il peut proposer une mise à jour CRM, pas écraser l’historique. Il peut créer une branche, pas merger seul du code critique.

Ce n’est pas du pessimisme. C’est la condition pour que l’autonomie reste utile. Une PME qui donne à un agent “les mêmes droits que moi, on verra bien” ne fait pas de l’innovation. Elle déplace une faille humaine dans une boucle plus rapide.

La vérification est le vrai goulot

Une étude publiée sur arXiv en mai 2026, basée sur seize praticiens dans douze entreprises, décrit un “capability-deployment verification gap”. Les capacités expérimentales existent, mais l’intégration en production bloque faute de mécanismes de vérification suffisants. Dans l’échantillon, une seule entreprise atteint le niveau “multi-agent orchestration”. Les autres restent surtout au stade assistant ou compensation.

La formule est un peu académique, mais elle nomme très bien le problème. La question décisive n’est pas “l’agent peut-il produire une sortie plausible ?” La question décisive est “comment savons-nous qu’elle est correcte ?”

Sur certaines tâches, c’est simple. Un test passe ou ne passe pas. Un total comptable tombe juste ou non. Une référence existe ou non. Une facture correspond au bon de commande ou non. Ces tâches peuvent accueillir de l’autonomie, parce que la vérification est externe à l’agent.

Sur d’autres tâches, la vérification est molle. Prioriser des prospects. Répondre à une réclamation ambiguë. Arbitrer entre deux fournisseurs. Décider si un dossier est “sensible”. Résumer une réunion où personne n’a osé dire la vraie décision. Là, l’agent peut aider, mais il ne doit pas devenir l’arbitre silencieux.

Le bon projet agent IA commence donc par la preuve. Quelle trace l’agent laisse-t-il ? Quelle règle permet de valider sa sortie ? Qui relit les cas limites ? Quelle action est réversible ? Que se passe-t-il si l’agent s’arrête au milieu ? Sans réponse, on n’a pas un produit. On a une démo avec des identifiants de production.

Ce qu’une PME devrait faire maintenant

Il ne faut pas conclure que les agents IA sont inutiles. Ce serait une lecture paresseuse. Ils deviennent utiles sur des tâches bornées, répétées, vérifiables, où l’action a de la valeur et où le coût d’une erreur reste maîtrisé.

Une bonne première vague tient en trois cas maximum.

Un agent de préparation, par exemple, qui lit les derniers échanges client, rassemble les documents utiles et propose un brief avant une réunion. Il n’envoie rien, il ne décide rien, il gagne du temps de contexte.

Un agent de contrôle, qui compare une facture, un bon de commande et une réception, puis isole les écarts à relire. Il n’approuve pas seul le paiement, il rend visible l’anomalie.

Un agent de tri, qui classe les demandes entrantes, propose une priorité et prépare une réponse. Il agit sur des brouillons, pas sur la relation finale.

Dans ces trois cas, l’entreprise apprend ce que coûte vraiment l’autonomie : nettoyage du contexte, droits minimaux, logs, revue humaine, gestion des exceptions. Elle apprend aussi où l’agent est meilleur qu’un workflow classique, et où un simple formulaire bien dessiné aurait suffi.

Le reste peut attendre. Les agents qui promettent de “gérer vos opérations” méritent une réponse froide : montrez la preuve, montrez les permissions, montrez l’annulation.

Le désordre revient toujours

La saison des agents IA sera bruyante. Chaque éditeur aura sa couche de contexte, sa mémoire, ses connecteurs, son agent personnel, son copilote qui devient collègue. Une partie sera utile. Une partie sera du packaging. Une partie fera perdre de l’argent à des entreprises qui auront confondu mouvement et maturité.

Le test de Jachère est plus simple : si un humain compétent a besoin de trois jours pour comprendre qui décide, où est la bonne donnée et quelle règle appliquer, un agent ne doit pas recevoir la tâche. Pas encore.

Avant l’autonomie, il faut une organisation que l’on peut lire. Les agents IA n’aiment pas les entreprises claires par morale. Ils les aiment parce qu’elles réduisent leur surface d’erreur.

La promesse sérieuse n’est donc pas “un agent pour tout faire”. C’est plus modeste, plus solide : un agent pour agir dans un bout d’entreprise suffisamment propre pour que l’action puisse être vérifiée. Le reste n’est pas de l’autonomie. C’est du désordre avec une API.