Storyboard
Par Sebastian · mise à jour le 21 août 2026
Storyboard : Suite de vignettes racontant l’usage de l’application dans son contexte, utile pour montrer ce qui se passe autour des écrans.
Entrée de la famille « Produit et UX » du glossaire. Elle s’adresse à un porteur de projet qui doit rédiger, comparer ou recetter, pas à un spécialiste du sujet.
Où intervient Storyboard dans un projet
Storyboard décrit une réalité observable du côté de l’utilisateur. On peut donc s’en assurer autrement qu’à l’intuition, ce qui met une équipe d’accord plus vite qu’un débat d’opinion.
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.
De la définition à la ligne de cahier des charges
Un cahier des charges qui traite « Storyboard » sérieusement décrit aussi les cas qui vont mal : état vide, erreur, connexion perdue, droits insuffisants. C’est un tiers du travail réel.
À é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.
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
Le contrôle de « Storyboard » repose sur les critères d’acceptation écrits avant le développement. Sans eux, la recette devient une discussion de goûts.
- Reprendre les critères d’acceptation et les cocher un par un, sans indulgence.
- Parcourir l’écran principal au lecteur d’écran, au moins une fois.
- Comparer les maquettes validées au résultat livré, écran par écran.
Ce qui n’est pas vérifié à la recette ne sera pas vérifié du tout : le jour de la mise en ligne, plus personne n’a le temps.
Erreurs fréquentes
Aucune de ces erreurs ne se voit le jour où elle est commise. Toutes se paient plus tard, au moment le moins commode.
- 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.
- 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 :
Questions fréquentes
Qu’est-ce que « Storyboard » ?
Suite de vignettes racontant l’usage de l’application dans son contexte, utile pour montrer ce qui se passe autour des écrans. 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 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.
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.