Presque tous les jours, sur Slack, j'ai droit à la question produit.

Pas une question abstraite. Pas une grande réflexion sur la vision à cinq ans. Une vraie question de terrain.

Est-ce qu'on peut faire ça ?

Qu'est-ce qui se passe si le client configure le produit comme ça ?

Quelle est la limite ?

Est-ce que cette règle s'applique aussi dans ce cas ?

Pourquoi le produit bloque ici ?

Est-ce qu'on peut promettre ça au client ?

Certaines de ces questions sont stratégiques. Elles demandent de comprendre le marché, le client, le positionnement, la direction que l'on veut prendre. Dans ces cas-là, il faut un product manager. Il faut un jugement. Il faut parfois dire non, parfois arbitrer, parfois assumer une orientation.

Mais beaucoup de questions ne sont pas de cet ordre.

Elles portent sur le comportement réel du produit.

Une règle. Une limite. Une exception. Une contrainte. Un cas d'usage. Une configuration. Une interaction entre deux fonctionnalités.

Et là, en théorie, la réponse devrait être simple.

Le problème, c'est qu'elle ne l'est pas toujours.

Le coût caché de la question produit

Quand la question est fine, il ne suffit pas toujours d'ouvrir la documentation.

D'abord parce que la documentation n'existe pas toujours.

Ensuite parce qu'elle existe parfois, mais qu'on ne sait pas si elle est encore à jour.

Enfin parce que la vraie question porte souvent sur un cas limite que personne n'a documenté explicitement.

Alors on fait ce que font tous les PM, CSM, supports ou développeurs quand ils ont un doute : on teste.

On ouvre un environnement de test.

On prépare un jeu de données.

On rejoue le scénario.

On vérifie si le produit bloque, accepte, calcule, affiche, masque, déclenche, envoie, refuse.

Et une demi-heure est passée.

Parfois une heure.

Parfois plus.

Ce temps n'apparaît nulle part. Il n'est pas dans Jira. Il n'est pas dans la roadmap. Il n'est pas dans les estimations. Il est simplement absorbé par le fonctionnement normal de l'organisation.

Il y a aussi un autre coût, encore plus invisible : le changement de contexte.

La question arrive rarement au bon moment. Elle arrive parce qu'un client attend. Parce qu'un commercial est en rendez-vous. Parce qu'un CSM prépare un point. Parce que le support doit répondre avant la fin de la journée.

Donc on interrompt ce qu'on faisait. On entre dans un sujet. On teste. On répond. Puis on essaie de revenir à ce qu'on faisait avant.

Ce n'est pas seulement une perte de temps. C'est une perte de continuité intellectuelle.

Et c'est précisément le genre de tâche que l'IA devrait absorber.

Le problème n'est pas la question. C'est la source.

On pourrait répondre : il suffit d'avoir une meilleure documentation.

En théorie, oui.

En pratique, non.

Une documentation produit est presque toujours en retard sur le produit réel. Ce n'est pas un problème de discipline individuelle. Ce n'est pas seulement parce que quelqu'un a oublié de mettre à jour une page.

C'est plus structurel.

Une spec décrit une intention. Un PRD décrit un objectif, des règles attendues, des scénarios. Une maquette décrit une interface souhaitée. Mais entre cette intention et la production, il se passe toujours quelque chose.

Des compromis sont faits.

Des détails sont ajustés.

Des cas limites apparaissent.

Des décisions sont prises pendant le développement.

Des contraintes techniques obligent à modifier légèrement le comportement.

Des échanges ont lieu dans une pull request ou une merge request.

Des arbitrages ne remontent pas toujours dans la documentation initiale.

Ce n'est pas forcément grave. C'est même assez normal. Un produit vivant ne se construit pas comme un document figé.

Mais cela crée une conséquence simple : la spec n'est pas la vérité du produit.

Elle est une approximation utile à un moment donné.

La vérité, c'est ce qui tourne.

Et ce qui tourne, c'est le code.

Le code comme source de vérité produit

La production est la réalité.

Pas la spec.

Pas le PRD.

Pas la page Notion.

Pas le souvenir du PM.

Pas la discussion Slack d'il y a trois semaines.

Pour savoir comment le produit se comporte réellement, il faut regarder ce qui est livré. Et ce qui est livré est porté par le code source.

