Note de version

Note de version : Résumé des changements apportés par une livraison, destiné à l’équipe et au client pour savoir ce qui est à vérifier.

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 Note de version, concrètement

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

Sur un projet réel, la question ne se pose jamais en théorie : elle arrive dans un devis, dans une réunion de cadrage ou dans un rapport de recette.

Ce que ça devient dans un cahier des charges

Le cahier des charges doit fixer ce que recouvre « Note de version » 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.

Reste à désigner qui écrit cette ligne et qui la valide. Sans nom en face, la rubrique se remplit la veille de la signature, avec les mots du prestataire.

Le modèle de cahier des charges du guide reprend ces rubriques dans l’ordre attendu par une agence, et la grille de lecture des devis montre à quoi ressemble un chiffrage comparable.

Vérifier plutôt que croire

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

• Vérifier chaque état vide et chaque message d’erreur, écran par écran.
• Relire les textes affichés : fautes, jargon interne, phrases tronquées.
• Contrôler ce que voit un utilisateur qui n’a encore aucun contenu.

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

Ce qui tourne mal le plus souvent

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

• 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.
• Ne relier le sujet à aucun critère de recette : ce qui ne se vérifie pas ne se livre pas.

Termes liés

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

• MVP
• Conception éthique
• Onboarding
• Churn

Questions fréquentes

Qu’est-ce que « Note de version » ?

Résumé des changements apportés par une livraison, destiné à l’équipe et au client pour savoir ce qui est à vérifier. 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.