De «Copilot dans Office» à «Office dans Copilot»

Pendant des années, l’evolution des produits de Microsoft s’est souvent lue comme une suite de «centres de gravité» qui se déplacent. Un coup le centre est le PC (Windows), puis la suite bureautique (Office), puis le cloud (Microsoft 365), puis la collaboration (Teams) et, maintenant, l’intelligence artificielle.

Ce qui est fascinant, c’est que la vague IA n’est pas «juste une fonctionnalité de plus». C’est une réorganisation du stack. Et, surtout, elle se fait en deux phases bien distinctes. Cela peut déjà être ressenti en testant le Mode Agent.

Comprendre ces deux phases, c’est comprendre pourquoi l’utilisateur va progressivement arrêter de «choisir une application» pour se concentrer sur «accomplir une étape de travail» et tout ce que cela implique dans la transformation des usages et donc l’accompagnement au changement (adoption).

Les grandes phases d’évolution des produits Microsoft

On peut résumer l’évolution «produit» de Microsoft comme une succession de paradigmes dominants:

1. Le paradigme logiciel local (desktop first)
   Le logiciel vit sur la machine, les fichiers aussi. Le cœur, c’est Windows + Office. L’utilisateur pense en termes de «j’ouvre Word / Excel / PowerPoint…».
2. Le paradigme serveur et entreprise (client-serveur, Active Directory, Exchange, SharePoint, etc.)
   Les usages se structurent à l’echelle de l’organisation. On partage, on gouverne, on sécurise. L’utilisateur pense en termes de «je dépose dans SharePoint, j’envoie via Outlook».
3. Le paradigme cloud et service (Microsoft 365)
   Les applications deviennent des expériences synchronisées, accessibles partout, avec une identité et une couche de sécurité transversale. L’utilisateur commence à penser en termes de «mon environnement de travail».
4. Le paradigme collaboration (Teams as a hub)
   Pendant la phase «modern workplace», Teams est devenu l’interface dominante: réunions, chats, fichiers, apps intégrées. L’utilisateur pense en termes de «je fais tout dans Teams».
5. Le paradigme IA (Copilot as a control layer)
   La bascule actuelle, c’est que l’interface dominante n’est plus une application. C’est l’assistant, puis l’orchestrateur. Et c’est là qu’on voit clairement les deux phases.

Phase 1: Copilot s’intègre dans les applications

L’idée de base

Phase 1, c’est l’IA comme «copilote» au sens littéral: tu restes dans ton application habituelle, et Copilot t’aide à faire mieux et plus vite.

• Dans Word: t’aider à rédiger, reformuler, structurer.
• Dans Excel: t’aider à analyser, générer des formules, faire parler les tableaux.
• Dans Outlook: t’aider à écrire, résumer, préparer des réponses.
• Dans Teams: t’aider à suivre les réunions, résumer, retrouver des décisions.

Le point clé: l’application reste le théâtre principal, Copilot est un panneau, une barre latérale, un compagnon.

Pourquoi cette phase était nécessaire

Parce que Microsoft devait:

• Habituer les utilisateurs (adoption, confiance).
• Accrocher l’IA aux objets natifs (documents, tableaux, mails, réunions).
• Construire la couche d’autorisations et de conformité autour de ces usages.

C’était la voie la plus «douce»: pas besoin de réinventer l’interface, on ajoute une surcouche.

Le symptôme typique de la Phase 1: les «App Skills» dans Excel

Excel à eu des «compétences d’application» (app skills) qui guidaient certaines actions. Or, Microsoft en a annoncé la disparition au profit du Mode Agent: «App Skills will be removed from Excel by late-February 2026».
Et ce retrait est aussi documenté dans les communications de type Message Center: App Skills retirées et remplacées par Agent Mode.

Ca, c’est un marqueur brutal: Microsoft ne «rafraichit» pas une feature, il remplace un modèle mental.

Quand l’assistant devient agent

Avant de parler de Phase 2, il faut comprendre ce que Microsoft entend par «Mode Agent» (au moins dans Excel, parce que c’est là ou la définition est la plus concrete pour le moment, mais c’est également le cas dans Word et bientôt PowerPoint, etc…).

Sur la page officielle, Microsoft décrit Agent Mode comme une manière de construire et modifier un classeur côte à côte avec Copilot, en utilisant des objets Excel complexes (tableaux, graphiques, tableaux croisés dynamiques, formules).

