Idée principale

Écrire « en cas de conflit entre un client et un fournisseur, nous privilégions le client » ne décrit aucune fonctionnalité, aucun écran, aucun workflow. C'est précisément ce qui donne sa portée à la phrase : elle influencera les règles de remboursement, les politiques de litige, les messages du support, les priorités produit et la communication client, parce qu'elle ne s'est engagée sur aucun d'entre eux.

L'altitude est donc une propriété fonctionnelle, pas une question de style. Une règle formulée au niveau du cas — « dans ce parcours, ce bouton fait ceci » — ne se transpose plus ailleurs ; elle a la forme d'une spécification et n'en a pas la précision. Une règle formulée au niveau du type de situation — « dans ce type de situation, voici ce que nous appliquons » — se laisse dériver par des gens qui n'étaient pas dans la discussion, sur des cas que personne n'avait envisagés.

Le contrôle est simple à opérer : si le document commence à dire ce qu'il faut construire, il a quitté son niveau et devient une spécification déguisée, moins utile qu'une vraie spécification.

Pourquoi c'est important

Cela donne un test de relecture pour tout document de décision : y chercher les verbes de fabrication. Leur présence indique que le niveau a glissé.

Cela protège aussi de l'erreur inverse, plus rare mais réelle : une règle si générale qu'elle ne relègue rien — « nous cherchons le meilleur équilibre entre client et fournisseur » — n'a pas changé de niveau, elle a cessé d'être une règle.

Nuances et limites

Certaines règles n'existent qu'incarnées : une exigence de conformité ou une contrainte réglementaire se formule au niveau du comportement attendu, et la remonter en principe la rend inapplicable.

Et l'altitude ne garantit rien seule : une règle au bon niveau mais inconnue des équipes n'est pas dérivable, elle est seulement bien rédigée.

Questions ouvertes

• Comment vérifier, autrement qu'à l'usage, qu'une règle écrite est effectivement dérivable sur des cas que ses auteurs n'avaient pas en tête ?