Seule designer, même rythme : code en production avec l'IA

Je suis product designer, la seule chez Cloud-IAM, aux côtés d'une équipe d'ingénierie qui livre vite. Sur la console, je prends les décisions de design produit, le layout, la hiérarchie, le wording, les espacements, la façon dont une chose se comporte, puis je les livre moi-même dans le produit qui tourne, en fermant l'écart entre « voilà ce que cet écran devrait donner » et « le voilà, en direct dans le navigateur, qui se comporte comme je le voulais ». Je n'ai jamais écrit une ligne de code frontend ou backend. Claude Code écrit tout. Je dirige, je ne dessine pas.

Presque tout ce qui s'écrit sur le design avec l'IA part d'une page blanche : une idée neuve, un repo vide, une démo propre. Cet article n'est pas ça. J'ai rejoint un SaaS B2B existant dont l'interface avait été construite par des développeurs. Elle fonctionnait, et il y avait un design system derrière, mais un système mince, avec de vrais problèmes d'ergonomie. Mon travail est de le tirer vers un système cohérent sans casser ce sur quoi les gens s'appuient déjà : la version plus lente, moins glamour, du métier, un écran à la fois, dans une codebase existante, dans un produit déjà en ligne.

Le produit, rapidement : Cloud-IAM est une plateforme de gestion des identités et des accès basée sur Keycloak. Keycloak est le système open source que les applications utilisent pour le login, connexion, inscription, single sign-on, et qui a le droit de faire quoi, et nous l'hébergeons et l'opérons pour que les entreprises n'aient pas à le faire. La console est l'endroit où nos clients l'installent et le pilotent : déploiements, realms, utilisateurs, sécurité, extensions. C'est cette surface que je designe.

Travailler comme ça a changé la forme de mon métier autant que sa vitesse. Trois choses ont bougé sous mes pieds : le design a cessé d'être un fichier que je transmets, le plus dur a cessé d'être le dessin, et ce que je peux même designer s'est mis à dépendre de ce qu'il y a sous l'écran. Ensuite il y a la façon dont je pilote tout ça au quotidien, et l'installation qui me le permet. Voici l'ensemble.

Le handoff a disparu

