Temps de lecture : ~8 minutes
La scène
Mardi matin. Je sors d’une réunion de pilotage avec un client en plein déploiement Copilot — une organisation de 200 personnes qui passe progressivement à l’IA, site par site, équipe par équipe.
On approche d’une étape charnière : la phase technique est derrière nous, la phase d’adoption commence. Il faut préparer le comité de pilotage.
Ordre du jour, plan de communication Go Live, gouvernance des feedbacks, plan de formation, indicateurs de suivi…
1 journée de boulot minimum pour un consultant classique.
En retard sur mon organisation, je tente. J’ouvre Copilot Cowork.
Je décris la situation à voix haute, comme si j’expliquais le contexte à un collègue :
« Pour mon client XXX, on passe de la phase déploiement à la phase adoption. Les équipes n’ont pas forcément été informées du Go Live. Il faut structurer le point d’entreprise avec : le bilan de ce qui a été fait, le kit de communication à déployer, une gouvernance des feedbacks, le plan de formation terrain… »
10 minutes plus tard, j’avais une présentation de 13 slides. Avec le contexte réel de la mission dedans — les dates clés, les noms des référents, la timeline depuis le début du projet. Avec mon branding appliqué. Rangée dans le bon dossier SharePoint.
Je n’avais pas touché à PowerPoint.
Ce qui vient de changer dans mon métier
Depuis dix ans, le travail d’un consultant ou d’un chef de projet ressemble à peu près à ça : tu passes une bonne partie de ton temps à structurer et produire des livrables.
Compte-rendu de réunion, présentation de steerco, plan de projet, note de cadrage.
Tu sais faire, les livrables sont propres, mais ça prend du temps. Avec un peu de chance tu as un·e junior pour faire aligner les champs sur PPT.
Ce temps-là, il vient de changer de nature.
Ce que je commence à observer dans ma propre pratique, c’est un glissement assez radical : mon travail ne consiste plus à produire des livrables. Il consiste à structurer les conditions pour que l’IA les produise.
Ce n’est pas la même chose.
Produire un livrable, c’est maîtriser Word, PowerPoint, les bonnes formulations, la mise en page, la logique de présentation. C’est du savoir-faire artisanal.
Structurer pour l’IA, c’est autre chose : c’est penser à comment l’information va circuler, être stockée, être retrouvée — et comment formuler les instructions pour que le résultat soit exploitable. C’est presque du design d’information.
Je remarque un changement concret dans mes réunions : il m’arrive de plus en plus souvent de reformuler une décision ou un point de discussion — non pas pour les participants autour de la table, mais pour que l’IA puisse le comprendre ensuite. Je parle différemment. Plus structuré. Moins dans l’implicite métier, plus dans l’explicite utilisable.
C’est un changement de posture qui semble anodin. Il ne l’est pas.
Voici le résultat :
Pourquoi Cowork a mieux fonctionné que Claude sur ce cas précis
C’est la question qui m’a le plus intéressé après cette session.
J’utilise Claude quotidiennement. C’est mon outil principal pour la réflexion, la structuration, la création de contenu. Et pourtant, sur ce cas, Copilot Cowork a produit un résultat supérieur — non pas parce que le modèle est meilleur, mais parce que les conditions d’usage étaient différentes. Pour comprendre pourquoi, il faut parler de contexte.
Le contexte : la matière première de l’IA
Quand tu interagis avec un outil IA, ce qu’il produit dépend entièrement de ce qu’il sait. Et ce qu’il sait dépend de deux types de contexte très différents.
Le contexte persistant, c’est tout ce que l’outil retient entre les sessions. Ses instructions permanentes, ses règles de comportement, ses connaissances sur toi, ton domaine, ta façon de travailler. C’est ce qui fait que l’outil te connaît avant même que tu commences à parler.
Le contexte dynamique, c’est tout ce qu’il peut aller chercher en temps réel. Tes fichiers, tes emails, tes conversations, tes données. C’est ce qui lui permet de comprendre ce projet précis, cette situation précise, maintenant.
Ces deux dimensions sont indépendantes — et les outils actuels sont rarement bons sur les deux à la fois.
Le problème de Copilot classique
Depuis son lancement, Copilot dispose d’un contexte dynamique exceptionnel. Il a accès à l’Office Graph — toutes tes conversations Teams, tes emails Outlook, tes fichiers SharePoint et OneDrive, tes réunions. Pour une mission client bien documentée dans M365, c’est une puissance de recherche réelle.
Mais son contexte persistant a longtemps été son talon d’Achille. Chaque instruction, chaque règle de comportement, chaque connaissance sur ta façon de travailler était reformulée par le modèle à chaque session. Le résultat : des livrables génériques, sans voix, sans logique métier propre. Techniquement corrects, mais pas à la hauteur.
Le problème de Claude
À l’inverse, Claude offre un contexte persistant de très haute qualité. Les instructions système, les skills spécialisés, les mémoires entre sessions — tout ça permet d’obtenir des résultats très qualitatifs, avec une voix cohérente, une logique métier respectée, des formats précis.
Son point faible : le contexte dynamique. Claude n’est pas nativement connecté à tes données M365. Il ne sait pas ce qui s’est dit dans ta réunion Teams d’hier. Il ne peut pas aller chercher le compte-rendu de la réunion de cadrage de mars. Il travaille avec ce que tu lui donnes dans la conversation — et seulement ça.
Copilot Cowork : le meilleur des deux mondes
Copilot Cowork change l’équation.
C’est techniquement Copilot — donc avec l’accès à l’Office Graph, au contexte dynamique complet. Mais c’est un Copilot qui tourne sur Claude et qui supporte les skills — des instructions persistantes structurées, précises, qualitatives.
Sur ma session de la semaine, voilà ce qui s’est passé concrètement :
- Contexte dynamique → Cowork a recherché dans mes conversations Teams et mes emails tout ce qui concernait la mission. Il a retrouvé les réunions de cadrage d’avril 2025, les échanges sur la structure des canaux, les décisions de gouvernance, le nom du référent côté client. Sans que je lui donne rien.
- Contexte persistant → grâce aux instructions chargées dans Cowork, il connaissait mon branding, ma structure de slides préférée, mes règles de présentation, ma logique métier.
L’intersection de ces deux dimensions a produit quelque chose que ni Claude seul ni Copilot classique n’auraient pu produire dans les mêmes conditions : un livrable qui parle de ma mission réelle, dans ma voix, avec mes standards.
La condition sine qua non : des données bien organisées
Là où cette session m’a le plus appris, c’est sur ce qui rend l’outil performant — et ce n’est pas l’outil lui-même.
Cowork a pu aller chercher le contexte de la mission parce que tous mes échanges client étaient dans Teams. Structurés. Datés. Retrouvables. Chaque conversation dans le bon canal, chaque fichier dans le bon dossier, chaque décision documentée quelque part dans le système.
Si j’avais travaillé de façon dispersée — emails personnels, notes sur papier, fichiers éparpillés sur un bureau local — l’agent aurait cherché dans le vide. Le résultat aurait été générique. Inutile.
C’est exactement le message que je répète à mes clients depuis deux ans, cette fois avec une démonstration grandeur nature : l’IA amplifie ce qui est bien structuré. Elle amplifie aussi le chaos.
Structurer avant l’IA. Pas après.
Les limites réelles — et pourquoi elles sont peut-être un garde-fou
Copilot Cowork n’est pas parfait. Et les limites actuelles méritent d’être nommées honnêtement.
Il peut lire. Il ne peut pas encore écrire partout.
Concrètement, au moment où j’écris ces lignes, Copilot Cowork ne peut pas modifier directement une liste SharePoint, éditer un OneNote, ou mettre à jour un fichier en place.
Il peut créer, générer, produire — mais la boucle d’action sur l’environnement M365 existant reste limitée.
C’est frustrant quand on imagine ce que ça pourrait donner : mettre à jour un plan de projet, alimenter un registre de décisions, pousser un feedback dans une liste… tout ça depuis une conversation naturelle.
Mais c’est peut-être aussi la limite la plus utile.
Un outil qui peut lire l’ensemble de votre environnement numérique et le modifier en autonomie, c’est une puissance considérable — et un risque de même ampleur. La limite actuelle force une validation humaine à chaque étape de modification. Pour l’instant, c’est probablement la bonne posture : l’agent propose, l’humain valide et exécute.
Deuxième limite, plus structurelle : les data boundaries européennes.
Cowork fait tourner Claude — c’est-à-dire un modèle Anthropic. Or, à ce jour, Anthropic ne propose pas encore de résidence des données en Europe. Concrètement, les données traitées par Claude transitent par des infrastructures américaines.
Pour un indépendant ou une PME qui fait une présentation de steerco, c’est souvent acceptable. Pour un grand compte soumis au RGPD, à des exigences sectorielles (santé, finance, défense) ou à une politique DSI stricte sur la souveraineté des données, ça peut être un bloquant réel — voire rédhibitoire.
Microsoft, de son côté, a déjà déployé ses EU Data Boundaries pour Copilot et M365 : les données des clients européens restent en Europe. Mais dès lors qu’on intègre un modèle tiers comme Claude dans la chaîne — ce que fait précisément Cowork — cette garantie ne tient plus entièrement.
C’est un point que je soulève systématiquement avec mes clients avant toute mise en production : quel est le niveau de sensibilité des données qui vont transiter dans cet outil ? Pour du contenu de pilotage interne peu sensible, la question se pose différemment que pour des données RH, des données clients ou des informations stratégiques couvertes par des accords de confidentialité.
Anthropic a annoncé travailler sur des options de résidence des données pour ses clients enterprise. Mais en l’état, c’est une contrainte à intégrer dans l’évaluation — pas une raison de ne pas tester, mais une raison de bien cadrer le périmètre d’usage.
Ce que tout cela annonce
Ce qui m’intéresse dans cette session, ce n’est pas la prouesse technique. C’est ce qu’elle révèle sur la trajectoire du métier.
Le consultant ou le chef de projet de demain ne sera pas jugé sur sa capacité à produire des livrables. Des outils s’en chargeront de mieux en mieux. Il sera jugé sur sa capacité à structurer l’environnement informationnel dans lequel ces outils travaillent.
Ça veut dire :
- Organiser les données dès le début de la mission pour qu’elles soient exploitables par un agent
- Formuler les éléments clés en réunion de façon à ce qu’ils soient compréhensibles hors contexte
- Construire les instructions persistantes qui donnent à l’outil une voix et une logique métier
- Savoir déléguer le formalisme pour se concentrer sur la valeur que l’IA ne peut pas encore produire : le jugement, la relation, la décision
Ce n’est pas « l’IA va remplacer les consultants. »
C’est : les consultants qui comprennent comment structurer pour l’IA vont rendre ceux qui ne le font pas obsolètes.
Pour aller plus loin
Ce sujet rejoint directement la problématique centrale de l’audit de maturité digitale que je propose aux organisations : avant même de déployer Copilot, est-ce que vos informations sont dans un état qui permet à un agent de travailler efficacement ?
La plupart du temps, la réponse honnête est non — et c’est un chantier à traiter avant, pas après.
Si vous êtes en train de réfléchir à votre déploiement Copilot ou à votre organisation M365, ce diagnostic est le point de départ.
👉 Faites votre auto-diagnostic en quelques minutes
Thibaud Hollender — fondateur Digital Ninja
MVP Microsoft | Expert M365 & Modern Work
digitalninja.fr
