Peut-on se passer de Figma en 2027 ? Le guide pragmatique

La réponse courte

Oui, pour explorer, valider et lancer des produits simples. Pas encore pour les produits ambitieux à forte logique métier, ni pour les équipes qui doivent maintenir un système cohérent dans le temps. Claude Code, Claude Design ou Google Stitch remplacent déjà une partie du travail confié hier à Figma. Mais l'outil n'est pas le vrai sujet. Le vrai sujet, c'est la méthode : qui décide, où vit la source de vérité, et comment l'équipe travaille ensemble quand chacun peut générer une interface seul dans son coin.

Une nuance change tout : Claude Code, Codex ou Cursor peuvent remplacer Figma comme outil de production, à une condition. Ils doivent être branchés sur une source de vérité bien cadrée, qu'il s'agisse de Figma lui-même via MCP ou d'un design system tokenisé. Sans cette ancre, l'IA invente. Avec elle, elle exécute. C'est le principe de notre méthode Figma to code.

Pourquoi la question est devenue légitime en 2026

En neuf mois, le terrain a bougé plus qu'en dix ans. Les outils d'IA ne se contentent plus de suggérer : ils produisent du code qui tourne, et Figma a dû redéfinir sa place.

‍

Les usages suivent. D'après le rapport AI in Design 2026 de Designer Fund, cité par Andy Budd, 91 % des designers utilisent l'IA chaque semaine (contre 54 % un an plus tôt) et la moitié déclare avoir déjà mis du code généré en production. Le designer moyen jongle avec sept outils IA, contre trois l'année précédente.

Figma, lui, ne s'effondre pas : la société annonce 333,4 millions de dollars de revenus au premier trimestre 2026, en hausse de 46 %. Ce qui recule, c'est sa position de passage obligé.

Ce que dit le web, langue par langue

‍

Le constat est le même partout : beaucoup d'articles sur les outils, très peu sur la façon dont une équipe s'organise autour. C'est là que la réflexion doit aller.

Là où l'on peut déjà se passer de Figma

Pour poser les bases d'un produit, l'IA générative d'interface est redoutable. En quelques prompts, on obtient des écrans fonctionnels, une navigation cohérente et une UI propre. Sur ce terrain, Claude Code ne produit pas seulement du « joli » : il pré-mâche réellement le travail, y compris pour un designer expérimenté.

Trois usages où Figma devient facultatif :

1. Valider un concept. On teste une idée en une après-midi au lieu d'y consacrer une semaine de maquettage. Si l'idée ne tient pas, on l'abandonne sans regret.
2. Tester un parcours sur du réel. Un prototype qui tourne dans le navigateur, avec de vraies données et de vrais états d'erreur, révèle des problèmes qu'un prototype Figma masque.
3. Lancer un projet simple. Site vitrine, outil interne, landing de test : l'objectif est d'être en ligne, pas d'atteindre la précision au pixel.

Le gain est réel mais il a une limite connue : sur les écrans standards (connexion, tableau de bord, profil), la génération fait très bien le travail. Plus le besoin s'écarte du générique, plus le nombre d'allers-retours augmente.

Là où Figma reste le bon outil

Le tableau change dès qu'on veut aller plus loin. Certains ajustements très précis (un rythme vertical, une hiérarchie typographique, l'équilibre d'une carte) deviennent longs à obtenir par le texte. Ce qui prend dix secondes à la main peut coûter dix prompts.

C'est pour cela que nous réimportons dans Figma une partie de ce qui sort de Claude Code. Depuis février 2026, le passage se fait en une commande, et l'aller-retour inverse passe par le serveur MCP de Figma. Concrètement, la boucle ressemble à ceci :

1. On génère les écrans et la logique dans Claude Code.
2. On envoie le résultat dans Figma sous forme de calques éditables.
3. Le designer retouche à la main : espacements, typographie, détails d'interaction.
4. Claude Code relit le fichier Figma et applique les changements dans le code.

