Il y a dix ans, Zeplin promettait de tuer le handoff. Puis Avocode. Puis Figma lui-même, avec Inspect, Dev Mode, Dev Mode premium. Et maintenant Figma Make, qui promet au designer de se passer du développeur. Et Claude Design, lancé en avril 2026 par Anthropic, qui promet au développeur de se passer du designer.
Deux outils. Deux discours symétriques. Une seule idée vendue en boucle : l'autre métier est optionnel.
Ce n'est pas vrai. Et si vous travaillez dans le design, vous méritez de comprendre pourquoi, pas avec du jargon technique, mais avec ce que vous savez déjà sur votre propre travail.
Ce que Figma Make génère vraiment
Figma Make vous permet de partir d'une maquette et d'obtenir une interface fonctionnelle, générée par IA, sans toucher au code. La démo est convaincante. L'interface générée ressemble à ce que vous avez dessiné. Les boutons répondent au clic.
Ce que la démo ne montre pas : ce que reçoit le développeur de l'autre côté.
Imaginez qu'on vous demande de reproduire une identité visuelle complexe en partant d'une seule capture d'écran. Pas de charte graphique, pas de fichier source, pas de contexte sur les polices ou les espacements exacts. Vous pouvez produire quelque chose de plausible. Pas quelque chose de maintenable.
C'est exactement ce que reçoit un développeur avec le code généré par Figma Make : une interface qui ressemble à la maquette, construite sans structure, sans séparation des éléments réutilisables, sans logique d'organisation. Plusieurs équipes ont estimé que repartir de zéro était moins coûteux que de travailler à partir de cette sortie.
Le problème n'est pas Figma. Le problème est le message : vous n'avez plus besoin d'eux. Ce message est faux, et il vous expose.
Claude Design : quand le développeur devient "designer"
Claude Design fait le chemin inverse. Lancé en avril 2026 par Anthropic, il permet à un développeur de décrire une interface en texte et d'obtenir un prototype visuel : couleurs, typographie, mise en page, états d'interaction. L'outil lit même le codebase existant pour "apprendre" le style de la marque.
Le résultat est visuellement présentable. Et c'est précisément là que ça devient problématique pour vous.
Un développeur qui utilise Claude Design ne devient pas designer. Il obtient quelque chose qui ressemble à du design sans en avoir fait aucune des décisions réelles : est-ce que cette hiérarchie guide l'œil au bon endroit ? Est-ce que cet état de chargement est anxiogène ou rassurant ? Est-ce que ce choix typographique tient sur mobile à 8h du matin sur un écran de téléphone bon marché ?
Ces questions ne sont pas décoratives. Elles sont le cœur de votre métier. Et un modèle de langage n'y répond pas, il les évite en produisant quelque chose d'acceptable au premier regard.
Le risque n'est pas que Claude Design soit meilleur que vous. Le risque est qu'il soit suffisant pour des clients qui ne savent pas faire la différence.
Ce que dix ans de pratique ne s'automatisent pas
Votre valeur en tant que designer ne tient pas à votre maîtrise de Figma. Elle tient à ce que vous faites avec Figma : des décisions argumentées, testées contre des contraintes réelles, affinées par des retours utilisateurs, cohérentes dans le temps.
Un bon design de formulaire de contact n'est pas une question d'esthétique. C'est une question de charge cognitive, d'ordre des champs, de messages d'erreur qui n'accusent pas l'utilisateur. Un bon état vide n'est pas juste une illustration sympathique : c'est une réponse à la question "qu'est-ce que l'utilisateur ressent quand il arrive ici pour la première fois ?".
Aucun outil ne peut poser ces questions à votre place. Il peut générer une réponse qui ressemble à une réponse. C'est différent.
Le design et le développement sont deux langages techniques distincts, construits sur des années de pratique. Un designer qui n'a pas codé pendant des années ne peut pas remplacer un développeur, même avec Figma Make. Un développeur qui n'a pas designé pendant des années ne peut pas vous remplacer, même avec Claude Design. Ces outils ne suppriment pas l'apprentissage. Ils le cachent jusqu'à ce que le produit soit en production.
Ce qui, en revanche, fonctionne vraiment
La meilleure évolution du pipeline Figma vers le code n'est pas la génération automatique. C'est Code Connect, une feature qui lie chaque composant de votre maquette à son équivalent réel dans le code des développeurs. Quand vous utilisez un bouton dans Figma, le développeur voit exactement quel composant utiliser dans son code. Pas une approximation générée. Le vrai élément.
C'est utile parce que ça ne cherche pas à remplacer l'un ou l'autre. Ça crée un vocabulaire commun.
Dans le même esprit, les design tokens correctement synchronisés (vos couleurs, vos tailles de texte, vos espacements définis une fois et partagés entre Figma et le code) réduisent vraiment la friction au quotidien. Pas sur les décisions complexes. Sur les détails répétitifs.
Et la chose la plus efficace reste la plus ancienne : être impliqué tôt dans les contraintes d'implémentation. Pas pour apprendre à coder. Pour savoir quelles décisions de design ont un coût de développement élevé, et choisir en connaissance de cause.
L'industrie continue de vendre des ponts entre le design et le code. Elle devrait peut-être commencer par admettre qu'il y a un fleuve, et que certains métiers existent précisément parce que traverser ce fleuve demande des compétences que personne n'improvise.
C'est en tout cas le point de vue d'un développeur qui apprend à construire sa barque pour traverser ce fleuve. Le design, c'est loin d'être simple.