J’ai commencé le design d’interfaces au début des années 2000, une époque où Adobe était roi dans le monde de la création graphique. La stack du webdesigner à ce moment là : Dreamweaver, Flash, Photoshop et Fireworks.

Puis le temps a passé, l’iPhone a bouleversé notre pratique en imposant le responsive, le touch et le rétina. Adieu Photoshop, Sketch est une application dédiée au design d’interface. Une révolution. Mais Sketch était aussi assez peu réactif sur ses évolutions, laissant les designers avec un outil frustrant avec des promesses folles, mais des fonctionnalités manquantes. Et c’est là que Figma entre en scène. Une app multi-plateforme, elle aussi pensée pour le designer d’interface, mais cette fois-ci plus moderne. Le Design ne se fait plus seul mais en “multi-joueurs”, et surtout il devient systémique avec la possibilité de créer des composants réutilisables. Je ne vous cache pas non plus que la vélocité de l’équipe à mettre à jour l’outil ne faisait que rassurer sur son avenir.

Mais l’argent a fini selon moi par détruire l’essence même de l’outil. Et je ne peux que le comprendre quand on parle de milliards. La descente aux enfers a commencé avec la promesse d’achat d’Adobe, finalement avortée par la SEC. Au passage Figma y a gagné $1 milliard pour rupture, mais surtout la disparition d’XD par Adobe lui-même, convaincu que Figma deviendrait leur outil pour les Designers. De mon point de vue c’est malheureusement à ce moment là que Figma a perdu de sa splendeur. Des mises à jour lentes, des bugs de plus en plus nombreux, des features jamais terminées (les tokens, l’auto-layout, les grids, …). Et puis surtout un changement de cible. Depuis quelques années Figma ne lance plus vraiment de features pour le Design d’interface mais surtout pour les marketeux et communicants.

On a eu quand même quelques tentatives autour de l’IA avec une première version de génération via un modèle maison entrainé à partir des fichiers de la communauté et qui a mené à des problèmes de copyright et surtout d’uniformité de ce qui a été produit, puis maintenant avec Figma Make qui tend à vouloir rapprocher les designers du code, en vain, c’est difficile, parce que pas prévu pour ce besoin.

Une limitation technique

Le problème est que Figma a atteint un plafond de verre : sa structure technique. Figma vient d’annoncer une intégration Claude + Figma permettant de passer de Claude vers Figma, puis Figma vers Claude. On peut donc se projeter dans un workflow où l’on peut reprendre un écran en prod, le basculer dans Figma, l’éditer avec une interface WYSIWYG, puis retourner dans Claude pour l’intégrer et le repousser en prod. C’est une belle promesse, j’aime beaucoup l’idée, ce serait même le mariage rêvé. Mais ça ne restera à date qu’un effet de communication qui ne peut pas fonctionner pour les raisons suivantes :

• Figma réinvente le web car développé via le Canvas HTML, et donc en javascript. Pas de Document Object Model (DOM), donc de faite ça devient un simulateur qui tente de reproduire du natif. Si vous voulez un écran Web dans Figma alors il va falloir le convertir entièrement. Une excellent stratégie initiale mais qui trouve ses limites.

• Parce que reproduire du natif ça prend du temps, mais surtout ça finit par poser des problèmes de performance et de cohérence DOM / JS. On se retrouve donc avec un bel élan, qui finit par s’essouffler. Des features commencées mais non terminées.

• Figma ne gère ses espacements que par le padding et le gap. Les marges sont complètement absentes. Pourtant indispensables d’un point de vue (eco-)conception : le padding oblige à créer un parent pour porter un espacement alors que dans certains cas l’enfant pourrait le faire tout seul avec du margin. Et puis même tout simplement fonctionnellement : on peut vouloir que l’enfant impose une marge à son parent sans que le parent n’en ait connaissance.

