Pendant longtemps, j'ai regardé le livrable comme le résultat principal du travail.
Un document est terminé. Une présentation est envoyée. Une spec est partagée. Un article est publié. Un cahier des charges est retourné au client.
On a produit quelque chose.
Donc le travail semble fini.
Mais plus j'utilise l'IA avec des contextes, plus cette évidence me paraît incomplète.
Le livrable est visible.
Il est nécessaire.
Mais il n'est pas toujours le vrai capital.
Le document final consomme une pensée
Un livrable est fait pour un usage.
Il répond à un public, à un moment, à une contrainte de forme. Une spec parle aux développeurs. Un pitch parle à un CPO. Une documentation support parle à une équipe qui doit répondre vite. Un article parle à des lecteurs qui ne connaissent pas encore le sujet. Un cahier des charges parle à un client avec ses propres cases, sa numérotation, son vocabulaire.
Chaque livrable sélectionne, simplifie, reformule et ordonne la matière pour un besoin précis.
C'est normal. C'est même son rôle.
Mais cette mise en forme a un coût : une partie de la pensée qui a permis de produire le livrable disparaît derrière lui.
On voit le document final.
On ne voit plus toujours les sources, les hésitations, les alternatives écartées, les exemples non retenus, les décisions intermédiaires, les contradictions, les nuances que l'on a gardées en tête mais pas dans la version envoyée.
Le livrable porte le résultat.
Il ne porte pas forcément le raisonnement.
Le problème commence au deuxième livrable
Ce problème reste discret tant qu'il n'y a qu'une sortie à produire.
On travaille une matière. On rédige un document. On l'envoie. Fin.
Mais dans la vraie vie, le même fond doit souvent servir plusieurs fois.
À partir de la même matière, il faudra peut-être produire :
- une spec fonctionnelle ;
- des user stories ;
- un pitch pour la direction ;
- une note pour les sales ;
- une documentation support ;
- un plan de test ;
- une réponse à un cahier des charges ;
- un article ;
- une synthèse courte pour une réunion.
Dans un workflow classique, chaque nouveau format donne l'impression de recommencer.
On repart du document précédent. On copie-colle. On reformule. On enlève ce qui ne parle pas au nouveau public. On ajoute ce qui manque. On oublie parfois une nuance. Deux versions commencent à diverger.
Ce n'est pas seulement pénible.
C'est dangereux.
Le support peut recevoir une explication différente de celle donnée aux sales. La spec peut contenir une hypothèse qui n'est plus dans le pitch. Le cahier des charges peut réutiliser une ancienne formulation qui n'est plus vraie. L'article peut simplifier une distinction importante parce que la matière disponible est déjà trop orientée.
Le problème n'est pas de produire plusieurs documents.
Le problème est de prendre un livrable comme source principale du livrable suivant.
Une sortie n'est pas une source de vérité
Un document final est une sortie.
Il peut être très bon.
Mais il a été écrit pour un contexte d'usage précis.
Il contient donc des choix qui n'appartiennent pas toujours à la connaissance elle-même : le ton, le niveau de détail, les exemples, l'ordre, le degré de prudence, la manière de nommer les choses, ce que l'on révèle ou non, ce que l'on suppose déjà connu.
Si l'on repart de ce document pour tout produire ensuite, on hérite de ses choix.
Parfois, c'est utile.
Souvent, cela enferme.
Une phrase écrite pour rassurer un client n'est pas forcément une bonne base pour une documentation interne. Une slide de direction n'est pas une bonne base pour une user story. Une réponse courte dans un tableau n'est pas une bonne base pour comprendre la décision produit.
Le livrable est orienté.
La connaissance de travail devrait rester plus neutre.
Le monde des idées
C'est pour cela que je trouve utile d'ajouter une couche intermédiaire entre les sources et les livrables.
J'appelle cela le monde des idées.
Ce n'est pas un nom très technique.
Mais il dit bien ce qu'il doit faire.
Le monde des idées rassemble ce qui a été compris avant de le transformer pour un public particulier.
On peut y trouver :
- des notes atomiques ;
- des notes thématiques ;
- des définitions ;
- des hypothèses ;
- des contradictions ;
- des décisions ;
- des exemples ;
- des limites ;
- des relations entre idées ;
- des points à vérifier.
Cette matière ne parle pas encore à un client, à un développeur ou à un lecteur.
Elle parle au travail lui-même.
Son rôle n'est pas d'être élégante.
Son rôle est d'être réutilisable.
Une note ne doit pas devenir une accroche
C'est un point plus subtil qu'il n'y paraît.
Quand on écrit un article, on a envie de transformer directement une idée en phrase.
Quand on prépare une présentation, on a envie de transformer directement une idée en bullet de slide.
Quand on rédige une spec, on a envie de transformer directement une idée en exigence.
Le problème, c'est que la note devient alors déjà un fragment du livrable.
Elle perd sa neutralité.
Une bonne note doit garder la connaissance à un niveau où elle pourra être réexprimée autrement.
Elle peut contenir une distinction, une preuve, une hypothèse, un arbitrage, une nuance. Mais elle ne doit pas être prisonnière de l'article, de la slide ou de la spec du moment.
Le build, lui, sert à produire.
La note sert à conserver ce qui pourra produire.
La différence paraît légère.
Elle change tout quand on revient trois semaines plus tard.
L'IA rend cette séparation beaucoup plus utile
Avant l'IA, maintenir cette couche intermédiaire pouvait sembler lourd.
On pouvait déjà prendre des notes propres, garder des sources, créer des synthèses. Mais produire ensuite plusieurs livrables restait un travail manuel important.
Avec l'IA, cette séparation devient beaucoup plus rentable.
Si la matière est bien organisée, l'IA peut aider à la recomposer.
Elle peut produire une version longue, une version courte, une version commerciale, une version technique, une version prudente, une version pédagogique.
Elle peut adapter la même connaissance à plusieurs publics.
Mais pour le faire correctement, elle doit partir de la bonne couche.
Pas seulement du dernier document envoyé.
Pas seulement d'un chat.
Pas seulement d'un PDF final.
Elle doit pouvoir revenir aux sources, aux notes, aux décisions, aux limites, aux éléments encore incertains.
Alors le travail change de nature.
On ne produit plus seulement un document.
On construit une matière qui peut produire.
Le capital, c'est ce qui reste après la sortie
Une bonne question à se poser après chaque livrable est simple :
qu'est-ce qui reste ?
Pas seulement : où est le fichier ?
Mais :
- quelles idées ont été stabilisées ?
- quelles sources soutiennent ces idées ?
- quelles décisions ont été prises ?
- quelles alternatives ont été écartées ?
- quelles formulations ont été validées ?
- quels points restent fragiles ?
- quels éléments pourront servir à un autre public ?
Si la réponse est « rien, sauf le document final », alors une grande partie du travail a été consommée.
Le livrable a été produit.
Mais le capital n'a pas été construit.
À l'inverse, si le travail laisse derrière lui des notes, des sources reliées, des décisions, des questions ouvertes, des formulations testées, des niveaux de confiance, alors le prochain livrable ne repartira pas de zéro.
Le résultat visible est le document.
Le capital est la capacité à refaire, adapter, expliquer, défendre et prolonger.
Cela change la manière de travailler
Cette idée peut sembler abstraite.
Elle devient très concrète dans une semaine de travail.
Un entretien utilisateur ne sert pas seulement à écrire un compte rendu. Il peut nourrir une note produit, une décision, une hypothèse, un exemple pour une future présentation.
Un cahier des charges ne sert pas seulement à répondre à un prospect. Il peut enrichir une mémoire de questions récurrentes, de réponses validées, de preuves et de limites de divulgation.
Un article ne sert pas seulement à publier une pensée. Il peut stabiliser des idées qui nourriront plus tard un livre, une formation, une méthode, une discussion produit.
Une spec ne sert pas seulement à développer une fonctionnalité. Elle peut garder la trace d'arbitrages qui permettront de comprendre, six mois plus tard, pourquoi le produit fonctionne ainsi.
Dans tous ces cas, le livrable n'est pas inutile.
Il reste indispensable.
Mais il devient une sortie parmi d'autres.
Il n'épuise plus la valeur du travail.
Le bon document au bon endroit
Je ne crois pas qu'il faille mépriser les livrables.
Au contraire.
Un bon livrable est souvent ce qui rend le travail transmissible. Il oblige à clarifier, à choisir, à couper, à formuler. Il met la pensée au contact d'un public réel.
Mais il faut arrêter de lui demander de tout porter.
Le document final n'a pas à contenir toutes les sources.
Il n'a pas à conserver toutes les alternatives.
Il n'a pas à exposer toutes les incertitudes.
Il n'a pas à devenir la mémoire complète du sujet.
Il doit faire son travail de livrable.
Et la mémoire du travail doit exister ailleurs.
C'est précisément ce que permet un contexte.
Le contexte conserve la matière.
Le build produit les sorties.
L'humain garde le jugement.
L'IA aide à recomposer.
Le déplacement de valeur
Le déplacement me paraît important.
Avant, on capitalisait surtout les documents.
On gardait les specs, les présentations, les notes de réunion, les comptes rendus, les cahiers des charges envoyés.
Demain, il faudra davantage capitaliser la matière qui permet de les produire.
Ce n'est pas la même chose.
Capitaliser un livrable, c'est conserver une forme passée.
Capitaliser un contexte, c'est conserver une capacité future.
Le livrable dit : voici ce que nous avons envoyé.
Le contexte dit : voici ce que nous avons compris, décidé, vérifié, écarté, et ce que nous pouvons encore produire à partir de là.
C'est pour cela que le livrable n'est plus le capital principal.
Il reste la partie visible.
Mais la valeur durable se déplace vers ce qui permet de produire plusieurs fois sans perdre le fond.
Le document part.
La pensée organisée reste.
Pour en savoir plus
Le PM comme architecte du Contexte Source de session : ce que vos documents ne capturent pas Sous le capot de mon moteur de contexte : comment une IA se souvient d'une mission Le second cerveau est une impasse pour le product management Dans le logiciel, l'avantage ne sera plus la technologie. Ce sera la compréhension du contexte.