Dit comme ça, cela peut sembler brutal. On pourrait croire que cela revient à dire : "jetez toute la documentation".

Ce n'est pas l'idée.

La bonne distinction n'est pas entre "code" et "documentation".

La bonne distinction est entre ce qui explique et ce qui décrit.

On garde ce qui explique.

On régénère ce qui décrit.

Les contextes doivent être conservés. Ils contiennent les discussions, les sources, les raisonnements, les idées qui ont permis d'arriver à un choix. Ce sont des briques réutilisables.

Les décisions doivent être conservées. Quand une entreprise choisit une direction, il faut garder le pourquoi. Pourquoi ce choix ? Quelles alternatives ont été écartées ? Pourquoi cette décision remplace-t-elle une décision précédente ?

C'est le rôle des Product Decision Records, les PDR. J'ai déjà écrit sur ce sujet : un PDR ne décrit pas une feature, il trace une décision produit structurante.

Certaines contraintes doivent aussi rester accessibles : contraintes contractuelles, réglementaires, documents externes, engagements spécifiques. Tout ne peut pas être déduit du code.

Mais la documentation qui décrit le comportement produit devrait, autant que possible, être régénérée depuis le code.

Parce que le code est la vérité du comportement implémenté.

Ce que l'IA rend possible

Jusqu'ici, cette idée avait une limite évidente.

Le code est du code.

Il n'est pas toujours lisible pour le support. Il n'est pas toujours lisible pour les sales. Il n'est pas toujours lisible pour un C-level. Il n'est même pas toujours lisible facilement pour un PM, surtout s'il n'a pas de culture technique.

Pendant longtemps, il fallait donc une couche intermédiaire. Des specs. Des documents support. Des pages produit. Des changelogs. Des tableaux. Des schémas.

L'IA change cette équation.

Elle peut devenir l'interface entre une question métier et le code source.

Un support peut demander : "Que se passe-t-il si le client annule cet élément après validation ?"

Un CSM peut demander : "Dans quelles conditions ce workflow se bloque ?"

Un commercial peut demander : "Est-ce qu'on peut promettre cette configuration à ce prospect ?"

Un PM peut demander : "Où est implémentée cette règle et quels cas ne sont pas couverts ?"

Et l'IA peut aller chercher dans le code, dans l'historique Git, dans les merge requests, dans les feature flags, dans les contextes métier, puis produire une réponse compréhensible.

Pas une réponse magique.

Une réponse ancrée.

Une bonne réponse produit doit montrer ses preuves

Le point clé est là.

Si l'IA répond sans preuve, elle devient une nouvelle documentation approximative. Plus rapide, plus élégante, mais pas forcément plus fiable.

Il faut donc obliger l'IA à ancrer sa réponse.

Quand elle affirme qu'une règle existe, elle doit dire pourquoi.

Pas seulement : "le produit fonctionne comme ça".

Mais : "le produit fonctionne comme ça parce que telle fonction applique cette règle, parce que telle exception bloque ce cas, parce que telle merge request a introduit ce comportement, parce que tel test couvre ce scénario".

Les preuves ne doivent pas nécessairement être au centre de la réponse. Pour le support ou les sales, elles peuvent être en bas du document. Tout le monde n'a pas besoin de lire les détails techniques.

Mais elles doivent exister.

Leur présence change le comportement de l'IA. Elle ne peut plus répondre seulement par vraisemblance. Elle doit rattacher ses affirmations à des éléments factuels.

C'est la même logique que dans une analyse de texte. Si je demande à une IA d'analyser un corpus, je préfère qu'elle me donne, pour chaque conclusion, la phrase ou le paragraphe sur lequel elle s'appuie. Cela limite fortement les hallucinations.

Pour une question produit, c'est pareil.

La preuve peut être un fichier.

Une fonction.

Une exception.

Un test.

Un commit.

Une merge request.

Une pull request.

Un feature flag.

Une décision produit.

Une source métier.

Sans cela, on ne fait que déplacer le problème. On remplace la mémoire imparfaite du PM par la mémoire probabiliste d'un modèle.

Ce n'est pas suffisant.

Il faut aussi dire ce qu'on ne sait pas

Une bonne réponse produit ne doit pas seulement répondre.

