En juin 2026, le signal le plus important pour les entreprises n’est pas l’arrivée d’un énième LLM ni même la guerre des benchmarks. Le vrai basculement, visible chez Google Cloud, AWS, Microsoft et Databricks, est ailleurs : le MLOps devient une discipline d’exploitation d’agents, avec quatre enjeux qui montent en même temps - le contexte métier, la gouvernance, l’observabilité et le coût unitaire de l’inférence. Quand tous les grands acteurs réorganisent leurs annonces autour du runtime, de l’identité, des gateways, de la mémoire, de la traçabilité et de l’évaluation continue, ce n’est plus un effet de mode ; c’est un changement de couche.
Autrement dit : en 2024, on demandait surtout quel modèle choisir ; en 2026, la question qui décide du passage en production est plutôt qui contrôle le contexte, les permissions, les traces, les coûts et la capacité à changer de fournisseur. Microsoft l’écrit presque noir sur blanc : le goulot d’étranglement n’est plus la capacité des modèles, mais le contexte partagé de l’entreprise. Databricks, de son côté, explique que la boucle agentique visible n’est qu’une petite partie du travail et que le reste relève d’une dette technique cachée faite de sécurité, déploiement, monitoring, coût et qualité. AWS insiste désormais sur l’amélioration continue à partir des traces de production. Google pousse une plateforme complète pour construire, déployer, gouverner et optimiser des agents.
Ce n’est pas l’IA qui entre dans le cloud ; c’est le cloud qui redevient le système d’exploitation de l’IA.
Le basculement visible chez tous les fournisseurs
Le point commun des annonces de ce printemps et de ce mois de juin est frappant. Google Cloud a lancé Gemini Enterprise Agent Platform comme une plateforme destinée à construire, mettre à l’échelle, gouverner et optimiser des agents, en réunissant sélection de modèles, outils d’intégration, DevOps, orchestration et sécurité dans une même couche. Lors de Google Cloud Next ’26, Google a aussi mis en avant un Agent Developer Kit fondé sur des graphes, ainsi qu’Agent Studio pour construire, tester et publier des agents à grande échelle.
Chez Microsoft, le message de Build 2026 est à peine moins explicite. L’entreprise affirme que le problème n’est plus la puissance du modèle, mais la capacité à fournir un contexte de données cohérent à des agents qui doivent agir dans les systèmes métiers. La page officielle de Build 2026 met d’ailleurs en avant, parmi ses annonces majeures, des briques qui vont de « l’observability to ROI for AI agents » à la gouvernance portable des agents, en passant par le déploiement et l’exécution à grande échelle de Foundry.
AWS, de son côté, a basculé Bedrock AgentCore dans une logique d’exploitation industrielle. Son annonce du 18 juin 2026 sur les nouvelles capacités d’optimisation n’insiste pas d’abord sur la création d’agents, mais sur un cycle où les traces de production servent à comprendre ce qui se passe, corriger ce qui dysfonctionne et prouver que les correctifs améliorent réellement le système. AWS formule même le vrai risque en des termes très parlants : les pannes les plus dangereuses ne sont pas celles qui remontent une erreur, mais les défaillances silencieuses qui n’apparaissent qu’après coup dans les plaintes clients.
Databricks pousse exactement la même lecture, avec d’autres mots. Dans son billet DAIS 2026, l’éditeur explique que la boucle agentique n’est que « le 1 % » visible, tandis que « les 99 % » restants relèvent du déploiement, de la capacité token, de la sécurité, de l’évaluation, de l’observabilité, du contexte et du partage. Le fait le plus intéressant n’est pas tant l’annonce produit que le cadrage : pour Databricks, le problème marché n’est déjà plus comment faire une démo d’agent, mais comment opérer un système agentique fiable.
La leçon pour un décideur est simple : quand Google, AWS, Microsoft et Databricks convergent, chacun avec son vocabulaire, vers les mêmes briques - runtime, identité, mémoire, gateways, tracing, scoring, gouvernance - cela signifie que l’on sort du cycle « POC + hype » pour entrer dans un cycle d’architecture. Le centre de gravité du MLOps se déplace donc du modèle vers la chaîne d’exploitation.
Pourquoi le MLOps devient de l’AgentOps
Ce déplacement change la nature même de la pile technique. Dans un MLOps classique, l’essentiel consistait à versionner des données et des modèles, déployer un endpoint, suivre quelques métriques, puis rejouer un pipeline de réentraînement. Dans la pile 2026, il faut en plus gérer un runtime d’agents, la mémoire courte et longue, les droits d’action, les outils externes, les traces d’exécution, la qualité des réponses, la conformité des comportements et la latence de chaînes multi-étapes. Google documente déjà cet empilement : Agent Platform propose un runtime managé, des sessions, une Memory Bank, des fonctions de logging, tracing et monitoring, ainsi qu’une identité par agent.
Le détail le plus intéressant est sans doute la montée de l’identité agentique. Dans la documentation Google, l’Agent Identity repose sur une identité cryptographiquement attestée, fondée sur le standard SPIFFE, pour authentifier un agent auprès de serveurs MCP, de ressources cloud, d’endpoints et d’autres agents. Autrement dit, le problème n’est plus seulement « qui appelle l’API ? », mais « quel agent agit, au nom de qui, avec quel périmètre de droits ? ». C’est un glissement majeur : la sécurité remonte au niveau du comportement automatisé.
AWS va dans la même direction avec AgentCore Gateway, qui transforme des API, des fonctions Lambda et des services existants en outils compatibles Model Context Protocol, avec authentification entrante et sortante, intégrations prêtes à l’emploi et contrôle d’accès fin. Cette couche est stratégique, parce qu’elle relie le monde des agents à celui du SI réel : CRM, messagerie, tickets, documentation, bases de données, workflows. Le MLOps cesse alors d’être un sujet purement « modèle » pour devenir un sujet plateforme + intégration + sécurité.
L’autre bascule est l’observabilité qualitative. MLflow 3 chez Databricks unifie déjà le suivi, l’évaluation et l’observabilité des applications et agents GenAI avec traces en temps réel, scorers, feedback humain et versioning. En production, Databricks propose un monitoring qui exécute automatiquement des scorers sur des échantillons de traces pour évaluer la qualité en continu - signe que l’on n’évalue plus seulement une version avant déploiement, mais le comportement réel après mise en circulation. AWS dit la même chose sous une autre forme : AgentCore Observability fournit des métriques temps réel sur le nombre de sessions, la latence, la durée, l’usage de tokens et les taux d’erreur, avec du filtrage par métadonnées pour l’investigation.
Enfin, l’infrastructure d’inférence elle-même devient plus « plateforme » que « simple hébergement GPU ». La CNCF rappelle que l’Inference Gateway fondé sur la Gateway API est désormais GA et permet de router le trafic selon le nom du modèle, les adaptateurs LoRA et l’état des endpoints, afin de mieux mutualiser les pools de serveurs et d’augmenter l’utilisation des accélérateurs. Google renforce ce mouvement avec l’intégration de NVIDIA Dynamo à GKE Inference Gateway, tout en annonçant des VM G4 fractionnables pour mieux dimensionner les charges. Là encore, la question n’est plus seulement où trouver des GPU ?, mais comment utiliser la capacité d’inférence avec discipline, mutualisation et arbitrage fin.
Ce que cela change côté organisation est décisif : le MLOps doit désormais travailler avec la sécurité, la plateforme cloud, le data engineering, les équipes IAM, les équipes FinOps et parfois le juridique. L’« AgentOps » n’est pas un nouveau mot à la mode ; c’est la preuve que l’exploitation de l’IA quitte le silo data science pour entrer dans le cœur opérationnel du SI.
Le coût caché qui finit par remonter au budget
C’est ici que le sujet devient vraiment décisionnel. Selon le State of the Cloud 2026 de Flexera, 58 % des organisations utilisent déjà des services GenAI de cloud public, 45 % disent les utiliser de façon extensive, 73 % opèrent en hybride, 49 % recourent désormais à des unit economics pour relier la dépense cloud aux résultats business, et la part estimée de gaspillage IaaS/PaaS remonte à 29 %. Flexera note aussi que 64 % des organisations mesurent désormais le cloud davantage par la valeur délivrée aux métiers que par la seule efficacité-coût. Ce n’est pas anecdotique : la conversation passe du « combien ça coûte ? » à « quel coût par service, par usage, par workflow, par équipe, par client ? ».
Cette évolution est cohérente avec ce que voient déjà les entreprises européennes sur le terrain. Reuters rapporte que des groupes comme Siemens, Renault, Orange ou ChapsVision multiplient les fournisseurs pour limiter le risque de dépendance, mais aussi parce que le coût au token devient un sujet de plus en plus sensible à mesure que les agents automatisent davantage de tâches. L’article cite explicitement la montée de cette obsession sur le coût unitaire et l’exemple d’un budget token consommé beaucoup plus vite que prévu. Même les marchés financiers s’inquiètent désormais du niveau des dépenses d’infrastructure IA des hyperscalers, signe que la question du retour économique est sortie du cercle technique.
Il faut ajouter un point souvent mal compris : la facture d’un système agentique ne se réduit pas au prix de l’API modèle. AWS montre, dans sa propre page de pricing AgentCore, que des coûts s’ajoutent autour du modèle - appels gateway, mémoire court terme, stockage mémoire longue durée, récupération de souvenirs, observabilité - avec des lignes de coût séparées. Les exemples de tarification publiés par AWS illustrent justement cette granularité : même hors coût du modèle lui-même, la couche d’exploitation agentique crée sa propre économie.
Le bon angle budgétaire pour un DSI ou un CFO n’est donc plus « combien me coûte un prompt ? » mais « quel est mon coût complet par agent utile ? ». Ce coût complet comprend au minimum le modèle, les outils externes, la mémoire, le logging, le tracing, la sécurité, les garde-fous, le stockage, les données de contexte et le temps humain nécessaire à l’évaluation et à la remédiation. Si l’entreprise ne suit pas cette unité économique, elle peut facilement constater de l’adoption sans savoir si elle crée de la valeur ou seulement de la charge cloud.
C’est pour cela que le FinOps change de nature. Flexera n’annonce plus simplement des fonctions de cloud cost management classiques, mais une couche d’AI Cost Management couvrant applications, agents, modèles, plateformes de données et compute. Le message implicite est clair : la dépense IA n’est plus un appendice de la dépense cloud ; elle devient un poste de pilotage distinct, assez complexe pour nécessiter des outils dédiés.
Le cloud IA redevient un choix de souveraineté
L’autre erreur de lecture serait de traiter le cloud IA comme un simple arbitrage technique entre AWS, Azure et Google Cloud. En Europe, en juin 2026, le sujet est aussi devenu un problème de continuité d’activité et de souveraineté opérationnelle. La Commission européenne a adopté le 3 juin une proposition de Cloud and AI Development Act, présentée comme un levier pour renforcer l’écosystème cloud et IA européen, ses investissements et ses infrastructures. Dans le même temps, le calendrier officiel rappelle que l’AI Act sera pleinement applicable à partir du 2 août 2026, avec des règles de transparence qui entrent en vigueur en août 2026 et un cadre général qui renforce les responsabilités des fournisseurs et déployeurs.
Cette dimension politique se traduit déjà dans les architectures d’entreprise. Reuters explique que des groupes européens accélèrent la diversification de leurs modèles et de leurs fournisseurs après des restrictions d’accès à certains services américains, précisément parce qu’un service propriétaire à distance peut être limité par son fournisseur et n’est pas forcément opérable sur les propres serveurs du client. Dans cet article, souveraineté ne veut pas dire autarcie : Siemens, Orange ou Renault parlent surtout de flexibilité, de mix fournisseurs, et de capacité de secours si un acteur coupe l’accès ou modifie ses conditions.
C’est dans ce contexte qu’il faut lire l’annonce d’OVHcloud. Reuters rapporte que le groupe français veut entraîner des modèles de frontière pour devenir un second grand acteur européen du LLM, avec un coût estimé de 150 à 200 millions d’euros pour ce nouveau cycle technologique, très loin du milliard d’euros souvent évoqué auparavant. Que l’initiative aboutisse ou non commercialement, elle dit quelque chose d’important : la souveraineté cloud IA n’est plus un discours institutionnel abstrait ; elle remonte dans la stratégie produit et infrastructure de grands acteurs européens.
Pour une entreprise, la bonne traduction métier de cette tension est concrète. Une architecture « souveraine » n’est pas seulement une architecture hébergée en Europe. C’est une architecture capable d’identifier quels composants doivent être opérables en propre, quels outils doivent rester substituables, quelles données de contexte ne doivent pas être prisonnières d’un runtime propriétaire, et dans quel délai un agent critique peut changer de modèle ou de fournisseur. À partir du moment où l’agent agit sur des processus métier, la dépendance fournisseur devient une variable de risque, pas un simple choix de développeur.
La grille utile pour décider maintenant
La question n’est donc pas « faut-il faire du MLOps pour l’IA générative ? », mais quel type d’exploitation veut-on standardiser. La grille ci-dessous synthétise ce que les signaux de juin 2026 changent réellement pour une entreprise. Elle sert à arbitrer un budget, une trajectoire d’architecture ou un choix fournisseur.
| Axe de décision | Ce qui change en 2026 | Question à poser en comité |
|---|---|---|
| Architecture | Le socle n’est plus un endpoint de modèle, mais un ensemble runtime + mémoire + gateway + identité + traces + évaluation. | Voulons-nous standardiser un runtime d’agents unique, ou garder une couche portable entre plusieurs clouds et frameworks ? |
| Gouvernance | L’observabilité devient comportementale : tokens, latence, sessions, outils invoqués, traces, feedback, scoring continu. | Quels indicateurs devons-nous exiger avant tout passage en production : coût, qualité, groundedness, sécurité, temps de résolution ? |
| Budget | La dépense IA devient composite : modèle, mémoire, outils, logs, tracing, sécurité, données, capacité GPU. Flexera observe la remontée des unit economics et du gaspillage cloud. | Connaissons-nous le coût complet par agent utile, par parcours utilisateur ou par métier ? |
| Contexte métier | Microsoft insiste sur le fait que le goulot n’est plus le modèle mais le contexte partagé ; Databricks fait de la qualité du contexte et de la gouvernance du savoir un pilier de sa plateforme. | Quels jeux de données, ontologies, documents et permissions constituent notre “source de vérité” pour les agents ? |
| Souveraineté | En Europe, la résilience passe par la diversité des fournisseurs, la substituabilité et la capacité d’opérer certaines briques localement ; le cadre réglementaire se resserre d’ici août 2026. | Si un fournisseur change ses règles d’accès, dans combien de jours pouvons-nous basculer un agent critique ? |
La conséquence la plus pratique est que les achats cloud IA ne devraient plus être évalués d’abord sur le « meilleur modèle disponible », mais sur cinq critères moins spectaculaires et plus décisifs : portabilité du contexte, qualité de l’observabilité, granularité des contrôles, visibilité des coûts et capacité de repli. Un fournisseur peut être excellent en démonstration et faible en industrialisation. C’est précisément ce décalage qui commence à structurer le marché.
Ce que les acteurs en avance ont déjà compris
Le signal à lire en avance est celui-ci : la prochaine bataille de l’IA d’entreprise ne portera pas principalement sur l’accès à un meilleur modèle, mais sur la capacité à faire vivre des agents dans un cadre économique et juridique soutenable. Les organisations qui prennent de l’avance ne sont pas seulement celles qui déploient le plus vite ; ce sont celles qui rendent les agents mesurables, changeables et gouvernables. Elles traitent le contexte comme un actif stratégique, le coût comme une métrique produit, et la sécurité comme une politique d’action plutôt que comme une liste d’accès.
Il faut évidemment garder une réserve méthodologique. Une partie importante du signal provient d’annonces fournisseurs et de documentations produit ; certaines fonctions sont encore en beta ou en preview, comme le monitoring de production MLflow 3 chez Databricks. Cela signifie que l’adoption réelle sera plus lente et plus inégale que les keynotes ne le suggèrent. Mais cette limite ne change pas le diagnostic de fond : lorsque les quatre grands écosystèmes cloud et data convergent vers les mêmes primitives techniques, le mouvement a de fortes chances de durer.
La phrase-thèse qui mérite d’être retenue est donc la suivante : le vrai sujet du MLOps & Cloud IA en 2026 n’est plus de servir un modèle, mais d’exploiter des agents avec du contexte, des preuves et des garde-fous. Les entreprises qui liront cela comme un simple sujet d’outillage prendront du retard. Celles qui y verront une refonte du pilotage cloud, du contrôle financier et de la gouvernance opérationnelle seront mieux placées pour absorber la prochaine vague.