Pendant l'essentiel de ma carrière, le design s'arrêtait à un handoff. Je travaillais un écran jusqu'à ce qu'il soit juste dans Figma, je rédigeais la spec, et je la passais à un développeur qui en faisait le vrai produit. Tout ce qui venait après (les cas limites, les vraies données, les interactions qu'une maquette statique ne peut pas montrer) se passait sans moi, et la distance entre ce que je dessinais et ce qui partait en production était l'endroit où le travail pouvait discrètement se perdre.

Aujourd'hui, je saute le handoff. Je designe dans le produit qui tourne, et le design est la chose qui part en production. Pour rendre ça concret, voici un même travail, ajouter une fonctionnalité de zéro à la production, l'ancienne méthode à côté de la nouvelle.

Claude Code a estimé ceci à partir de notre façon de travailler le design sur les trois derniers mois : une fonctionnalité qui prenait deux à trois semaines de zéro à la production part maintenant en quelques jours, jusqu'à 60 % plus vite, selon le changement. Presque rien de ce gain ne vient d'un design plus rapide. Il vient des réunions, des handoffs et des allers-retours de QA design qui ont simplement cessé d'exister, parce qu'il n'y a plus d'écart à surveiller entre mon travail et le build.

Une partie vient aussi de la fidélité de l'endroit où je travaille. Une maquette Figma ne porte mon intention que sur le chemin idéal, donc un développeur doit deviner les cas limites qu'elle n'a jamais montrés, et quand il devine autrement que ce que j'imaginais, on perd un tour en réunion. Une vraie bibliothèque de composants réduit cet écart, bien sûr, mais elle montre chaque pièce isolément. L'écran entier ne prend forme que dans le produit qui tourne, et c'est là que je préfère rencontrer les surprises, avant qu'un client ne le fasse.

Le design a cessé d'être un fichier que je transmets. Il est devenu le produit lui-même.

Le goulot d'étranglement s'est déplacé

On suppose que la partie lente du design, c'est le dessin. Sur un produit comme celui-ci, ça n'a jamais été le cas. Cloud-IAM, un SaaS B2B, a des fonctionnalités denses, et les gens qui les utilisent sont des profils techniques. Le plus dur, c'est de comprendre une fonctionnalité assez bien pour la designer honnêtement, et pendant des années, obtenir cette compréhension passait par une chaîne de handoffs : je demandais à un développeur de me l'expliquer, je la maquettais dans Figma, je revenais retravailler les cas limites que j'avais manqués, je posais d'autres questions, et seulement là j'arrivais à quelque chose de final.

Maintenant, le premier geste est une conversation. Comprendre la technicité d'une fonctionnalité me demandait quelques allers-retours de discussions avec les développeurs. Je le fais désormais avec Claude en une seule session, avant de commencer à designer, et parfois pendant que je designe. C'est comme avoir une personne technique capable de me répondre à tout moment. Je lui demande de me mettre à niveau sur la fonctionnalité et la personne à qui elle s'adresse :

can u get me the general context of this feature, what it does and what the user is trying to achieve

whats the link between the screen "upgrade" and the releases?

Ensuite je designe à partir d'une vraie compréhension au lieu de deviner. Sur un produit aussi dense, c'est la différence entre un écran auquel un utilisateur technique fait confiance et un écran qu'il contourne en silence. Le goulot d'étranglement était la communication : obtenir qu'un développeur construise ce que je voulais dire. C'est désormais la compréhension : saisir la fonctionnalité, et la personne à qui elle s'adresse, assez bien pour la designer. Le plus dur a atterri au bon endroit, parce que cette compréhension a toujours été mon travail, pas celui de quelqu'un d'autre.

La donnée décide de ce que je peux designer

Travailler dans un produit vivant m'a appris quelque chose qu'un prototype ne pouvait pas m'apprendre : ce qui décide de la façon dont je designe un écran, ce n'est pas son apparence, c'est ce qu'il y a dessous. Chaque changement part en merge request, et ce que je peux en faire dépend entièrement de la donnée : est-ce qu'elle existe déjà, et est-ce que je la contrôle.

La plupart des jours, le changement ne touche rien en dessous : cohérence, layout, espacements, hiérarchie. Ce genre de nettoyage vit entièrement dans l'interface, donc je le prends de bout en bout, seule : branche, changement, revue en direct, livraison. Il n'y a rien à attendre.

Parfois, le design que je veux a besoin d'une donnée que le backend n'expose pas encore. Là, je construis l'écran tel qu'il devrait fonctionner, je mocke la donnée manquante, et je le montre à l'équipe en direct avant d'expliquer aux développeurs ce qu'il faut brancher. À ce moment-là, le design est la spec : il montre exactement quoi ajouter et comment ce sera utilisé, donc le travail backend se cadre sur quelque chose de réel plutôt que sur un paragraphe dans un ticket.

Et parfois la donnée vient d'une source qui ne nous appartient pas, une API ou un flux externe. Alors je peux façonner la façon dont elle se lit : le regroupement, l'ordre, ce que l'écran montre quand il n'y a rien à montrer ou que la source met du temps à répondre. Mais je ne laisserai pas l'interface prétendre contrôler des chiffres qu'elle ne contrôle pas.

Savoir dans laquelle de ces trois situations je me trouve avant de commencer, c'est la moitié du travail. Ça me dit si je suis libre de livrer, en train de spécifier une donnée qui n'existe pas encore, ou en train de donner du sens à une donnée que je ne contrôle pas.

Ce qui décide de la façon dont je designe, ce n'est pas l'apparence de l'écran. C'est ce que le changement touche en dessous.

Diriger, concrètement

Je viens de l'architecture, et ce bagage continue de porter tout ce que je fais ici. L'architecture vous apprend à tenir une structure entière en tête pendant que vous travaillez sur une seule pièce, à sentir comment une décision à un endroit pèse sur une autre. C'est, au fond, l'essentiel de ce métier : tenir plusieurs fils à la fois, cartographier ce dont un travail a besoin avant de le commencer, faire avancer quelques branches et merge requests en parallèle sans qu'elles se percutent.

Si le design est désormais le produit qui tourne, mon travail est de l'y conduire. Je n'écris pas des spécifications ; je réagis à ce qui est à l'écran et je le pousse vers ce qu'il devrait être. Mes messages sont courts, en minuscules, visuels, et prompts à changer de direction. Quelques habitudes reviennent dans presque chaque session.

Regarder, pas lire

Je juge le travail en le regardant, jamais en lisant le code. Presque chaque demande se termine par une variante de :

ok give me in local this page and lets iterate

La boucle est toujours la même : brancher, regarder l'app qui tourne, réagir, ajuster, regarder à nouveau. Et quand il n'y a encore rien à regarder (un tableau vide ne dit rien de ses propres contrôles), je commence par le rendre visible :

mock me some data in the table

Claude sème de fausses lignes, et d'un coup je peux regarder le tri, la pagination et les espacements se comporter avant de m'engager sur quoi que ce soit.

Corriger, pas spécifier

Mes meilleurs résultats sortent de corrections, pas de premiers jets. Quand le premier essai est faux, je le nomme simplement et je re-spécifie en termes concrets, visuels :

ok i see you did the side menu in medium weight. put them back. i meant the menu of the top bar

u took it too literal i think. the install button can stay where it is. the rest can change.

C'est l'aperçu en direct qui rend ça peu coûteux. Il me laisse changer d'avis, même revenir sur une décision prise une heure plus tôt, une fois que je la vois devant moi : « ok make the top bar items as in the deployments i think it was better. » Et je donne le feedback comme un principe, pas comme un pixel : proximité, ordre de lecture, étiquetage honnête, retenue. Claude comprend ce vocabulaire, donc je travaille avec lui comme avec un autre designer senior, au lieu de narrer « décale ça de 4px à gauche ». Nommer le principe, c'est ce qui porte l'intention : la correction tient sur tout l'écran, pas seulement à l'endroit que j'ai pointé. Sur le drawer des releases, je n'ai jamais demandé à personne de déplacer une boîte ; j'ai fait remarquer que l'écran obligeait à choisir une release d'abord puis à remonter chercher les détails qui justifiaient le choix, alors on l'a reconstruit pour qu'il se lise dans l'ordre où la décision se prend vraiment.

La décision reste la mienne

Je parle à Claude comme à un collègue designer, c'est-à-dire que j'ouvre le raisonnement au lieu de simplement donner des ordres :

so ill tell u my issues with this screen layout:...

what do u think?

Cette dernière question revient tout le temps, et je la pense vraiment : c'est un partenaire de réflexion, pas un distributeur dans lequel je glisse des instructions. Quand je doute vraiment, je ne tranche pas dans l'abstrait ; je fais construire les options à Claude et cacher un interrupteur à l'écart pour les comparer en direct :

build me 3 variants and put a toggle in absolute position somewhere so its not impacting the design

Parfois je garde une version déjà assez bonne au chaud pendant que je poursuis une V2 que mon instinct préfère. Et une fois la direction posée, je tranche et je nettoie le reste, pour ne rien laisser de mort derrière :

none of the rest is good, keep only V2

Je nomme le principe, pas le pixel. La dernière décision reste la mienne.

Ce qui tient l'ensemble

Rien de tout ça ne marche grâce à des prompts astucieux. Ça marche grâce au contexte. J'ai tout installé une fois, et maintenant Claude a un accès permanent à la base de code via Claude Code (chaque fichier de la console, les conventions, le design system, et les notes que j'ai écrites sur ma façon de travailler), donc il lit et écrit le code et fait tourner l'app sur staging, jamais sur la production. Je ne réexplique jamais le projet, et j'en suis venue à croire que ça compte bien plus que la formulation d'un prompt : un prompt astucieux posé sur zéro contexte ne donne que la supposition confiante d'un inconnu.