Elle doit aussi dire où elle bloque.

C'est une directive essentielle.

L'IA doit pouvoir écrire :

"Je n'ai pas trouvé de test couvrant ce cas."

"Le code montre deux comportements possibles selon l'état du feature flag."

"Je ne peux pas déterminer le comportement exact pour ce client sans accéder à sa configuration."

"Le PDR indique une règle, mais le code semble implémenter autre chose."

"La documentation support actuelle contredit le comportement observé dans le code."

C'est inconfortable, mais c'est précieux.

Un humain sérieux fait la même chose. Quand il ne sait pas, il le dit. Quand il a un doute, il le signale. Quand il doit tester, il teste.

L'objectif n'est pas de faire croire que l'IA sait tout.

L'objectif est de réduire le coût de recherche, tout en augmentant la traçabilité.

Tous les publics n'ont pas besoin de la même lecture

Une question produit peut intéresser plusieurs métiers.

Le support veut souvent une réponse exploitable face au client.

Le CSM veut comprendre l'usage et les impacts.

Les sales veulent savoir ce qu'ils peuvent promettre, et quelle valeur mettre en avant.

Le PM veut vérifier la règle, la limite, l'exception.

La direction peut vouloir comprendre l'enjeu stratégique.

On pourrait donc imaginer une réponse différente pour chaque public.

Mais ce n'est pas forcément nécessaire.

Une même réponse peut être structurée en plusieurs angles. Une partie courte pour répondre à la question. Une partie support. Une partie usage. Une partie valeur. Une partie limites. Une partie preuves.

Chacun lit ce dont il a besoin.

Et parfois, c'est justement utile qu'un commercial voie une limite produit ou qu'un CSM comprenne l'origine technique d'un comportement. Cela dépend de la culture de l'entreprise. Certaines organisations préfèrent limiter l'information. D'autres gagnent en maturité en la partageant.

Ce n'est pas une question purement technique.

C'est une question de culture.

Les briques nécessaires

Techniquement, il ne suffit pas de brancher un LLM sur un dépôt Git et d'espérer que tout fonctionne.

Plusieurs outils sont complémentaires.

Le RAG permet de retrouver les bons fragments. Il est souvent très efficace pour faire émerger les morceaux pertinents dans une grande masse documentaire ou dans un code volumineux.

Mais le RAG ne suffit pas toujours. Il retrouve. Il ne voyage pas forcément.

Un graphe sémantique peut aider à explorer les éléments proches : concepts liés, modules voisins, règles connectées, événements qui déclenchent d'autres événements.

Le parcours du filesystem reste aussi indispensable. Quand on a identifié une zone, il faut parfois lire le répertoire, ouvrir les fichiers proches, comprendre la structure locale. C'est moins élégant qu'une recherche vectorielle, mais souvent très efficace.

Git apporte une autre dimension : le temps.

Le code actuel dit ce qui existe. L'historique dit comment on y est arrivé. Les commits, les pull requests ou les merge requests peuvent révéler l'intention, les discussions, les compromis, les corrections.

Les feature flags ajoutent encore une nuance. Le code peut contenir plusieurs comportements possibles. Le comportement réel dépend alors de l'état du flag.

Si l'IA n'a pas accès à cet état, elle doit répondre conditionnellement : si le flag est activé, alors le comportement est celui-ci ; sinon, il est différent.

Si elle a accès à l'environnement, elle peut aller plus loin : pour ce client précis, dans cette configuration précise, le comportement actif est celui-là.

Ce passage est important. La question produit ne porte pas toujours sur le code abstrait. Elle porte parfois sur le produit tel qu'un client précis le vit.

La condition : un code qui parle métier

Il y a cependant une condition de base.

Le code doit représenter le métier.

Si le code est un plat de nouilles, si les concepts métier sont cachés derrière des noms techniques, si les règles sont dispersées, si les exceptions ne portent pas le vocabulaire du domaine, alors l'IA aura du mal.

Mais ce n'est pas une limite nouvelle.

Un développeur humain aura aussi du mal.

Un PM technique aura aussi du mal.

Une équipe qui veut faire évoluer le produit aura aussi du mal.

