Premier bundle OKF : choisir un périmètre réduit avec un ROI visible

Pourquoi ne pas commencer par toute l'entreprise ?

La tentation naturelle est de lancer un grand chantier: exporter tout Notion, tout Drive, tous les tickets, tous les dashboards et toute la documentation produit. Sur le papier, cela ressemble à une stratégie ambitieuse. Dans la pratique, cela produit souvent un corpus énorme, bruyant et difficile à maintenir.

Un bundle OKF devient utile quand il reste relié à une tâche. Si le périmètre est trop large, personne ne sait quels concepts sont prioritaires, quelles sources sont fiables, quelles citations manquent ou comment tester la qualité du résultat.

La bonne V1 doit donc être volontairement petite. Elle doit isoler une douleur visible, sélectionner les sources utiles, produire quelques concepts solides, puis montrer que l'agent répond mieux qu'avant.

Le bon critère : une boucle métier avec douleur visible

Un bon premier bundle commence par une douleur que l'équipe reconnaît déjà: une règle support souvent mal appliquée, une métrique revenue que personne n'explique pareil, une relance commerciale trop générique, une procédure ops qui dépend d'un expert senior ou une FAQ produit qui devient incohérente.

Cette douleur doit être assez concrète pour être testée. On doit pouvoir demander à un agent: réponds à ces tickets, explique cette métrique, prépare cette relance, compare ces décisions, cite tes sources. Si le test est impossible à formuler, le périmètre est probablement trop flou.

Le ROI n'a pas besoin d'être financier dès la V1. Il peut être opérationnel: moins d'ambiguïtés, plus de citations correctes, réponses plus cohérentes, meilleure traçabilité, ou capacité à dire clairement quand l'information manque.

Les 5 bons candidats pour un premier bundle

Certains périmètres se prêtent mieux que d'autres à une première V1. Ils combinent une douleur claire, des sources existantes et un test agent simple.

Le support est souvent un bon candidat parce que les tickets révèlent immédiatement les ambiguïtés. La data est aussi un bon point d'entrée quand les métriques sont discutées en réunion mais mal documentées. Le sales fonctionne bien quand les offres, personas, objections et preuves sont dispersés. Les opérations sont intéressantes quand les runbooks vivent dans la tête de quelques personnes. Le contenu/SEO devient pertinent quand les briefs, preuves et entités doivent être réutilisés par des agents de production.

Ce qu'un premier bundle doit contenir

Un premier bundle utile contient peu de choses, mais des choses bien choisies. Il doit avoir une carte d'entrée, quelques concepts, des sources citées, des liens internes et un minimum d'historique.

La cible réaliste est souvent 5 à 10 concepts. En dessous, le bundle risque de manquer de contexte. Au-dessus, la V1 peut devenir trop longue à relire et trop difficile à tester. L'objectif n'est pas d'être complet, mais d'être suffisamment fiable pour une tâche précise.

Chaque concept doit pouvoir répondre à une question: quelle est la règle ? quelle est la formule ? quelle source fait foi ? quelle action déclencher ? quelle limite respecter ? quelle décision a changé le contexte ?

Ce qu'il ne doit pas encore contenir

Un premier bundle ne doit pas contenir tout ce qui existe. Il ne doit pas devenir un dump de documentation, un export automatique non relu, une copie complète d'un workspace Notion ou un graphe impossible à maintenir.

Il ne doit pas non plus chercher à résoudre toute la gouvernance de l'entreprise. Les sujets d'ownership, de validation, de fraîcheur et de droits d'accès sont importants, mais la V1 doit rester concentrée sur un cas d'usage vérifiable.

La meilleure règle est simple: si un fichier ne sert pas le test agent prévu, il peut attendre la V2.

Méthode en 90 minutes : cadrer le périmètre

En 90 minutes, l'objectif n'est pas d'écrire le bundle. L'objectif est de choisir le bon combat. Réunissez les personnes qui connaissent la boucle métier: support lead, sales, analyste, product manager, ops ou expert métier.

Posez quatre questions: quelle tâche l'agent doit-il mieux réussir ? où échoue-t-il aujourd'hui ? quelles sources font foi ? comment saura-t-on que la V1 aide vraiment ? Les réponses deviennent le brief du bundle.

À la fin de cette session, vous devez avoir un périmètre nommé, un propriétaire, une liste courte de sources, 5 à 10 concepts candidats et un test agent simple.

Méthode en 1 journée : produire la V1

La journée de production consiste à créer l'ossature: dossier racine, `index.md`, éventuellement `log.md`, puis les premiers concept files. Il faut privilégier la clarté à l'exhaustivité.