Cette boucle a deux mérites. Elle évite de « prompter dans le vide » au moment où le texte devient contre-productif. Et elle garde l'œil du designer comme arbitre final, au lieu de laisser le modèle trancher par défaut.

Figma garde aussi un avantage que peu d'articles soulignent : c'est un lieu partagé. Commentaires, revues, bibliothèques de composants, historique : l'équipe y est déjà. Une étude de terrain menée par Anna Lefour l'illustre : lors d'un test de passation, le développeur a jugé le fichier Figma classique plus clair que la version générée via MCP et Cursor.

Les deux angles morts : la durée et le collectif

La plupart des comparatifs « Figma vs IA » jugent un outil sur une après-midi. Un produit, lui, vit des années, et il est construit par une équipe. C'est sur ces deux axes que les approches 100 % prompt montrent leurs limites.

1. Le maintien de la méthode dans le temps

Un agent IA n'a pas de mémoire de design. Session après session, il réinvente un espacement, choisit une couleur voisine, renomme un composant. Chaque écran est correct ; l'ensemble dérive. Les développeurs anglophones parlent de design drift, et plusieurs articles proposent un même remède : un fichier DESIGN.md versionné qui décrit tokens, typographie et règles de composants, et que l'agent relit à chaque tâche (GeekyAnts).

C'est utile, mais ce n'est qu'une partie de la réponse. Côté français, Mickael Peyrot (Insign) dans le JDN rappelle que sans design system formalisé en amont, l'ajustement des écrans devient long, imprécis et incohérent avec la marque. Il note aussi qu'une application générée en quelques prompts fait souvent un bon prototype, rarement un bon produit, et que le refactoring reste nécessaire.

Ce qu'il faut retenir : la question n'est pas « Figma ou pas Figma », mais où vit la source de vérité du design system, et qui en est garant. Elle peut vivre dans le code, dans Figma, ou dans les deux synchronisés. Elle ne peut pas vivre nulle part.

Chez Jujotte, cette source de vérité est une chaîne continue : un Figma entièrement tokenisé sur le vocabulaire Tailwind, lu par Claude Code via le serveur MCP, un skill qui encode nos règles maison, puis Storybook et un dépôt Git qui portent exactement les mêmes données.
L'IA ne choisit jamais une valeur : elle pioche dans un vocabulaire fermé.
Nous détaillons la méthode, garde-fous anti-hallucination compris, dans Figma to code : de la maquette au code sans perte à la traduction.

Autrement dit, la bonne question n'est pas « peut-on se passer de Figma ? » mais « peut-on se passer d'une source de vérité ? ». À la seconde, la réponse est non.

2. La collaboration : l'IA en silo

C'est l'angle le moins traité, et le plus coûteux. Aujourd'hui, le travail avec l'IA est souvent solitaire : une personne derrière son LLM, les autres qui attendent le résultat. Peu d'échanges en cours de route, peu de transversalité.

Les données vont dans ce sens. Dans son étude, Anna Lefour a réduit un prototypage de deux jours à deux heures, mais elle observe que la relation designer-développeur, elle, n'a pas changé : l'IA rend les individus plus rapides, pas les équipes meilleures. Andy Budd fait un constat voisin à l'échelle des organisations : l'apprentissage se fait entre pairs, par petites poches, sans que la direction suive. Une équipe transforme sa façon de travailler pendant que la voisine produit encore des maquettes statiques.

Les risques concrets d'un fonctionnement en silo :

• Le prototype qui arrive « fini ». Un PM ou un fondateur génère une interface avant que le problème soit cadré. Elle a l'air aboutie, donc elle circule, et les décisions se prennent dessus.
• La revue impossible. Personne n'a vu les dix prompts qui ont mené au résultat. On ne peut critiquer que la surface.
• Le savoir qui ne se transmet pas. Les bons prompts, les pièges du modèle, les règles du design system restent dans la tête d'une seule personne.
• Le volume qui noie la décision. Dix variantes au lieu de deux, sans meilleur moyen de choisir.

