Exigence

Exigence : Énoncé vérifiable de ce que le produit doit satisfaire, formulé de façon à pouvoir être testé lors de la recette.

Classé dans la famille « Produit et UX », ce terme revient dans les échanges entre un client et son agence. Voici ce qu’il faut en comprendre avant d’en discuter le prix.

Où intervient Exigence dans un projet

Dans un projet d’application, Exigence sert à trancher : quelles fonctions entrent en version 1, dans quel ordre, et ce qu’on assume de laisser de côté.

Dans la pratique, deux interlocuteurs qui n’ont pas la même définition en tête avancent d’accord pendant des semaines, puis découvrent le désaccord à la livraison.

De la définition à la ligne de cahier des charges

Le cahier des charges doit fixer ce que recouvre « Exigence » en version 1 et ce qui attend la suite. Un périmètre non borné s’étend tout seul pendant la recette.

À écrire noir sur blanc, dans le chapitre qui correspond :

• Les rôles utilisateurs, et ce que chacun a le droit de faire.
• Les écrans concernés, listés, avec leur état vide et leur état d’erreur.
• Ce qui est explicitement hors périmètre de la version 1.
• Les contenus fournis par le client, et la date à laquelle ils arrivent.

Une exigence bien écrite tient en trois lignes et se refuse en une. Si elle ne peut pas être refusée à la recette, elle n’est pas encore écrite.

Pour le cadre général, le guide des prix donne les fourchettes constatées en France et le modèle de cahier des charges la structure qui les rend opposables.

Les contrôles à prévoir

À la recette, « Exigence » se juge sur le parcours complet, pas sur un écran isolé qui fonctionne en démonstration.

• Utiliser l’application sur un petit écran, d’une seule main.
• Parcourir l’écran principal au lecteur d’écran, au moins une fois.
• Comparer les maquettes validées au résultat livré, écran par écran.

Chacun de ces contrôles prend quelques minutes. Les découvrir après la mise en ligne prend des jours.

Erreurs fréquentes

Les mêmes causes reviennent d’un projet à l’autre, quel que soit le prestataire et quelle que soit la taille du budget.

• Décrire une fonctionnalité par une intention plutôt que par des écrans et des règles.
• Oublier les cas qui vont mal : liste vide, erreur réseau, droits insuffisants.
• Confondre l’avis de trois collègues et un test auprès de vrais utilisateurs.
• Laisser le back-office hors du cahier des charges, alors qu’il pèse lourd dans le chiffrage.
• Employer le mot sans le définir, et laisser chaque partie prenante y mettre son propre sens.

Termes liés

Les entrées du glossaire déjà publiées sur des sujets voisins :

• MVP
• Onboarding
• Churn
• Wireframe
• User story

Questions fréquentes

Que signifie « Exigence » ?

Énoncé vérifiable de ce que le produit doit satisfaire, formulé de façon à pouvoir être testé lors de la recette. La définition tient en une phrase, son application dépend du projet. C’est pour cette raison qu’elle doit figurer dans le cahier des charges plutôt que dans un échange de courriels.

Comment le vérifier à la recette ?

Avec un critère écrit avant le développement, formulé de façon à pouvoir être refusé. « L’écran doit être agréable » ne se recette pas. « La liste vide affiche tel message et tel bouton » se recette.

Comment savoir si le budget annoncé est cohérent ?

En comparant le périmètre écrit aux fourchettes constatées en France, détaillées poste par poste sur le guide des prix. Un chiffre isolé ne veut rien dire sans le périmètre qui va avec.

Toutes les définitions publiées sont rassemblées dans l’index du glossaire, classées de A à Z et par famille.