Recette utilisateur

Recette utilisateur : Tests menés par les futurs utilisateurs sur des cas réels, distincts des vérifications faites par l’équipe technique.

Ce terme appartient à la famille « Business ». La page reprend l’essentiel : à quoi ça sert, comment l’écrire, ce qui se passe quand on l’oublie.

Pourquoi Recette utilisateur compte sur un projet mobile

Recette utilisateur appartient au vocabulaire de l’achat de prestation. Le mot apparaît dans les propositions commerciales, et son sens exact décide de qui paie quoi.

Ce que le mot recouvre exactement dépend du projet. Ce qui suit vaut pour la plupart des applications mobiles françaises, et sert de point de départ à la discussion.

Comment l’écrire dans un cahier des charges

Le cahier des charges doit préciser ce que recouvre « Recette utilisateur » exactement, faute de quoi chaque prestataire y mettra sa propre définition dans sa proposition.

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

• Ce que couvre la garantie après la mise en ligne, et sa durée.
• Le contenu du forfait de maintenance, distinct du budget des évolutions.
• Les profils affectés au projet, et leur taux de présence réel.
• Le tarif des évolutions après le lancement, fixé avant la signature.

Cette formulation se rédige avant la consultation, pas après réception des propositions : c’est elle qui rend deux devis comparables entre eux.

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

Recette utilisateur se vérifie sur les documents : contrat, annexe, facture, compte rendu de jalon.

• Demander le relevé des jours consommés, pas seulement un pourcentage d’avancement.
• Lire ce que couvre la garantie avant d’avoir à la déclencher.
• Obtenir par écrit le tarif des évolutions à venir.

Ces vérifications s’inscrivent au cahier de recette, avec un nom en face de chacune. Une case sans responsable reste vide.

Ce qui tourne mal le plus souvent

Ces erreurs ne viennent presque jamais d’un manque de compétence, mais d’un point qui n’a été écrit nulle part.

• Oublier la maintenance annuelle dans le budget, puis la découvrir la première année.
• Confondre le prix de fabrication et le coût total de possession de l’application.
• Ne pas prévoir la réversibilité, et se retrouver captif d’un prestataire.
• Bâtir un retour sur investissement sur des hypothèses d’usage jamais vérifiées.
• 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 :

• Cahier des charges
• TJM
• Forfait
• Régie
• MRR

Questions fréquentes

Recette utilisateur : de quoi parle-t-on exactement ?

Tests menés par les futurs utilisateurs sur des cas réels, distincts des vérifications faites par l’équipe technique. 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.

Comment comparer deux prestataires sur ce point ?

Demandez la même ventilation à tous, dans le même ordre. Deux propositions ne se comparent que si les postes couvrent le même périmètre, ce qui n’arrive jamais spontanément.

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.