La mort des maquettes : pourquoi la conception par le code a gagné 2026
Les maquettes statiques ont connu leur heure de gloire. En 2026, elles ont été dépassées. L'IA transforme désormais les instructions en composants fonctionnels plus rapidement qu'un designer ne peut livrer une simple maquette Figma. Cet article aborde l'intérêt de concevoir en codant, la nouvelle pile technologique qui s'est imposée, les compromis nécessaires et le rôle du designer qui perdure.

La maquette est morte. Ni comme croquis, ni comme outil de réflexion, ni comme moodboard. En tant que livrable. La structure plate Figma que les designers ont livrée comme produit final pendant quinze ans a perdu la bataille en 2026, face à un composant fonctionnel qu'un ingénieur peut déployer le jour même.
Ce n'est pas une idée reçue. L'IA transforme désormais un paragraphe d'intention en un composant React opérationnel plus rapidement que la plupart des designers ne peuvent placer un en-tête dans Figma. Les jetons de conception ont remplacé les planches de travail comme source de référence. Les studios qui continuent de vendre des présentations Figma comme livrables finaux en 2026 perdent des contrats au profit d'équipes qui livrent du code fonctionnel, et l'écart de prix se creuse chaque trimestre.
Plaidoyer pour la conception dans le code, la pile technologique qui a triomphé, les compromis nécessaires et le rôle qui perdure.
La maquette est morte et enterrée, l'intelligence artificielle l'a emportée
L'ère de la maquette comme livrable est révolue, et les studios qui continuent de vendre des présentations Figma comme livrables finaux en 2026 se rendent inabordables. Pendant quinze ans, le flux de travail des maquettes a suivi une logique implacable. Le designer livrait des images fixes en Figma. L'ingénieur traduisait ces images en code. Les parties prenantes les approuvaient. La production rattrape son retard plus tard, parfois jamais. Cette logique a été mise à mal lorsque la production a cessé d'être le goulot d'étranglement.
En 2026, le goulot d'étranglement est le jugement, et non plus le résultat. L'IA livre la couche de production en quelques minutes. L'image fixe Figma est désormais l'étape la plus lente du pipeline, et non la plus rapide, et les clients l'ont bien compris. Une équipe qui produit un composant fonctionnel en un après-midi le livre et tire des enseignements de quatre cycles de développement avant que l'équipe produisant une maquette haute fidélité n'en livre une seule.
La maquette n'est pas morte parce que les designers sont devenus moins compétents. Elle est morte parce que l'intelligence artificielle s'est améliorée.
Qu'est-ce qui a réellement changé en 2026 ?
Le changement ne résidait pas dans un seul outil, mais dans une suite d'éléments atteignant simultanément une masse critique. Figma Make a transformé les frames Figma en React prêts à l'emploi. Le curseur avec shadcn a rendu la production de composants fidèles au design peu coûteuse. v0, Bolt et Lovable ont bouclé la boucle entre la génération de l'invite et la mise en production des applications complètes. Claude Code a introduit un véritable agent de codage sur un véritable dépôt, avec des humains pour la comparaison des différences. Les jetons de conception, formalisés dans le brouillon du W3C et adoptés par toutes les équipes sérieuses, sont devenus la source de référence, remplaçant ainsi le plan de travail.
Chacun de ces éléments existait sous une forme ou une autre avant 2026. Ce qui a changé, c'est qu'ils ont tous atteint leur pleine maturité au même moment. Le résultat combiné est un flux de travail où l'application en cours d'exécution est l'artefact et le plan de travail une ébauche, et non l'inverse.

