Workflow OKF : passer d'un contexte dispersé à un bundle testable

Pourquoi un workflow compte plus qu'un export massif

Un export massif donne souvent l'impression d'avancer vite, mais il produit rarement un contexte exploitable. On obtient beaucoup de Markdown, beaucoup de bruit, peu de structure et très peu de garanties sur la fraîcheur ou la source des informations.

Un workflow OKF part de l'autre côté: il commence par une tâche concrète que l'agent doit réussir. Par exemple répondre à une objection support, expliquer une métrique revenue, préparer une relance commerciale ou diagnostiquer un incident. Le bundle est ensuite construit autour de cette boucle de travail, pas autour de toute l'entreprise.

Cette approche réduit le risque de créer une bibliothèque morte. Chaque concept existe parce qu'il aide un humain ou un agent à mieux décider, mieux répondre, mieux retrouver une source ou mieux agir.

Étape 1 : choisir une boucle métier testable

La première décision n'est pas technique. Il faut choisir une boucle où le manque de contexte coûte déjà quelque chose: réponses support incohérentes, métriques mal expliquées, relances sales trop génériques, onboarding produit lent, diagnostics ops dépendants d'un expert senior.

Une bonne boucle tient dans une phrase: aider un agent support à répondre aux demandes de remboursement, aider un analyste à expliquer le MRR, aider un sales à préparer une relance enterprise. Si vous n'arrivez pas à nommer la tâche, le bundle sera trop vague.

Le bon périmètre V1 doit être assez petit pour être produit en quelques jours, mais assez important pour montrer une amélioration visible: meilleure citation, moins d'allers-retours, moins d'erreurs, réponse plus rapide ou décision plus traçable.

Étape 2 : auditer les sources existantes

L'audit consiste à lister les endroits où la connaissance existe déjà: Notion, Drive, Slack, tickets support, CRM, dashboards, code, data catalog, API docs, emails de décision, expert métier. L'objectif n'est pas de tout importer, mais d'identifier les sources de vérité et les zones de flou.

Pour chaque source, notez trois informations: ce qu'elle contient, qui en est propriétaire, et à quel point elle est fiable. Une page Notion peut être utile mais obsolète. Un dashboard peut être fiable mais incompréhensible sans la formule. Un ticket peut contenir une exception métier importante mais non généralisable.

Cet audit sert aussi à révéler les trous de contexte. Si personne ne sait citer la source d'une règle, ce n'est pas un problème OKF: c'est un problème de gouvernance que le workflow rend visible.

Étape 3 : définir une taxonomie légère

La taxonomie doit rester légère. Il ne s'agit pas de construire une ontologie complète, mais de choisir quelques familles de concepts qui aident l'équipe à ranger et retrouver l'information.

Pour un bundle support, les types utiles peuvent être `Playbook`, `FAQ`, `Policy`, `Product Area`, `API Endpoint` et `Source`. Pour un bundle data, on trouvera plutôt `Metric`, `Table`, `Dashboard`, `Decision` et `Owner`. Pour un bundle sales, on peut démarrer avec `Persona`, `Offer`, `Objection`, `Proof`, `Template` et `Playbook`.

La règle pratique: si deux personnes ne rangeraient pas le même fichier au même endroit, la taxonomie est encore trop ambiguë. Si elle nécessite un atelier de trois semaines, elle est trop lourde pour une V1.

Étape 4 : créer les premiers concept files

Un premier bundle utile contient souvent 5 à 10 concept files, pas 300. Chaque fichier doit décrire une connaissance claire: une métrique, une table, une procédure, une décision, une source, une objection, une persona ou un endpoint.

Le frontmatter YAML donne les métadonnées minimales, notamment le champ `type`. Le body Markdown donne l'explication humaine: définition, contexte, exemples, règles, limites, liens et citations. Le fichier doit pouvoir être relu par une personne métier sans outil spécial.

Un exemple support: `playbooks/refund-request.md` décrit comment traiter une demande de remboursement; `policies/refund-policy.md` explique la règle officielle; `apis/create-ticket.md` documente l'action à déclencher; `sources/help-center-refunds.md` cite la source publiée.

Étape 5 : relier, citer et documenter les preuves

Les liens transforment une liste de fichiers en carte de connaissance. Un playbook peut pointer vers une policy, une API, une FAQ et une décision. Une métrique peut pointer vers une table, un dashboard et une décision de définition.

