Dust conçoit un outil de productivité pensé pour travailler avec des agents. L'équipe design compte trois product designers et un brand designer, pour vingt à vingt-cinq ingénieurs. Tous les designers poussent des PR. Edouard Wautier a auparavant construit l'équipe design d'Alan, jusqu'à vingt-cinq ou trente personnes. Il détaille ici ses flows, ses règles de gouvernance et sa vision du métier.
Sommaire10 sections
- 1.Le design engineering n'est pas nouveau
- 2.Du Figma au code, la sandbox Playground
- 3.Qui review les PR des designers ?
- 4.Quand les ingénieurs produisent plus
- 5.La qualité de la décision devient la compétence clé
- 6.Concevoir pour un utilisateur agent
- 7.Des rituels sans gatekeeper
- 8.Devenir builder, avec de vrais projets
- 9.Personne n'a raté le train
- 10.Le replay
1. Le design engineering n'est pas nouveau
Des designers qui codent, il y en a toujours eu. Edouard Wautier vient du design industriel. On y apprend à connaître les matériaux pour concevoir avec. Il applique la même logique au digital : comprendre le médium aide à concevoir pour lui.
Chez Withings, il construisait ses propres interfaces pour afficher des écrans sur le hardware. Chez Alan, il a tenté de former ses designers au code. L'expérience n'a pas pris.
Ce qui change avec l'IA : produire du code devient simple. Produire du bon code reste difficile. La barrière baisse, et les excuses disparaissent.
"Si tu ne fais pas du code, tu es toujours dépendant de ce que les outils qu'on te donne t'autorisent à faire."
2. Du Figma au code, la sandbox Playground
D'où vient le changement
Edouard a découvert une autre façon de travailler sur des projets perso. Il part du besoin, décrit, observe le résultat et converge vers une solution. Il compare cette approche à du modelage plutôt qu'à un plan. Il a ensuite cherché à reproduire ce mode de travail au bureau.
Le dispositif
Un petit serveur tourne à côté du Storybook qui héberge le design system. L'agent est guidé pour utiliser ce design system. Le Playground se lance en une ligne. Vercel déploie chaque PR avec un lien public, partageable sur Slack. Edouard accompagne souvent ce lien d'un screencast. Toute l'équipe design l'utilise.
Le flow
Sa stack tient en deux étapes : un carnet papier pour tester des idées, puis la sandbox dès qu'une solution se dessine. Pour un gros projet, le prototype sert de spec à l'équipe projet. Pour une petite modification, il donne le prototype à un agent, qui pousse une PR. Un ingénieur la revoit, puis elle est mergée.
Avant, la même correction passait par un Figma, une spec et une bataille de priorisation. Elle sortait deux à trois semaines plus tard.
"Je commence à travailler dessus début de matinée, fin de matinée, c'est plié, c'est shippé."
Figma reste utilisé, notamment pour la librairie d'assets. Pour une refonte majeure du produit, pas de raccourci : il faut des ingénieurs et une décision collective.
3. Qui review les PR des designers ?
Le code du Playground n'est pas relu. C'est du prototype jetable. La question se pose dès qu'on modifie la code base en prod. Pour Edouard, ce sera probablement le sujet numéro un dans les entreprises.
Recevoir des PR du CEO, du CPO, des PM et des designers peut épuiser un ingénieur. Chez Dust, la règle est claire : l'ingénieur qui valide la PR en est responsable. S'il n'est pas motivé, la PR ne part pas. En pratique, une correction répond souvent à un pain point. Les ingénieurs ont alors intérêt à la merger.
"Le truc à apprendre peut-être pour les designers, c'est comment est-ce que tu fais un truc qui peut se revoir, se vérifier en une minute et demie ou deux minutes."
Au-delà du code, il y a une question de décision. Un ingénieur ne peut pas savoir seul si une direction produit est la bonne.
4. Quand les ingénieurs produisent plus
See it, say it, fix it
Les ingénieurs poussent de plus en plus de choses. Personne ne repense l'ensemble. Edouard cite une page de settings où les ajouts s'étaient accumulés en deux mois. Il l'a corrigée en une heure. Dust applique un principe : see it, say it, fix it. C'est la responsabilité de tout le monde.
"Le problème et la solution résident au même endroit."
Un design system pour les agents
Ce qui charge les designers, c'est la qualité de l'UI et de l'UX produites par les ingénieurs. Un design system bien conçu et bien documenté améliore cet output. La documentation des patterns et le guidage des agents comptent autant. La technicité des équipes design system augmente.
"Le client du design system ça devient des agents qui travaillent sur le produit."
Plus de designers, pas moins
La productivité des designers n'a pas augmenté autant que celle des ingénieurs. Produire beaucoup rend aussi les résultats difficiles à évaluer. Edouard rappelle la logique du MVP : s'assurer que chaque décision est bonne. Si les designers ne font que corriger l'UI, ce temps de décision disparaît.
"Il faut que les designers aient du temps à passer sur la qualité de la décision."
Une product team, pas deux camps
Opposer designers et ingénieurs rejoue l'ancien clivage back-end contre front-end. Les designers produisent de plus en plus de code. Les ingénieurs n'ont plus le blocage de la page blanche. Edouard pense plutôt en product team aux compétences complémentaires.
5. La qualité de la décision devient la compétence clé
Un bon design system permet de produire des écrans corrects sans designer. Produire des écrans perd donc de la valeur. Un designer qui ne sait faire que ça sera en difficulté.
Edouard ne recrute pas sur la maîtrise de Claude Code. Il juge l'outil relativement facile à apprendre. Il cherche la capacité à poser les bonnes questions en discovery. Et à relier des frameworks aux objectifs business.
Cela pose une question pour les juniors. La progression d'un designer partait souvent de l'UI pour monter vers le business. La formation doit être repensée.
6. Concevoir pour un utilisateur agent
Le harnais
Dust ne conçoit pas directement les agents, mais le harnais qui les entoure. Il regroupe les outils et les capacités de contrôle donnés au modèle. Dans cette image, l'utilisateur est sur le cheval, le cheval étant le modèle.
"Tu as vraiment une bête qui est le modèle, qui est très intelligent, mais qui tout seul est un cerveau dans un bocal."
Le principe de symétrie
Chez Dust, chaque élément doit être contrôlable par un humain et par un agent. Un designer pense spontanément une page d'admin avec des settings. Un agent gère probablement mieux la tâche. Exemple : l'utilisateur annonce cinq nouveaux arrivants, et l'agent gère les invitations.
Des API, pas de l'UI
Un agent peut naviguer dans une interface pensée pour les humains. Edouard l'a testé pour retrouver des justificatifs sur Qonto. Résultat : quarante-cinq minutes et beaucoup de tokens pour un résultat moyen. Les agents ont besoin d'API, exposées aujourd'hui via des serveurs MCP. Dust en utilise en interne, invisibles pour l'utilisateur. Il faut penser les primitives du produit sous une forme textuelle, exploitable par un agent.
7. Des rituels sans gatekeeper
Des design sprints recomposés
La méthode d'origine vise surtout les startups early stage. Edouard en utilise les exercices comme des briques réagençables. Chez Alan, elles servaient à écrire des roadmaps collaboratives à l'échelle de l'entreprise. Chez Dust, il s'en sert ponctuellement pour traiter les retours du GTM et des sales.
Des design reviews informelles
Edouard dit avoir abandonné tout contrôle. Chaque designer décide, communique et demande du feedback. Son avis n'est jamais imposé. Le designer le traite comme un retour de user test. Ce fonctionnement horizontal tient à l'échelle actuelle de l'équipe. La condition : une direction partagée, un drapeau vers lequel tout le monde avance.
8. Devenir builder, avec de vrais projets
Pour Edouard, il faut simplement faire des choses. Cela demande un abonnement à Lovable ou à Claude Code. Un projet perso oblige à penser comme un entrepreneur ou un PM.
Tester l'outil sans objectif ne suffit pas. Sans contrainte, on ne découvre pas les limites. Il faut un vrai projet, tenu jusqu'à la livraison.
Côté outils, il alterne principalement entre Cursor, Claude Code et Codex.
9. Personne n'a raté le train
Beaucoup de designers sont anxieux face au changement. Edouard pense qu'on est tout au début. Le danger est de mettre la tête dans le sable. Il invite aussi à relativiser ce qui circule sur LinkedIn et Twitter. Très peu d'équipes ont bouclé un produit construit de A à Z par des agents.
"Personne n'a raté le train. Le train, il n'a pas encore quitté la gare."