La bonne nouvelle : rien de cela n'est une fatalité technique. C'est un sujet d'organisation, de rituels et de rôles. Et c'est exactement le type de sujet sur lequel une équipe gagne à être accompagnée.

Reste une question que peu d'équipes se posent explicitement : où se retrouve-t-on ? Pendant dix ans, la réponse allait de soi : dans Figma. Elle ne va plus de soi. Avec les code layers, la collaboration peut rester dans Figma, mais autour du code. Elle peut aussi migrer vers le dépôt Git : prévisualisations de chaque modification, revues dans Storybook, commentaires sur les pull requests. Peu importe le lieu choisi, pourvu qu'il soit unique et que toute l'équipe y ait accès, y compris ceux qui ne codent pas.

Sept autres angles morts que les comparatifs oublient

Les articles « Figma vs IA » se concentrent sur la vitesse de production. Voici ce qu'ils laissent de côté, et qui pèse pourtant lourd dans une décision d'équipe.

1. Votre chaîne repose sur un pont entre deux concurrents

En février 2026, Figma et Anthropic lançaient ensemble le passage de Claude Code vers Figma. Deux mois plus tard, le directeur produit d'Anthropic quittait le conseil d'administration de Figma, trois jours avant le lancement de Claude Design (Noqta). Les deux sociétés sont désormais concurrentes.

Construire sa production sur une passerelle entre deux rivaux est un risque : elle peut devenir payante, se dégrader ou disparaître. La parade consiste à garder une source de vérité qui survit sans le pont : tokens exportés en JSON, composants documentés dans Storybook, historique dans Git. Si l'un des outils change ses règles, le système reste intact.

2. L'accessibilité ne se génère pas toute seule

C'est l'angle le plus sous-estimé. En septembre 2026, AudioEye a demandé à cinq outils d'IA (dont ceux d'OpenAI, Anthropic, Google et Lovable) de construire trois sites conformes aux WCAG 2.2 niveau AA. D'après VentureBeat, les quinze sites ont échoué dès le niveau A, avec 55 problèmes par page en moyenne. Le même rapport relève que 81 % des équipes utilisatrices pensent pourtant leur code généré conforme.

Ce n'est pas qu'un sujet de qualité. L'European Accessibility Act s'applique depuis le 28 juin 2025 aux sites et applications d'e-commerce, de banque ou de transport, avec des contrôles de la DGCCRF. Les modèles reproduisent les défauts du web sur lequel ils ont été entraînés. L'accessibilité doit donc être inscrite dans la source de vérité (contrastes dans les tokens, règles dans le skill ou le DESIGN.md) et vérifiée par un humain.

3. Le coût réel n'est pas celui de la licence

On compare souvent un siège Figma à un abonnement IA. Le vrai calcul inclut la consommation de tokens, le temps de revue, les corrections et la remise en cohérence. Le serveur MCP de Figma, par exemple, est très gourmand en contexte : sans hygiène de session, une conversation sature et bloque l'assistant. Le temps gagné à générer peut être reperdu à relire. Mesurez le cycle complet, de l'idée à la mise en production, pas seulement la génération.

4. Le prototype trop fini biaise les tests

Un prototype qui a l'air abouti suscite des retours plus polis et moins critiques : les participants n'osent pas remettre en cause ce qui semble terminé. La vitesse de génération pousse aussi à tester ce que l'on sait construire plutôt que ce que l'on a besoin de comprendre. La phase de découverte (entretiens, observation, cadrage du problème) ne s'accélère pas avec un prompt, et c'est souvent elle qui saute.

5. Comment se forme l'œil des juniors ?

Si un designer junior ne construit jamais une maquette à la main, d'où viendra le regard qu'on présente comme l'arbitre final ? Le sens de la hiérarchie, du rythme et de l'espace s'acquiert en faisant. Les équipes qui adoptent l'IA doivent prévoir des temps de pratique manuelle et de revue commentée, sans quoi elles consomment une expertise qu'elles ne renouvellent plus.

6. La confidentialité des données clients

