Idée principale

Une spécification 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. Aucun de ces documents ne décrit ce que le client rencontrera : entre eux et la mise en production, des compromis sont faits, des détails sont ajustés, des cas limites apparaissent, des contraintes techniques obligent à modifier légèrement le comportement, et des décisions se prennent au fil d'une pull request sans remonter dans le document initial.

Ces arbitrages ne sont pas des accidents à supprimer : un produit vivant ne se fabrique pas comme un document figé. Mais ils ont une conséquence sur ce qu'il faut regarder pour connaître un produit. La spécification reste une approximation utile à un moment donné ; la version en production est la seule description complète de ce qui a été livré.

L'effet se lit aussi sur les outils de suivi : les tickets se désynchronisent au même titre que les spécifications, parce que les arbitrages pris pendant la réalisation ne remontent dans aucun des deux.

Couche apportée par « Le backlog n'est pas un dépotoir : c'est un outil d'action » (2026-06-03).

Couche apportée par « PM, développeurs et IA : les rôles se brouillent, les responsabilités restent » (2026-08-01). Ces arbitrages ont un nom et un auteur : ce sont des décisions produit, et ce sont les développeurs qui les prennent. Une spécification complète est une fiction — même bonne, elle laisse des zones muettes : cas limites, messages d'erreur, comportements implicites, règles de sécurité, temps d'expiration, priorités invisibles, micro-interactions, décisions de repli. Le constat ne décrit donc pas seulement un écart entre le document et la production ; il désigne qui, dans les faits, décide de ce que le client rencontrera.

Pourquoi c'est important

Cela déplace le lieu où l'on va chercher la vérité d'une fonctionnalité : dans le comportement livré, pas dans le ticket qui l'a demandée. Les écarts ne sont pas des erreurs de conformité, ils sont la matière même de la décision produit.

Cela dit aussi ce qu'on perd en restant en amont : la part des choix qui détermine l'expérience du client s'est jouée après le document, dans des échanges que ce document n'enregistre pas.

Nuances et limites

Sur certains périmètres, l'écart est faible et l'intention tient : un changement de libellé, un paramètre, une règle métier simple arrivent en production tels qu'ils ont été écrits.

Et un produit soumis à une contrainte réglementaire inverse partiellement la règle : la conformité s'y démontre sur le document autant que sur le comportement livré, et l'écart devient un défaut en soi.

Questions ouvertes

• Par quel dispositif un arbitrage pris dans une pull request pourrait-il remonter à celui qui a conçu la fonctionnalité, sans reconstituer la charge documentaire qu'on cherche à éviter ?