Calipia : le blog

Microsoft publie son playbook IA et désigne un fossé défensif que vous possédez peut-être déjà

Il y a quelque chose de savoureux à voir le premier vendeur mondial de licences expliquer que déployer des licences ne transforme rien. C’est pourtant le message central du document publié par Microsoft le 17 septembre, un playbook de 44 pages intitulé « Becoming a Frontier Firm », construit à partir de l’analyse de plus de cent chantiers internes de transformation par l’IA, menés dans les fonctions corporate, la force commerciale et les équipes d’ingénierie.

La thèse tient en une phrase que tout DSI ayant piloté un déploiement Copilot reconnaîtra avec un sourire un peu crispé : un outil licencié et déployé auprès de 100 000 collaborateurs ne change pas la façon dont le travail se fait. Kathleen Hogan, Chief Strategy and Transformation Officer, reconnaît que Microsoft a d’abord traité l’IA comme un déploiement logiciel classique, à savoir installer, former, pousser l’adoption, avant de constater que l’accès et l’usage ne produisaient pas mécaniquement d’impact métier. Autrement dit : Redmond a fait exactement ce que Redmond vend depuis trente ans, et cela n’a pas suffi.

« Lean before agents », ou l’art de ne pas automatiser le désordre

La recommandation la plus opérationnelle du document est aussi la moins vendeuse commercialement. Avant d’introduire le moindre agent, Microsoft conseille de cartographier le processus de bout en bout, de supprimer les validations et les transferts inutiles, de constituer un socle de données partagé, d’établir une propriété transverse du processus, de construire une couche réutilisable d’orchestration et d’observabilité, et de décider explicitement quelles parties du travail restent pilotées par l’humain. La formule maison est « lean before agents ».

Le contre-exemple implicite est limpide : poser des agents sur des processus mal conçus revient à automatiser le dysfonctionnement existant. Pour ceux qui ont connu les grandes heures du BPM et des workflows SharePoint, la leçon a un parfum de déjà-vu. La nouveauté est qu’un agent, contrairement à un workflow figé, échoue de façon probabiliste et non déterministe, ce qui rend la dette de processus beaucoup plus coûteuse à diagnostiquer.

Microsoft illustre avec sa propre supply chain cloud. Une équipe transverse a d’abord simplifié les flux et créé une source unique de vérité à partir de laquelle les agents pouvaient raisonner, avant de déployer 111 agents spécialisés sur la planification, le sourcing, l’exécution et la logistique. Certains agents peuvent comparer des alternatives de transport entre air, terre et mer selon le coût, les délais et l’impact carbone, et, dans des seuils d’autorisation définis, mettre à jour ou annuler des commandes d’achat…

Les chiffres annoncés sont spectaculaires : jusqu’à 75 % de réduction du temps de cycle sur certains flux, avec un passage d’environ dix jours ouvrés à moins de deux jours et demi sur cinq cycles mensuels de planification entre avril et août 2026. Pour la vingtaine d’investigations mensuelles sur les plans de demande, la production d’une explication validée par un humain passe de cinq à sept jours à quelques heures, parfois moins de vingt minutes.

Prenons une seconde pour la lecture critique, qui est après tout notre prisme. Ces résultats proviennent d’une analyse interne portant sur un chantier de plus de 150 personnes conduit entre septembre 2025 et août 2026, et Microsoft précise lui-même qu’ils valent pour ces flux et ces périodes de mesure, sans constituer un benchmark généralisable. Un effort de 150 personnes pendant un an sur une chaîne logistique aurait sans doute produit des gains substantiels même sans agents, simplement grâce au nettoyage des processus et à la création du référentiel unique. La part attribuable aux agents reste, elle, non isolée. Ce n’est pas une critique du résultat, c’est une invitation à ne pas transposer le pourcentage dans un business case.

Le point vraiment intéressant : le fossé défensif se situe au-dessus du modèle

