Réponse en bref
Une passation de design ne laisse rien à deviner lorsqu’elle fixe, en plus des écrans, sept éléments : quels cadres sont définitifs et dans quelle version, tous les états de chaque composant, erreurs et écrans vides compris, les design tokens derrière les valeurs, le comportement des mises en page entre les tailles, les règles du contenu réel, les ressources avec leurs licences et les critères d’acceptation de chaque écran. Les questions passent par un seul canal et chaque réponse revient dans le fichier.
Chaque vide de la passation devient une décision prise par la mauvaise personne
Un fichier de design répond aux questions auxquelles son auteur a pensé. La production pose les autres : à quoi ressemble ce bouton pendant le traitement du paiement, que devient la carte quand le nom compte quarante caractères, quel gris est-ce. Si le fichier se tait, le développeur décide, seul et sous la pression d’un délai, et cette décision part en ligne.
Il n’y a de négligence ni d’un côté ni de l’autre. Une maquette montre un instant d’une interface avec un contenu idéal, alors qu’une interface, ce sont des centaines d’instants avec un contenu réel. L’écart entre les deux, c’est la passation, et il est comblé soit par une règle écrite, soit par une supposition. Supposer coûte peu ; retrouver la supposition plus tard coûte cher.
Une passation du design aux développeurs qui ne laisse rien à deviner contient, outre les écrans, sept éléments : un statut pour chaque cadre, tous les états et cas limites, les tokens, les règles responsives, les règles de contenu, les ressources avec leurs licences et les critères d’acceptation. Un huitième les tient ensemble : un lieu unique où l’on pose les questions et où l’on y répond.
Indiquez ce qui est terminé et de quelle version il s’agit
La première chose qu’un développeur doit deviner, c’est si un cadre est définitif. Les fichiers contiennent des explorations, des variantes écartées et des idées inachevées à côté du travail validé, et tout paraît également réel. Énoncez le périmètre en toutes lettres : la liste des écrans et des composants de cette version, et un statut visible sur chacun.
Les outils de design le permettent désormais directement. La documentation de Figma décrit Dev Mode comme un espace de travail servant à inspecter les maquettes, à comparer les modifications et à gérer la passation ; les cadres, composants et sections peuvent recevoir le statut « Ready for dev », et la version actuelle d’un cadre peut être comparée aux précédentes. Quel que soit l’outil, le principe reste le même.
Un statut est une promesse ; tout ce qui change ensuite est donc traité comme une modification. Si un cadre validé est retouché, laissez à côté une courte note datée disant ce qui a changé et pourquoi, et prévenez ceux qui le développent. Une correction silencieuse sur un écran « prêt », c’est ainsi que deux versions d’un même composant arrivent en production.
Dessinez chaque état, puis les cas gênants
Un composant n’est pas une image unique. Les spécifications de Material Design regroupent les tokens d’un composant d’abord par état, « enabled, disabled, hover, etc », c’est-à-dire activé, désactivé, survolé et ainsi de suite, puis seulement par élément ; c’est un bon modèle pour une passation. Pour chaque composant interactif, montrez l’état par défaut, le survol, le focus clavier, l’état appuyé et l’état désactivé, et pour tout ce qui attend des données, le chargement, le succès et l’erreur.
Concevez ensuite les cas que personne ne met dans une présentation. La liste vide avant l’arrivée du premier élément. La recherche sans résultat. Le nom trois fois plus long que l’exemple, la photo qui ne s’est pas chargée, le tableau d’une ligne et celui de mille. L’utilisateur qui n’a pas les droits, et celui dont la connexion est lente.
Un tableau des états rend l’exercice gérable : les composants en lignes, les états en colonnes, un lien ou une note dans chaque case. Une case vide est une question qui sera posée en plein sprint. « Identique à l’état par défaut » est une réponse légitime ; il faut simplement qu’elle soit écrite par le designer et non supposée par le développeur.
Les tokens transforment des valeurs copiées en décisions nommées
Material Design définit les design tokens comme de petites décisions de design réutilisables qui composent le style visuel d’un système et remplacent les valeurs statiques par des noms explicites. Sa documentation avance elle-même l’argument de la passation : lorsque la maquette du designer et l’implémentation de l’ingénieur renvoient au même token, tous deux peuvent être certains que la même couleur est utilisée, même si sa valeur hexadécimale est mise à jour plus tard.
Il existe désormais un format de fichier commun. Le Design Tokens Community Group a publié en octobre 2025 le Design Tokens Format Module 2025.10 en tant que rapport stable ; le document précise qu’il ne s’agit pas d’un standard du W3C. Les tokens sont enregistrés en JSON, chacun avec une valeur et un type et, en option, une description de son rôle, et un token peut être un alias qui renvoie à un autre token.
Pour une passation, le minimum pratique est un tableau ou un fichier de tokens couvrant la couleur, la typographie, les espacements, les rayons, les ombres et le mouvement, avec des noms qui disent à quoi sert une valeur et non à quoi elle ressemble. Les trois classes de Material offrent un bon modèle : tokens de référence pour les valeurs brutes disponibles, tokens système pour les rôles, tokens de composant pour les parties d’un composant. Tout ce qui, dans le fichier, n’utilise aucun token devrait être signalé comme une exception voulue.
Le comportement responsive est un ensemble de règles, pas trois captures
Trois plans de travail, pour mobile, tablette et ordinateur, décrivent trois largeurs parmi des milliers. Ce dont la production a besoin, c’est du comportement entre elles : quels éléments s’étirent, lesquels gardent une taille fixe, lesquels passent à la ligne, lesquels s’empilent, lesquels disparaissent, et dans quel ordre. Rédigez-le sous forme de règles attachées à la mise en page, avec des largeurs minimales et maximales là où il y en a.
Indiquez où la mise en page change, et pourquoi. Un point de rupture est utile lorsqu’il est lié au contenu, par exemple à la largeur à laquelle la navigation ne tient plus sur une ligne, et arbitraire lorsqu’il est recopié d’une liste d’appareils. Dites aussi ce qui reste constant : la largeur de lecture du texte, la taille des zones tactiles, l’échelle des espacements.
La largeur n’est qu’une condition parmi d’autres. La documentation de Material Design sur les tokens en énumère d’autres sous le nom de contextes : formats d’appareils, thème sombre, mises en page denses et systèmes d’écriture de droite à gauche. Une passation devrait dire lesquels le produit prend en charge dans cette version et montrer au moins un écran clé dans chacun, afin que le reste se déduise des tokens et des règles.
Règles de contenu : texte réel, limites et ce qui se passe au-delà
Le faux texte masque la plupart des problèmes de mise en page. Fournissez les textes réels de chaque écran, y compris les libellés des boutons, les messages d’erreur, les états vides et les courriels de confirmation, rédigés ou validés par la personne responsable des mots. Un développeur obligé d’inventer un message d’erreur en écrira un, et il parviendra aux utilisateurs.
Pour chaque élément de texte alimenté par des données, donnez la règle : la longueur attendue, la longueur maximale et ce qui se passe au-delà, que le texte passe à la ligne, soit tronqué avec un moyen de voir la suite ou rétrécisse. Faites de même pour les images : le rapport largeur-hauteur, le recadrage et ce qui s’affiche lorsqu’il n’y en a pas.
Ajoutez les formats qui varient selon la langue et la région : dates, heures, nombres, devises, pluriels. Si le produit doit être traduit, testez la mise en page avec la langue la plus longue que vous prévoyez et avec une langue écrite de droite à gauche si nécessaire. Et donnez à chaque image porteuse de sens son alternative textuelle dès la passation, car c’est aussi un contenu que quelqu’un doit écrire.
Les ressources et les licences voyagent avec le fichier
Ce n’est pas non plus au développeur de deviner comment exporter les ressources. Listez ce qui est nécessaire et dans quel format : fichiers vectoriels pour les icônes et les logos, images matricielles aux tailles et densités utilisées par le produit, vidéos et animations avec leurs réglages. Le Dev Mode de Figma, par exemple, permet de télécharger des ressources et d’exporter des calques en PNG, JPG, SVG ou PDF ; encore faut-il que quelqu’un dise lesquels.
Les noms comptent plus qu’il n’y paraît. Une convention de nommage cohérente, alignée sur les noms du code, épargne à tous une table de correspondance, et un seul dossier ou une seule bibliothèque convenus évitent de se demander quel logo est le bon. Conservez avec la passation les originaux en pleine résolution, et pas seulement les exports compressés.
Viennent ensuite les licences. Pour chaque police, indiquez quelle licence couvre son usage sur le web ou dans une application, et au nom de qui elle est établie. Faites de même pour les photographies de banque d’images, les illustrations, les jeux d’icônes et la musique. Une maquette peut être montée avec une police d’essai ou un aperçu filigrané ; le produit publié exige la vraie licence, et le développeur ne peut pas savoir lequel est lequel si la passation ne le dit pas.
Critères d’acceptation et un seul canal pour les questions
Le Service Manual du gouvernement britannique décrit les critères d’acceptation comme une liste de résultats utilisée à la manière d’une liste de contrôle pour confirmer qu’un service a rempli son rôle et répond au besoin de l’utilisateur, souvent rédigée comme une liste qui commence par « it’s done when… », « c’est terminé quand… ». Le même procédé vaut pour un écran : il est terminé quand tous les états du tableau sont développés, que les tokens correspondent, que les règles de mise en page tiennent à toute largeur et que le contenu réel trouve sa place.
Rédigez les critères avant le début du développement et contrôlez le résultat d’après eux, sur de vrais appareils et en présence du designer. La revue de design cesse alors d’être une affaire de goût pour devenir une comparaison avec une liste, et le développeur dispose de quoi vérifier avant de demander la revue.
Enfin, choisissez un seul canal pour les questions et annoncez-le dans la passation. Une question posée dans une messagerie, tranchée lors d’un appel et retenue par deux personnes est perdue pour toutes les autres. Gardez les questions près du design, sous forme de commentaires ou d’annotations sur le cadre, nommez la personne qui répond et son délai, et réécrivez chaque réponse dans le fichier sous forme de règle. Le projet suivant démarrera ainsi avec moins de vides.
Checklist pratique
- Attribuez un statut à chaque cadre du périmètre et notez toute modification faite après l’avoir déclaré prêt.
- Remplissez un tableau des états pour chaque composant, avec le chargement, l’erreur, le vide et l’absence de droits.
- Livrez les tokens sous forme de fichier ou de tableau, nommés d’après leur rôle, et signalez chaque valeur qui n’en utilise aucun.
- Écrivez en toutes lettres les règles responsives, de contenu et d’image, puis testez la mise en page avec le texte réel le plus long.
- Listez les ressources avec leurs formats et leurs licences, rédigez des critères d’acceptation par écran et désignez un seul canal pour les questions.
Questions et réponses
Que doit contenir une passation de design aux développeurs ?
En plus des écrans : un statut indiquant quels cadres sont définitifs, tous les états de chaque composant, les cas limites, les design tokens, les règles du comportement responsive, le contenu réel avec ses limites, les ressources avec leurs licences et les critères d’acceptation de chaque écran. Ajoutez un canal de questions nommément désigné. Si un développeur peut construire un écran sans demander ce qui se passe quand les données manquent ou sont trop longues, la passation est complète.
Que sont les design tokens, et un petit projet en a-t-il besoin ?
Les design tokens sont des décisions de design nommées, comme une couleur, un pas d’espacement ou un corps de texte, enregistrées une fois et référencées partout. La documentation de Material Design indique qu’ils sont surtout utiles lorsqu’un produit doit évoluer, couvre plusieurs plateformes ou s’appuie sur un design system, et moins utiles pour une application existante aux valeurs codées en dur qui a peu de chances de changer. Un petit projet peut commencer par un court tableau de couleurs, de tailles et d’espacements nommés.
Le format des design tokens est-il un standard officiel du W3C ?
Non. Le Design Tokens Format Module 2025.10 a été publié par le Design Tokens Community Group, qui travaille selon le processus des groupes communautaires du W3C, et le document précise qu’il n’est pas un standard du W3C et ne se trouve pas sur la voie de standardisation du W3C. Le groupe décrit la spécification comme stable et destinée à être implémentée. Vérifiez la version en vigueur sur le site du groupe avant de bâtir des outils dessus.
Quels états prévoir pour chaque composant d’interface ?
Cela dépend du composant, mais l’ensemble habituel pour un élément interactif comprend l’état par défaut, le survol, le focus clavier, l’état appuyé et l’état désactivé. Les éléments qui dépendent de données ont aussi besoin des états de chargement, de succès, d’erreur et de vide. Les spécifications de Material Design organisent les valeurs des composants par état pour la même raison. Listez les états dans un tableau et écrivez « identique à l’état par défaut » lorsque c’est la réponse, afin que rien ne soit laissé à la supposition.
Comment rédiger les critères d’acceptation d’un design ?
Écrivez pour chaque écran une courte liste de résultats observables, selon la formule que propose le Service Manual du gouvernement britannique : « c’est terminé quand… ». Par exemple : c’est terminé quand tous les états listés sont développés, quand la mise en page tient à toute largeur entre le minimum et le maximum indiqués, quand le contenu réel de longueur maximale trouve sa place et quand les tokens du code correspondent à ceux du fichier. Convenez de la liste avant le développement et contrôlez le résultat d’après elle.