J'ai conçu des agents Rovo pour Confluence

Comment j'ai transformé une stratégie documentaire en conception d'agents

J'ai récemment eu l'occasion de passer de la réflexion sur l'IA appliquée à la documentation à la conception concrète d'agents documentaires.

Le contexte était une vaste base de connaissances Confluence couvrant de la documentation technique et produit autour du Marketing Mix Modeling (MMM). Ses utilisateurs comprenaient des Data Scientists, des Data Engineers et des consultants travaillant sur les domaines Data, Modeling, Insights et Simulations.

Comme cela m'arrive souvent dans mes missions freelance, j'arrivais dans un domaine que je ne connaissais pas encore. Avant de penser à l'IA, j'ai d'abord dû comprendre le domaine métier, l'écosystème documentaire, ses auteurs et ses utilisateurs.

Cela fait partie du métier.

Quand on travaille sur une documentation construite au fil du temps dans des plateformes collaboratives comme Confluence, Notion ou SharePoint, on retrouve souvent des couches successives de contenus produits par différentes équipes et différents auteurs. D'anciennes pages restent accessibles. Des sujets proches sont documentés à plusieurs endroits. La terminologie évolue. Ce qui paraît évident pour une équipe ne l'est pas forcément pour une autre.

Et parce que les auteurs connaissent déjà le produit et son contexte, ils peuvent inconsciemment compenser les lacunes de la documentation. Un lecteur qui ne partage pas ce contexte ne le peut pas.

Dans cette mission, cela créait une double problématique.

• La première audience était interne : les auteurs de la base de connaissances et les consultants qui l'utilisaient déjà.
• La seconde était externe : des consultants travaillant chez les clients, qui devaient comprendre et utiliser ces connaissances sans nécessairement bénéficier du même contexte ni des mêmes formations.

La documentation contenait une grande quantité d'expertise, mais une partie de cette expertise restait difficile à exploiter en dehors des équipes qui l'avaient produite.

Les agents étaient directement liés aux problèmes et aux recommandations précédemment identifiés dans l'audit.

Quatre services documentaires ont émergé de ce travail :

• un Documentation Intelligence Assistant, pour rechercher, comparer et synthétiser des informations techniques ;
• un Documentation Duplicate Finder, pour identifier les recouvrements, doublons et incohérences ;
• un Glossary Intelligence Agent, pour clarifier la terminologie, les acronymes et leurs variantes ;
• un User Adoption & Support Assistant, pour l'onboarding, les procédures et les questions de support.

J'ai également conçu un orchestrateur, destiné à fournir un point d'entrée unique et à orienter les demandes vers l'agent spécialisé approprié.

Je n'ai pas commencé par un agent

L'une des conclusions les plus fortes que je tire de cette expérience est simple :

Le besoin doit précéder l'agent.

Chacun des quatre agents répondait à un problème que j'avais déjà identifié dans la documentation.

• Trouver et combiner des informations était difficile ? → Cela suggérait un service de recherche et de synthèse.

• Les contenus dupliqués ou qui se recoupaient compliquaient la maintenance ? → Cela suggérait un service d'analyse.

• La terminologie variait selon les équipes et les pages ? → Cela suggérait un service de glossaire.

Le support constituait un autre problème.
Certaines pages de FAQ étaient trop pauvres ou mal rédigées pour répondre aux vraies questions des utilisateurs, tandis que l'équipe support continuait à recevoir de nombreux tickets sans que ces problèmes récurrents ne soient systématiquement réinjectés dans la documentation. Cela suggérait un service de support — mais aussi une manière de mettre en évidence les lacunes que la documentation elle-même devait corriger.

Un problème, un service spécialisé.

Plutôt que de traiter la création d'agents comme une nouvelle tendance IA à suivre, ou d'essayer de construire un assistant impressionnant capable de tout faire, je définissais d'abord des services documentaires, puis je choisissais la technologie.

La technologie suivait la stratégie documentaire — et non l'inverse.

Le prompt design est aussi du design documentaire

C'est là que mon expertise documentaire a le plus compté.

Rovo Studio m'a fourni l'environnement permettant de configurer les agents. Copilot, disponible dans l'environnement Microsoft 365 du client, est devenu mon partenaire de conception.

Remarque

Je l'ai utilisé comme j'utilise l'IA dans d'autres aspects de mon travail : pour me challenger, clarifier les instructions, formaliser les rôles et les périmètres, affiner les résultats attendus et les prompts de test, et imaginer des cas limites permettant de préciser le scope et le hors-scope ou de révéler des faiblesses dans le comportement d'un agent.

Le résultat a été une collaboration à trois entre expertise documentaire, Rovo Studio et Copilot.

Mais c'est l'expertise documentaire qui a permis de rendre les agents réellement spécifiques.

Un agent générique peut être configuré rapidement. Un agent sur mesure réellement utile doit être adapté à la base de connaissances qu'il va parcourir : son contenu, sa structure, sa terminologie, ses utilisateurs, ses faiblesses et ses règles de gouvernance.

C'est là que les problèmes documentaires et les bonnes pratiques se sont transformés en directives de prompt.

