Pendant des années, nous avons parlé de Microsoft 365 en parlant de ses outils.
Word pour les documents. Excel pour les tableaux. PowerPoint pour les présentations. Outlook pour les courriels. SharePoint pour les espaces documentaires. OneDrive pour les fichiers individuels. Teams pour les conversations et la collaboration.
Cette manière de regarder Microsoft 365 était parfaitement logique lorsque nous étions essentiellement préoccupés par la création, le stockage et le partage de contenus.
Mais l’arrivée de Copilot et, plus largement, des agents IA est en train de changer la question.
Un agent ne se demande pas vraiment si l’information qu’il recherche se trouve dans Word, dans SharePoint, dans un courriel ou dans le compte rendu d’une réunion Teams.
Il cherche une source de connaissances.
Et cette petite différence de vocabulaire cache, à mon avis, un changement beaucoup plus important qu’il n’y paraît.
Microsoft 365 est en train de passer progressivement d’un ensemble d’applications contenant des données à une infrastructure de connaissances consommable par des humains, des assistants, des agents et des applications.
Pour comprendre ce changement, il faut commencer par oublier Copilot quelques minutes.
Et aller à la bibliothèque.
Une Knowledge Source, c’est quoi exactement ?
Microsoft définit les Knowledge Sources comme les données auxquelles un agent peut accéder lorsqu’il répond aux questions d’un utilisateur. Elles permettent de « grounder », c’est-à-dire d’ancrer, les réponses de l’agent dans des informations réelles plutôt que de s’appuyer uniquement sur les connaissances générales du modèle et ses instructions.
C’est une définition techniquement correcte.
Mais en formation, je préfère utiliser une autre image.
Une Knowledge Source est une bibliothèque.
Imaginez votre bibliothèque municipale.
Elle contient des milliers de livres. Pourtant, pouvoir entrer dans le bâtiment ne signifie pas que tous les ouvrages du monde s’y trouvent. Quelqu’un a décidé lesquels acheter, lesquels conserver, comment les classer, lesquels retirer des rayonnages et lesquels déplacer vers les archives.
Il existe donc plusieurs choses différentes.
Il y a d’abord le droit d’entrer dans la bibliothèque.
Ensuite, il y a le catalogue disponible dans cette bibliothèque.
Puis il y a la sélection éditoriale qui a constitué ce catalogue.
Enfin, il y a le travail permanent permettant de maintenir ce catalogue pertinent dans le temps.
C’est exactement comme cela que nous devrions commencer à regarder les Knowledge Sources dans Microsoft 365.
flowchart LR
U[Utilisateur ou agent] --> A[Identité]
A --> P[Permissions]
P --> K[Knowledge Source]
K --> C[Catalogue de connaissances]
C --> R[Contenus pertinents]
R --> AI[Raisonnement de l'IA]
AI --> REP[Réponse]L’IA ne devrait donc jamais être considérée indépendamment de la bibliothèque qu’on lui donne à consulter.
Un excellent modèle connecté à une mauvaise bibliothèque produira des réponses fondées sur une mauvaise bibliothèque.
Une bibliothèque n’est pas un entrepôt de livres
C’est probablement l’erreur la plus importante que nous avons commise avec la gestion documentaire depuis vingt ans.
Nous avons progressivement confondu stocker de l’information et organiser de la connaissance.
Ce n’est absolument pas la même chose.
Prenez une bibliothèque scientifique.
Le bibliothécaire ne récupère pas tous les documents qu’il trouve sur Internet pour les jeter sur des étagères.
Il existe un choix éditorial.
Certains ouvrages sont considérés comme pertinents. Certaines publications répondent à des critères scientifiques. Certains auteurs ou éditeurs constituent des références. Certains documents sont disponibles dans la section courante, d’autres sont conservés pour des raisons historiques.
Et surtout, la bibliothèque évolue.
Un ouvrage médical datant de 1983 peut avoir une immense valeur historique sans constituer la meilleure source pour répondre à une question médicale en 2026.
Il n’est pas nécessairement faux.
Il appartient simplement à un autre contexte temporel.
C’est une nuance absolument fondamentale pour l’IA.
flowchart TB
S[Corpus documentaire] --> Q{Quelle valeur possède le contenu ?}
Q -->|Actuel et fiable| A[Connaissance active]
Q -->|Historique mais utile| H[Connaissance historique]
Q -->|Obsolète sans valeur| D[Suppression]
Q -->|Obligation réglementaire| R[Conservation réglementaire]
A --> C1[Accessible au grounding]
H --> C2[Accessible avec contexte]
R --> C3[Conservé selon les règles]
D --> C4[Retiré du corpus]Microsoft commence d’ailleurs à formaliser très clairement cette nécessité. Dans ses recommandations pour préparer une fondation Microsoft 365 gouvernée pour Copilot, Microsoft recommande notamment d’identifier les contenus inactifs ou obsolètes, d’utiliser des politiques de rétention et de suppression et, lorsque nécessaire, d’archiver des contenus afin qu’ils soient conservés sans être utilisés par Copilot pour son raisonnement.
Nous revenons donc à notre bibliothèque.
La question n’est plus simplement :
« Avons-nous ce document ? »
Elle devient :
« Ce document doit-il encore faire partie des connaissances utilisées pour répondre à cette question ? »
Et cette question est beaucoup plus difficile.
Microsoft 365 est déjà votre bibliothèque
Regardons maintenant Microsoft 365 avec cette métaphore.
Une partie considérable de la connaissance d’une organisation s’y trouve déjà.
Dans SharePoint se trouvent les procédures, les documents d’équipe, les politiques et les espaces de collaboration.
Dans OneDrive se trouvent les documents professionnels individuels.
Dans Outlook se trouve une quantité phénoménale de connaissances contenues dans les échanges.
Dans Teams se trouvent les conversations.
Dans les réunions se trouvent des décisions, des explications et maintenant des transcriptions.
À cela peuvent s’ajouter Planner, les données organisationnelles, des systèmes externes et des sources reliées à Microsoft 365 par des connecteurs.
Work IQ illustre particulièrement bien cette évolution. Microsoft documente aujourd’hui une couche d’intelligence capable de raisonner sur les courriels, réunions, documents OneDrive et SharePoint, messages Teams, personnes, contexte organisationnel, Planner et résultats de recherche d’entreprise.
Vu de cette couche d’intelligence, la frontière entre Word, Outlook, Teams et SharePoint devient beaucoup moins importante.
Ce qui compte, c’est la connaissance accessible.
Le problème OneDrive : nous avons déménagé le désordre
Et c’est là que nous retrouvons un problème dont nous sommes en partie responsables.
OneDrive a été extraordinaire pour faciliter les migrations vers Microsoft 365.
Microsoft fournit encore aujourd’hui, pour de nombreux abonnements, 1 To de stockage OneDrive par utilisateur, avec des capacités supérieures selon les plans.
À l’époque des grandes migrations vers Microsoft 365, cette capacité a résolu un problème très concret.
Les lecteurs utilisateurs étaient remplis de fichiers.
Des années de documents.
Des copies.
Des versions.
Des fichiers temporaires.
Des présentations datant de plusieurs années.
Des documents dont personne ne savait vraiment s’ils étaient encore utiles.
Et quand venait le moment de migrer, il aurait fallu demander à chaque utilisateur :
« Peux-tu nettoyer ton lecteur avant la migration ? »
On connaît tous la réponse.
Alors nous avons trouvé une solution techniquement brillante.
On a tout migré.
Pourquoi faire le ménage quand on dispose d’un immense espace OneDrive ?
La migration était terminée.
Le problème semblait réglé.
Sauf que nous n’avions pas nettoyé la bibliothèque.
Nous avions déménagé le désordre dans le cloud.
Et pendant longtemps, ce n’était pas si grave.
Un fichier inutile perdu au fond du OneDrive d’un utilisateur ne gênait pratiquement personne.
Mais maintenant arrive l’IA.
Et nous lui demandons précisément de fouiller cette bibliothèque.
L’IA transforme la dette documentaire en problème opérationnel
C’est probablement l’une des conséquences les plus sous-estimées de Microsoft 365 Copilot.
L’IA ne crée pas nécessairement le problème de gouvernance documentaire.
Elle le révèle.
Imaginez une bibliothèque dans laquelle personne n’aurait fait de ménage depuis quinze ans.
Trois éditions d’une même procédure.
Une politique datant de 2018.
Une nouvelle version datant de 2024.
Une copie modifiée par quelqu’un en 2025.
Un brouillon non approuvé.
Une présentation qui décrit un projet finalement abandonné.
Une procédure officielle de 2026.
Tout est là.
Puis vous embauchez le bibliothécaire le plus rapide du monde.
Vous lui posez une question et, en quelques secondes, il est capable de parcourir les rayonnages.
Formidable.
Mais quel document doit-il croire ?
C’est exactement le problème.
Une IA disposant d’un accès parfait à une bibliothèque mal entretenue ne résout pas le problème documentaire. Elle devient simplement extrêmement efficace pour fouiller dans une bibliothèque mal entretenue.
L’accès n’est pas la qualité
Il faut donc distinguer plusieurs dimensions que l’on mélange trop facilement.
| Dimension | Question à poser | Équivalent dans une bibliothèque |
|---|---|---|
| Existence | L’information existe-t-elle ? | Le livre existe-t-il ? |
| Accessibilité | L’utilisateur peut-il y accéder ? | Possède-t-il une carte et le droit de consulter ce fonds ? |
| Pertinence | Cette information répond-elle à la question ? | Est-ce le bon ouvrage ? |
| Autorité | Cette information fait-elle référence ? | L’ouvrage est-il reconnu comme fiable ? |
| Actualité | Est-elle encore valide ? | S’agit-il de l’édition actuelle ? |
| Classification | Savons-nous ce qu’elle représente ? | Le livre est-il catalogué correctement ? |
| Cycle de vie | Devons-nous encore la conserver ? | Reste-t-elle en rayon, part-elle aux archives ou est-elle retirée ? |
| Sensibilité | Qui doit pouvoir la consulter ? | S’agit-il d’un fonds à accès restreint ? |
C’est une distinction essentielle.
Les permissions répondent à la question :
« Puis-je accéder à cette information ? »
Elles ne répondent absolument pas à :
« Cette information est-elle bonne ? »
Lorsqu’un agent utilise SharePoint comme source de connaissances, Microsoft conserve le modèle de permissions et ne doit restituer que le contenu auquel l’utilisateur a accès.
C’est indispensable.
Mais une permission correcte sur un document obsolète produit toujours un document obsolète correctement sécurisé.
La sécurité ne remplace pas la qualité documentaire.
Alors, qu’est-ce qu’une source standard ou premium ?
C’est ici qu’il faut être précis sur les mots.
Microsoft utilise déjà la distinction standard/premium pour certains mécanismes d’accès aux données, notamment dans l’écosystème des connecteurs Power Platform. Microsoft décrit des connecteurs standard, inclus selon les plans, des connecteurs premium disponibles avec certains plans et des connecteurs personnalisés permettant de se connecter à des API.
Dans Copilot et Copilot Studio, la situation est plus riche que cette simple opposition.
Les sources peuvent notamment être des sites SharePoint, des fichiers, des sites web, des données Dataverse, des Copilot connectors ou des données accessibles en temps réel par l’intermédiaire de Power Platform connectors.
Il ne faut donc pas prétendre qu’en 2026 Microsoft a déjà rangé universellement toutes les Knowledge Sources dans deux boîtes officielles appelées « Standard » et « Premium ».
Ce n’est pas le cas.
En revanche, plusieurs niveaux économiques apparaissent déjà très clairement.
| Situation | Nature de la connaissance | Mécanisme | Logique économique actuelle |
|---|---|---|---|
| Site web public | Publique | Grounding web | Peut être utilisable sans coût additionnel dans certains scénarios d’agents |
| SharePoint / Microsoft 365 | Données du tenant | Microsoft Graph / grounding Microsoft 365 | Dépend de la licence Copilot ou de la consommation selon le scénario |
| Copilot connector | Données externes indexées | Indexation dans Microsoft Graph | Dépend du scénario et de la licence |
| Power Platform connector | Données externes temps réel | Appel API | Peut dépendre du caractère standard ou premium du connecteur et du plan |
| API personnalisée | Source externe | API / custom knowledge | Dépend de l’infrastructure, de Copilot Studio et des services consommés |
| Work IQ API | Connaissance Microsoft 365 | REST, MCP ou A2A | Facturation à l’usage en Copilot Credits |
Microsoft indique par exemple que les agents reposant uniquement sur des instructions ou des sites publics peuvent être accessibles sans coût supplémentaire dans certains scénarios Copilot Chat, alors que l’accès à des données partagées du tenant, comme SharePoint ou le contenu de Copilot connectors, peut déclencher une facturation à la consommation pour des utilisateurs ne disposant pas de la licence Copilot correspondante.
Ce n’est donc déjà plus uniquement l’application utilisée qui détermine la valeur économique de l’expérience.
La nature de la connaissance consommée commence elle aussi à compter.
Et c’est là que les choses deviennent vraiment intéressantes.
Du fichier à l’API/MCP
Pendant des décennies, nous avons pensé l’informatique en termes de ressources.
D’abord la puissance de calcul.
Combien de processeurs ?
Combien de mémoire ?
Puis, avec le SaaS, une partie de ces questions a disparu pour l’utilisateur.
Dans Microsoft 365, personne ne demande combien de processeurs font fonctionner son site SharePoint.
En revanche, nous avons continué à mesurer une ressource très visible :
le stockage.
Microsoft 365 reste d’ailleurs largement construit autour d’entitlements de stockage. SharePoint dispose par exemple d’une capacité tenant calculée notamment à partir d’une capacité de base et du nombre de licences, tandis que OneDrive attribue une capacité par utilisateur.
Mais l’IA introduit une nouvelle unité économique.
La consommation.
Pour les modèles génératifs eux-mêmes, cette consommation est fréquemment mesurée en tokens. Microsoft Foundry distingue notamment les tokens d’entrée, les entrées mises en cache et les tokens de sortie. La génération de tokens de sortie nécessite davantage de calcul que le traitement de tokens d’entrée et leur coût peut donc être sensiblement supérieur selon le modèle.
Dans Microsoft 365, Microsoft ne facture pas nécessairement chaque expérience directement au nombre de tokens visibles par le client.
Microsoft introduit plutôt une unité abstraite : les Copilot Credits.
Ces crédits constituent désormais une monnaie commune pour plusieurs expériences IA facturées à l’usage. Microsoft explique explicitement que le coût d’une tâche peut varier selon le modèle utilisé, la quantité de contexte récupérée, le temps nécessaire à l’exécution et les outils appelés.
Regardez bien le changement.
flowchart LR
A[Informatique historique] --> CPU[Puissance de calcul]
CPU --> ST[Capacité de stockage]
ST --> SaaS[Licence SaaS par utilisateur]
SaaS --> AI[IA et agents]
AI --> USE[Consommation réelle]
USE --> CTX[Contexte récupéré]
USE --> MODEL[Modèle utilisé]
USE --> TOOLS[Outils et API appelés]
USE --> TIME[Travail effectué]
CTX --> CREDIT[Copilot Credits]
MODEL --> CREDIT
TOOLS --> CREDIT
TIME --> CREDITWork IQ est peut-être le signal le plus important
À mon avis, Work IQ mérite ici énormément d’attention.
Microsoft décrit Work IQ comme une couche d’intelligence capable de raisonner sur les données Microsoft 365 tout en conservant permissions, conformité et gouvernance.
Mais surtout, Microsoft expose désormais cette intelligence à travers plusieurs protocoles : REST, MCP et A2A.
Autrement dit, la connaissance contenue dans Microsoft 365 devient progressivement consommable comme un service.
Une application peut demander une information.
Un agent peut demander une information.
Un autre agent peut déléguer une tâche.
Un client compatible MCP peut appeler Work IQ comme outil.
Et Microsoft indique très explicitement que Work IQ constitue la fondation recommandée pour les nouveaux développements agentiques et IA sur les données Microsoft 365. Son utilisation est facturée selon un modèle de consommation utilisant les Copilot Credits.
Pour moi, c’est un signal extrêmement important.
flowchart TB
M365[Microsoft 365]
M365 --> SP[SharePoint]
M365 --> OD[OneDrive]
M365 --> EX[Outlook]
M365 --> TM[Teams]
M365 --> PL[Planner]
SP --> WIQ[Work IQ]
OD --> WIQ
EX --> WIQ
TM --> WIQ
PL --> WIQ
WIQ --> REST[REST API]
WIQ --> MCP[MCP]
WIQ --> A2A[Agent-to-Agent]
REST --> APP[Applications]
MCP --> AG1[Assistants IA]
A2A --> AG2[Autres agents]
APP --> CONS[Consommation]
AG1 --> CONS
AG2 --> CONS
CONS --> CC[Copilot Credits]Nous ne sommes plus simplement en train d’ouvrir Word pour lire un document.
Nous sommes en train de permettre à des systèmes de consommer de la connaissance organisationnelle par API.
Et si le vrai changement de licence était là ?
À partir d’ici, je quitte volontairement la documentation Microsoft.
Ce qui suit est ma lecture de l’évolution actuelle, pas une annonce de Microsoft.
Je pense que nous allons progressivement passer d’un modèle économique principalement organisé autour de l’utilisateur, de l’application et du stockage à un modèle dans lequel la consommation de connaissances et de capacités IA prendra une place beaucoup plus importante.
Microsoft ne dit pas aujourd’hui :
« Demain, Microsoft 365 sera facturé en fonction du type de Knowledge Source. »
Je ne prétends donc absolument pas que ce modèle est annoncé.
Mais regardons les pièces déjà posées sur la table.
Microsoft dispose de Knowledge Sources.
Microsoft distingue déjà des connecteurs standard et premium dans Power Platform.
Microsoft permet aux agents d’utiliser des connaissances publiques, des connaissances du tenant et des connaissances provenant de systèmes externes.
Microsoft dispose de mécanismes de facturation à la consommation.
Microsoft introduit les Copilot Credits comme monnaie commune de plusieurs services IA facturés à l’usage et annonce que davantage de services pourront rejoindre ce modèle.
Microsoft expose maintenant la connaissance Microsoft 365 à travers Work IQ, notamment via REST, MCP et A2A, avec une facturation à la consommation.
Le déplacement est difficile à ignorer.
Hier :
Combien d’espace stockons-nous ?
Aujourd’hui :
Quels utilisateurs possèdent quelle licence ?
Demain, de plus en plus :
Quelle connaissance consommons-nous, par quel service, avec quel niveau de traitement et en quelle quantité ?
Je ne pense pas que le stockage disparaisse.
Je pense simplement qu’il cessera progressivement d’être la seule unité intéressante.
La connaissance premium ne peut pas être simplement une connaissance chère
Et c’est ici que j’aimerais pousser le raisonnement encore plus loin.
Si nous commençons à parler de sources de connaissances auxquelles nous attribuons davantage de valeur, une source « premium » ne devrait pas simplement signifier :
« une source dont l’accès coûte plus cher ».
Une véritable source de connaissances premium devrait être une source mieux gouvernée.
Une source dont on connaît le propriétaire.
Une source dont le contenu est classifié.
Une source dont les permissions sont maîtrisées.
Une source dont le cycle de vie est défini.
Une source dans laquelle les documents obsolètes sont identifiés.
Une source dans laquelle on sait distinguer le document de référence du brouillon.
Une source dans laquelle on sait quelle information fait autorité.
Autrement dit :
la valeur d’une Knowledge Source ne devrait pas seulement dépendre de la technologie utilisée pour y accéder. Elle devrait dépendre de la qualité de la connaissance qu’elle contient.
Et cela, aucune licence Copilot ne peut le faire à votre place.
Le grand retour de l’archiviste
Il y a quelques années, nous avons probablement cru que SharePoint allait simplifier tellement la gestion documentaire que nous aurions moins besoin des métiers traditionnels de l’information.
On pouvait créer des bibliothèques documentaires.
Ajouter des colonnes.
Faire de la recherche.
Créer des sites.
Stocker énormément de contenu.
Et progressivement, dans beaucoup d’organisations, le travail documentaire a été remplacé par le stockage documentaire.
On a parfois oublié une personne essentielle.
L’archiviste.
Pas nécessairement l’archiviste au sens de quelqu’un qui descend des boîtes de documents dans un sous-sol.
Je parle du métier.
Celui qui sait définir la valeur d’une information.
Celui qui comprend son cycle de vie.
Celui qui sait pourquoi on conserve quelque chose.
Celui qui sait quand il faut le détruire.
Celui qui distingue un document courant d’un document historique.
Celui qui comprend qu’un document peut être authentique sans être encore applicable.
Avec l’IA, ce métier devient soudain extrêmement moderne.
Microsoft Purview Data Lifecycle Management permet précisément de conserver ce qui doit l’être et de supprimer ce qui ne doit plus l’être dans Exchange, SharePoint, OneDrive, Teams et d’autres services Microsoft 365. Records Management apporte les mécanismes nécessaires à la gestion des enregistrements et de leurs obligations réglementaires.
Purview, SharePoint Advanced Management et les autres outils de gouvernance deviennent donc beaucoup plus que des outils destinés à satisfaire le service juridique.
Ils participent à la construction de la bibliothèque que l’IA utilisera.
flowchart LR
ARCH[Archiviste / Records Manager] --> RULES[Règles documentaires]
RULES --> PUR[Microsoft Purview]
PUR --> CLASS[Classification]
PUR --> RET[Conservation]
PUR --> DEL[Suppression]
PUR --> SEC[Protection]
PUR --> LIFE[Cycle de vie]
CLASS --> KS[Knowledge Source gouvernée]
RET --> KS
DEL --> KS
SEC --> KS
LIFE --> KS
KS --> AI[Copilot et agents]
AI --> USER[Utilisateur]Je pense donc que nous allons assister à quelque chose d’assez amusant.
Nous avons passé des années à considérer certains métiers documentaires comme appartenant au passé.
L’IA pourrait bien être ce qui les rend indispensables au futur.
Le titre changera peut-être.
Records Manager.
Information Governance Specialist.
Knowledge Manager.
Purview Specialist.
Peu importe.
La fonction, elle, redevient fondamentale.
Votre futur Copilot sera aussi bon que votre bibliothèque
Pendant des années, nous avons administré Microsoft 365 comme un ensemble d’outils.
Je pense que nous devons maintenant commencer à l’administrer comme une bibliothèque de connaissances.
Et une bibliothèque ne se gouverne pas uniquement avec des téraoctets.
Elle se gouverne avec des choix.
Quelles connaissances voulons-nous conserver ?
Lesquelles font autorité ?
Qui en est responsable ?
Qui peut les consulter ?
Pendant combien de temps sont-elles valides ?
Quand deviennent-elles historiques ?
Quand doivent-elles être archivées ?
Quand doivent-elles disparaître ?
Et surtout :
quelles connaissances sommes-nous prêts à laisser une intelligence artificielle utiliser pour prendre part à notre travail ?
Voilà, à mon avis, la véritable question derrière les Knowledge Sources.
La distinction entre standard et premium n’est peut-être que le début.
Parce que lorsque les applications, les assistants et les agents consommeront de plus en plus nos connaissances à travers des API, la valeur ne sera plus seulement dans l’endroit où l’information est stockée.
Elle sera dans la qualité, la gouvernance, l’accessibilité et la consommation de cette connaissance.
Nous avons passé vingt ans à remplir Microsoft 365.
Nous allons probablement passer les prochaines années à apprendre à décider ce qu’il mérite de savoir.
Et finalement, ce n’est peut-être pas Copilot qui va nous obliger à réinventer notre gestion documentaire.
Il va simplement nous obliger à refaire ce que les bons bibliothécaires et les bons archivistes savaient déjà faire depuis longtemps :
choisir, classer, contextualiser, conserver et, parfois, avoir le courage de jeter.




