• Figma n’offre que peu d’unités de valeurs : le px et le %. Là où le web est très riche (em, rem, ex, ch, ic, cap, lh, rlh, vw, vh, vi, vb, vmin, vmax, svw, svh, svi, svb, svmin, svmax, lvw, lvh, lvi, lvb, lvmin, lvmax, dvw, dvh, dvi, dvb, dvmin, dvmax, cm, mm, Q, in, pt, pc, fr, deg, grad, rad, turn, s, ms, Hz, kHz, dpi, dpcm, dppx, …). Évidemment vous n’allez pas toutes les utiliser, j’ai demandé à ChatGPT de me générer cette liste, mais elles font partie des possibilités qui apportent plus de créativité et surtout des façons plus modernes de concevoir des interfaces (rem, vh, ch, …)

• Figma ne permet pas nativement de reproduire des comportements responsive. Hors en 2025 on ne conçoit plus une interface pour une taille d’écran, mais pour un ensemble de devices ou d’usages.

• Figma permet le dark / light via des modes, pas en natif. Là aussi ça devient problématique car ça touche à la structure même des tokens et à l’interprétation par le navigateur.

La limitation est donc liée à l’outil en lui-même qui devrait, pour que ça fonctionne vraiment, être complètement redéveloppé avec une autre Stack (idéalement basée sur le DOM) pour imaginer pouvoir utiliser Claude avec Figma avec des aller-retours possibles entre l’IA et la conception visuelle. Presque improbable, ou en tous cas pas pour tout de suite.

Quelles contraintes ?

La tendance vise plutôt à s’échapper de Figma ou autre outil de conception similaire, quitte à développer des outils maison en attendant qu’un nouveau challenger réponde au besoin actuel. Les contraintes sont multiples mais l’IA devient tellement pertinente que l’on est assez proche du but. Le limitations actuelles que j’ai identifié pour le moment :

• L’IA a du mal à comprendre ce qu’elle peut ou ne peut pas faire. D’abord d’un point de vue Design System, si dans l’inspecteur Cursor je pointe un élément dans une page et que je lui demande de changer par exemple la font-size, je vais devoir penser à faire un prompt précis qui lui indique de faire ce changement au niveau du composant, et non via une surcouche au niveau de l’écran. C’est très fastidieux et coûteux en token & charge mentale pour un changement aussi simple.

• L’IA perd vite du contexte. Vous en aurez déjà certainement fait l’expérience mais d’un écran à l’autre, l’IA va avoir tendance à dévier de la logique globale au lieu de réutiliser des éléments déjà présents ailleurs.

• Concevoir en donnant des consignes est moins intuitif que de pouvoir dessiner dans l’outil pour exprimer ce que l’intention et surtout itérer.

• L’éco-conception ? Elle commence par un usage responsable de nos outils de conception avant de toucher directement l’utilisateur. Et on le sait, l’IA consomme beaucoup (beaucoup …). Il faut donc aller chercher l’économie de tokens à tout prix, en évitant les aller-retour entre les outils.

Quelles solutions ?

Je me dis que si il y a bien un moment où Adobe pourrait renaitre de ses cendres et prendre sa revanche c’est bien maintenant, grâce à l’IA, en faisant de Dreamweaver l’outil rêvé des Designers. Car oui, à ma grande surprise, Dreamweaver existe toujours en 2025. J’avoue ne pas y avoir mis les pieds depuis les années 2000, mais de mon souvenir il cochait pas mal de cases :

• WYSIWYG : J’édite du HTML de façon visuelle.

• J’ai accès au code source. Il est chez moi, en local, ou sur un serveur distant. Au choix.

• Il utilise le natif et les standards. On peut l’utiliser aussi avec n’importe quel framework.

Je le disais aussi juste avant, j’observe déjà autour de moi depuis bientôt 1 an des solutions sur mesure qui émergent chez des acteurs où l’industrialisation du Design leur fait économiser des millions, notamment, disons le clairement, en réduisant de la ressource (designers, développeurs, …). Ça n’est d’ailleurs pas pour rien que le marché se tend pour les juniors ou Designers restés sur leurs acquis : l’IA va vite et ce que l’on va désormais chercher ce sont des Designers en capacité de juger si ce qu’elle produit est correcte.

