Arrêtez de designer dans Figma

Votre fichier Figma est la photo statique d'un produit qui n'existe pas. Le temps que l'ingénieur le livre, il est déjà faux. Les polices s'affichent différemment, les breakpoints que vous avez ignorés refont surface, l'état vide que vous avez oublié apparaît, et le hover que vous aviez griffonné en commentaire est interprété par quelqu'un qui n'est pas vous. La solution n'est pas de meilleurs plugins Figma. La solution est d'arrêter d'utiliser Figma comme outil de design et de commencer à utiliser la codebase.

Ceci n'est pas un règlement de comptes avec Figma. Figma gagne encore pour le travail sur les systèmes, l'exploration de marque et les diagrammes FigJam. La thèse est plus étroite et plus dure. En 2026, le design produit se fait dans le code. v0, Cursor, Lovable et le registre Vercel UI ont remplacé l'artboard comme lieu où les surfaces sont réellement designées. Les designers qui livrent encore des frames Figma pixel-perfect pour que les ingénieurs les « implémentent » font deux métiers à moitié vitesse.

Ce qui a vraiment changé

Figma a été conçu pour une époque où la production était le goulot d'étranglement. En 2018, générer un composant React fonctionnel prenait trois jours à un ingénieur, et un designer pouvait sortir vingt frames hi-fi dans le même laps de temps. Livrer des artboards à plat comme livrable était le choix rationnel. L'artboard était la partie la plus rapide de la chaîne.

Ce calcul s'est inversé en 2026. v0 transforme une phrase en composant fonctionnel en trente secondes. Cursor édite un vrai repo avec un vrai diff. Lovable monte une app déployable à partir d'un seul prompt. L'artboard est désormais la partie la plus lente de la chaîne, pas la plus rapide, et l'écart se creuse chaque trimestre. Le démontage plus profond du changement au niveau de l'artefact est dans la mort de la maquette. Cet article parle de l'outil qui produit l'artefact.

La frame à plat n'est pas devenue moins bonne. L'établi, lui, s'est amélioré.

Là où Figma mérite encore sa place

Soyons honnêtes. Figma est excellent pour quatre tâches, et prétendre le contraire ferait rejeter le reste de l'argumentation.

Figma gagne encore pour l'exploration d'identité de marque, là où vivent logos, études typographiques et systèmes de couleurs avant qu'une codebase existe. Il gagne pour les inventaires de design system, ce fichier unique qui liste chaque token, variante et état avec un modèle multijoueur qu'aucun autre outil ne reproduit. Il gagne pour les diagrammes FigJam et l'alignement d'équipe, le whiteboarding et la cartographie de parcours où la surface est la conversation. Et il gagne encore pour le designer qui ne sait vraiment pas lire du code, un profil plus rare en 2026 que ce que l'industrie prétend, mais toujours réel.

Tout le reste, chaque surface produit livrée à un vrai utilisateur, appartient au code.

Les cinq différences

Designer dans Figma et designer dans le code ne sont pas le même travail à des vitesses différentes. Ce sont des métiers différents.

Fidélité. Une frame Figma approxime la typo, ignore le hover, simule le scroll et affiche des polices que le navigateur ne chargera pas de la même façon. Une surface en code utilise la vraie police, le vrai composant bouton, le vrai breakpoint, le vrai focus ring. L'écart entre approximation et réalité était autrefois acceptable. Dans un produit où les états de chargement, vide et de contenu long représentent la moitié du design, il ne l'est plus.

Vitesse. La boucle Figma : éditer la frame, commenter à l'ingénieur, attendre, relire le build, recommenter, attendre encore. La boucle code : éditer, recharger, voir. La première se mesure en jours, la seconde en secondes. La vitesse d'itération décide du nombre d'idées que l'équipe peut tester avant le lancement.

Modèle de collaboration. Les commentaires Figma et les commentaires de PR sont des surfaces différentes. Les commentaires Figma vont du designer vers les parties prenantes, ou du designer vers l'ingénieur comme spec. Les commentaires de PR mettent designer et ingénieur sur un pied d'égalité autour d'un seul artefact. Le second modèle est celui des équipes de design engineering, et il est structurellement plus rapide.

Le handoff disparaît. Le handoff est le moment le plus coûteux de la chaîne traditionnelle. Designer dans le code le supprime. Il n'y a pas d'étape de traduction, car le design est l'implémentation.

Les cas limites se révèlent immédiatement. Vide, chargement, contenu long, mobile, erreur, réseau lent. Dans Figma, ils existent si le designer a pensé à les dessiner. Dans le code, ils existent que le designer y ait pensé ou non, car le composant doit les gérer pour s'afficher. Le code force l'honnêteté.