Les citations rendent le bundle vérifiable. Elles ne sont pas là pour faire joli: elles permettent à un humain ou à un agent de comprendre d'où vient une affirmation importante. C'est essentiel pour les métriques, les règles métier, les obligations légales, les procédures clients ou les décisions de pricing.

La phrase autour du lien compte autant que le lien lui-même. Écrire `Cette procédure applique la [politique de remboursement](/policies/refund-policy.md)` est plus utile que poser un lien isolé sans relation explicite.

Étape 6 : construire index.md et log.md

`index.md` sert de carte d'entrée. Il ne doit pas tout répéter, mais guider la lecture: quels concepts sont prioritaires, dans quel ordre les consulter, quelles zones du bundle sont stables ou expérimentales.

`log.md` sert à garder l'historique des changements importants: ajout d'une règle, correction d'une métrique, remplacement d'une source, changement de propriétaire, décision de supprimer un concept. Ce fichier évite le contexte fantôme, c'est-à-dire les connaissances qui changent sans laisser de trace.

Dans une V1, ces deux fichiers peuvent être très simples. L'essentiel est qu'un humain ou un agent puisse comprendre rapidement ce que contient le bundle, pourquoi il existe et ce qui a changé récemment.

Étape 7 : tester avec un agent réel

Un bundle OKF doit être testé dans une tâche réelle, pas seulement relu comme une documentation. Demandez à l'agent de retrouver une règle, expliquer une métrique, préparer une réponse, citer ses sources ou comparer deux décisions.

Le test doit chercher les failles: l'agent cite-t-il la bonne source ? comprend-il les exclusions ? confond-il une ancienne règle avec une règle récente ? sait-il dire quand l'information manque ? utilise-t-il les liens pour naviguer au lieu de répondre uniquement depuis un passage isolé ?

Le résultat du test devient une liste de corrections: clarifier une définition, ajouter une citation, créer un concept manquant, renommer un fichier, simplifier un index ou documenter une exception.

Étape 8 : itérer sans vouloir tout cartographier

La tentation naturelle est de transformer le workflow en grand programme de cartographie de l'entreprise. C'est rarement le bon point de départ. OKF fonctionne mieux quand le bundle grandit à partir des usages qui prouvent sa valeur.

Après un premier test, ajoutez seulement ce qui réduit une friction observée. Si l'agent manque une source, ajoutez-la. S'il mélange deux concepts, séparez-les. S'il ne trouve pas le bon chemin, améliorez l'index. S'il cite mal, rendez la citation plus explicite.

Cette logique permet de construire une base de contexte durable sans immobiliser l'équipe dans un chantier documentaire infini.

Exemple concret : workflow support client

Prenons une équipe support qui reçoit beaucoup de demandes de remboursement. Aujourd'hui, les règles sont dispersées entre une page help center, des tickets anciens, une note Notion, une décision produit et une API interne de création de ticket.

La V1 peut créer un bundle réduit: `index.md`, `log.md`, `playbooks/refund-request.md`, `policies/refund-policy.md`, `apis/create-ticket.md`, `faqs/refund-exceptions.md`, `sources/help-center-refunds.md` et `decisions/refund-window-2026.md`.

Le test agent est concret: répondre à trois tickets représentatifs, citer la règle utilisée, signaler les cas ambigus, proposer l'action suivante et indiquer quand une validation humaine reste nécessaire. Si l'agent réussit mieux qu'avant, le bundle a déjà de la valeur.

Checklist de production d'un premier bundle

Avant de considérer une V1 comme exploitable, vérifiez qu'elle tient debout sans explication orale. Le bundle n'a pas besoin d'être parfait, mais il doit être relisible, testable et suffisamment sourcé.

Erreurs fréquentes à éviter

La première erreur consiste à commencer par l'entreprise entière. C'est séduisant, mais trop vaste. Commencez par une boucle où le contexte manquant crée déjà des erreurs ou des lenteurs.

La deuxième erreur consiste à importer sans curer. OKF n'est pas une benne Markdown. Un concept doit être choisi, nommé, relié, sourcé et utile à une tâche.

La troisième erreur consiste à oublier le test agent. Si aucun agent ne consomme le bundle, vous ne savez pas encore si le contexte est vraiment exploitable.

La quatrième erreur consiste à faire du bundle un artefact figé. Le `log.md`, les owners et les revues régulières sont là pour que la connaissance reste vivante.

Lire ensuite

Le workflow donne la méthode générale. Le chapitre suivant montre comment choisir un tout premier périmètre sans vouloir cartographier toute l'entreprise.

Sources officielles et lectures utiles