Un code qui ne représente pas le métier n'est pas un bon code. Il impose en permanence une traduction entre le besoin métier et la mécanique logicielle. Chaque évolution demande de reconstruire mentalement ce lien. Chaque debug devient plus coûteux. Chaque règle devient plus difficile à retrouver.

C'est exactement pour cela que des approches comme le DDD existent depuis longtemps. L'idée n'est pas née avec l'IA.

L'IA rend simplement cette exigence plus visible.

Si l'on veut interroger le code comme source de vérité produit, le code doit parler le langage du produit.

Les entités doivent porter les noms du métier.

Les actions doivent être lisibles.

Les événements doivent raconter ce qui s'est passé.

Les exceptions doivent exprimer des règles, pas seulement des erreurs techniques.

Les politiques doivent rendre visibles les réactions en cascade.

Les modules doivent avoir une structure prévisible.

Une exception comme ElementAnnuléNonModifiable n'est pas seulement un message d'erreur. C'est une règle métier écrite en code.

C'est ce type de code qui devient interrogeable.

Pas parce que l'IA est magique.

Parce que le métier est déjà présent dans la matière qu'elle lit.

De la réponse ponctuelle à la documentation régénérée

Répondre à une question Slack est le premier cas d'usage.

Mais ce n'est pas le seul.

Si l'on peut répondre à une question produit depuis le code, on peut aussi régénérer une partie de la documentation produit.

On peut produire une FAQ support.

Mettre à jour un article vivant sur une fonctionnalité.

Générer un changelog.

Reconstituer une spec à partir de l'état actuel du produit.

Produire une documentation commerciale plus fiable sur ce qui peut être promis ou non.

La logique est toujours la même : ne pas maintenir à la main des artefacts qui décrivent le comportement réel si ce comportement peut être reconstruit depuis la source de vérité.

Les specs ne disparaissent pas entièrement.

Elles changent de statut.

Avant production, elles servent au dialogue.

Elles permettent de discuter, d'explorer, de cadrer, de décider.

Après production, elles ne doivent plus prétendre être la vérité durable du produit.

Elles deviennent régénérables.

Ce n'est pas une règle religieuse

Il faut évidemment garder un peu de pragmatisme.

Toutes les entreprises ne peuvent pas appliquer cela au millimètre près.

Certaines ont un historique documentaire lourd.

Certaines ont un legacy difficile.

Certaines ont des contraintes réglementaires fortes.

Certaines n'ont pas encore une culture technique suffisante.

Certaines ont des décisions produit mal tracées.

Certaines ne peuvent pas exposer les mêmes informations à tous les métiers.

Il ne s'agit donc pas de dire : demain matin, supprimez toute votre documentation.

Ce serait absurde.

Il s'agit de changer le centre de gravité.

Arrêter de considérer la documentation descriptive comme la source de vérité.

Arrêter de demander au PM de vérifier manuellement, encore et encore, ce que le produit fait déjà.

Arrêter de maintenir à la main des artefacts qui divergent mécaniquement.

Et commencer à construire un système où le code, les décisions, les contextes et les sources dialoguent.

Plus qu'une méthode produit

Au fond, la question produit n'est qu'un cas particulier.

Elle révèle une transformation plus large.

Pendant longtemps, le système d'information de l'entreprise a été composé de bases de données, de bases documentaires, de wikis, de tickets, de tableaux, de dossiers, de documents.

On cherchait.

On lisait.

On recopiait.

On mettait à jour.

On oubliait.

Avec l'IA, on peut commencer à faire autre chose.

On peut dialoguer avec le système d'information.

On peut poser une question.

On peut demander une preuve.

On peut explorer les idées proches.

On peut remonter l'historique.

On peut détecter une contradiction.

On peut régénérer un artefact.

La question produit est un bon point d'entrée parce qu'elle est concrète. Elle coûte du temps tous les jours. Elle interrompt le travail. Elle révèle la divergence entre documentation et production.

Mais derrière elle, le sujet est plus profond.

Il ne s'agit pas seulement d'aider le support à répondre plus vite.

Il s'agit de rendre l'entreprise interrogeable depuis ses vraies sources.

Et dans le cas du produit, la vraie source du comportement, c'est le code.

Pour en savoir plus

Code centric Product Decision Record : tracer les choix produit qui structurent l'entreprise Wiki IA : pourquoi j'ai construit une base de connaissances maintenue par une IA