v0, Cursor, Lovable et Vercel UI sont la nouvelle surface de design

Le nouvel environnement de design n'est pas un outil, c'est une pile qui atteint sa masse critique d'un coup. Chacun de ces outils prend en charge une couche de ce que Figma faisait seul.

v0 de Vercel transforme un prompt en composant React et Tailwind fonctionnel en environ trente secondes. Forkez le résultat, itérez par prompt ou à la main, livrez-le dans la codebase. Le modèle fork-et-itère remplace le dupliquer-et-ajuster de Figma, sauf que le duplicata est du vrai code.

Cursor est la surface de design des product designers qui savent lire du code. Ouvrez le vrai repo, voyez le vrai rendu, éditez un composant par prompt ou à la main, et regardez le changement dans le navigateur dans la minute.

Lovable est la surface des fondateurs et des designers solo. Un prompt, une app web fonctionnelle, puis on itère sur la chose qui tourne. Le chemin le plus rapide de l'intention à une URL en ligne, sans fichier Figma.

Vercel UI et le registre shadcn sont l'étagère de composants. Récupérez un vrai composant, personnalisez-le dans la codebase, livrez-le. shadcn livre les composants comme du code que vous possédez, ce qui signifie que le design system s'édite sur la même surface que le design.

Les outils diffèrent par la forme, mais partagent la même idée. La surface en fonctionnement est l'artefact. L'artboard est un brouillon, s'il existe seulement. Pour le pattern plus approfondi côté praticien, voyez le vibe coding pour designers et Claude Code pour designers.

Comment Linear, Stripe et Anthropic fonctionnent vraiment

Les équipes qui livrent la meilleure UI produit en 2026 partagent la même forme de workflow, et aucune ne livre Figma comme livrable final.

Linear traite la codebase comme source de vérité. Son équipe de design engineering livre les designs sous forme de pull requests sur l'app en production, pas sous forme de frames Figma. Le design system de Stripe est construit et livré depuis le code. Figma existe comme documentation en aval du code, pas comme source en amont. Éditer le système, c'est éditer le code. Anthropic designe les surfaces produit de Claude en ligne, dans des composants React et des artifacts Claude, avec des designers qui lisent et éditent l'app réelle à chaque release.

Le pattern se répète dans chaque équipe produit qui livre à vitesse premium. Tokens en amont, code comme canevas, IA comme couche de production, designers dans le diff. Le pipeline de frames à plat n'est la façon de travailler d'aucune d'entre elles, et le calcul a fini par rattraper le reste de l'industrie.

Cinq questions à se poser avant de designer dans le code

Tous les designers ne devraient pas abandonner Figma demain. Le test honnête tient en cinq questions. Si trois réponses ou plus sont oui, designer dans le code est la bonne surface pour votre prochain projet.

1. Livrez-vous le travail, ou le passez-vous à quelqu'un d'autre ? Si vous livrez, le code gagne. Si vous passez le relais, le code gagne encore, mais le choc culturel est plus grand.
2. Savez-vous lire la codebase ? Pas écrire du React de production de zéro, juste lire des composants, comprendre les props, reconnaître un design token et modifier des valeurs sans casser le build.
3. Le design est-il une spec statique ou une surface interactive ? Une spec appartient à Figma. Une surface avec hover, focus, scroll, motion et états limites appartient au code.
4. L'équipe a-t-elle un design system à étendre ? Une vraie bibliothèque de composants, même une base shadcn, rend le design code-first deux ordres de grandeur plus rapide que Figma.
5. La vitesse d'itération est-elle votre goulot d'étranglement ? Si vous perdez des sprints dans le cycle de handoff, le code-first tue le goulot. Si vous perdez des sprints à cause de la stratégie de marque, le code-first ne fait rien. Résolvez le bon problème.

Une équipe qui coche quatre sur cinq vit dans le code. Une équipe qui en coche deux sur cinq devrait quand même partager le travail entre Figma et le code, avec un biais légèrement favorable au code sur chaque nouveau projet.

Les anti-patterns à abandonner

Quatre patterns tuent plus d'UI de produit livré que n'importe quel choix d'outil. Si une équipe en pratique un seul, le changement d'outil compte moins que le changement de workflow.

Le fantasme du Dev Mode comme handoff. Le designer livre un fichier Figma couvert de lignes rouges. L'ingénieur « utilise le Dev Mode » pour traduire. Tous deux font semblant que la traduction est fidèle. Elle ne l'est jamais. Le Dev Mode est utile, mais c'est le même fantasme de handoff dans un nouvel emballage. La vraie solution est que l'ingénieur et le designer éditent le même artefact, ce que permettent les surfaces en code. Pour la couche de connexion, voyez le guide Figma MCP.