C’est ici que le document devient stratégiquement inconfortable pour son propre auteur. Microsoft recommande aux entreprises de ne pas placer un modèle de fondation particulier au centre de leur architecture, et de loger leur avantage durable dans les évaluations privées, le contexte propriétaire, l’orchestration des processus, les boucles de feedback et la connaissance institutionnelle, autant d’actifs qui survivent au remplacement du modèle sous-jacent.

L’intelligence propriétaire est découpée en quatre catégories : le point de vue de l’entreprise sur son marché, ses données, workflows et savoirs internes, sa définition particulière de la qualité ou du « goût », et ses limites de risque définissant où les agents peuvent agir de façon autonome. Ces standards deviennent des évaluations, ou évals, contre lesquelles les systèmes d’IA sont mesurés en continu, le tout enveloppé dans ce que Microsoft appelle une « hill-climbing machine », une architecture d’apprentissage continu où le feedback, le scoring et le tuning améliorent les systèmes au regard des critères maison.

Le schéma d’architecture mérite d’être affiché en salle de comité. Sécurité et gouvernance au sommet ; en dessous un environnement d’apprentissage par renforcement contenant les évals et les grilles d’évaluation ; puis les runtimes d’agents, l’hébergement managé et les outils ; puis une couche de contexte et de « harness » regroupant l’accès multimodèle, la connaissance d’entreprise, la mémoire, les compétences et MCP ; et tout en bas, les modèles de fondation, explicitement étiquetés « interchangeables », gloups.

Pour un architecte, c’est une carte de découplage assez classique dans sa logique, à savoir isoler le composant volatil derrière une couche d’abstraction stable. Sauf que le composant volatil coûte ici plusieurs dizaines de milliards en capex à ceux qui le produisent. Dire que le modèle est interchangeable quand on s’appelle Microsoft revient à admettre que la valeur migre vers l’orchestration, ce qui est précisément là où Foundry, Copilot Studio, Entra Agent ID, Purview et le support de MCP viennent se positionner. Le verrouillage ne disparaît pas, il déménage d’un étage vers le haut. Et l’étage du haut, contrairement au modèle, ne se remplace pas par un simple changement de chaîne de connexion.

Reste que le conseil est juste, et qu’il devrait structurer les feuilles de route 2027. Microsoft recommande de conserver dans le périmètre de l’entreprise les prompts, les systèmes de recherche documentaire, les évaluations, les décisions d’agents et l’intelligence des workflows, avec des contrôles d’architecture pour la résidence des données, l’isolation du tenant, l’indépendance vis-à-vis des modèles et la protection de la propriété intellectuelle. Le document souligne que rétrofitter la résidence et l’isolation après le déploiement est infiniment plus difficile que de les concevoir dès l’origine. Les RSSI français, déjà occupés à documenter leurs flux pour NIS2 et à qualifier leurs traitements au regard du RGPD, apprécieront que l’argument de la souveraineté par conception arrive enfin par la voie de l’architecture plutôt que par celle du juridique.

L’angle mort des évals

Le playbook fait reposer l’avantage concurrentiel sur des évaluations privées et automatisées. La réalité du terrain est moins glorieuse. Dans une enquête VentureBeat Intelligence de juillet 2026 portant sur 108 entreprises, seulement 13 % déclarent faire pleinement confiance à l’évaluation automatisée ; parmi les 53 entreprises ayant déjà mis en production un agent ayant passé les évals internes avant d’échouer devant un client, ce chiffre tombe à 4 %, contre 24 % chez celles qui n’ont pas encore été échaudées.

Traduction : construire un référentiel d’évals qui discrimine réellement un bon résultat d’un mauvais, sur des tâches métier ouvertes, est un travail d’ingénierie de la qualité plus que d’IA. Cela ressemble beaucoup à écrire des tests de non régression pour un système qui change d’avis, avec des jeux de données annotés par des experts métier dont le temps est justement la ressource la plus rare de l’entreprise.

Copilot Cowork, ou comment se tirer une balle dans la métrique