C’est crucial, parce que ca change la nature de l’aide:

• On n’est plus dans «Copilot me propose du texte ou une formule».
• On est dans «Copilot orchestre une séquence d’actions, applique des changements, manipule les objets natifs».

Autrement dit: l’IA n’est plus seulement un conseiller, elle devient un exécutant.

Et c’est exactement la rampe de lancement vers Phase 2.

Phase 2: les applications s’intègrent dans l’orchestrateur Copilot

L’idee de base

Phase 2, ce n’est plus «Copilot dans Word».
C’est «Word dans Copilot».

Dit autrement: Copilot devient la surface principale. Les applications (Word, Excel, Outlook, PowerPoint) deviennent des capacités mobilisées à la demande, comme des «bras» spécialisés.

Microsoft pousse cette idée avec des «Agents Word, Excel et PowerPoint» accessibles depuis Copilot Chat, dans une approche chat-first: tu démarres ton projet dans la conversation, l’agent te pose des questions, et produit le bon livrable. Ce qui au passage permet également de contextualiser les intéractions avec Copilot de manière plus complète.

Et Microsoft communique aussi sur «Agent Mode across Word, Excel, and PowerPoint», avec un accès «Frontier» (preview) et une logique de déploiement progressif.

Ce qui rend la Phase 2 possible

La pièce technique derrière le rideau, c’est l’émergence de Model Context Protocol (MCP), que Microsoft intègre dans Copilot Studio pour connecter des serveurs fournissant:

• des ressources (données «type fichiers»),
• des outils (fonctions actionnables),
• des prompts (gabarits).

Et surtout, Microsoft publie un catalogue de serveurs MCP intégrés qui inclut notamment Outlook Mail, Outlook Calendar, Teams, SharePoint/OneDrive, Word, etc.

https://mcp.azure.com/?vendors.microsoft=true

Un détail qui vaut de l’or: la référence du serveur calendrier dit explicitement qu’il sert à créer, mettre à jour, récupérer des évènements, gérer des invitations, vérifier des disponibilités, et qu’il est lié au programme Frontier.

Donc l’intuition qui fait penser «je ne serais pas surpris de voir Copilot générer des invitations à des rendez-vous et les envoyer» n’est pas juste plausible: l’outillage officiel est déjà décrit comme capable de le faire, dans le cadre de cette architecture.

Pourquoi c’est une approche radicalement différente

Ces agents / serveurs vont faire «mieux que Python» sur de nombreux sujets.

Pas parce que Python est mauvais. Mais parce que Python est un outil généraliste alors que:

• Agent Mode et les agents Office manipulent les objets natifs (styles, thèmes, layouts, sections, tableaux, champs, références, gabarits, structures de documents, etc.).
• Un serveur MCP peut exposer des opérations de haut niveau («créer un plan de cours conforme à tel gabarit», «générer une invitation et vérifier les disponibilités »), là ou Python a besoin de bibliothèques, de glue code, et d’un environnement d’exécution.

La vraie différence, c’est la granularité et la gouvernance:

• Python, c’est souvent «je génère du contenu, puis je colle dans le document».
• Les agents Office, c’est «je modifie le document comme si j’étais dans l’application, avec ses règles et ses objets».

Pour les gabarits, les chartes graphiques, les structures «non négociables», cette approche à un potentiel énorme.

Le changement de paradigme pour l’utilisateur

C’est la partie la plus importante: l’utilisateur ne veut pas «utiliser Word». Il veut «produire un document à un moment du processus».

Prenons un exemple: produire un support de cours.

Avant (paradigme application)

1. «Je dois faire un plan de cours: j’ouvre Word.»
2. «Je dois définir des exercices: je reste dans Word, ou j’ouvre Excel.»
3. «Je dois faire les slides: j’ouvre PowerPoint.»
4. «Je dois inviter des gens: j’ouvre Outlook ou Teams.»
5. «Je dois stocker: je vais dans SharePoint.»

L’utilisateur doit connaitre les outils, leurs gabarits, leurs bonnes pratiques, et l’ordre logique du travail.

Demain (paradigme orchestrateur)

