ai for designersApril 21, 202614 min read

Les agents IA pour les designers : comment concevoir et construire des workflows agentiques

Ce qu'est réellement un agent IA, en quoi il diffère d'un chatbot ou d'un copilot, et trois workflows agentiques que tout designer peut construire sans écrire de code de production.

By Boone
XLinkedIn
ai agents for designers

La différence entre un chatbot et un agent, c'est la différence entre un junior qui attend votre prochain message et un junior qui part et finit tout le travail.

Cette deuxième version s'est glissée dans vos outils quelque part au cours des dix-huit derniers mois, et la plupart des designers ne l'ont toujours pas remarqué. Ils tapent des prompts dans une fenêtre de chat, copient la réponse, la collent dans Figma, et se demandent pourquoi leur workflow ressemble à une version légèrement plus rapide de 2023. Le basculement vers les agents, ce n'est pas « un ChatGPT amélioré ». C'est un changement de catégorie.

Un agent reçoit un objectif. Il décide quels outils appeler. Il les appelle dans l'ordre, lit les résultats, corrige le tir et vous remet un livrable terminé. Vous ne tapez plus dans un chat. Vous briefez une petite équipe et vous relisez le livrable.

Chatbot, copilot, agent : pourquoi la différence compte

Trois mots utilisés comme s'ils signifiaient la même chose. Ce n'est pas le cas.

Un chatbot fonctionne par tours. Vous posez une question, il répond, vous posez une autre question. ChatGPT sans outils, Claude dans une fenêtre de chat simple, Gemini dans l'application. Le contexte, c'est ce que vous collez. Le résultat, c'est du texte.

Un copilot est une assistance intégrée. GitHub Copilot, les fonctionnalités IA de Figma, Notion AI. Il vit à l'intérieur d'un autre outil et suggère la prochaine action pendant que vous travaillez. Il ne quitte pas la voie où vous êtes. Il ne planifie pas de travail en plusieurs étapes.

Un agent est orienté objectif. Vous lui donnez un résultat attendu, pas une prochaine étape. Il choisit ses propres outils, les appelle en boucle, vérifie sa propre progression et s'arrête quand l'objectif est atteint ou qu'il a besoin de votre intervention. L'exemple contemporain le plus clair est Claude Code qui tourne dans votre terminal avec des serveurs MCP connectés, même si le mode agent de ChatGPT, le panneau agent de Cursor et Computer Use d'Anthropic fonctionnent tous de la même façon.

ModeVous ditesIl faitQuand il s'arrête
Chatbot« Écris-moi un titre »Renvoie du texteAprès un message
CopilotCommencer à taperSuggère la ligne suivanteQuand vous le rejetez
Agent« Audite nos variantes de Button et propose une API consolidée »Lit le code, lance des tests, écrit une PR, pose des questionsQuand l'objectif est atteint

À retenir : les chatbots répondent, les copilots assistent, les agents livrent.

Un agent est une boucle, pas un simple prompt

Chaque agent que vous utiliserez un jour tourne sur le même cycle en quatre étapes. Comprenez cette structure et vous pouvez prédire comment n'importe quel outil agentique va se comporter.

  1. Planifier. L'agent lit l'objectif et décide de la première étape.
  2. Agir. Il appelle un outil. Lit un fichier, interroge une API, exécute une commande, récupère une URL.
  3. Observer. Il lit le résultat de l'outil et décide s'il s'est rapproché de l'objectif.
  4. Itérer. Si ce n'est pas terminé, il planifie la prochaine étape. Si c'est terminé, il rend compte.

Cette boucle, c'est tout. La magie qu'on attribue aux agents, c'est simplement la boucle qui tourne proprement avec suffisamment d'outils utiles connectés. Pas de boucle, pas d'agent. Un modèle qui répond une seule fois est un chatbot. Un modèle qui fait tourner la boucle, avec des outils, vers un objectif, est un agent.

Un diagramme en quatre étapes montrant planifier, agir, observer, itérer sous forme de boucle, avec une fine flèche revenant d'itérer vers planifier, style éditorial
Un diagramme en quatre étapes montrant planifier, agir, observer, itérer sous forme de boucle, avec une fine flèche revenant d'itérer vers planifier, style éditorial

La boîte à outils des agents pour designers en 2026