La forme de l'installation :

Autour du repo, une poignée d'outils donne à Claude des yeux, des oreilles et une surface de travail :

• Un aperçu en direct persistant sur http://localhost:3000, connecté à staging, la page où je designe vraiment. Chaque fois que Claude crée une branche, il me tend ce lien, pour que je puisse commencer à regarder tout de suite.
• Figma, pour que Claude lise mon UI kit (les composants et tokens que je garde volontairement lisibles par l'IA) et redessine dans les fichiers ; ça marche dans les deux sens.
• Mobbin, pour pointer Claude vers la façon dont de bons produits résolvent le même problème quand je veux un regard neuf, au lieu de l'inventer seule à mon bureau.
• Slack, pour qu'il lise les canaux de l'équipe et les retours clients qui y atterrissent, ce qui nourrit ma façon de trier ce qui est même un problème de design.
• GitLab, où le travail est suivi et livré. Je ne tape pas de commandes git ; les règles (brancher depuis staging et jamais main, un format de commit strict sinon le push est rejeté) sont encodées une fois pour que Claude les applique sans que je les voie jamais.

Quand Claude dérive vers le parler développeur et commence à me perdre, il y a un mode dans lequel je le bascule — un skill custom que nous avons créé :

lets alexandra dev

Il fait une seule chose : garder Claude en train de me parler comme à une designer. Pas de jargon, une étape à la fois, raconté en termes de ce que je devrais voir plutôt que de ce qui s'est passé dessous. Quand quelque chose passe au rouge, c'est normal : « le rouge, c'est juste l'ordinateur qui pointe la petite chose à corriger ensuite. » C'est un bouton de volume pour la technicité de Claude, et quand il dérive trop profond, ça redescend le curseur à mon niveau.

Mises bout à bout, ces pièces forment une seule boucle avec une couture nette au milieu : ma moitié, c'est le design et la structure ; celle de l'équipe, la vérification et la sécurité. Chaque merge request que j'ouvre est relue par un ingénieur avant de partir en production.

Ce qu'est devenu le métier

J'en suis venue à penser que ça fait simplement partie du métier maintenant : une product designer devrait améliorer l'UX de sa propre façon de travailler, pas seulement celle du produit. Chez Cloud-IAM, l'équipe technique cherche en permanence de meilleures façons d'opérer, et voilà où nous en sommes en juin 2026. Dans quelques mois, ça aura peut-être changé, ou creusé plus loin ; pour l'instant, ça tient.

Ce qui me surprend, c'est que je ne suis pas sûre de pouvoir revenir confortablement à un design uniquement dans Figma. Travailler comme ça me laisse plus de contrôle (plus dans le siège d'orchestration que dans celui du dessin), et ça retire une couche de friction que j'avais cessé de remarquer. Une maquette attire doucement votre attention sur le fichier lui-même : ses composants, ses variantes, son auto-layout, alors que ce qui compte vraiment, c'est l'effet que le produit fait entre les mains de quelqu'un. Designer dans la version vivante me garde les yeux sur ça, plutôt que sur son substitut.