Une consigne simple et qui se fait entendre un peu partout : Designer sans Figma (Attention, je dis Figma parce qu’ils ont le monopole, mais c’est valable évidemment pour l’ensemble de leurs concurrents). Ça mène les entreprises à repenser leurs workflows de conception, leur façon de faire. Il ne s’agit plus d’un outil unique mais d’un ensemble de compétences où le Designer devient l’orchestrateur, responsable de la gouvernance sur l’IA. Des outils plus techniques qui poussent le designer à revenir à l’essence même de son métier : comprendre les besoins de ses utilisateurs et y apporter une solution.

Je suis très excité par ce bouleversement, je l’attends depuis quelques années, dépité de voir de plus en plus de designers enfermés dans leur outil, oubliant pour beaucoup que le code est source de vérité et que la conception commence par un papier et un crayon, pas par le choix des couleurs ou d’une typo.

Et vous, l’IA a-t-elle déjà changé votre workflow ?

Je ne vous lance pas la pierre, j’ai pu être tenté de le faire par le passé. Sauf que lorsque l’on travaille sur un Design System, chaque choix doit suivre une logique, certaines convictions sont remises en question, les standards et référentiels font foi, et après de nombreuses recherches, j’ai réalisé que je me trompais.

Un champ peut être désactivé, il n’y a aucun doute, mais qu’en est-il de son label ?

À cette question, on me répond souvent : « Mais Hugo, puisque l’utilisateur ne peut rien faire avec le champ, alors son label n’a pas besoin d’être lu, et d’un point de vue UX ça lui permet d’identifier les champs qui sont justement désactivés ».

C’est vrai que ça part d’une bonne intention et que la réflexion n’est pas mauvaise, mais c’est une erreur. Je ne vais pas vous donner mon avis subjectif sur la question, nous allons plutôt regarder ce qu’en dit le RGAA et le WHATWG.

Problème d’accessibilité

Depuis mon passage chez EDF, notamment aux côtés de Vincent PERRIER-PERRERY, il m’est impossible de concevoir la moindre interface sans chercher à être 100% raccord avec le RGAA. C’est une obligation légale pour certains de mes clients, en réalité ça devrait être une obligation morale pour tout designer.

Au delà de permettre la création d’interfaces inclusives, les règles d’accessibilité nous aident aussi à savoir ce que l’on peut (doit ?) faire ou non. Regardons le RGAA :

• Critère 3.2 : « Dans chaque page web, le contraste entre la couleur du texte et la couleur de son arrière-plan est-il suffisamment élevé (hors cas particuliers) ? ».
  Dans les cas particuliers on retrouve : « Le texte ou l’image de texte fait partie d’un élément d’interface sur lequel aucune action n’est possible (par exemple un bouton avec l’attribut disabled). ».

• Critère 3.3 : « Dans chaque page web, les couleurs utilisées dans les composants d’interface ou les éléments graphiques porteurs d’informations sont-elles suffisamment contrastées (hors cas particuliers) ? ».
  Ici aussi, dans les cas particuliers : « Composant d’interface inactif (par exemple, un bouton avec un attribut disabled) sur lequel aucune action n’est possible ».

Ces critères ne s’appliquent donc pas à un composant d’interface comme un champ de formulaire qui peut être « disabled », ils font exception. Et c’est vrai qu’en toute logique on pourrait se dire : « Un label accompagne un champ, et ce champ est désactivé, alors le label l’est aussi, il ne répond pas lui non plus à ces critères ».

Et que dit le RGAA au sujet du label ? Rien du tout. Et ça n’est pas un oubli, un label n’est pas un composant d’interface, il ne permet pas à l’utilisateur de communiquer avec la machine. C’est une étiquette, un texte, il est donc traité comme tel et on se doit de respecter les règles d’accessibilité et de contraste comme tout autre label ou simple texte, il ne fait pas exception.

Un label HTML n’a pas d’attribut « disabled »