Vous n'avez pas besoin de construire un agent de zéro. En avril 2026, la surface d'agents utiles pour les designers ressemble à ceci.

Claude Code. Vit dans votre terminal ou dans VS Code. Lit tout votre repo. Appelle des fichiers, exécute des commandes, parle aux serveurs MCP. Idéal pour tout ce qui touche au code, aux tokens, ou à un repo de design system.

Claude Desktop et ChatGPT avec MCP. Les deux supportent maintenant les connexions MCP. Vous pouvez les connecter à Figma, Google Drive, Notion, Linear, et votre système de fichiers. Mieux adaptés pour la recherche, les briefs, la rédaction de specs et le travail de contenu que pour le code.

Cursor agent mode. Agent natif à l'éditeur pour construire avec React, Vue, ou Svelte. Plus proche de Claude Code dans ce qu'il fait, avec une interface visuelle plutôt qu'un terminal.

Figma MCP. Pas un agent en lui-même. Un connecteur d'outils. Il transforme Figma en source de données qu'un agent peut lire. Connectez-le une seule fois, et chaque agent compatible MCP peut désormais voir vos frames. La configuration est couverte dans Figma MCP : connecter Figma à Claude Code et aux agents IA.

n8n, les agents Zapier et les scripts personnalisés. Si vous voulez un agent qui tourne selon un calendrier ou réagit à un webhook (nouveau commentaire Figma, nouvelle soumission Google Form, nouvel e-mail dans une boîte partagée), ce sont les plateformes d'hébergement. Les designers les utilisent pour les agents de « collage », ceux qui tournent en arrière-plan pendant que vous dormez.

Pour la plupart des designers, le bon stack de départ est Claude Code plus Figma MCP plus une connexion à Google Drive ou Notion. C'est suffisant pour couvrir quatre-vingt-dix pour cent du travail de design agentique.