Brancher un agent sur une base de code et des fichiers de design revient à transmettre ces contenus à un fournisseur de modèle, souvent hors d'Europe. Cela pose des questions contractuelles (clauses de confidentialité, propriété des livrables), réglementaires (RGPD) et de politique interne. En entreprise, c'est souvent ce point, plus que la qualité du résultat, qui freine l'adoption. Il se traite en amont : offres entreprise, réglages de conservation des données, périmètre de ce qui est envoyé au modèle.

7. L'uniformisation visuelle

Beaucoup d'interfaces générées finissent par se ressembler, avec les mêmes composants par défaut, les mêmes ombres, les mêmes dégradés. Pour un outil interne, ce n'est pas grave. Pour une marque, c'est un problème : se distinguer redevient précisément le travail du designer, et c'est là que la main reprend l'avantage sur le prompt.

La grille de décision : quel outil pour quel projet ?

On lit souvent que plus un produit est complexe, plus Figma devient indispensable. C'est vrai en partie, mais trompeur. Un SaaS métier très dense, adossé à un design system codé et mature, est peut-être le cas où le code-first fonctionne le mieux : l'IA pioche dans un vocabulaire fermé. À l'inverse, un site de marque très simple, où le visuel est le produit, peut réclamer bien plus de travail à la main.

Deux critères décident vraiment : la maturité de votre source de vérité (design system, tokens, composants) et votre besoin de différenciation visuelle. La complexité métier, elle, décide surtout du temps de cadrage nécessaire avant de produire le moindre écran.

La case surlignée correspond à la boucle décrite plus haut : un système solide, une marque à faire exister, et des allers-retours permanents entre le code et Figma. Le tableau ci-dessous décline la matrice par type de projet.

‍

Ces repères viennent de notre pratique d'agence, pas d'une étude : ils servent à ouvrir la discussion en équipe, pas à la clore.

Comment Jujotte accompagne les équipes

Nous utilisons ces outils au quotidien, en production, et nous avons appris à quel moment basculer de l'un à l'autre. C'est cette expérience que nous transmettons. Notre accompagnement porte sur la méthode, pas sur le choix d'un logiciel :

1. Faire l'état des lieux. Qui utilise quoi, pour quel usage, avec quels résultats. Les pratiques IA existent déjà dans l'équipe, souvent sans que personne n'en ait la vue d'ensemble.
2. Situer chaque projet dans la matrice. Maturité du design system et besoin de différenciation : on cale le bon outil par phase sur vos projets réels.
3. Installer une source de vérité. Design system, tokens, DESIGN.md, synchronisation code ↔ Figma : un seul endroit fait foi, il survit si un outil change ses règles, et quelqu'un en est responsable.
4. Inscrire l'accessibilité dans le système. Contrastes dans les tokens, règles dans les instructions de l'agent, audit humain avant mise en ligne.
5. Sortir l'IA du silo. Sessions de prototypage à plusieurs, revues où l'on regarde le résultat et le chemin, partage des prompts et des pièges dans un espace commun.
6. Redéfinir les rôles et former. Quand un PM peut générer une interface, le designer devient garant du cadrage, de la cohérence et de la qualité. On l'écrit noir sur blanc, et on garde des temps de pratique manuelle pour les profils juniors.
7. Cadrer la confidentialité. Ce qui part chez le fournisseur de modèle, sous quelles conditions, avec quelles clauses vis-à-vis de vos propres clients.

Conclusion

Se passer de Figma en 2027 ? Oui, pour poser les bases, tester et explorer. Pas encore pour les produits ambitieux à forte logique métier, ni pour les équipes qui doivent tenir un système dans la durée. La compétence qui compte n'est plus de choisir un camp, mais de savoir quand basculer, et de faire en sorte que toute l'équipe bascule ensemble. Avec, toujours, le designer comme arbitre de ce que la machine ne sait pas trancher : la cohérence du système, les états limites, l'accessibilité et, d'abord, la pertinence du problème posé.

Votre équipe se pose la question ? Parlons-en : on part de vos projets, pas d'une liste d'outils.