Figma Make a transformé Figma en générateur de code
Figma Make a aboli la frontière entre le plan de travail et le code source en générant des composants React directement à partir des frames. Les frames ont cessé d'être le livrable dès l'instant où Figma les a transformées en brouillon. Les designers utilisant Make ne fournissent plus une frame à l'équipe de développement, mais un composant fonctionnel qu'une équipe peut intégrer au dépôt après quelques retouches.
Make n'est pas parfait. Le code généré nécessite toujours une relecture par un expert, le mappage des jetons reste partiel dans les fichiers existants et la logique interactive complexe requiert encore une intervention humaine. Rien de tout cela n'est pertinent pour déterminer si une frame plate sera le livrable en 2026. La réponse est non. Figma l'a décidé.
Grâce au mode développeur et aux Figma et MCP, le processus complet, de la Figma à l'application fonctionnelle, est passé d'un transfert de plusieurs jours à un aller-retour dans la même journée.
Cursor et shadcn rendent le code fidèle au design accessible et économique
Cursor, associé à shadcn, a simplifié la création de composants accessibles et conformes à la marque, un travail que le flux de travail de maquettage justifiait auparavant. Un designer ayant besoin d'un composant de production « fidèle au design » passait auparavant une semaine à annoter l'espacement, la typographie, les couleurs, les états, puis à le transmettre à l'équipe de développement. Cursor et shadcn produisent ce composant à la demande, avec des variantes prenant en charge les jetons et accessibles par défaut, en quinze minutes.
Cette combinaison est essentielle. Cursor modifie un véritable dépôt avec un véritable diff. shadcn distribue les composants sous forme de code dont vous êtes propriétaire, et non sous forme de package dont vous dépendez. Les tokens Tailwind s'intègrent parfaitement aux deux. Le résultat : un code de production fidèle au design, moyennant un framework Figma, ce qui a éliminé la principale raison de déployer Figma.
v0, Bolt et Lovable ont bouclé la boucle entre la conception et le produit
v0 (de Vercel), Bolt (de StackBlitz) et Lovable ont permis de boucler la boucle, de la conception à une application fonctionnelle et déployable, en quelques minutes. Aucun de ces outils n'est parfait. Tous trois sont plus rapides que la création d'une maquette haute fidélité de la même interface.
v0 l'emporte grâce à sa couche de composants fidèle au design, car il prend en charge nativement shadcn et Tailwind. Bolt l'emporte grâce à son prototype complet pour navigateur, car il déploie un backend dans la même session. Lovable l'emporte grâce à sa conception adaptée aux développeurs non-ingénieurs qui déploient un produit sans équipe de développement. Chacune de ces méthodes transforme une intention en une surface de travail à la vitesse à laquelle les clients attendent un moodboard.
Lorsque les clients constatent qu'une application fonctionnelle existe dans le même laps de temps qu'un moodboard nécessitait auparavant, ce dernier perd de son attrait.

⟦MARQUE1⟧ a mis en place une collaboration en temps réel sur une application en production.
⟦MARQUE2⟧, sur un véritable dépôt, a offert aux designers et aux ingénieurs une surface de travail partagée qui correspond au produit final, et non à une simple représentation. Le processus est simple : un designer collabore avec ⟦MARQUE3⟧ sur l'application en production, modifie un composant, teste la modification dans le navigateur dans la minute qui suit, et l'ingénieur examine les différences. La version est ensuite déployée.
Ce cycle de collaboration est ce qui se rapproche le plus de la conception sur tableau blanc depuis l'avènement du CSS. À ceci près que le tableau blanc est l'application en production, le marqueur une modification réelle de composant et la gomme une différence Git. Le flux de travail basé sur les maquettes ne peut rivaliser avec un cycle aussi court.
Pour une analyse plus approfondie du fonctionnement de cette boucle sur un code source réel, consultez Le codage d'ambiance pour les designers et Comparaison des éditeurs de code IA.
Les jetons de conception deviennent la référence
En 2026, ce sont les jetons, et non les plans de travail, qui constituent la référence. Ce simple changement a rendu obsolète la majeure partie du flux de travail utilisant Figma comme livrable final. Lorsque la couleur, l'espacement, la typographie, le rayon, le mouvement et l'élévation sont définis dans un fichier de jetons que l'outil de conception et le code source lisent, le plan de travail est un rendu des jetons, et non leur définition.
La spécification des jetons de conception du W3C, le dictionnaire de styles, les fichiers de thème Tailwind et les plugins de jetons de Figma convergent tous vers la même idée : les jetons en amont, toutes les interfaces en aval. Une équipe travaillant de cette manière modifie le fichier de jetons, surveille la mise à jour de Figma, surveille la mise à jour de l'application en cours d'exécution, puis la déploie. Dans ce processus, il n'est pas nécessaire de fournir un plan de travail plat comme livrable final, car le fichier token en est déjà un.
C'est un point que la plupart des studios qui vendent encore des decks Figma n'ont pas intégré, et c'est pourquoi leurs prix baissent. Pour connaître la marche à suivre, consultez Transfert de conception de Figma à l'équipe de développement.
Où les maquettes restent incontournables en 2026
Les maquettes ont toujours toute leur place. Prétendre le contraire est malhonnête, et ce genre d'affirmation exagérée discrédite le reste de cet argument.
Premièrement, l'idéation initiale. Une maquette plate Figma à l'étape de divergence est plus rapide que de passer trente minutes dans un éditeur de code à imaginer différentes configurations. Deuxièmement, les croquis de marque. Le travail sur le logo, l'exploration de l'identité, les études typographiques, les systèmes de couleurs avant leur implémentation : ces éléments ont toujours leur place dans un plan de travail plat ou dans Illustrator avant même la création du fichier token. Troisièmement, l'exploration visuelle pure, sans pile de composants. Nouvelles catégories de produits, concepts axés sur l'ambiance, éléments sans base de code. Quatrièmement, présentation au client des décisions stratégiques de la marque, où le produit final repose sur le système et non sur l'interface.
Tout le reste – chaque écran déployé pour un utilisateur réel, chaque composant intégré à un produit, chaque page indexée – doit être codé en 2026.