1. L’utilisateur dit dans Copilot: «Je construis une formation de 2h, aide-moi à produire le plan de cours conforme au gabarit AFI.»
2. Copilot orchestre l’agent (ou le serveur MCP) qui sait produire un document avec une structure précise.
3. Ensuite: «Propose 5 exercices progressifs et prépare leur fiche animateur.»
4. Puis: «Génère une présentation conforme à notre slide master et à notre palette.»
5. Puis: «Crée l’invitation, vérifie les disponibilités, envoie à la liste X.»

Et la, le détail dingue, c’est que l’utilisateur peut ne même plus se demander si c’est Word, PowerPoint ou autre. Il suit un workflow.

Techniquement, ce workflow peut s’appuyer sur:

• un serveur Outlook Calendar MCP pour les invitations et la disponibilité,
• un serveur Outlook Mail MCP pour la préparation et l’envoi de communications,
• des agents Word / Excel / PowerPoint pour produire les livrables depuis Copilot Chat.

Les signaux faibles qui confirment la Phase 2

Voici les marqueurs les plus parlants, et ils sont tous «écrits noir sur blanc»:

• Retrait d’App Skills dans Excel fin fevrier 2026 au profit d’Agent Mode.
  Quand Microsoft retire une fonctionnalite récente, c’est rarement cosmetique: c’est une consolidation de trajectoire.
• Agent Mode se formalise comme expérience majeure (Excel) et s’étend à Word / Excel / PowerPoint via Frontier et rollout.
• Les agents Word/Excel/PowerPoint dans Copilot Chat: le demarrage de projet «chat-first» est explicite.
• Le catalogue officiel de serveurs MCP Microsoft: Outlook, calendrier, Teams, SharePoint/OneDrive, Word, etc.
  Ca, c’est un statement architectural: Microsoft transforme ses apps en services actionnables.

Ce qu’on peut dors et déjà affirmer

• Il y a un mouvement clair vers Agent Mode et le retrait d’App Skills dans Excel.
• Microsoft pousse des agents Office dans Copilot Chat (Word, Excel, PowerPoint).
• Microsoft formalise MCP dans Copilot Studio et fournit des serveurs MCP (dont Outlook Calendar) avec opérations d’invitations et disponibilités.

Ce qu’on peut poser comme hypothèses (très plausibles)

• Agent Mode, les agents Office, et les serveurs MCP convergent vers une même architecture «orchestrateur -> outils».
• Les gabarits et chartes (documentaires et graphiques) deviendront une «couche d’actions» standardisée, bien mieux intégrée que des scripts ad hoc.
• L’utilisateur opèrera de plus en plus par «intention de processus» et de moins en moins par «choix d’application».

Conséquences pratiques

1) La formation change de cible

Avant: former sur Word / Excel / PowerPoint.
Demain: former sur des scénarios et des processus («produire un livrable conforme»), et sur la manière de dialoguer avec l’orchestrateur.

2) Les gabarits deviennent un actif stratégique

Si Copilot devient l’interface, alors:

• tes gabarits Word (plan de cours, fiche exercice, rapport),
• tes slide masters PowerPoint,
• tes modèles Excel,
  deviennent des «recettes industrielles». Ils ne sont plus juste des fichiers, ils deviennent des standards de production.

3) La gouvernance ne disparait pas, elle remonte d’un cran

Plus l’orchestration est puissante, plus tu dois:

• maitriser les droits,
• tracer qui a produit quoi, et ce même par délégation potentielle à un agent doté d’une identité,
• encadrer les actions (envoi de mails, creation d’évènements, partage de fichiers).

MCP rend l’intégration plus simple, mais ca rend aussi les actions plus faciles à automatiser. Donc la question «qui à le droit d’exécuter quoi» devient centrale.

Deux phases, une seule trajectoire

Phase 1: Copilot dans les apps. Maintenant mais déjà hier…
Phase 2: les apps dans Copilot. Maintenant et déjà le futur…

Et la différence n’est pas un détail de produit, c’est un renversement du centre de gravité: on passe d’un monde ou l’utilisateur navigue entre des outils, à un monde ou l’utilisateur suit une intention, et l’orchestrateur mobilise les bons agents et serveurs pour exécuter. Et c’est un changement énorme dans l’approche de l’accompagnement au changement, l’adoption de l’usager et la formation qui soutient cette stratégie.

C’est exactement le genre de bascule qu’on n’apprecie pas assez tant qu’on la décrit en « fonctionnalités ».

En réalité, c’est une refonte de l’interface du travail.