# Une spécification validée reste une hypothèse
La livraison · diagnostic · https://build-here.africa/livre/chapitres/05-04-valider-une-spec-ne-la-rend-pas-juste.html

## Le symptôme

Un document décrit le résultat attendu et les contraintes. Il a été validé. Une observation nouvelle contredit une de ses hypothèses.

## Le signal

Sépare ce qui est exigé, ce qui a été vérifié et ce qui reste supposé. Puis porte la contradiction à la personne qui a validé.

## Ce qui se passe

Une spécification validée est un accord sur ce qu'on croyait au moment de la valider. Elle ne rend pas les hypothèses vraies. La réalisation et l'usage les testent, et certaines tombent.

Un document prévoit un choix de créneau pour l'inscription. L'équipe suppose que cela la facilitera. Au premier essai, des personnes ne comprennent pas les horaires. Le document est validé. Il est aussi faux sur ce point. Il faut une réponse : une meilleure explication ou un autre choix.

Certaines exigences viennent d'un engagement, d'une obligation légale ou d'une contrainte de fonctionnement. Un retour contraire ne les annule pas. Distingue les deux avant de proposer un changement.

Ne diverge pas en silence. Apporte les faits et les options à la personne qui a validé, et fais mettre le document à jour. Un document qui ne suit pas la réalité devient une source d'erreurs pour le suivant.

## À vérifier

Dans un document de travail, ajoute l'hypothèse qui compte le plus :

> Nous supposons que ...
> Nous le vérifierons par ...
> Si ce n'est pas le cas, nous ...

Au retour, mets le document à jour, que l'hypothèse tienne ou non.

## À discuter

Quel document validé contient une hypothèse que l'usage a déjà démentie ?