Et quand bien même il y aurait un doute sur le référentiel d’accessibilité ou que vous ne voudriez simplement pas le suivre, on peut aussi regarder du côté du WHATWG (Web Hypertexte Application Working Group) quels sont les attributs de l’élément <label>.

Documentation WHATWG du label, dans les attributs on retrouve :

• Global attributes -> Comprenez tous les attributs que l’on retrouve par défaut sur chaque élément HTML (title, style, …)

• for -> Associe le label à un contrôle de formulaire.

• Et c’est tout ! Pas de « disabled » comme sur un contrôle.

Serait-ce un oubli du WHATWG ? Le meilleur Design System que vous trouverez et dont vous devez vous inspirer est celui du web natif (HTML & CSS). Il est incroyablement bien pensé et documenté. Chaque élément répond à une logique précise. Et même si vous faites du mobile natif, le référentiel du web reste votre meilleur guide sur les bonnes pratiques à suivre. Un label n’est pas désactivé, c’est le champ auquel il est rattaché qui l’est.

Et l’UX ?

Reste la question de l’UX, c’est vrai. On pourrait se dire que ces référentiels se trompent, qu’ils n’ont pas assez pensé à l’utilisateur qui aimerait identifier dans son formulaire les éléments désactivés. Que si le label d’un champ désactivé est affiché comme les autres alors il sera difficile pour lui de s’y retrouver.

Un champ désactivé EST une information pour votre utilisateur. Sinon il ne serait simplement pas affiché. Votre utilisateur doit donc quoi qu’il arrive pouvoir lire le label qui l’accompagne. Inutile de chercher à réinventer la roue, il n’y a aucun besoin réel à vouloir le rendre moins visible, seulement de mauvaises inspirations.

C’est aussi quelque chose que je vois fréquemment : Les designers s’inspirent beaucoup du travail des autres, et encore plus quand il s’agit de belles références. Gardez l’esprit critique, ne suivez pas toujours la masse, et servez-vous des référentiels comme argument pour ne pas faire leurs erreurs et vous démarquer.

Ce que vous pouvez faire

Si malgré tout cela votre souhait serait de pouvoir rendre différenciants ces labels dans vos formulaire tout en respectant les référentiels et standards, vous avez toujours ces possibilités :

• Utiliser un contraste légèrement plus clair, mais qui respecte bien le minimum de ratio 4.5:1 entre le label et son fond. Pour l’avoir expérimenté, ça fonctionne bien sur les labels qui accompagnent une Checkbox ou un Radio Button dans un groupe. C’est léger et tous les utilisateurs ne verront pas ce détail, mais pour d’autres ça peut améliorer leur perception de ces éléments désactivés.

• L’italic pourrait aussi aider. Je n’irais pas le conseiller, je préfère le garder pour les placeholders car ça aide à les différencier de la valeur d’un champ, mais ça reste une option qui respecte les référentiels.

Il n’y a donc plus de doute à avoir désormais quand vous concevrez vos champs de formulaire : chaque label doit rester accessible, en toute situation. Amusez-vous si vous le souhaitez avec leur style je ne saurais dire si c’est réellement une bonne idée, mais veillez à ce que ceux-ci suivent les règles d’accessibilité et les standards pour une meilleure inclusivité et moins de travail pour vos devs.

Si ce post vous a plu, n’oubliez pas de laisser un like et un petit commentaire, ça aidera à lui donner de la visibilité et je suis curieux que vous me partagiez votre expérience à ce sujet !

Ce « pourquoi ? » me permet de m’assurer que je n’ai pas fait les choses uniquement parce que ça me plaisait de les faire comme ça ou par habitude, mais de pouvoir les expliquer, les justifier. Répondre à cette question m’assure de ne pas avoir à faire autrement, peu importe les critiques. Si un « pourquoi ? » n’est pas répondu, alors je dois me remettre en question, prendre du recul, pivoter si nécessaire, jusqu’à y répondre. Je pose cette même question aux personnes avec qui je travaille dès que je sens une impasse, une difficulté à justifier un choix, ou que je n'en comprends pas le but, et ça fonctionne à chaque fois.

