Wireframe

Wireframe : Schéma d’écran en niveaux de gris qui pose la structure et la hiérarchie des blocs sans engager de parti pris graphique.

Cette entrée du glossaire relève de la famille « Produit et UX ». Elle donne la définition, sa traduction en exigences, et les erreurs vues le plus souvent sur des projets réels.

À quoi sert Wireframe

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

Le sujet mérite trois minutes d’attention au cadrage. C’est le seul moment du projet où il ne coûte rien à traiter.

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

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

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.

Comment le vérifier à la recette

Sur « Wireframe », la recette se fait écran par écran, y compris dans les cas que personne n’aime tester : liste vide, erreur, coupure de réseau.

• 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.

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

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.
• Se contenter d’une réponse orale en réunion, jamais reprise dans le document contractuel.

Termes liés

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

• Conception éthique

Questions fréquentes

Wireframe : de quoi parle-t-on exactement ?

Schéma d’écran en niveaux de gris qui pose la structure et la hiérarchie des blocs sans engager de parti pris graphique. Le mot est employé tel quel par les équipes francophones. C’est celui à utiliser dans les échanges avec une agence, y compris quand la traduction française existe.

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.