Un produit qu’on comprend
avant même de l’utiliser.

On regarde ce que vos utilisateurs font vraiment, pas ce qu’ils disent. On dessine les écrans en gris avant de parler couleur, pour que la discussion porte sur le parcours. On teste avec cinq personnes réelles. On livre des fichiers qu’un intégrateur peut utiliser sans vous rappeler.

Ce que vous obtenez : Une arborescence validée, des wireframes, des maquettes dans tous leurs états, un prototype cliquable du parcours principal, et les fichiers sources qui vous appartiennent.

Ce que vous n’avez pas à faire : Choisir entre trois planches graphiques sans savoir ce qu’elles impliquent, ni arbitrer des détails visuels avant que la structure soit tranchée.

Le design n’est pas une couche de peinture posée à la fin. C’est l’étape où l’on décide ce que l’utilisateur voit, dans quel ordre, et ce qu’on lui demande de faire.

Nous travaillons sur Figma, du wireframe basse fidélité jusqu’au design system réutilisable. L’objectif n’est pas de produire de jolies planches, c’est de réduire le nombre de décisions à prendre pendant la construction, et d’éviter les allers-retours coûteux une fois le développement lancé.

Sur les projets que nous livrons de bout en bout, cette étape est intégrée. Elle peut aussi être menée seule, pour vos équipes ou pour un prestataire technique déjà en place.

Concrètement, cela veut dire que nous refusons de commencer par une planche graphique. Une maquette validée avant d’avoir tranché ce que l’utilisateur doit faire, dans quel ordre et avec quelle information, produit un écran séduisant qu’il faudra réécrire à la construction. C’est le scénario de dérive le plus fréquent, et il se paie deux fois.

Le design ne se sépare pas non plus de l’outil dans lequel il sera intégré : une maquette dessinée sans savoir ce que la plateforme sait faire génère des reprises. Nous avons détaillé ces contraintes dans nos comparatifs, notamment Framer ou Webflow et Webflow ou WordPress.

Ces trois mots sont souvent employés l’un pour l’autre, et c’est la source la plus fréquente de malentendus en projet. Ils ne servent ni au même moment ni au même interlocuteur.

Le wireframe sert à trancher, pas à plaire

Sans couleur, sans image, sans typographie choisie, il ne montre qu’une chose : ce qui est présent sur l’écran et dans quel ordre. C’est volontaire. Un wireframe gris empêche la discussion de glisser vers le goût, et force la seule question utile à ce stade : est-ce que l’utilisateur trouve ce qu’il cherche, et sait-il quoi faire ensuite ?

C’est l’étape la moins spectaculaire et la plus rentable. Déplacer un bloc dans un wireframe prend cinq minutes ; le déplacer après l’intégration prend une journée.

La maquette sert à décider de l’exécution

Elle fixe la typographie, les couleurs, les espacements, l’iconographie et le ton. Elle se valide écran par écran, et surtout dans ses états : un écran vide au premier usage, un écran plein de données, un écran en cours de chargement, un écran en erreur. Ces états sont ceux que l’utilisateur rencontre le plus souvent et ceux qu’on oublie le plus systématiquement de dessiner.

Le prototype sert à tester, pas à démontrer

Un prototype cliquable permet de mettre un vrai utilisateur devant un vrai enchaînement et de le regarder faire, sans rien construire. C’est le seul moyen honnête de savoir si un parcours tient, parce qu’une réunion de validation ne mesure jamais que la politesse des participants.

Nous le construisons court et ciblé, sur le parcours qui porte l’enjeu, plutôt que complet sur l’ensemble du produit. Un prototype exhaustif coûte le prix de la construction et sert moins.

Un design system n’est pas une charte graphique. Une charte décrit une identité ; un design system décrit des composants réutilisables, avec leurs règles d’emploi et leurs états.

Ce qu’il contient réellement

