Pour l'entreprise, la promesse de l'IA agentique dépasse de loin celle d'un meilleur chatbot : il s'agit de logiciels capables d'exécuter des tâches métier de bout en bout, à travers les personnes, les processus, les données et les systèmes. Mais faire passer un agent de la démonstration à la production ne relève pas d'un problème de modèle : c'est un problème de plateforme. Un article de MIT Technology Review Insights, sponsorisé par Intel, résume les prérequis — capacité de calcul, accès résilient aux données, usage d'outils encadré par des règles, observabilité, gestion de la mémoire, capacité à planifier et à passer à l'échelle. Recoupé avec des analyses indépendantes, le constat converge : l'agent autonome ne vaut que ce que vaut l'environnement qui l'exécute.

Un problème de système, pas d'inférence

Le message central de l'article de MIT Technology Review, issu de « milliers d'expériences » menées sur des charges de travail agentiques par Intel, tient en une phrase : l'IA agentique est un défi de système, pas seulement d'inférence. Autrement dit, la performance ne dépend plus uniquement de la vitesse à laquelle le modèle génère des jetons, mais de la manière dont s'articulent l'orchestration des tâches, l'accès aux données, l'exécution des outils, la latence, la gouvernance et l'infrastructure sous-jacente.

Un agent, contrairement à un assistant conversationnel, interprète une demande, décompose un objectif, choisit des outils, appelle des API, lit des données internes et déclenche des actions — souvent en plusieurs étapes et sans supervision humaine à chaque pas. C'est cette autonomie qui séduit, et c'est elle qui fait exploser les exigences d'infrastructure. Le fournisseur d'infrastructure Mirantis parle d'un empilement de couches interdépendantes — orchestration, calcul isolé, mémoire, intégration des outils, observabilité, gouvernance — qui doivent fonctionner ensemble en production. Le goulet d'étranglement n'est plus l'inférence seule, mais l'inférence plus tout le reste, en même temps.

Ce point mérite d'être rappelé sans naïveté : l'article source est un contenu commercial d'Intel, dont l'intérêt est de mettre en avant la capacité des processeurs (CPU) à absorber ces charges. Ses recommandations techniques n'en sont pas moins largement corroborées par des acteurs qui n'ont aucun lien avec le fondeur.

Mesurer autrement : la densité plutôt que la puissance brute

L'un des enseignements les plus concrets concerne les indicateurs de suivi. Pour des charges agentiques, le taux d'utilisation moyen du processeur est un signal trompeur : les agents ont une consommation « en rafales » (bursty), alternant pics d'activité et temps morts. Un serveur qui affiche 30 % d'utilisation moyenne peut très bien saturer par à-coups.

L'article recommande donc de renoncer à quelques réflexes hérités de l'infrastructure classique. Plutôt que la puissance brute par agent, il propose de raisonner en densité — le nombre d'agents par cœur virtuel (vCPU). Plutôt que l'utilisation moyenne, il privilégie la latence de tâche (la métrique P95, c'est-à-dire le temps sous lequel 95 % des tâches s'exécutent) comme signal de performance avancé. Et plutôt que d'empiler des machines toujours plus puissantes (scale-up), il conseille de multiplier les instances (scale-out) pour la plupart des architectures d'agents. Six métriques métier sont mises en avant pour piloter un parc : taux de réussite des tâches, coût par tâche, durée par tâche, débit, densité d'agents et latence.

On retrouve ici, en creux, la même bataille que celle des coûts : l'unité de mesure de l'IA générative n'est plus l'heure de calcul ni le giga-octet, mais des grandeurs nouvelles que les tableaux de bord d'infrastructure ne captent pas nativement. C'est tout l'enjeu de la nouvelle génération d'outils de FinOps IA qui cherchent à rendre la dépense visible et pilotable.

Observabilité : voir chaque décision

