J’ai volontairement construit un projet qui se contredit pour tester les blocs-notes Copilot
Les démonstrations d’IA générative sont souvent trop propres.
On prend un document, on demande un résumé. On ajoute un second document, on pose une question. Puis on montre que Copilot est capable de retrouver une information cachée à la page 37 d’un PDF que personne n’avait envie de lire.
C’est utile.
Mais ce n’est pas vraiment le problème que nous rencontrons dans une entreprise.
Le problème commence lorsque plusieurs documents parlent du même projet, mais ne racontent plus exactement la même histoire.
C’est précisément pour cela que j’ai construit Project Atlas, un scénario volontairement imparfait que j’utilise maintenant pour expérimenter les blocs-notes Copilot.
Et puisque le scénario commence à prendre une certaine ampleur, j’ai décidé d’en partager une partie ici.
Une partie seulement.
Parce qu’il faut quand même que je garde quelques surprises pour mes conférences et, surtout, pour la formation de 3 h 30 où nous pouvons réellement pousser l’exercice à l’échelle d’une organisation.
Le vrai problème n’est pas de trouver l’information
Imaginons une entreprise fictive, Contoso.
Contoso prépare le déploiement de Microsoft 365 Copilot auprès de ses employés.
Comme dans n’importe quel vrai projet, l’information est dispersée.
Il existe une charte de projet dans SharePoint.
Une présentation PowerPoint préparée pour la direction.
Un budget Excel.
Des risques.
Des réunions Teams.
Des échanges Outlook.
Des documents RH.
Des plans de formation.
Des communications.
Et, évidemment, quelques présentations qui ont déjà commencé à raconter le futur avant que les décisions aient réellement été prises.
Rien d’exceptionnel.
C’est même probablement beaucoup plus réaliste qu’un joli dossier contenant cinq documents parfaitement cohérents.
flowchart LR
A[SharePoint<br/>Documents] --> N[Bloc-notes Copilot]
B[Outlook<br/>Échanges] --> N
C[Teams<br/>Réunions] --> N
D[Excel<br/>Données] --> N
E[PowerPoint<br/>Narratif] --> N
N --> F[Analyse]
F --> G[Contradictions]
G --> H[Vérification]
H --> I[Livrable]Le travail intéressant ne consiste donc pas simplement à demander :
« Qu’est-ce que disent mes documents ? »
La vraie question devient plutôt :
« Qu’est-ce que je peux réellement considérer comme établi, décidé, proposé ou encore incertain ? »
Et là, les choses deviennent beaucoup plus intéressantes.
Voici le début du scénario Atlas
Je vais vous donner suffisamment d’éléments pour que vous puissiez reproduire l’expérience.
Pas suffisamment pour connaître toute la fin.
Dans Project Atlas, vous pouvez commencer avec cinq documents seulement.
La charte du projet
C’est le document qui sert de référence initiale.
Il indique notamment :
- 500 employés ciblés;
- une date cible au 15 octobre;
- une enveloppe initiale de 120 000 $, hors licences;
- 70 % d’utilisateurs actifs après trois mois.
J’insiste sur un mot : initiale.
Ce détail deviendra important.
La présentation du programme
Quelques jours plus tard, quelqu’un prépare une présentation PowerPoint.
Elle parle plutôt de :
- 350 employés;
- un lancement au 1er novembre;
- 100 000 $;
- 60 % d’adoption;
- 20 ambassadeurs.
Le réflexe serait de considérer qu’un document est faux.
Je préfère ne pas partir de cette hypothèse.
Les deux documents peuvent être parfaitement légitimes.
Ils n’ont peut-être simplement pas le même statut.
L’un peut représenter un cadrage approuvé.
L’autre une proposition.
Ou une option.
Ou une vision préparée pour une discussion.
Et c’est précisément cela que je veux que l’IA comprenne.
Ajoutons maintenant un budget
Un troisième document apparaît.
Cette fois, un fichier Excel.
Il détaille les dépenses :
65 000 $ pour la formation.
35 000 $ pour le support.
12 000 $ pour les communications.
8 000 $ pour les événements.
15 000 $ de réserve.
Total :
135 000 $.
Et toujours sans les licences.
Nous avons donc maintenant trois chiffres qui circulent autour du même projet :
100 000 $.
120 000 $.
135 000 $.
La mauvaise question à poser à Copilot serait :
« Quel est le budget du projet ? »
Parce que nous invitons pratiquement l’IA à choisir une valeur à notre place.
La question intéressante devient :
« Quels montants apparaissent dans les différentes sources, quel est le statut de chacun et quelles informations permettent de déterminer celui qui fait autorité ? »
Ce n’est plus du résumé.
C’est de l’analyse de contexte.
Le rôle du bloc-notes n’est pas de tout absorber
C’est là que les blocs-notes Copilot deviennent intéressants.
Je ne commence surtout pas en ajoutant tout le SharePoint de l’entreprise.
Je commence par une intention.
Dans mon cas :
Préparer une note de décision vérifiable pour le comité de lancement de Project Atlas.
Ensuite seulement, je choisis les références nécessaires.
Pour reproduire le début de l’exercice, créez un bloc-notes appelé par exemple :
Project Atlas – Individual Preparation
Puis ajoutez uniquement :
- la charte;
- la présentation du programme;
- le budget;
- un registre de risques;
- une liste de questions encore ouvertes.
Pas davantage.
Le but n’est pas de construire le plus gros corpus possible.
Le but est de construire le plus petit contexte capable de répondre correctement à la question.
Il faut aussi apprendre au bloc-notes comment travailler
Une autre différence importante entre un simple prompt et un bloc-notes tient aux instructions.
Un prompt dit à l’IA ce que vous voulez maintenant.
Les instructions définissent comment vous souhaitez qu’elle travaille de manière plus constante dans ce contexte.
Pour Atlas, vous pouvez commencer avec quelque chose de très simple :
Utilise uniquement les références disponibles dans ce bloc-notes pour les affirmations concernant Project Atlas.
Distingue les faits confirmés, les décisions, les propositions, les hypothèses et les informations manquantes.
Signale les contradictions au lieu de les résoudre silencieusement.
N’invente aucune valeur manquante.
Indique les références qui soutiennent les affirmations importantes.
Termine les analyses par une section « À valider ».
Je m’arrête volontairement ici sur les instructions.
Celles que j’utilise réellement dans la démonstration sont un peu plus exigeantes.
Il faut bien garder quelques cartes dans ma manche… 😉
Premier exercice : établir l’état du projet
Une erreur fréquente avec l’IA consiste à demander trop rapidement une recommandation.
Je préfère commencer par :
« Que savons-nous réellement ? »
Par exemple :
Établis l’état actuel de Project Atlas à partir des références disponibles. Sépare les éléments confirmés, les hypothèses de travail, les décisions non résolues, les principaux risques et les informations à valider. Pour chaque affirmation importante, indique la source correspondante.
Regardez ensuite ce que fait Copilot avec les contradictions.
Est-ce qu’il transforme automatiquement 135 000 $ en nouveau budget ?
Est-ce qu’il considère le 1er novembre comme la nouvelle date officielle uniquement parce que cette valeur apparaît dans une présentation ?
Est-ce qu’il distingue réellement une proposition d’une décision ?
C’est là que l’exercice commence.
Deuxième exercice : construire une matrice des contradictions
Ensuite, demandez-lui explicitement de ne plus cacher les désaccords entre les sources.
Par exemple :
Identifie les contradictions entre les références de Project Atlas concernant la population cible, la date de lancement, le budget, l’objectif d’adoption et le réseau d’ambassadeurs. Pour chaque contradiction, indique les valeurs, leurs sources, leur statut probable et l’information ou la décision nécessaire pour la résoudre.
Vous devriez rapidement obtenir quelque chose de beaucoup plus utile qu’une synthèse.
Vous commencez à voir le projet comme un ensemble de faits, décisions, propositions et questions ouvertes.
Et surtout, vous commencez à voir ce qui manque.
Le piège du « plus récent »
Une des choses que j’aime particulièrement dans cet exercice concerne la temporalité.
Un fichier récent n’est pas nécessairement plus autoritaire.
Un PowerPoint préparé hier peut contenir une proposition.
Une charte vieille de trois semaines peut toujours constituer le cadrage officiel.
Un fichier Excel peut présenter une prévision beaucoup plus précise sans qu’elle ait encore été approuvée.
Un compte rendu peut mentionner une option sans qu’une décision ait été prise.
Cette distinction est essentielle.
Je résume souvent cela ainsi :
Plus récent ne signifie pas automatiquement plus vrai.
Mais il existe un autre piège encore plus subtil.
Répété trois fois ne signifie toujours pas décidé
Imaginons maintenant qu’un chiffre apparaisse dans plusieurs documents.
Par exemple : 80 participants pour un pilote.
Un plan l’utilise.
Une présentation le reprend.
Un compte rendu en parle.
Il devient extrêmement tentant de conclure :
« Le pilote comptera 80 personnes. »
Pas forcément.
Les trois documents peuvent simplement répéter la même hypothèse.
La répétition donne une impression de certitude.
Elle ne crée pas une décision.
C’est précisément le genre de vérification que j’aime faire en direct avec Copilot :
« Retrouve toutes les sources qui mentionnent cette valeur et détermine si elle constitue une décision, une recommandation ou une hypothèse de travail. »
C’est beaucoup plus intéressant que « résume-moi ce document ».
Puis le projet commence à vivre
Et c’est ici que je vais commencer à devenir volontairement vague.
Parce que dans ma démonstration complète, de nouvelles informations arrivent progressivement.
Des courriels.
Des décisions de réunion.
Des données opérationnelles.
Des contraintes de formation.
Des informations provenant des achats.
Des chiffres qui semblaient certains deviennent des objectifs.
Certaines propositions deviennent des décisions.
D’autres ne le deviennent jamais.
Et certaines présentations très convaincantes s’avèrent beaucoup moins autoritaires qu’elles en avaient l’air.
Je ne vais pas publier toute cette partie ici.
Sinon, le petit plaisir de l’enquête disparaît.
flowchart TD
A[Contexte initial] --> B[Identifier les contradictions]
B --> C[Ajouter de nouvelles preuves]
C --> D[Requalifier l'information]
D --> E[Vérifier les affirmations]
E --> F[Préparer un livrable]
F --> G[Construire un contexte collectif]Ce qui m’intéresse ici, c’est que le bloc-notes ne recommence pas à zéro lorsque le contexte évolue.
Les références changent.
Les instructions restent.
Les questions deviennent plus précises.
Le raisonnement peut évoluer avec le projet.
Le vrai test : vérifier une affirmation
À un moment donné, il faut arrêter de regarder la réponse comme une jolie synthèse.
Choisissez une affirmation importante.
Une date.
Un budget.
Un nombre de participants.
Un nombre d’ambassadeurs.
Puis demandez à Copilot de vous montrer exactement pourquoi il considère cette information comme vraie.
Et allez vérifier la source.
C’est un geste extrêmement simple.
Mais c’est probablement l’un des plus importants.
Un système ancré sur des références peut toujours produire une mauvaise interprétation de ces références.
Le fait qu’une réponse possède une source ne signifie pas automatiquement que la conclusion tirée de cette source est correcte.
La conversation n’est pas le livrable
Autre point essentiel : je ne veux pas finir l’exercice avec une excellente conversation Copilot.
Je veux finir avec quelque chose qu’un humain peut utiliser.
Dans Atlas, le résultat devient une note de décision.
Elle peut contenir :
- un résumé exécutif;
- l’état actuel;
- les informations à valider;
- plusieurs scénarios;
- les risques associés;
- les décisions attendues;
- les références permettant de vérifier les éléments critiques.
Puis cette analyse peut sortir de la conversation et devenir une Copilot Page.
À ce moment-là, nous ne sommes plus simplement en train de discuter avec l’IA.
Nous produisons un objet de travail.
Et ensuite vient la partie que je trouve la plus intéressante
Jusqu’ici, tout se passe dans mon espace professionnel individuel.
Je choisis mes sources.
Je teste.
Je pose de mauvaises questions.
Je challenge les réponses.
Je change d’avis.
Je prépare quelque chose.
C’est normal.
Je n’ai aucune raison de transformer immédiatement cet atelier en espace collectif.
Une fois mon analyse suffisamment solide, je peux créer un second bloc-notes.
Cette fois, pour le comité.
Et je ne copie surtout pas tout.
flowchart LR
A[Bloc-notes individuel] --> B[Analyse]
B --> C[Vérification]
C --> D[Livrable validable]
D --> E[Bloc-notes collectif]
E --> F[Contexte partagé]Le collectif n’a pas forcément besoin de mes explorations.
Il a besoin d’un contexte adapté à son propre travail.
C’est ici que je vois le véritable passage de l’usage individuel de l’IA vers quelque chose qui commence à ressembler à de l’intelligence collective.
Pas parce que plusieurs personnes utilisent le même chatbot.
Mais parce qu’elles peuvent enfin travailler à partir d’un contexte explicite, sélectionné et vérifiable.
Vous pouvez déjà reproduire cette première partie
Pour expérimenter sans disposer de mon corpus complet, vous pouvez créer vos propres cinq documents fictifs.
Une charte avec une première série de chiffres.
Une présentation contenant quelques propositions différentes.
Un budget plus détaillé.
Un registre de risques.
Une liste de décisions encore ouvertes.
Introduisez volontairement quelques contradictions.
Puis observez le comportement du bloc-notes.
Est-ce qu’il écrase les différences ?
Est-ce qu’il comprend leur statut ?
Est-ce qu’il cite correctement les références ?
Est-ce qu’il sait dire « je ne peux pas déterminer cela avec les sources disponibles » ?
Et surtout :
est-ce que vous êtes capable de vérifier sa réponse ?
Si oui, vous êtes déjà beaucoup plus loin que la démonstration classique du PDF résumé en dix secondes.
Je garde volontairement la suite
Dans ma conférence Copilot Notebooks: From Personal AI to Team Intelligence, je déroule la suite du scénario en direct.
Le contexte évolue.
De nouvelles preuves arrivent.
Certaines certitudes tombent.
Le livrable se construit.
Puis nous passons de l’espace individuel au contexte collectif.
Et je garde encore davantage de choses pour ma formation de 3 h 30 chez AFI Expertise, parce qu’à ce moment-là nous pouvons réellement faire l’exercice nous-mêmes, prendre le temps de tester les réponses, provoquer des erreurs, comparer les sources et travailler les questions de gouvernance qui apparaissent lorsque ce type de contexte commence à être utilisé à l’échelle d’une entreprise.
Il faut bien qu’il reste une différence entre lire un article, regarder une conférence et vraiment mettre les mains dedans.
Le plus intéressant n’est finalement pas Copilot
Project Atlas est fictif.
Les problèmes qu’il représente ne le sont absolument pas.
Dans toutes les entreprises, nous avons des documents qui vieillissent.
Des propositions prises pour des décisions.
Des chiffres réutilisés sans leur contexte.
Des présentations plus convaincantes que les données qu’elles résument.
Des informations réparties entre SharePoint, Teams, Outlook et les personnes qui participent au projet.
L’IA ne supprime pas ce problème.
Elle peut même l’amplifier si nous lui demandons trop rapidement de produire une réponse unique à partir d’un contexte qui, lui, ne l’est pas.
C’est pour cela que je trouve les blocs-notes Copilot intéressants.
Ils nous obligent à revenir à une question beaucoup plus fondamentale :
Quel contexte sommes-nous réellement en train de construire pour permettre à l’IA, puis aux humains, de travailler correctement ?
Et c’est probablement là que commence le vrai sujet.
Pas la génération de texte.
La structuration de la connaissance.
Et, peut-être, un peu d’intelligence collective.