• Des fondations : échelle typographique, palette avec ses usages, grille d’espacement, rayons et ombres. Ce sont des décisions prises une fois, qui cessent ensuite de se rediscuter à chaque écran.
• Des composants : boutons, champs, cartes, tableaux, messages, chacun décliné dans ses états normal, survolé, actif, désactivé, en erreur.
• Des règles d’assemblage : comment ces composants se combinent, et surtout ce qu’on n’a pas le droit de faire avec.

Le gain, qui est un gain de temps et non d’esthétique

Sur un projet d’une dizaine d’écrans, il n’en vaut pas toujours la peine. À partir de vingt écrans, ou dès que plusieurs personnes conçoivent ou intègrent en parallèle, il devient l’élément qui empêche la dérive. Sans lui, chaque nouvel écran réinvente ses marges et ses boutons, et le produit devient hétérogène sans que personne ait pris de mauvaise décision.

Le second gain est moins visible et souvent plus important : il rend le produit modifiable par d’autres que ceux qui l’ont conçu. Un design system tenu est ce qui permet à votre équipe interne, ou à un prestataire suivant, de continuer sans repartir de zéro.

Ce qui le tue

Un design system meurt de deux façons. Trop tôt, quand on le construit avant de savoir de quoi le produit a besoin, et il devient un catalogue de composants inutilisés. Trop rigide, quand aucune exception n’est prévue, et les équipes finissent par le contourner en silence. Nous le livrons donc volontairement incomplet, avec une règle explicite pour les cas non couverts.

Ces deux sujets sont traités comme des contraintes subies, à régler en fin de parcours. Pris à l’envers, ils sont deux des meilleurs outils de conception disponibles.

Concevoir pour le petit écran d’abord

Un écran de téléphone ne laisse pas la place à ce qui n’est pas nécessaire. Concevoir dans cette contrainte oblige à hiérarchiser réellement, et la version large en sort meilleure parce qu’elle a été construite sur une hiérarchie assumée plutôt que sur l’espace disponible.

La démarche inverse, celle qui consiste à dessiner large puis à réduire, produit presque toujours des pages mobiles où tout a été empilé faute d’avoir su choisir. C’est visible immédiatement, et c’est aussi ce qui pèse sur la vitesse d’affichage, sujet que nous traitons en détail sur la page SEO et performance.

L’accessibilité, qui ne concerne pas une minorité

Les règles d’accessibilité se résument en pratique à quelques exigences que tout le monde gagne à respecter : un contraste suffisant, des zones cliquables assez grandes, des libellés explicites plutôt que des icônes seules, un parcours utilisable au clavier, et une taille de texte qui ne suppose pas une vue parfaite.

Un contraste insuffisant ne gêne pas qu’une personne malvoyante ; il gêne aussi la personne qui consulte votre site en plein soleil. Un libellé explicite ne sert pas qu’aux lecteurs d’écran ; il sert à tous ceux qui vont vite. C’est pour cette raison que nous le traitons comme une exigence de qualité générale et non comme une conformité à cocher.

Ce que nous vérifions avant de livrer

• Chaque écran existe en version étroite et en version large, pas seulement en version de présentation.
• Les états vides, en chargement et en erreur sont dessinés, parce qu’ils seront intégrés de toute façon, avec ou sans maquette.
• Les contrastes sont mesurés, pas estimés à l’œil.
• Les textes réels sont utilisés le plus tôt possible : un faux texte fait tenir une maquette qui ne tiendra pas avec le vrai contenu.

La majorité des projets de design ne partent pas d’une feuille blanche. Il existe déjà un site ou un outil, il fonctionne à peu près, et quelque chose ne va pas sans qu’on sache exactement quoi. La première erreur consiste à redessiner tout de suite.

Commencer par les données, pas par les avis

Un produit existant a un avantage énorme sur une feuille blanche : il a des utilisateurs, donc des traces. Avant de proposer quoi que ce soit, nous regardons où les gens arrivent, quel chemin ils prennent réellement, à quel écran ils s’arrêtent, et quels formulaires ils abandonnent en cours de route.