Débloquer une voie sans issue

Ce « pourquoi ? » me permet aussi de faire réaliser à mon interlocuteur qu’il s’est peut être trompé. Dire à quelqu’un « tu as tort » vous placera au dessus de lui et sera très certainement mal interprété, menant à une confrontation de points de vue plutôt qu’à avancer dans une direction constructive. Alors que si vous lui faites réaliser par lui même par ce simple mot qu’il part dans la mauvaise direction, votre échange va évoluer et vous allez être désormais deux à essayer de répondre à cette question.

C’est d’ailleurs assez amusant cette petite étincelle qui se créé dès que vous ou votre interlocuteur réalisez que le « pourquoi ? » n’est pas répondu et qu’il suffirait de lui trouver une réponse pour donner du sens à ce que vous faites. Pour savoir si vous deviez même le faire.

Car le « pourquoi ? » peut aussi mener à une non-réponse. Si vous ne savez pas y répondre, alors c’est qu’il ne faut très certainement pas le faire. Il restera votre instinct pour justifier votre choix, mais il aura peu de poids et sera vite facilement déstabilisé. Cette non-réponse peut être très bénéfique d’ailleurs. On a tendance à écouter trop rapidement les demandes de nouvelles fonctionnalités et à vouloir s’empresser de les ajouter car elles nous semblent aussi faire sens. Mais dès que vient la remise en contexte, et la recherche de sens à ce qui doit être fait, on réalise parfois qu’en réalité le besoin imaginé n’est en réalité pas le bon. Il manque quelque chose, on le sait, on le sent, mais on ne sait pas encore quoi. Et le « pourquoi ? » aura permis de mettre en évidence précisément que l’on doit encore chercher, creuser, comprendre ce qui ne va pas, pour enfin exprimer un besoin clair et tangible.

Le webdesign, une exception

Il y a néanmoins une exception à cette règle. Je vous en parlais plus haut : la création artistique. Elle est aussi présente dans le Design d’interfaces, notamment au travers d’un métier presque disparu : celui de Webdesigner. C’est un débat que j’ai régulièrement avec mes collègues Designers : qu’est-ce que le webdesign ? N'est-ce pas l'ancien mot pour désigner l'UX / UI ? (Non !) J’ai commencé ma carrière il y a plus de 20 ans. À l’époque on ne parlait pas d’UX, d’UI, de règles, c’était l’aventure. Le terrain était vierge, il y avait tout à inventer, on était des webdesigners. Puis le métier s’est structuré, l’expérience utilisateur avec. L’originalité a fait place à l’efficacité. Il fallait faire des sites qui convertissent, des interfaces qui fonctionnent sans mode d’emploi. Mais ça a aussi mené à une uniformisation ennuyeuse de nos sites et interfaces. Tout se ressemble, on suit les mêmes règles, et ceux qui en sortent sont peu nombreux, ou le font timidement.

Avec la bascule vers plus de structuration, les métiers d’UX et UI Designers sont apparus, faisant disparaître petit à petit celui de « webdesigner », vécu aujourd’hui comme un terme réducteur pour beaucoup, de boomer. Et je trouve cela dommage car il ne l’est pas. Le webdesign c’est justement fait fi de contraintes et ne pas avoir vraiment à répondre à tous les « pourquoi ? ». C’est sortir du cadre, proposer une expérience différente, qui sera généralement justifiée par un goût artistique de son auteur. Je regrette de ne pas voir ce métier plus assumé ni plus recherché. On retrouve néanmoins cette mentalité dès que de nouveaux usages sont à explorer. Avec la réalité augmentée / virtuelle, avec l’IA. On se cherche, on explore. Et on se rend compte que petit à petit la masse suit ce qui fonctionne mais qu’il y a quand même cette phase sans règles et où le « pourquoi ? » n’a pas encore de sens et ce n’est pas grave, il n’en a pas besoin.

Le « quoi », réponse au « pourquoi »

