Valeur perçue
Par Sebastian · mise à jour le 21 août 2026
Valeur perçue : Bénéfice que l’utilisateur estime retirer du produit, seule mesure qui compte au moment où on lui demande de payer.
Le mot appartient à la famille « Produit et UX » du lexique. Cette page dit ce qu’il recouvre, comment il se formule dans un cahier des charges, et ce qu’il vaut mieux ne pas écrire.
Ce que recouvre Valeur perçue, concrètement
Dans un projet d’application, Valeur perçue 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.
La traduction en exigences
Un cahier des charges lisible relie « Valeur perçue » à un utilisateur nommé et à une action précise : qui fait quoi, depuis quel écran, avec quel résultat visible.
À é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.
Rien n’oblige à tout figer dès le premier jour. Ce qui reste ouvert doit alors être signalé comme tel, avec la date à laquelle la décision sera prise.
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.
Ce que ça change au moment de la recette
Le contrôle de « Valeur perçue » repose sur les critères d’acceptation écrits avant le développement. Sans eux, la recette devient une discussion de goûts.
- Faire dérouler le parcours principal par quelqu’un qui n’a pas participé au projet.
- Relire les textes affichés : fautes, jargon interne, phrases tronquées.
- Contrôler ce que voit un utilisateur qui n’a encore aucun contenu.
Un prestataire sérieux propose ces contrôles de lui-même. Quand ce n’est pas le cas, c’est au client de les inscrire au cahier de recette.
Erreurs fréquentes
Sur ce point précis, voici ce qui coûte le plus cher aux porteurs de projet, dans l’ordre où on le rencontre.
- Valider des maquettes sans avoir écrit les critères d’acceptation correspondants.
- Empiler les fonctionnalités en version 1 au lieu de sortir un périmètre défendable.
- Repousser l’accessibilité à plus tard, ce qui revient à refaire les écrans une seconde fois.
- Découper le projet en sprints sans jamais rien mettre entre les mains d’un utilisateur.
- 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 :
Questions fréquentes
Que signifie « Valeur perçue » ?
Bénéfice que l’utilisateur estime retirer du produit, seule mesure qui compte au moment où on lui demande de payer. Cette définition suffit pour une discussion de cadrage. Pour un contrat, il faut y ajouter ce que le terme recouvre exactement sur votre application.
Faut-il tout traiter dès la version 1 ?
Non, et c’est le principal levier de budget. Ce qui compte est d’écrire ce qui est repoussé, pour que la version 1 reste défendable et que la suite reste chiffrable.
Est-ce que ça se retrouve dans le devis ?
Un devis lisible sépare conception, design, développement, tests, publication et suivi. La grille de lecture des devis détaille poste par poste ce qui doit y apparaître.
Toutes les définitions publiées sont rassemblées dans l’index du glossaire, classées de A à Z et par famille.
Un doute sur ce point de votre projet ?
30 minutes avec un technicien : on relit votre périmètre, on vous dit ce qui manque dans le cahier des charges et à quel palier de prix votre projet se situe. Sans engagement.