Idée principale

Une spécification, un PRD, une maquette sont accusés de mentir dès qu'on découvre l'écart entre ce qu'ils annoncent et ce que le produit fait. L'accusation vise le mauvais objet : ces documents ne se sont pas trompés, ils ont cessé d'occuper la fonction pour laquelle ils ont été écrits.

Avant la mise en production, une spécification sert au dialogue. Elle donne au Product Manager, aux développeurs et aux métiers quelque chose à contester : elle permet d'explorer une hypothèse, de cadrer un périmètre, de faire apparaître un désaccord avant qu'il ne coûte cher, de décider. Sa valeur ne tient pas à sa justesse mais à sa capacité à provoquer des objections — un document que personne n'a discuté a échoué même s'il décrit exactement ce qui sera livré.

Le passage en production retire cette fonction. Les compromis pris pendant le développement, les cas limites découverts, les arbitrages tranchés dans une merge request sont entrés dans le produit sans repasser par le document. Ce qu'il disait du comportement n'est plus une proposition à discuter : c'est une description concurrente de celle que porte le dépôt, et perdante. L'artefact ne devient pas faux, il devient régénérable — ce qu'il énonce du comportement se reconstruit depuis le code, et le maintenir à la main revient à entretenir un doublon qui dérive.

Le basculement est donc daté, et ce n'est pas la date de rédaction. Un même document est légitime avant la livraison, illégitime après, sans qu'une seule de ses phrases ait changé.

Pourquoi c'est important

Cela lève le faux dilemme entre « il faut de meilleures specs » et « il faut arrêter d'en écrire ». Les deux camps supposent que la spécification a un statut unique ; elle en a deux, et l'erreur courante consiste à prolonger le premier après le moment où il expire.

Cela réoriente aussi l'effort : plutôt que de réécrire un document après chaque livraison pour qu'il reste vrai, on l'écrit franchement pour la conversation qu'il doit ouvrir, et on accepte qu'il soit périmé dès la mise en production. Le soin se déplace vers la qualité de la discussion en amont et vers la capacité de régénération en aval — deux choses, contrairement à la mise à jour manuelle, qui ne se dégradent pas avec le temps.

Nuances et limites

Le basculement ne concerne que la part descriptive. Une spécification contient presque toujours, mêlées dans les mêmes paragraphes, la description d'un comportement et la raison qui l'a fait retenir — la seconde ne se régénère depuis aucun dépôt et doit survivre au document.

Une spécification peut par ailleurs être opposable : annexe d'un contrat client, pièce d'un dossier réglementaire, engagement écrit d'un appel d'offres. Elle garde alors une autorité juridique que la mise en production ne lui retire pas, même quand le produit s'en écarte — et c'est justement l'écart qui devient le sujet.

Enfin, « la mise en production » suppose une frontière nette. Un déploiement progressif derrière un feature flag, une livraison à quelques clients pilotes, un retour arrière étalent le moment du basculement au lieu de le marquer.

Questions ouvertes

• Qu'est-ce qui, concrètement, marque ce changement de statut sur le document lui-même, pour qu'un lecteur qui le rouvre huit mois plus tard sache lequel des deux régimes il consulte ?
• Une spécification écrite en sachant qu'elle sera périmée à la livraison s'écrit-elle autrement — plus courte sur le comportement, plus longue sur les alternatives écartées ?