Ce que ces traces montrent contredit souvent l’intuition interne. Les pages jugées secondaires reçoivent parfois l’essentiel du trafic ; le bouton qu’on a longuement discuté n’est presque jamais cliqué ; et l’abandon se produit une étape avant celle que tout le monde soupçonnait. Redessiner sans ce préalable revient à corriger un problème supposé.

Regarder cinq personnes se servir de l’existant

Les chiffres disent où ça casse, ils ne disent pas pourquoi. Pour cela, il faut regarder des gens faire, sans les aider, en leur donnant une tâche réelle et en se taisant. Cinq personnes suffisent à faire ressortir l’essentiel des blocages, et la séance dure moins d’une heure chacune.

C’est l’exercice le plus inconfortable du métier, pour nous comme pour vous, parce qu’il montre en direct ce qu’on avait défendu en réunion. C’est aussi le seul qui mette tout le monde d’accord sans argumenter : quand trois personnes sur cinq ne trouvent pas le bouton, la discussion sur sa couleur devient sans objet.

Distinguer ce qui relève du design de ce qui n’en relève pas

Une partie des problèmes attribués au design n’en sont pas. Une page lente est perçue comme mal conçue, alors que le remède est technique et relève de la performance. Un formulaire trop long est parfois long parce qu’un outil de gestion en aval exige ces champs, et la vraie solution passe par l’intégration au CRM plutôt que par la maquette. Un contenu confus reste confus quelle que soit la mise en page.

Nous trions donc explicitement, et nous le disons quand le problème principal n’est pas le nôtre. Vendre une refonte graphique pour régler un problème de vitesse serait facile et malhonnête.

Refondre par étapes plutôt que d’un bloc

Une refonte totale mise en ligne d’un seul coup a un défaut structurel : si les indicateurs baissent, on ne sait pas laquelle des cinquante modifications en est la cause. Quand l’existant reçoit du trafic, nous préférons donc avancer par lots, en commençant par les écrans qui portent l’enjeu, et en mesurant entre chaque.

C’est plus lent en apparence et plus rapide en réalité, parce que chaque lot informe le suivant. Cela évite aussi la situation la plus pénible d’un projet de refonte : devoir défendre un nouveau site dont on ne peut pas prouver qu’il fait mieux que l’ancien.

Ce que nous livrons à l’issue de cette phase

• Une liste de problèmes constatés, classés par ce qu’ils coûtent et non par leur visibilité.
• Pour chacun, la nature du remède : conception, contenu, technique ou organisation.
• Un ordre de traitement, avec ce qu’on fait maintenant et ce qu’on repousse volontairement.

Un devis de conception se compare mal, parce que le mot « maquettes » recouvre des périmètres très différents. Voici notre découpage.

Ce qui est toujours compris

• Les ateliers de cadrage, qui produisent les arbitrages structurants avant le premier écran.
• L’arborescence et les wireframes, c’est-à-dire les décisions qui coûtent cher à changer plus tard.
• Les maquettes des gabarits, dans leurs états, et le prototype cliquable du parcours principal.
• Les fichiers sources, qui vous appartiennent, et la documentation nécessaire à un intégrateur.

Ce qui se chiffre à part, et pourquoi

La rédaction des contenus, parce qu’elle dépend de qui l’assume et qu’elle est presque toujours le chemin critique du projet. La photographie et l’illustration sur mesure, parce qu’une séance sur site n’a rien à voir avec une banque d’images. Les tests utilisateurs modérés, parce qu’ils supposent du recrutement et un temps d’analyse qui n’a pas de rapport avec le nombre d’écrans.

Le nombre de gabarits, qui est la vraie variable

Ce n’est pas le nombre de pages qui fait le prix, c’est le nombre de modèles différents. Trente pages construites sur cinq gabarits coûtent moins cher que huit pages toutes différentes. C’est la première question que nous posons au chiffrage, et c’est aussi le levier le plus simple pour ajuster un budget sans dégrader le résultat.