Le nouveau rôle : les designers comme éditeurs de composition en direct
Le designer de 2026 est un éditeur de composition en direct au sein d'une application en production, et non un simple producteur de fichiers statiques. Le travail est jugé sur l'interface finale déployée, et non sur le plan de travail. Le produit final est un composant déployé, et non une simple image.
Ce rôle est plus exigeant, et non moins. Un éditeur de composition en direct lit le code, modifie les jetons, déploie une comparaison réelle et est responsable de l'interface finale. Il est également mieux rémunéré, car le travail s'effectue au rythme de la production et la valeur réside dans le jugement, et non dans le nombre de variantes. Les développeurs seniors qui opèrent cette transition facturent des tarifs premium car le livrable est une application fonctionnelle, et non une simple présentation qu'un junior aurait pu réaliser.
Si vous souhaitez une interface utilisateur produit livrée sous forme de code avec la stack de 2026, embauche Brainy. AppBrainy propose une ingénierie produit complète avec des designers travaillant directement sur le diff. ClaudeBrainy fournit les packs de compétences et les bibliothèques d'invites qui transforment l'IA en couche de production d'une base de code réelle.
Comment fonctionnent concrètement Linear, Vercel, Anthropic et Anysphere
Les équipes qui livreront les meilleures interfaces utilisateur produit en 2026 partagent un même flux de travail : les tokens en amont, le code comme canevas, l'IA comme couche de production et les designers travaillant directement sur le diff.
L'équipe de conception de Linear considère la base de code comme la source de référence. Les tokens et les composants résident dans le dépôt, et les designers soumettent des pull requests à l'application en production. Leurs journaux de modifications et pages de fonctionnalités ne sont pas des exportations Figma, mais le produit lui-même. Vercel utilise la même forme sur sa page d'accueil et ses interfaces v0, les designers travaillant directement dans l'application déployée et utilisant la v0 pour créer rapidement de nouvelles variantes de motifs. L'équipe produit de Anthropic conçoit les interfaces du produit Claude, les designers lisant et modifiant le code source de l'application, souvent avec l'aide de Claude Code. Anysphere, l'équipe Cursor, utilise ses propres outils : les designers travaillent directement dans Cursor sur le code source de Cursor, ce qui est la preuve la plus convaincante que le flux de travail est bien réel.
La forme est cohérente. Aucune de ces équipes ne livre Figma comme produit final. Toutes considèrent l'interface comme un outil de réflexion et l'interface d'exécution comme le résultat final.
Mise en garde : les studios qui vendent encore des présentations Figma en 2026
Les studios qui proposent encore des présentations Figma comme livrables finaux en 2026 perdent des contrats au profit d’équipes qui déploient du code fonctionnel. L’écart de prix se creuse chaque trimestre, et la raison n’est pas esthétique, mais structurelle.
Un studio qui facture 40 000 € pour une présentation Figma est en concurrence avec une équipe qui facture 50 000 € pour la même surface, une fois le code livré. Le client obtient le même résultat visuel, plus une application déployée, un système de jetons et un système de design opérationnel, pour un trimestre de plus. Le calcul est implacable. Le studio qui ne propose que des présentations Figma perd le contrat. Si cela se répète sur une année, le studio revoit ses tarifs ou change de cap. La plupart changent de cap tardivement.
Ce n’est pas une prédiction. C’est une réalité dès maintenant sur Calendly. Les studios qui considèrent encore le livrable Figma comme le produit final incitent leurs clients à se tourner vers un autre prestataire.
FAQ
La maquette est-elle vraiment morte ?
La maquette est morte en tant que livrable final pour l'interface utilisateur d'un produit livré en 2026. Elle reste un outil précieux pour la réflexion en phase de conception, un espace d'esquisse de marque et un canevas pour explorer les divergences. Le changement réside dans la nature du livrable, et non dans le rôle des maquettes.
Que signifie concrètement concevoir dans le code ?
Concevoir dans le code signifie que le concepteur intègre ses modifications dans une base de code réelle, et non dans un simple plan de travail. Il modifie les jetons, les composants, exécute l'application, compare les différences et déploie. Le résultat est l'interface d'exécution, et non la structure.
Les concepteurs doivent-ils apprendre l'ingénierie ?
Les concepteurs doivent savoir lire du code, modifier des jetons, exécuter un serveur de développement et comparer les différences. Ils n'ont plus besoin de développer React de A à Z. L'IA prend en charge la majeure partie du code de production. Le rôle du designer se concentre sur la composition, le jugement, le goût et l'interface.
Figma est-il terminé ?
Figma n'est pas terminé. Figma Make, le mode Dev et Figma MCP font de Figma le point d'entrée du nouveau flux de travail, et non sa sortie. Le plan de travail est une ébauche, le code est le livrable, et Figma se situe en amont du processus.
Qu'en est-il du travail de marque et de la conception d'identité visuelle ?
La conception de marque et d'identité visuelle reste basée sur des outils de conception plate. Logos, typographies, systèmes de couleurs, esquisses d'identité visuelle : tout cela a sa place dans Figma, Illustrator, ou dans un carnet de croquis, avant même l'écriture du moindre code. L'enjeu est l'interface utilisateur du produit, et non la conception de la marque.
Comment réussir cette transition le plus rapidement ?
Trois étapes. Maîtriser les tokens shadcn et Tailwind. Concevoir en binôme avec Cursor ou Claude Code sur un dépôt réel. Déployer un composant via une pull request ce trimestre. La troisième étape est cruciale.
Adopter la bonne approche
Le workflow basé sur les maquettes a connu son heure de gloire. En 2026, il a été supplanté par une application fonctionnelle, et les équipes qui développent l'interface utilisateur du produit directement dans le code facturent plus cher, apprennent plus vite et remportent les contrats autrefois réservés aux studios utilisant Figma.
Trois étapes pour adopter la bonne approche. Premièrement, intégrer les tokens en amont. Couleur, police, espacement, rayon, mouvement, élévation. Un seul fichier, lisible par les deux outils, sans qu'aucun plan de travail n'en soit propriétaire. Ensuite, exécutez Shadcn (ou son équivalent) sur un dépôt réel, associez-le à Cursor ou Claude Code, et livrez un composant sous forme de pull request déployée ce trimestre. Troisièmement, modifiez le livrable. Arrêtez de vendre des présentations Figma comme livrables finaux. Vendez des composants livrés, des applications déployées, des interfaces fonctionnelles.
Si vous souhaitez une interface utilisateur produit livrée sous forme de code sur la pile technologique de 2026, embauche Brainy. AppBrainy propose une ingénierie produit complète avec des designers dans le diff. ClaudeBrainy fournit les packs de compétences et les bibliothèques de prompts qui transforment l'IA en couche de production d'une base de code réelle. Les studios qui facturent encore des présentations Figma comme livrables finaux ne seront pas inclus dans le brief du prochain trimestre. Soyez inclus dans le brief.
If you want a product UI shipped in code on the 2026 stack, AppBrainy ships full product engineering with designers in the diff, and ClaudeBrainy ships the Skill packs and prompt libraries that turn AI into the production layer of a real codebase.
Get Started

