Product building : la dette de contexte que l’IA vient de rendre visible
Écrit par : Florain Zilliox, Dalvince Boyer · Durée de lecture estimée : 8 minutes
Meta description : Le product building déplace le goulot du build vers la spécification. PRD, skills et documentation deviennent la vraie source de vérité de vos agents IA.
Il y a une scène qui se rejoue en ce moment dans beaucoup d’équipes produit. Quelqu’un écrit quelques lignes dans une fenêtre de chat pour décrire un besoin, récupère quatre cents lignes de code, et tout fonctionne. Le code compile, il tourne, il passe les tests. Il résout un problème légèrement différent de celui qu’on voulait résoudre, et personne ne s’en apercevra avant trois semaines.Ce n’est pas un problème de modèle. C’est un problème de contexte, et c’est devenu le sujet central du product building. On a beaucoup répété que le goulot d’étranglement s’était déplacé du build vers la formalisation.
Le mot formalisation est trompeur : il évoque de la documentation, alors qu’il s’agit en réalité de tout ce que votre organisation sait sans l’avoir jamais écrit.
Gardons à l’esprit que la qualité des spécifications conditionne directement la qualité des livrables générés par l’IA.
Ce que fait un développeur et que l’agent ne fera jamais
Un développeur qui reçoit une spécification floue exécute une opération que personne ne valorise et que tout le monde tient pour acquise. Il détecte l’ambiguïté, il se lève, et il pose la question. « Attends, tu es sûr que tu veux ça ? » Cette interruption est probablement le mécanisme de contrôle qualité le plus efficace jamais déployé dans une organisation produit, et il n’apparaît dans aucun tableau de bord.
Un agent, lui, ne se lève pas. Il tranche. Il comble le vide avec la réponse la plus statistiquement plausible, sans jamais signaler qu’il a comblé quoi que ce soit. L’ambiguïté ne disparaît pas, elle devient silencieuse. Et elle part en production à la vitesse d’un sprint compressé en une journée.
Appelons cela la dette de contexte. Elle fonctionne comme la dette technique, avec une différence désagréable : on l’accumule depuis quinze ans sans en payer les intérêts, parce que des humains la compensaient gratuitement, tous les jours, sans le dire. Brancher des agents sur une base de code, c’est appeler cette dette d’un coup.
Le Product Requirements Document redevient la source de vérité
C’est ce qui donne son sens réel au Specification Driven Development. On abandonne le backlog éclaté en dizaines de user stories au profit d’un document unique et complet, qui rassemble :
- le besoin, c’est à dire le problème réellement à résoudre,
- les personas, pour savoir pour qui l’on construit,
- les contraintes techniques, réglementaires et business,
- les règles métier, y compris celles que personne n’a jamais écrites,
- les spécifications fonctionnelles, le comportement attendu dans le détail
- les métriques de succès, pour savoir si la chose a marché.
Présenté ainsi, on croit reconnaître un retour au cycle en V. C’est la première objection qu’on entend, et elle passe à côté du geste. Le PRD n’est plus un document à faire valider puis à ranger. Il est lu par une machine qui produit du code à partir de lui, littéralement. Ce n’est plus une intention, c’est une entrée de programme.
Ce que change une spécification structurée
| Sans spécification structurée | Avec le PRD comme source de vérité |
| L’ambiguïté est résolue oralement, au cas par cas | L’ambiguïté est tranchée une fois, par écrit, pour tous |
| Le contexte vit dans les têtes et s’en va avec les départs | Le contexte est explicite et interrogeable par les agents |
| L’agent devine ce qu’on ne lui a pas dit, en silence | L’agent s’appuie sur des règles métier formulées |
| Le sprint est le rythme naturel du cycle | La valeur d’un sprint peut être produite en une journée |
| Une erreur de cadrage coûte quelques jours | Une erreur de cadrage se propage à l’échelle, très vite |
Les skills, ou comment arrêter de reprompter
Les organisations les plus avancées ont compris qu’un travail de cadrage ne doit pas être refait à chaque fois. C’est exactement ce que sont les skills : des compétences codifiées, souvent un simple fichier markdown, qui encapsulent une pratique maison et la rendent réutilisable par l’IA.
| Skill | Ce qu’il encapsule | Ce qu’il évite |
| Rédaction de PRD | Le format et les rubriques attendues en interne | Réexpliquer la structure à chaque nouvelle fonctionnalité |
| Spec Driven | Faisabilité, pertinence, analyse du code existant | Que l’IA se jette sur le code avant d’avoir réfléchi |
| Revue de code | Les conventions et les pièges connus de la codebase | Des correctifs qui rouvrent d’anciens bugs |
| Analyse d’impact | Les dépendances et les zones sensibles du produit | Les régressions découvertes en production |
Chez Décathlon, par exemple, ce sont les équipes Product Ops qui rédigent ces skills. Le détail n’en est pas un : la codification est confiée à ceux qui maîtrisent la pratique, pas à ceux qui maîtrisent l’outil.
Au passage, cela règle le sort d’une compétence qu’on a beaucoup survendue. Le prompt engineering, métier d’avenir il y a dix-huit mois, se fait absorber par les skills qui l’encapsulent. Personne ne cherche plus la formulation magique, on capitalise.
Une précaution s’impose cependant. Codifier une mauvaise pratique, c’est industrialiser une erreur. Une méthode approximative qui vivait dans les habitudes de deux personnes devient, une fois encapsulée dans un skill, la façon officielle dont trois cents personnes travaillent. Plusieurs organisations se retrouvent déjà avec des dizaines de skills de qualité inégale, produits par des gens de bonne volonté, qui polluent le contexte plus qu’ils ne l’enrichissent. La connaissance mal structurée ne reste jamais neutre, elle se propage.
Le pipeline complet, de l’observation à la production
Une fois le contexte structuré et les skills en place, les étapes s’enchaînent d’elles-mêmes :
- 1) Observation : Un signal remonte du terrain, d’un ticket support ou d’un entretien utilisateur.
- 2) Spécification : Le skill dédié produit un PRD complet à partir du contexte existant et des anciens PRD.
- 3) Planification : L’agent analyse la demande, la base de code et le design system, puis propose un plan.
- 4) Validation humaine : Le plan est approuvé, amendé ou refusé avant qu’une ligne de code soit écrite.
- 5) Génération : Le code est produit en respectant l’architecture existante.
- 6) Recette : Le tout est testé sur un environnement de staging alimenté par une copie récente de la production.
- 7) Déploiement : Le commit part sur GitHub, la CI/CD prend le relais et génère les notes de version.
L’étape 4 est celle qu’on oublie systématiquement dans les démonstrations, et c’est pourtant la seule qui protège de la dette de contexte. L’agent qui présente son plan avant d’exécuter reproduit exactement le geste du développeur qui se levait pour poser sa question.
Les connecteurs MCP (Model Context Protocol, le standard qui permet aux agents de dialoguer avec vos outils) sont ce qui rend ce pipeline possible : ils donnent accès aux anciens PRD, à Confluence, à Notion et à la CI/CD sans intégration sur mesure. Nous détaillons ce mécanisme dans notre article sur les MCP servers, et son application au métier de PM dans l’IA dans les métiers produits.
Là où l’humain fait la différence
Une observation contre intuitive revient sur le terrain : les organisations qui tirent le plus de valeur de l’IA ne sont pas celles qui ont les meilleurs modèles, ce sont celles qui avaient déjà une documentation propre. L’avantage compétitif est en train de se loger dans le travail le plus ingrat de l’informatique.
D’où l’émergence discrète d’un profil que personne n’avait vu venir. Le documentaliste tech, celui dont le métier consiste à structurer et organiser la connaissance pour la rendre exploitable, redevient un poste stratégique. La technologie la plus spectaculaire de la décennie fait remonter à la surface un métier de bibliothécaire.
Il existe une nuance importante, et elle mérite d’être dite. Certaines équipes produisent d’excellentes choses avec une documentation quasi inexistante. Trois personnes, un produit, un contexte partagé qui vit dans trois têtes et se met à jour en temps réel dans la même pièce. Ces équipes n’ont pas de dette de contexte, elles ont un contexte parfaitement liquide. La variable n’est donc pas le volume de documentation, c’est la distance entre celui qui sait et celui qui construit. Tant que cette distance est nulle, rien n’a besoin d’être écrit. Dès qu’un agent entre dans la boucle, la distance devient infinie, parce que la machine n’a rien d’implicite. Elle n’a jamais assisté à la réunion.
4 piliers pour maîtriser sa dette de contexte
Écrire ce que tout le monde croit savoir.
Les règles métier non documentées sont exactement celles que l’agent inventera.
Confier les skills aux experts.
Product Ops et Design Ops codifient la pratique. Un skill médiocre se propage plus vite qu’une mauvaise habitude.
Garder l’humain avant l’exécution.
Faire valider le plan, pas seulement le résultat. C’est le seul endroit où l’ambiguïté redevient visible.
Traiter la documentation comme de l’infrastructure.
Elle n’est plus un livrable annexe, elle est ce qui détermine la qualité de tout ce que vos agents produiront.
Ce qui change ici, c’est la nature du travail produit. Moins de temps passé à écrire des lignes de code, beaucoup plus à écrire ce qu’il faut construire, pour qui et pourquoi. La rigueur ne disparaît pas, elle remonte simplement d’un cran, là où elle a le plus d’impact.