IBM compte plus de 1 000 agents d'IA en production — Ce que les DSI peuvent apprendre du playbook de scaling en entreprise
IBM a déployé des centaines d'agents d'IA pour workflows d'entreprise et des milliers d'agents de productivité personnelle, selon Matt Lyteson, CIO d'IBM. Ce n'est pas un pilote. C'est une exploitation en production à grande échelle. Et ce qu'IBM a appris en exécutant plus de 1 000 agents, c'est le playbook de mise à l'échelle que la majorité des entreprises encore au stade des pilotes ne possèdent pas encore.
Don Schuerman de Pega expose sans détour la contrainte actuelle : les hallucinations freinent l'adoption grand public, et les entreprises qui ont résolu les problèmes de production savent que l'architecture doit être protégée contre les hallucinations dès le premier jour. Ce billet présente le playbook pratique issu de l'expérience d'IBM : ce que signifie concrètement l'approche par résultats ciblés, comment IBM a défini le périmètre et gouverné ses déploiements, et quels changements organisationnels ont été nécessaires pour passer d'une poignée de pilotes à plus de 1 000 agents en production.
À quoi ressemblent plus de 1 000 agents chez IBM
Le chiffre de plus de 1 000 agents est un ensemble de deux catégories de déploiement très différentes qu'IBM gère différemment.
Agents pour workflows d'entreprise : des centaines d'agents automatisant des processus métier transversaux. Conçus sur mesure pour des fonctions métier spécifiques, chacun lié à un workflow défini avec des résultats mesurables. Niveau d'exigence élevé, enjeux importants, exigences architecturales plus strictes. Ces agents nécessitent une architecture complète anti-hallucinations, une gouvernance formelle et une couverture dédiée des opérations d'agents.
Agents de productivité personnelle : des milliers d'agents déployés auprès d'employés individuels pour l'automatisation de tâches. Tri des e-mails, gestion de calendrier, rédaction de documents. Enjeux individuels moindres, économies de temps agrégées plus importantes. Cycle de déploiement plus rapide, itération plus rapide. Ces agents peuvent être déployés plus rapidement auprès de travailleurs individuels car la portée de l'incident en cas d'échec se limite au workflow d'une personne, et non à un processus métier transversal.
Ce que cette composition révèle à la plupart des entreprises : il ne faut pas essayer de déployer des agents pour workflows d'entreprise à tout le monde simultanément. IBM a commencé par les agents de productivité personnelle, ce qui lui a permis d'acquérir une expérience opérationnelle avec des agents dans un contexte moins risqué, tout en construisant l'infrastructure pour les workflows d'entreprise.
L'approche par résultats ciblés — Le principe central de mise à l'échelle d'IBM
Le principe des résultats ciblés est la première chose qu'IBM fait correctement et que la plupart des entreprises font mal. Chaque agent déployé par IBM est lié à un résultat métier spécifique et mesurable. Pas une injonction technologique. Pas « utiliser des agents d'IA ». Un objectif concret comme réduire de 60 % le temps de tri des e-mails pour l'équipe de ventes entreprise.
Pourquoi cela fonctionne : quand vous partez d'un résultat défini, vous délimitez le périmètre de l'agent en fonction de ce résultat. L'agent est plus facile à tester car vous savez exactement ce que représente le succès. Il est plus facile à surveiller car vous avez un chiffre à suivre. Quand l'agent réussit, vous disposez d'une métrique non ambiguë pour démontrer le retour sur investissement. Quand il échoue, vous savez exactement ce qui s'est passé.
Pourquoi le déploiement à grande échelle échoue : « Des agents d'IA pour l'organisation » ne produit aucune définition claire du succès, aucun moyen de mesurer le retour sur investissement, aucune boucle de rétroaction et aucune itération. Les agents déployés sans résultats clairs deviennent des vitrines technologiques. Ils sont impressionnants en démonstration. Personne ne sait s'ils fonctionnent réellement.
L'approche d'IBM en pratique : chaque agent a un propriétaire métier défini. Chaque agent a une métrique de succès mesurable convenue avant le déploiement. Chaque agent a un humain référent qui examine la performance. Les agents ne sont étendus qu'après un succès mesurable, et non selon un calendrier.
L'architecture anti-hallucinations — Ce qu'IBM a construit pour permettre la mise à l'échelle
Les hallucinations freinent l'adoption grand public. Chaque incident d'hallucination érode la confiance organisationnelle dans les agents et crée une résistance qui rend le prochain déploiement plus difficile. À l'échelle d'IBM, les hallucinations ne sont pas seulement un problème de fiabilité. Elles sont une contrainte de mise à l'échelle.
À quoi ressemble une architecture protégée contre les hallucinations à l'échelle entreprise : Graph-RAG connecte les sources de données d'entreprise à un graphe de connaissances. Les agents récupèrent uniquement des faits vérifiés, et non des extraits de texte bruts susceptibles de contenir des erreurs. La sélection sémantique des outils confirme la correspondance de l'outil avant l'appel. Les politiques d'entreprise sont encodées sous forme de guardrails neurosymboliques qui supplantent la sortie du modèle. Les workflows métier critiques bénéficient d'une validation multi-agents : un deuxième agent examine les actions du premier agent avant l'exécution.
Cette infrastructure est un prérequis pour la mise à l'échelle, et non un ajout optionnel. Les plus de 1 000 agents d'IBM n'ont pas d'humains qui examinent chaque action. Ils disposent d'une architecture qui contraint ce que les agents peuvent faire et vérifie que ce qu'ils font est correct.
La fonction Operations Agents — Ce qu'implique réellement l'exploitation de plus de 1 000 agents
Les logiciels s'exécutent. Les agents nécessitent une gestion. Cette distinction semble évidente une fois formulée, et la plupart des organisations l'apprennent à leurs dépens après leur premier incident impliquant un agent.
Les agents dérivent. Leur comportement change à mesure que l'environnement évolue, que les modèles se mettent à jour, que les données dont ils dépendent se modifient. Un agent qui fonctionnait correctement il y a six semaines peut se comporter différemment aujourd'hui.
Les agents échouent silencieusement. Ils accomplissent des tâches de manière qui semble raisonnable mais qui est erronée. Un logiciel s'exécute ou génère une erreur. Les agents accomplissent des tâches qui semblent avoir réussi sans avoir atteint le résultat escompté.
L'infrastructure opérationnelle d'IBM pour plus de 1 000 agents : une équipe dédiée aux opérations agents. Une pile d'observabilité où chaque agent est observable. Des playbooks de réponse aux incidents clairs pour les échecs d'agents. Des revues de performance régulières où les résultats des agents sont comparés aux métriques de succès ciblées.
Le cadre de gouvernance — Comment IBM maintient le contrôle à l'échelle
Le défi de gouvernance pour les agents autonomes diffère de la gouvernance des logiciels d'une manière que la plupart des entreprises ne prévoient pas. Un logiciel exécute correctement une procédure définie ou ne l'exécute pas. Les agents peuvent exécuter des procédures de manière techniquement correcte mais contextuellement erronée.
L'approche de gouvernance d'IBM comporte quatre composantes. Des limites de périmètre claires : les agents sont autorisés à faire des choses spécifiques, pas tout. Des pistes d'audit : chaque action d'agent est journalisée avec suffisamment de contexte pour reconstruire ce qui s'est passé. Des parcours d'escalade : les agents savent quand escalader vers un humain. L'encodage des politiques : les règles métier sont encodées sous forme de guardrails qui supplantent la sortie du modèle, et non de simples directives souples que le modèle est invité à suivre.
Le modèle de responsabilité humaine est ce qui rend le déploiement d'agents autonomes acceptable pour les régulateurs et la gouvernance interne. Chaque agent a un propriétaire humain nommé qui est responsable de sa performance. Il y a toujours un humain responsable. Cette structure de responsabilité est ce qui permet aux agents d'opérer de manière autonome dans leur périmètre.
Ce que chaque DSI devrait retenir du playbook d'IBM
Cinq leçons transférables de l'expérience d'IBM.
Leçon 1 : Commencez par des résultats ciblés, pas par des mandats élargis. Si vous ne pouvez pas énoncer quel résultat spécifique et mesurable cet agent doit atteindre, vous n'avez pas un déploiement d'agent. Vous avez un pilote qui ne se mettra pas à l'échelle.
Leçon 2 : Construisez une architecture protégée contre les hallucinations avant d'en avoir besoin. Graph-RAG, sélection sémantique des outils, guardrails et validation multi-agents ne sont pas optionnels quand vous atteignez un certain nombre d'agents. Ils constituent l'infrastructure habilitante qui rend la mise à l'échelle possible.
Leçon 3 : Désignez les opérations agents avant de déployer. Les agents nécessitent une gestion continue. C'est une nouvelle fonction organisationnelle, pas une tâche annexe. Les entreprises qui traitent les opérations agents comme de l'infrastructure exploiteront les agents plus efficacement.
Leçon 4 : Les agents pour workflows d'entreprise et les agents de productivité personnelle sont différents. Ne les traitez pas de la même manière. Commencez par les agents de productivité personnelle pour construire une expérience opérationnelle avant de tenter des agents pour workflows d'entreprise.
Leçon 5 : La majorité des pilotes échouent parce qu'ils négligent le travail organisationnel. La technologie n'est pas l'obstacle. La préparation organisationnelle l'est.
La fenêtre concurrentielle est réelle. IBM est en avance de plusieurs années sur la plupart des entreprises en matière de déploiement d'agents. Les entreprises qui construisent maintenant l'infrastructure des opérations agents bénéficieront d'un avantage cumulatif.