Des règles faibles, implicites ou absentes de la documentation ont pu être rendues explicites dans le prompt. Celui-ci leur a donné une forme concrète et les a transformées en comportements attendus de l'agent.

En ce sens, les questions de gouvernance documentaire sont aussi des questions de conception d'agents.

Ce qui a bien fonctionné

Une fois que je savais précisément ce que je voulais que chaque agent fasse, j'ai trouvé Rovo Studio relativement simple à utiliser.

➕ L'intégration native avec Confluence représentait évidemment un avantage majeur.
Je travaillais directement avec l'environnement de connaissances que les agents devaient parcourir, sans avoir à résoudre au préalable un problème d'accès séparé.

J'ai également été agréablement surprise par la capacité des agents à suivre des prompts détaillés.

Ils étaient capables de produire des réponses structurées, de combiner des informations issues de plusieurs pages et de travailler avec le contexte technique que j'avais défini pour eux.

La boucle d'expérimentation était elle aussi particulièrement agréable.

Écrire le prompt. Le tester. Identifier un point faible. Affiner une règle. Essayer une autre question. Découvrir que la réponse révèle quelque chose sur la documentation elle-même. Revenir au prompt.

Je n'avais pas l'impression de simplement « configurer une IA ».

Je spécifiais progressivement un service documentaire. Et c'est probablement la partie que j'ai préférée.

Quelques écueils pratiques

Bien sûr, de bonnes spécifications ne suppriment pas toutes les contraintes pratiques.

La principale concernait l'orchestrateur.

Je l'avais conçu comme un point d'entrée unique capable d'orienter les demandes vers les quatre agents spécialisés et de restituer une réponse consolidée.

➖ Mais Rovo Studio ne propose pas réellement d'« orchestrateur » en tant que tel. L'idée était de construire un agent de niveau supérieur capable d'appeler les quatre agents spécialisés en tant que Tools, mais mon environnement ne me donnait pas les permissions nécessaires pour configurer ce fonctionnement.

➖ J'ai rencontré une limitation similaire avec les Insights. La fonctionnalité pouvait fournir des métriques d'usage, mais mes droits Confluence et la durée de la mission ne m'ont pas permis d'observer les agents suffisamment longtemps pour tirer des conclusions significatives sur leur adoption.

Il y avait aussi un problème très concret de timing : certains collègues ont réellement commencé à utiliser les agents après la fin de ma mission.

C'est l'une des limites d'une mission freelance courte. On peut concevoir, configurer et tester un service, mais partir avant que ses véritables usages n'apparaissent.

Aucun de ces points ne constituait un échec des agents eux-mêmes.

Ils m'ont surtout rappelé que la conception d'un agent dépend aussi de l'environnement dans lequel il va évoluer : permissions, intégrations, droits d'accès, conditions de déploiement et temps disponible pour observer son usage.

J'ai expérimenté un score de confiance

L'une des fonctionnalités que j'ai ajoutées à titre expérimental dans certaines réponses était un score de confiance.

L'intention était simple.

Lorsqu'un agent combine plusieurs sources, rencontre une documentation incomplète ou doit choisir entre des informations de qualité différente, je voulais donner à l'utilisateur une indication du degré de prudence avec lequel lire la réponse.

J'aimais également l'idée qu'un tel signal puisse indirectement mettre en évidence certaines zones faibles de la documentation.

Si un agent produit régulièrement des réponses à faible niveau de confiance sur un même sujet, le problème ne vient peut-être pas uniquement de l'agent. La documentation sous-jacente a peut-être besoin d'être clarifiée, consolidée ou de disposer d'une source de vérité plus clairement identifiée.

Mais il y a une réserve importante.

Il s'agissait d'une expérimentation, et non d'une mesure scientifique.

Le score ne représentait pas une probabilité objective que la réponse soit correcte.

C'était un signal.

Et les signaux numériques sont dangereux, car ils peuvent facilement paraître plus précis que ne l'est réellement la méthode qui les produit.

J'aimerais certainement poursuivre cette piste, mais en rendant cette limite très explicite.

Est-ce que je recommencerais ?

Oui.

J'ai vraiment aimé concevoir ces agents.

Ce qui m'a le plus intéressée n'était pas la nouveauté de Rovo Studio.

C'était la possibilité de prendre tout ce que j'utilise déjà dans mon travail documentaire — architecture, terminologie, gouvernance, analyse des audiences, qualité des sources, recherche d'information — et de le traduire en comportements d'agents.

J'aimerais en concevoir d'autres, pour d'autres bases de connaissances et dans d'autres environnements.

Et j'ai également envie d'étendre ce travail au-delà des plateformes collaboratives comme Confluence.

Les sites Web de documentation constituent pour moi un prochain terrain d'expérimentation évident. 😊

Je travaille déjà avec des sites docs-as-code, du contenu structuré, des métadonnées et de la documentation AI-ready. Concevoir des agents capables d'interagir avec ces systèmes documentaires me semble être une prolongation naturelle de ce travail.

Les outils changeront.

Les plateformes changeront.

Mais le travail de fond reste étonnamment familier : comprendre la connaissance, la structurer, la qualifier et concevoir la meilleure manière possible de la rendre accessible aux utilisateurs — humains ou machines.**

---

P.S. Merci, E., pour cette opportunité !