Comment concevoir un agent (c'est toujours un brief)

Concevoir un agent n'est pas une tâche de code. C'est une tâche de brief. La même que vous faites chaque fois que vous confiez un travail à un freelance ou à un junior.

Quatre questions auxquelles répondre, dans l'ordre, avant de construire quoi que ce soit.

  1. Quel est l'objectif ? Une phrase. « Produire un moodboard et un court brief créatif à partir d'une transcription d'appel de découverte client. »
  2. De quels outils l'agent a-t-il besoin ? Listez-les. « Lire un Google Doc, chercher sur le web, récupérer des images, écrire dans un fichier Figma, sauvegarder dans un dossier Google Drive. »
  3. Quelles règles le contraignent ? « N'utiliser des images que de sources éditoriales, pas de photographie de stock. Ne jamais inventer une marque. Citer chaque source. Toujours produire le brief dans notre format maison. »
  4. Quand s'arrête-t-il ? « Quand le fichier Figma a un frame de moodboard avec au moins 12 références et que le brief est sauvegardé en PDF dans le Drive partagé. »

Ratez l'objectif et l'agent dérive. Ratez les outils et il improvise avec les mauvais. Ratez les règles et il vous livre la moyenne de ses données d'entraînement, qui est généralement du stock et de la camelote IA. Ratez la condition d'arrêt et il boucle indéfiniment ou s'arrête trop tôt.

C'est la même structure que le prompt en cinq parties couvert dans Prompt Engineering for Designers, adapté pour un travail en plusieurs étapes.

Un modèle de brief d'agent d'une page montrant les quatre sections (objectif, outils, règles, condition d'arrêt) sous forme de notes autocollantes de designer, style éditorial
Un modèle de brief d'agent d'une page montrant les quatre sections (objectif, outils, règles, condition d'arrêt) sous forme de notes autocollantes de designer, style éditorial

Recette 1 : l'agent recherche-vers-moodboard

Le premier agent que tout studio de design devrait construire. Il ingère une transcription d'appel de découverte client et produit un moodboard de première passe plus un court brief créatif.

Objectif. À partir d'une transcription d'appel de découverte, produire un moodboard dans Figma et un brief créatif dans Google Drive.

Outils nécessaires. Google Drive MCP (lire la transcription, écrire le brief), recherche web, récupération d'images, Figma MCP (écrire dans un frame de moodboard).

Structure du system prompt. C'est l'instruction que vous donnez à l'agent une seule fois, au début de la session.

You are a senior brand strategist at Brainy, a design studio with 2M+
community followers. Your job: turn a discovery call transcript into
a first-pass creative direction.

Goal:
- Read the transcript at the Google Drive URL I give you.
- Extract: client name, industry, audience, brand adjectives (3-5),
  competitors mentioned, any visual references they named.
- Produce two deliverables:
  1. A creative brief, saved as a Google Doc in /Brainy/Briefs/
     using our template at /Brainy/Templates/brief.docx.
  2. A Figma moodboard in the file I specify, populated with at
     least 12 editorial image references (no stock photography).

Rules:
- Use only editorial sources: Are.na, It's Nice That, Brand New,
  museum archives, design studio portfolios. Never Shutterstock,
  Getty, or Unsplash generic.
- Every image needs a source URL captioned on the Figma frame.
- Voice for the brief: Brainy house voice. Opinionated on craft,
  neutral on facts. No corporate filler.
- If the transcript is unclear on an adjective, flag it as "needs
  confirmation" in the brief instead of inventing one.

Stop when:
- Brief is saved, moodboard has 12+ captioned references, and you
  have posted the two URLs back to me.

C'est un brief d'agent fonctionnel. Collez-le dans Claude Desktop avec des connexions MCP à Drive et Figma, pointez-le vers une transcription, et relisez le résultat.

Ce que vous relisez. Les adjectifs sont-ils justes ? Les références sont-elles dans l'esprit de la marque et ne dérivent-elles pas vers l'évident ? A-t-il vraiment légendé chaque image avec une source ? Le brief est-il dans la voix maison ou a-t-il rechuté dans le jargon corporate de LinkedIn ?

Itération. La première passe sera approximative. Mettez à jour le system prompt avec ce que l'agent a raté. Relancez. Après trois ou quatre cycles, l'agent livre des briefs que vous pouvez remettre à un stratège en contact avec les clients sans les réécrire.

Recette 2 : l'agent spec-vers-handoff

Cet agent comble l'écart entre « le design est validé » et « le dev a tout ce dont il a besoin ». Il lit un fichier Figma et écrit le document de handoff pour les développeurs.

Objectif. À partir d'une URL de fichier Figma, produire un document de handoff développeur avec un inventaire de composants, une liste de tokens, des valeurs d'espacement et des questions ouvertes.

Outils nécessaires. Figma MCP, un endroit où écrire le résultat (Notion, issue GitHub, Google Doc, à votre choix).

Structure du system prompt.

You are a senior design systems engineer acting as the bridge
between a design team and a front-end team.

Goal:
- Read the Figma file at the URL I give you.
- Produce a handoff document containing:
  1. Component inventory: every component instance used, counted,
     with Figma component name and closest existing code component
     name from our /components/ directory.
  2. Token usage: every color, spacing, and typography variable
     referenced, compared against /design/tokens.css.
  3. Layout specs: breakpoints used, any auto-layout frames that
     might be ambiguous at edge cases.
  4. Open questions: a bulleted list of anything in the Figma file
     that cannot be resolved from the file alone (missing states,
     unclear interactions, content placeholders).
- Write the output as a Notion page in /Engineering/Handoffs/.

Rules:
- Never invent a component. If a Figma element does not map to an
  existing code component, list it under "new components required"
  with a one-line description.
- Flag every free-form (non auto-layout) frame as a risk.
- Include the Figma node ID for every item so devs can jump to it.
- Do not assume interactions that are not explicitly in the file.

Stop when:
- Notion page is written and you have posted the URL back to me.

Pourquoi cette recette compte. Le problème « le designer pensait avoir tout transmis, le dev n'a jamais trouvé les tokens » est un classique. Cet agent l'élimine en à peu près quatre-vingt-dix secondes par fonctionnalité.

Où ça casse. Sur les fichiers Figma qui sont un désordre. Des frames sans auto-layout, une utilisation incohérente des variables, des composants one-off aléatoires. L'agent met le désordre en évidence, ce qui est soit un cadeau (maintenant vous savez) soit un problème (maintenant vous devez le corriger).

Une maquette de document de handoff propre divisée en quatre sections étiquetées (composants, tokens, mise en page, questions ouvertes), composition éditoriale
Une maquette de document de handoff propre divisée en quatre sections étiquetées (composants, tokens, mise en page, questions ouvertes), composition éditoriale

Recette 3 : l'agent QA design

L'agent qui tourne après un déploiement et vous dit ce qui a mal été livré.

Objectif. Comparer une URL de staging déployée au fichier Figma de référence et signaler les dérives visuelles.

Outils nécessaires. Figma MCP, Playwright (pour prendre des captures d'écran de la page de staging), comparaison d'images (Claude peut comparer des images nativement dans son mode vision).

Structure du system prompt.

You are a senior product designer doing a pre-release visual QA pass.

Goal:
- Visit the staging URL I give you at three breakpoints: 1440px,
  768px, 375px.
- For each breakpoint, take a full-page screenshot using Playwright.
- Compare each screenshot to the corresponding Figma frame at the
  URL I provide.
- Produce a QA report listing every visual difference, categorized:
  - BLOCKING: wrong components, wrong colors, broken layouts
  - NON-BLOCKING: spacing off by less than 4px, minor type weight
    mismatches, image crops slightly different
  - INFORMATIONAL: intentional differences between design and code
    worth noting

Rules:
- Do not flag differences that are within 2px of intended spacing
  unless they visibly break alignment.
- Include a screenshot-with-annotation for every BLOCKING item.
- Link every item back to the Figma node ID.
- Output as a Markdown file in /qa/reports/ with timestamp.

Stop when:
- Report is saved and you have posted the path back to me.

Pourquoi cette recette compte. La plupart des équipes font le QA design manuellement ou pas du tout. Un agent QA tourne à chaque déploiement pré-prod. Il attrape les 80 % de dérives que les yeux manquent à la troisième page.

Comment les designers l'utilisent. Connectez-le au CI pour qu'il tourne automatiquement sur les déploiements de staging. Ou gardez-le manuel et lancez-le avant de livrer quoi que ce soit de visible. Dans les deux cas, vous cessez d'être le goulot d'étranglement pour « est-ce que ça a bien été livré ».

Ce que les agents ne peuvent pas faire (encore)

Soyez honnête avec vous-même. Voici où les agents échouent en avril 2026.

Les décisions de goût. L'agent vous livrera un moodboard compétent. Il ne peut pas vous dire que le moodboard est émotionnellement plat ou que la marque devrait miser davantage sur la retenue. Ça, c'est encore vous.

Les objectifs ambigus. « Améliore le site » n'est pas un objectif. L'agent boucle ou produit un résultat générique. Si vous ne pouvez pas énoncer l'objectif en une phrase avec une condition d'arrêt claire, l'agent n'a aucune chance.

La stratégie inédite. Les agents sont excellents pour exécuter une stratégie que vous avez définie. Ils sont mauvais pour en inventer une à partir d'une page blanche. Le positionnement, l'architecture de marque, les décisions produit fondamentales restent du travail humain.

Le jugement à long terme. Un agent peut vous dire « cette variante de Button n'est pas utilisée ». Il ne peut pas vous dire « nous allons bientôt lancer une page de tarification qui aura besoin d'une quatrième variante de Button, donc ne la supprimez pas ». L'agent voit l'instantané, pas la feuille de route.

Tout ce qui exige de la confiance avec un client ou un partenaire. Un stratège en contact avec les clients, un directeur artistique donnant du feedback à un freelance, un directeur créatif qui pitch une idée. Les agents assistent ces humains. Ils ne les remplacent pas.

La règle : les agents gèrent l'exécution. Les humains gèrent le goût, la stratégie et la confiance.

Penser comme un concepteur d'agents, pas comme un utilisateur d'agents

Il y a une différence entre utiliser des agents et les concevoir. La plupart des designers finiront par faire les deux.

Utiliser un agent, c'est du travail de prompt. Écrire un brief, relire le résultat, itérer.

Concevoir un agent, c'est du travail de système. Vous définissez l'objectif, choisissez les outils, écrivez les contraintes, fixez la condition d'arrêt et construisez une boucle de feedback pour que l'agent s'améliore au fil du temps. C'est plus proche de gérer une petite équipe que d'écrire un prompt.

Trois habitudes qui séparent ceux qui conçoivent de bons agents de ceux qui luttent avec des agents cassés.

Premièrement, ils écrivent le brief avant d'ouvrir l'outil. Pas de frappe avant que l'objectif, les outils, les règles et la condition d'arrêt soient sur le papier. Ça économise une heure de tâtonnements.

Deuxièmement, ils versionnent le system prompt comme du code. Stockez-le dans un fichier. Commitez-le dans git si vous pouvez. Chaque fois que l'agent échoue d'une nouvelle façon, vous ajoutez une règle. Le prompt devient plus intelligent avec le temps, pas plus bruyant.

Troisièmement, ils relisent chaque passe pour les dix premières passes. Pas de confiance par défaut. Chaque résultat est lu, évalué et utilisé pour mettre à jour le prompt. Après dix passes, l'agent est suffisamment fiable pour tourner en arrière-plan. Avant dix passes, non.

Si vous voulez d'autres analyses de workflows IA, parcourez le reste des Brainy Papers. Si vous voulez des workflows agentiques intégrés dans votre équipe sans les trois premiers mois de tâtonnements, faites appel à Brainy et nous livrons l'ensemble du stack.

Le plan de démarrage d'agents pour les designers

Une semaine, un agent, une boucle fonctionnelle.

  • Choisissez un workflow que vous faites régulièrement. Pas un workflow imaginaire. Un vrai que vous avez fait ce mois-ci.
  • Écrivez l'objectif en une phrase, la liste d'outils, les règles et la condition d'arrêt sur papier.
  • Configurez Claude Code ou Claude Desktop avec une connexion MCP (Figma, Drive, ou système de fichiers).
  • Collez le brief comme system prompt. Lancez l'agent sur une vraie entrée.
  • Lisez le résultat de façon critique. Évaluez-le par rapport à ce que vous auriez livré.
  • Mettez à jour le prompt avec ce qui a échoué. Relancez.
  • Répétez trois à cinq fois. Notez le temps que prend chaque passe par rapport à le faire vous-même.
  • Sauvegardez le system prompt final. C'est votre premier agent de production.

Faites ça une fois et le deuxième agent prend la moitié du temps. Le quatrième agent prend un après-midi. Le huitième agent tourne selon un calendrier pendant que vous dormez.

FAQ

Dois-je savoir coder pour construire un agent IA ?

Non. Chaque recette ci-dessus est configurée via un system prompt plus des connexions MCP, les deux étant configurés dans une interface ou une seule commande. Vous écrivez des briefs et connectez des outils, vous n'écrivez pas de code de production. Si vous pouvez configurer Zapier, vous pouvez configurer un agent.

Quelle est la différence entre Claude Code et un agent Claude ?

Claude Code est un agent spécifique, celui qui vit dans votre terminal et est conçu pour travailler avec des codebases. « Un agent Claude » est n'importe quel agent propulsé par le modèle Claude, ce qui peut être Claude Code, Claude Desktop avec des outils, un agent personnalisé construit via l'API Anthropic, ou un agent style ChatGPT utilisant Claude sous le capot. Claude Code est l'agent phare pour le travail designer-développeur en 2026.

Combien ça coûte de faire tourner un agent ?

Pour les designers individuels, un abonnement Claude Max ou un abonnement ChatGPT Plus couvre respectivement Claude Code et le mode agent. Ça tourne dans les quelques centaines de dollars par mois et inclut la plupart des outils dont vous avez besoin. Pour les équipes, l'utilisation de l'API évolue selon la fréquence de fonctionnement des agents. Le budget commence autour de 50 à 200 dollars par designer par mois pour une utilisation intensive. Pas cher comparé au temps que ça fait économiser.

Vous gérez maintenant une petite équipe

Vous étiez designer. On vous donnait des briefs et vous produisiez du travail. Ça fait toujours partie du job.

Maintenant il y a une deuxième partie. Vous écrivez des briefs pour de petites équipes d'agents qui produisent du travail pendant que vous faites la première partie. Vous relisez leurs résultats. Vous les corrigez quand ils dérivent. Vous mettez à la retraite les agents qui ne valent pas leur salaire et vous promouvez ceux qui le font.

Les designers qui saisissent ce basculement en premier vont dominer la décennie. Pas parce que les agents remplacent les designers, mais parce que les designers qui gèrent des agents remplacent les designers qui ne le font pas.

Choisissez un workflow. Écrivez le brief. Livrez le premier agent. Relisez le résultat. Recommencez lundi.

Want agentic workflows wired into your design team without the guesswork? Brainy ships the setup.

Get Started