Chaque concept doit avoir un `type`, un titre, une description courte, un body Markdown structuré, quelques liens utiles et les citations nécessaires. Si une source manque, mieux vaut l'indiquer explicitement que laisser l'agent combler le trou.

La V1 doit rester relisible par un humain en moins de 30 minutes. Si personne ne peut la relire rapidement, elle est déjà trop grosse pour un premier bundle.

Méthode en 1 semaine : tester et améliorer

La semaine de test sert à confronter le bundle à des cas réels. Utilisez quelques exemples représentatifs: tickets support, questions data, scénarios de relance, incidents ou briefs contenu.

Demandez à l'agent de répondre avec sources, limites et raisonnement observable. Notez les erreurs: mauvaise source, concept manquant, lien ambigu, définition trop vague, citation absente, règle obsolète.

Chaque erreur devient une amélioration concrète. C'est là que le bundle gagne de la valeur: non pas parce qu'il grossit, mais parce qu'il corrige les points où l'agent échouait vraiment.

Exemple concret : premier bundle support remboursement

Un premier bundle support peut partir d'un problème simple: les agents humains et IA répondent différemment aux demandes de remboursement. Les sources existent, mais elles sont dispersées entre le help center, des tickets anciens, une note produit et l'API de création de ticket.

La V1 contient `index.md`, `log.md`, `policies/refund-policy.md`, `playbooks/refund-request.md`, `faqs/refund-exceptions.md`, `apis/create-ticket.md`, `sources/help-center-refunds.md` et `decisions/refund-window-2026.md`.

Le test agent est très concret: répondre à trois tickets de remboursement, citer la règle appliquée, indiquer les cas qui nécessitent une validation humaine et proposer l'action suivante.

Exemple concret : premier bundle métrique revenue

Un premier bundle data peut partir d'une métrique que tout le monde utilise mais que personne ne définit exactement pareil. Par exemple le MRR: inclut-on les coupons ? exclut-on les setup fees ? quelle table fait foi ? quel dashboard est officiel ?

La V1 peut contenir `metrics/monthly_recurring_revenue.md`, `tables/orders.md`, `dashboards/revenue-dashboard.md`, `decisions/pricing-v2.md`, `sources/finance-definition.md` et `owners/revenue-analytics.md`.

Le test agent consiste à expliquer la formule, citer la source, lister les exclusions, pointer vers la table source et signaler les zones encore ambiguës. Si l'agent répond mieux qu'avant une réunion revenue, le bundle a déjà un ROI.

Préparer la suite : vers un outil de création de bundles

Cette page prépare naturellement une logique productisable: aider une entreprise à importer des sources, proposer une taxonomie, générer des premiers concepts, réécrire les fichiers, ajouter des citations et produire une V1 relisible.

Mais un outil ne doit pas remplacer la décision métier. Il peut accélérer la production, détecter des trous, proposer une structure et aider à reformuler. Il ne peut pas décider seul quelle source fait foi, quel périmètre mérite d'être traité ou quelle règle doit être validée par l'entreprise.

La bonne direction produit serait donc un assistant de création et de réécriture de bundles: il aide à passer du chaos documentaire à une V1 OKF testable, tout en gardant une validation humaine sur les sources, les décisions et les critères de succès.

V1 prête à tester

Avant de considérer votre premier bundle comme prêt, vérifiez qu'il peut être donné à un agent sans conversation supplémentaire. Il ne doit pas tout savoir, mais il doit savoir assez pour réussir le test prévu.

Erreurs fréquentes à éviter

La première erreur consiste à choisir un périmètre politiquement important mais opérationnellement flou. Un bon premier bundle doit être utile sur une tâche précise, pas seulement stratégique sur une slide.

La deuxième erreur consiste à confondre quantité et qualité. Dix concepts relus, sourcés et testés valent mieux que cent fichiers exportés automatiquement.

La troisième erreur consiste à oublier le test agent. Sans test, vous ne savez pas si le bundle améliore réellement le contexte ou s'il ajoute seulement une couche documentaire.

La quatrième erreur consiste à déléguer trop vite la vérité métier à l'IA. Un agent peut aider à produire et réécrire, mais les sources de vérité, les décisions et les limites doivent rester validées par des humains responsables.

Lire ensuite

Une fois le premier périmètre choisi, les chapitres suivants aident à adapter la méthode selon les personas et les cas d'usage: fondateur, PME, data, marketing, support, sales ou ops.

Sources officielles et lectures utiles