Si un thème fait consensus au-delà du document sponsorisé, c'est bien l'observabilité. Un agent enchaîne des décisions internes — appels de modèle, récupérations de données, choix d'outils, accès à la mémoire, vérifications de garde-fous — qui ne sont pas lisibles sans traces structurées. « Les chemins de raisonnement agentiques ne sont pas lisibles par un humain sans traces structurées ; le débogage exige une visibilité pas à pas », résume Mirantis. En clair : sans instrumentation dédiée, on ne sait ni pourquoi un agent a échoué, ni pourquoi il a agi comme il l'a fait.

Cette exigence n'est pas cosmétique. Elle conditionne la conformité, l'audit et la capacité à corriger. Les équipes qui réussissent en 2026 traitent l'observabilité comme une contrainte de conception dès le premier jour, et non comme une rustine ajoutée après coup. C'est exactement le fossé que documentait déjà ZapNews entre la démonstration séduisante et la mise en production : déployer un agent « à l'aveugle » se paie en incidents, en coûts et en confiance perdue.

Mémoire et données : une préoccupation de premier plan

Un agent utile a besoin de contexte : ce qu'il a fait précédemment, les préférences de l'utilisateur, l'état d'un dossier. La mémoire devient donc, selon la formule de Mirantis, « une préoccupation d'infrastructure de premier plan, et non une réflexion après coup au niveau applicatif » — bases vectorielles, pipelines de récupération de connaissances, rétention des données sur plusieurs années.

Mais la mémoire n'est pas une pure bénédiction. Des travaux relayés par ZapNews ont montré que des systèmes de mémoire mal conçus peuvent dégrader les réponses d'un modèle et le rendre flagorneur, c'est-à-dire enclin à donner raison à l'utilisateur plutôt qu'à dire vrai. La leçon rejoint celle de l'infrastructure : accumuler du contexte ne suffit pas, encore faut-il le gérer. À cela s'ajoute l'accès résilient aux données — un agent coupé de ses sources ou confronté à des données incohérentes ne produit que des décisions fragiles.

Gouvernance des outils : l'agent comme identité à part entière

Dernier pilier, et non des moindres : l'usage encadré des outils. Chaque appel d'outil par un agent devrait faire l'objet d'une validation de schéma, d'une limitation de débit et d'une journalisation d'audit. Le protocole MCP (Model Context Protocol) s'est imposé comme interface standard pour la découverte et la gestion de ces outils.

Le risque est loin d'être théorique. La Cloud Security Alliance rapporte, selon Mirantis, que 80 % des organisations ont déjà rencontré des comportements d'agents à risque. D'où le principe qui fait aujourd'hui consensus : traiter chaque agent comme une identité non humaine dotée de permissions strictement limitées au nécessaire (moindre privilège), avec gestion des identités et des accès (IAM), approbations fondées sur des règles et pistes d'audit résistant à un contrôle de sécurité. C'est précisément la bombe à retardement des identités non humaines que les directions des systèmes d'information voient grossir : les identités machines dépassent déjà largement les humaines, et la plupart des organisations reconnaissent ne pas disposer de contrôles adaptés.

Une plateforme, pas un modèle

Au fond, tous ces prérequis dessinent un même déplacement : la valeur d'un agent en entreprise ne se joue pas au niveau du modèle, mais de la plateforme qui l'exécute — calcul, orchestration, mémoire, outils, observabilité et gouvernance réunis. C'est cohérent avec l'évolution des attentes financières : les entreprises ne cherchent plus seulement à « gagner du temps », elles exigent désormais un impact mesurable sur le chiffre d'affaires et les marges. Or ce retour sur investissement ne se matérialise que si les agents tiennent en production, à l'échelle et dans la durée.

Le chiffre le plus parlant est peut-être celui rappelé par Mirantis : une majorité d'organisations expérimentent les agents, mais moins de 10 % les exploitent réellement à l'échelle. L'écart entre les deux ne se comble pas en changeant de modèle. Il se comble en construisant l'environnement qui permet à ces modèles d'agir — sûrement, de manière traçable, et sans voler à l'aveugle.