La maquette pixel-perfect qui ignore les vraies polices et breakpoints. Une frame à 1440px avec du Lorem Ipsum et une police que l'app de production ne charge pas. La maquette a l'air pixel-perfect, le produit livré n'y ressemble en rien, et tout le monde a validé le mensonge.

Le design system qui vit dans Figma et diverge silencieusement du code. La bibliothèque Figma dit que le bouton a 12px de padding. Le code dit 14px. Personne n'a mis à jour l'un ou l'autre. Au bout de six mois, le fichier Figma est une fiction. Une seule source de vérité, dans le code, avec Figma comme rendu en aval.

La refonte de six mois qui est livrée en PDF. Une refonte phare délivrée sous forme d'export Figma de cent pages, présentée au comité de direction, transmise à l'ingénierie pour la « phase deux ». La phase deux n'a jamais lieu, parce que le temps que l'ingénierie chiffre la reconstruction, l'entreprise a changé deux fois de stratégie. La refonte qui n'est pas livrée n'a jamais existé.

L'audit du design code-first

Avant le lancement du prochain projet, faites l'audit. Sept questions, dix minutes, des réponses tranchées.

1. Quel est le livrable, une frame ou une surface livrée ? Si c'est livré, le livrable est du code. Arrêtez de prétendre que la frame est le produit.
2. Qui possède l'app en production, et le designer est-il dans le diff ? S'il n'y est pas, réglez ça avant de changer d'outil.
3. Où vivent les tokens ? Si la réponse est Figma, déplacez-les. Le fichier de tokens doit être la source de vérité que Figma lit, pas l'inverse. Le décryptage du workflow de design IA couvre le chemin de migration.
4. Quel est le cycle d'itération, en heures ? S'il faut plus de quatre heures entre l'édition et le changement livré, le problème est le workflow, pas le design.
5. Quelles surfaces sont encore designées en artboards à plat, et lesquelles sont passées au code ? Cartographiez la répartition. Elle devrait pencher vers le code pour chaque nouvelle initiative.
6. Sur quels plugins l'équipe s'appuie-t-elle pour simuler la fidélité du handoff ? Si la réponse est « beaucoup », voyez les plugins Figma qui valent le coup et coupez le reste.
7. Que livre l'équipe le trimestre prochain qui prouve que le workflow fonctionne ? Pas une slide, une surface déployée. Si la réponse est floue, le workflow n'a pas encore vraiment changé.

Un workflow qui survit à l'audit livre du produit. Un workflow qui échoue à l'audit livre des decks. La différence se cumule chaque trimestre, et la vitesse est la marque quand toutes les autres variables sont à peu près égales.

FAQ

Figma est-il mort ?

Non. Figma n'est pas mort, et la thèse n'est pas « Figma est mort ». Figma est excellent pour le travail d'identité de marque, les inventaires de design system, les diagrammes FigJam et les présentations aux parties prenantes. La thèse est plus étroite. Figma n'est plus l'endroit où se fait le design produit, parce que la codebase est plus rapide, plus fidèle, et livre le même artefact que celui que l'utilisateur touche.

Et les designers qui ne savent pas lire du code ?

Ce designer devrait apprendre à lire du code, pas à en écrire. Lire des composants, reconnaître des tokens, modifier des valeurs et relire un diff est une compétence d'une semaine, pas une reconversion. L'IA fait le gros du travail sur le code de production en 2026. Le designer apporte composition, jugement et goût à la surface en fonctionnement, ce qui a plus de valeur, pas moins, quand la couche de production ne coûte presque rien.

Une petite équipe doit-elle vraiment se passer entièrement de Figma ?

Pas entièrement. Une petite équipe devrait encore utiliser Figma pour l'exploration de marque, les inventaires de systèmes et l'alignement d'équipe. Le basculement concerne les surfaces produit, où v0, Cursor, Lovable ou le registre shadcn surpasseront un artboard sur chaque métrique. La répartition honnête : marque et systèmes dans Figma, surfaces produit dans le code, avec un biais vers le code sur les nouvelles initiatives.

Placez-vous du bon côté du workflow

L'ère de Figma comme outil de design a eu raison pendant quinze ans, et elle est terminée. La codebase est l'environnement de design en 2026, et les équipes qui livrent l'UI produit dans le code facturent plus cher, apprennent plus vite et gagnent des briefs que les studios à decks Figma avaient l'habitude de rafler.

Si vous voulez une UI produit livrée en code, avec des designers dans le diff plutôt qu'un deck Figma balancé par-dessus le mur, engagez Brainy. Brainy livre la marque, l'ingénierie produit et le workflow IA comme un seul projet, pas trois. Les studios qui facturent encore le fichier Figma comme livrable final ne seront plus sur le brief le trimestre prochain. Soyez sur le brief.