L’exemple le plus spectaculaire du document concerne l’ingénierie. Une équipe de neuf personnes travaillant sur Copilot Cowork a été placée dans un bac à sable avec pour consigne d’aborder le développement produit en mode AI-first, autour de trois éléments : des spécifications décrivant l’intention, des évals définissant ce qu’est une bonne sortie, et le contexte fourni aux agents. Les membres de l’équipe deviennent des « méta-ingénieurs », « méta-designers » et « méta-PM », et le playbook annonce 18 600 commits, soit 123 par jour, 9,3 millions de lignes de code et une première version livrée en 35 jours.

Neuf personnes, 9,3 millions de lignes en 35 jours, cela fait environ 265 000 lignes par jour, soit près de 30 000 lignes par personne et par jour. Si quelqu’un vous présente ce chiffre comme une mesure de productivité, ne souriez pas, restez courtois :). Microsoft le précise également : ce résultat vient d’un projet dédié et ne constitue pas un benchmark applicable à l’ensemble de l’entreprise. Compter les lignes de code générées par des agents, c’est mesurer la qualité d’une maçonnerie au poids du ciment livré. Ce qui est réellement intéressant dans cet exemple n’est pas le volume, c’est le modèle opératoire : on ne cherche plus à accélérer le développeur individuel, on restructure l’équipe autour des specs, des évals et du contexte partagé. Le code devient un artefact dérivé ; la spécification et le critère de qualité deviennent le code source véritable.

Mesurer le métier, pas les jetons

Le cadre de mesure proposé sépare quatre couches : les entrées comme l’adoption et la préparation, le débit qui indique si l’IA pénètre réellement les workflows, les sorties comme les gains de productivité, et enfin les résultats métier comme le chiffre d’affaires ou le succès client. Les horizons diffèrent : deux à quatre semaines pour les entrées, un à trois mois pour les changements de workflow, trois à six mois pour les effets de performance, au-delà de six mois pour les résultats business. Voilà de quoi calmer les comités de direction qui réclament un ROI trimestriel sur un chantier qui touche l’organisation du travail.

Le pilote commercial cité mérite la même prudence. Sur 687 vendeurs Microsoft 365 Copilot au premier semestre 2024, Microsoft annonce un triplement de l’adoption des cas d’usage prioritaires, une hausse de 9,4 % du revenu par account manager et des taux de closing supérieurs de 20 % par rapport aux vendeurs faiblement utilisateurs. La comparaison repose sur des données observationnelles internes et non sur une expérimentation randomisée. Comparer les vendeurs qui utilisent beaucoup Copilot à ceux qui l’utilisent peu, c’est aussi comparer les vendeurs curieux et bien organisés aux autres. La corrélation est réelle, la causalité reste à démontrer.

Ce qu’il faut en retenir pour une DSI

Le document est un exercice de leadership éclairé produit par un fournisseur qui vend l’essentiel de la pile décrite, et aucun des résultats internes n’a été validé de façon indépendante. Cela dit, la structure d’argumentation est solide et utilisable telle quelle en interne.

Trois chantiers en découlent directement. D’abord, industrialiser le socle de données et de contexte, puisque c’est lui qui conditionne tout le reste, avec la gouvernance associée sur les étiquettes de sensibilité et les habilitations, sujet où beaucoup d’organisations découvrent que leurs droits SharePoint des quinze dernières années n’étaient pas conçus pour être lus par une machine très rapide et très zélée. Ensuite, créer une capacité interne d’évaluation, avec des jeux d’évals versionnés, des grilles rédigées par le métier et une observabilité des décisions d’agents. Enfin, poser une couche d’abstraction multimodèle assumée, via MCP et une passerelle d’inférence, de façon à pouvoir changer de fournisseur sans réécrire les workflows.

La conclusion de Microsoft se résume ainsi : la ressource rare n’est plus l’accès à un modèle puissant, mais les évaluations privées, le contexte propriétaire, les systèmes d’orchestration et de sécurité, et les boucles de feedback. C’est probablement vrai. C’est aussi, accessoirement, exactement ce que Microsoft vend :). Les deux affirmations peuvent parfaitement coexister, et c’est bien ce qui rend ce playbook intéressant à lire plutôt qu’à croire sur parole.