Une fois que le « pourquoi » est répondu il vous reste à trouver le « quoi », la solution. Quoi faire. Quoi choisir. Et ce quoi va se construire petit à petit à force d’aller questionner les options qui s'offrent à vous. C'est une pensée en arborescence qui va se mettre en place. Quoi -> Pourquoi -> Quoi -> Pourquoi, jusqu'à ne plus avoir de question sans réponse.

Designer : J'aimerais une snackbar qui ne disparait pas automatiquement.
Moi : Pourquoi ?
Designer : Parce que je souhaite afficher une information que mes utilisateurs ne doivent pas louper, et c'est à eux de la masquer
Moi : Ok, mais la snackbar est un élément temporaire, il ne peut pas porter d'information critique. Dans ce cas pars plutôt sur un toast.
Designer : Super, c'est exactement ce que je cherche, mais je vois qu'il n'a pas de couleur. Je voudrais qu'il soit rouge.
Moi : Pourquoi ?
...

Ceci est un exemple d'échange que j'ai fréquemment en tant que Lead Design System avec des Designers qui utilisent nos composants (évidemment j'y mets plus de forme, j'ai exagéré pour la démo). Si j'écoutais simplement les besoins de mes utilisateurs sans les questionner, je finirais par faire des choses que je ne saurais pas expliquer, et donc pas documenter ou justifier. Le fait d'avoir constamment cet arbre de décision "quoi -> pourquoi ?" permet de faire les bons choix, de sortir du piège de la solution comme seule expression de besoin et surtout qu'ils soient compris et acceptés. C'est un outil très puissant qui s'utilise en toutes circonstance. Pour vous-même, avec vos collègues, vos clients, vos prospects, ... N'hésitez pas à demander pourquoi !

D'ailleurs, pourquoi avez-vous trouvé ce billet intéressant ? :)

Laissez un commentaire.

Hugo, un blog ? En 2025 ?

C'est la réaction de ma femme quand je lui ai dit que je lançais un nouveau blog. Je me suis évidemment posé la question : pourquoi ? J'aurais pu continuer à faire des posts LinkedIn au milieu de la masse d'experts en tous genres et chercher à flatter l'algo pour les rendre visibles, mais je n'y trouve pas d'intérêt. La visibilité, évidemment, est importante, et je vais continuer d'utiliser les réseaux. Ils nous permettent de rester connectés les uns aux autres, de discuter, de partager.

Mais je trouve ça oppressant. J'ai envie de liberté, d'avoir mon propre espace, celui avec mes codes et pas ceux d'un réseau social. Parce que c'était ça les blogs, avant les réseaux sociaux. Des espaces réellement personnels, à l'image de leurs propriétaires. Un regroupement de leurs pensées, du partage sans filtre, ou du moins celui que l'on se fixe.

Mes premiers blogs étaient très thématiques et très tech. Sur la réalité augmentée, sur l'iPad à sa sortie, j'ai aussi participé à certains plus importants comme AccessOWeb de Philippe Lagane à l’époque. Les blogs c'était le début de l'influence et des influenceurs avant Instagram ou LinkedIn. Ça nous donnait accès à des soirées privées, des lancements de produits, et c'était un petit monde où tout le monde se connaissait. C’était génial, et ça me manque.

Oui, je sais, on est en 2025 et maintenant on parle de “Newsletter”. Mais c’est du marketing. En réalité il s’agit toujours de blogs, qu’à l’époque on pouvait aussi recevoir par email. Et puis j’ai envie de l’appeler “blog” pour me rappeler que ça doit rester un espace personnel sur lequel je vous partagerais mon expérience, ma passion pour la création, mes expérimentations techniques, mes pensées actuelles mais aussi mes coups de gueule.

J’espère que vous prendrez plaisir à me lire autant que je vais prendre plaisir à écrire et que mes billets seront l’occasion de discuter ensemble des sujets qui m’animent.

Vous pouvez dès maintenant laisser votre email pour recevoir mes posts et partager cette nouvelle autour de vous.

À très vite ici !

—
Hugo