Ce n'est pas sans friction pour autant. Comme il y a soudain la place d'en faire plus, et plus vite, j'ai essayé de mener plusieurs choses en parallèle comme le font certains développeurs, et je suis tombée sur quelque chose de propre au design. Deux tâches superficielles en même temps, ça va ; mais quand les deux demandent de vraies décisions, basculer entre ces profondeurs pendant que Claude réfléchit sur chacune est réellement difficile ; le jugement de design ne change pas de contexte aussi proprement que le code semble le faire. Alors je garde le travail profond sur un seul fil à la fois, et je laisse le parallélisme aux choses plus légères.

Je ne suis toujours pas développeuse, et je n'ai pas besoin de le devenir. Le design est devenu la chose qui part en production, et ça m'a déplacée de la fin du processus vers son milieu, là où les décisions se prennent vraiment.

Pourquoi j'ai écrit cet article

C'est Claude Code qui a écrit les mots de cet article, à partir de mon vrai travail des trois derniers mois plutôt que d'un brief que j'aurais dicté. Je n'avais pas ouvert Figma pour la console de tout ce temps, donc Claude avait déjà le contexte qu'il fallait : ma façon d'aborder le travail, ma façon de parler, notre façon de collaborer.

Mais l'article est le mien. J'ai lancé l'idée, façonné sa structure, puis vérifié, recoupé, et simplifié le texte jusqu'à ce qu'il se lise comme je le voulais.

Je l'ai demandé parce que je n'ai pas trouvé grand-chose d'écrit sur ce cas précis : une designer qui met du code en production avec l'IA au sein d'une entreprise SaaS B2B existante, plutôt que quelqu'un qui part d'une page blanche.

Voilà donc une étude de cas d'une seule personne : trois mois de vrai travail, mesurés.