La stack du designer en 2026 : de Figma à MCP

J'ai regardé où passait réellement mon temps sur la conception d'un SaaS piloté par des agents. Figma : environ 20 %. Cet article détaille les 80 % restants, et ce qu'ils impliquent pour la façon dont un designer travaille aujourd'hui.

Ce n'est pas un plaidoyer pour que les designers deviennent développeurs. C'est un constat : sur un produit IA, les décisions de design les plus structurantes se prennent en dehors de l'outil de design. Ne pas y participer, c'est concevoir un cinquième du produit et découvrir les quatre autres cinquièmes une fois qu'ils ont été arbitrés par quelqu'un d'autre.

Le modèle de données : ce qu'on stocke détermine ce qu'on peut afficher

Une maquette qui suppose une donnée inexistante en base est une jolie fiction. Le cas typique : un écran qui affiche « dernière interaction : il y a 3 jours » alors que le système n'a jamais horodaté les interactions.

Ce que ça change concrètement : avant de dessiner un écran de liste, je regarde le schéma. Quels champs existent, lesquels sont optionnels, lesquels sont calculés. Un champ optionnel dans le schéma est un état vide dans l'interface — et cet état doit être conçu, pas subi.

Le réflexe utile : pour chaque bloc d'information affiché, savoir répondre à « d'où vient cette donnée, et que se passe-t-il si elle est absente ? ». Les deux réponses appartiennent au design.

L'orchestration : le design de comportement

Quel agent se déclenche, sur quel événement, avec quel garde-fou. C'est du design, même si ça ne ressemble à rien de visuel.

Un exemple. Un agent de veille surveille l'activité de contacts suivis et prépare des commentaires. Trois décisions à prendre, toutes de nature produit :

• Le déclencheur. À chaque nouvelle publication, ou une fois par jour en lot ? La première option est plus réactive, la seconde produit une expérience de « revue du matin » qui respecte mieux l'attention.
• Le garde-fou. Que se passe-t-il si le contact publie dix fois dans la journée ? Sans plafond, l'utilisateur reçoit dix suggestions et cesse de les lire.
• La sortie. Le résultat atterrit-il dans une file à traiter, une notification, un email ? Ce choix détermine si la fonctionnalité est utilisée ou ignorée.

Aucune de ces trois décisions n'apparaît sur une maquette. Toutes déterminent l'expérience réelle.

Les prompts système : un composant d'interface

Un prompt système définit le ton du produit, son niveau de détail, ce qu'il refuse de faire. C'est exactement la définition d'un composant d'interface, et il mérite le même traitement : une source de vérité, un versionnement, une revue quand il change.

Ce que j'ai appris en les traitant comme du design plutôt que comme de la configuration :

• Un prompt trop long produit des réponses qui dérivent ; la contrainte de concision est une décision de design, pas une optimisation technique.
• Les instructions négatives (« ne fais pas X ») fonctionnent moins bien que les instructions positives assorties d'un exemple. C'est vrai en rédaction d'interface aussi.
• Un changement de prompt modifie l'expérience autant qu'un changement de composant. Il devrait passer par la même revue.

Les tokens et le design system qui s'entretient

Tout design system meurt de la même manière : personne n'a le temps de le maintenir. Un composant dupliqué au lieu d'être réutilisé, une couleur écrite en dur, une documentation qui décrit une version disparue. Six mois plus tard, design et front travaillent sur deux systèmes différents qui portent le même nom.

Ce n'est pas un problème de discipline mais de charge : la maintenance est un travail répétitif, sans gratification, prioritaire pour personne. C'est exactement le profil de tâche qu'un agent absorbe bien.

Ce que j'automatise :

• la détection des valeurs écrites en dur qui devraient être des tokens ;
• la synchronisation des tokens entre l'outil de design et le code, dans un seul sens, avec une source de vérité en JSON ;
• la mise à jour de la documentation quand un composant change de props ou d'états.

Ce que je n'automatise pas, et que je ne compte pas automatiser : décider si un nouveau composant a le droit d'exister, nommer les choses, trancher entre deux conventions qui se valent techniquement. L'agent absorbe l'entretien ; l'arbitrage reste au designer, et c'est là qu'était la valeur depuis le début.

MCP : donner des bras au modèle

Un modèle de langage, seul, ne peut rien faire d'autre que générer du texte. Ce qui le transforme en agent, ce sont les outils qu'on lui branche : lire une base, envoyer un email, créer une tâche. Le standard qui sert à les brancher s'appelle MCP — Model Context Protocol.

Pourquoi un designer devrait s'y intéresser : parce que la liste des outils donnés au modèle est une décision de design produit, pas une décision d'infrastructure. Elle détermine trois choses.

Ce que l'utilisateur peut demander. Un assistant sans accès au calendrier ne saura jamais répondre à « déplace ma réunion », quel que soit le modèle. La frontière du produit est la frontière des outils.

Ce que le produit peut faire dans son dos. Chaque outil qui écrit est une action potentiellement irréversible. Un outil qui lit se conçoit comme une requête ; un outil qui écrit se conçoit comme un parcours, avec confirmation et trace.

Ce qui sort de l'entreprise. Chaque connecteur est une porte. « Notre IA tourne en local » ne dit rien tant qu'on n'a pas listé ce à quoi elle est branchée.

Le réflexe pratique : demandez la liste des outils avant de dessiner l'assistant. Elle vous en dira plus que n'importe quel cahier des charges.

Les états d'erreur et de coût

Un appel modèle échoue, coûte de l'argent, ou renvoie n'importe quoi. Trois écrans que presque personne ne maquette et que tous les utilisateurs finissent par voir.

Sur les produits IA, ces états méritent un traitement de première classe :

• L'échec du modèle. Que voit l'utilisateur ? Un message technique est un aveu d'impréparation. Un repli déterministe — le résultat sans la partie générée — est presque toujours meilleur qu'un écran d'erreur.
• Le quota atteint. C'est un moment de produit, pas une impasse : c'est là qu'on explique ce qui reste possible gratuitement.
• Le résultat aberrant. Comment l'utilisateur le signale-t-il, et que se passe-t-il ensuite ? Sans ce chemin, les erreurs ne remontent jamais.

Prototyper en production plutôt qu'en maquette

Conséquence de tout ce qui précède : sur ces produits, j'ai arrêté la maquette haute fidélité. Je passe du croquis basse fidélité directement à un prototype qui tourne sur de vraies données.

La maquette ment sur trois plans. Sur le contenu : elle affiche des résultats calibrés, de la bonne longueur, alors que le modèle renvoie parfois trois lignes et parfois deux pages. Sur le temps : tout y est instantané, alors que c'est là que se joue l'essentiel de l'expérience. Sur les cas dégradés : la donnée y existe toujours, le quota n'est jamais atteint, l'agent ne se trompe jamais.

Ce que la maquette garde comme usages légitimes : explorer une direction visuelle, aligner une équipe sur une intention, documenter un design system. Ce sont de vrais usages — ce ne sont simplement pas des usages de validation.

Ce que ça demande, concrètement

Pas de devenir développeur. Plutôt d'acquérir un niveau de littératie suffisant pour participer aux arbitrages : lire un schéma de données, comprendre ce qu'est un appel d'outil, savoir ce que coûte une requête, assembler un enchaînement fonctionnel avec les outils d'automatisation disponibles aujourd'hui.

C'est un investissement de quelques semaines, pas de quelques années. Et il change la position du designer dans le projet : de quelqu'un qui reçoit des contraintes à quelqu'un qui participe à les définir.