Design-to-code
eSIM Simple
Concevoir et coder un produit de bout en bout avec l'IA, du premier écran au frontend livré.
- Thales
- Product Designer
- 6 mois
Un prototype conçu pour être montré, et écrit pour être gardé.
- Le produit : un espace de gestion de commandes eSIM à deux faces, back-office opérateur et espace client, conçu et codé en 2 mois. Sept semaines supprimées du cycle, et un frontend qui part en production tel quel.
- La validation : pas de recherche amont : cinq démonstrations, dont deux devant de vrais clients, et une décision d'industrialisation à la clé.
- Mon rôle : Product Designer, seule designer, dans une équipe de six : un PM, un architecte, un Scrum Master, deux développeurs.
Nomad · opérateur fictif
Deux faces, une seule application
Le produit sert deux publics qui ne doivent jamais voir la même chose : l'équipe de l'opérateur, qui gère les comptes partenaires et les commandes, et le partenaire lui-même, qui consulte son catalogue de profils. Un sélecteur placé sur l'avatar du header fait passer de l'un à l'autre, sans déconnexion, sans écran de login, sans rupture au milieu d'une démonstration.
Prototype de démonstration. Partenaires, codes et sites sont fictifs, Nomad est un opérateur inventé.
Comptes partenaires
| Statut | Actions | ||||
|---|---|---|---|---|---|
| Solaris Mobile | SOL-6690 | LYN | Brouillon | 11 mars 2026 | |
| Corvus Wireless | COR-8834 | PRTHMBGDN | En attente | 03 mars 2026 | |
| Verano Móvil | VER-5093 | LYNPRT | Actif | 28 févr. 2026 | |
| Meridian Telecom | MER-4471 | LYNPRTHMB | Actif | 14 févr. 2026 | |
| Kestrel Connect | KES-3318 | HMBPRTSEV | Actif | 07 févr. 2026 |
Cliquez ou touchez l'avatar pour basculer. Reconstruction neutre sur « Nomad », un opérateur inventé : aucune donnée, aucune marque ni aucune interface réelles n'y figurent.
Reconstruction neutre sur « Nomad », opérateur inventé : aucune donnée, aucune marque ni aucune interface réelles.
Le projet
eSIM Simple n'a pas commencé comme un projet. Pour tester une nouvelle direction d'interface, j'avais développé un petit prototype en React. Le PM y a vu autre chose qu'une expérimentation, et la hiérarchie nous a confié un mandat plus large : mener un produit de bout en bout en nous appuyant sur l'IA à chaque étape, de l'idéation au développement. Des consultants dédiés nous ont aidés à mettre en place les outils.
Le produit : un espace de gestion de commandes eSIM. Deux publics dès le cadrage, et ce n'était pas un détail d'implémentation. Le back-office opérateur et l'espace client partagent les mêmes objets — des comptes, des lots de profils, des commandes — mais pas les mêmes droits, ni les mêmes priorités de lecture. Concevoir les deux séparément aurait produit deux produits ; les concevoir ensemble a produit un seul système avec deux points de vue.
Restait à décider comment le construire. Une maquette aurait suffi à illustrer des écrans, pas à répondre à la question posée : est-ce que ça tient quand on manipule de vraies données ? Un catalogue de profils, ce sont des centaines de lignes, des états qui se contredisent, des cas limites qu'on ne dessine jamais dans une maquette. J'ai continué en code — et le prototype a fini par servir trois usages à la fois : tester en environnement réel, donner quelque chose à montrer et à faire commenter, et donner aux développeurs une base sur laquelle s'appuyer.
Mon rôle
Product Designer, seule designer, dans une équipe de six : un PM, un architecte, un Scrum Master, deux développeurs.
Idéation, architecture de l'information, conception des écrans, prototypage directement en code, jusqu'au frontend livré.
La validation
Ce projet n'a pas donné lieu à une phase de recherche utilisateur : le besoin était cadré en amont, et la question posée était ailleurs. Le produit tient-il quand on le manipule ?
Le PM a porté seul les cinq démonstrations : devant les équipes commerciales, devant la hiérarchie, et deux fois devant de vrais clients. Le prototype n'a jamais été distribué au-delà : il n'avait pas à l'être. Il devait tenir devant les bonnes personnes, et décider de la suite.
C'est ce qu'il a fait. Le produit est aujourd'hui en cours de déploiement.
La décision clé
Prototyper en code, pas en Figma.
Une maquette ne se branche pas à de vraies données. En prototypant en code, j'ai pu itérer sur des cas réels plutôt que sur des états idéaux, et manipuler le produit au lieu de le décrire.
Le coût de ce parti pris : beaucoup plus d'effort en amont pour cadrer l'IA, qui produisait spontanément du code hors design system — une table importée de Material ici, un bleu absent de la palette là. Les règles du système n'étaient écrites nulle part ; elles vivaient dans la tête des designers. J'ai ouvert un chantier parallèle pour les encoder. Apprendre à une IA un design system qu'elle n'a jamais lu.
Le gain : sept semaines de cycle en moins, et un produit qui ressemble à ce qui a été conçu.
Deux autres décisions
Écrire un prototype livrable plutôt qu'un prototype jetable.
Un prototype de démonstration n'a besoin de tenir que le temps d'un rendez-vous. Le mien a été écrit comme s'il devait survivre : composants du design system, états d'erreur gérés, responsive, accessibilité tenue.
Le coût : du temps passé sur des choses qu'aucune démonstration ne rend visibles, et l'effort de cadrer l'IA pour qu'elle produise du code structuré plutôt que du code qui affiche.
Le gain, d'abord en temps. Le prototype a tenu lieu de spécification au moment de la livraison. Cinq semaines de handoff et deux semaines d'idéation ont disparu du cycle, et l'effet s'est propagé au-delà de mon périmètre : rien à traduire, donc rien à interpréter, pas d'écart entre l'intention et l'implémentation à recetter, et un guide utilisateur rédigé devant un produit qu'on manipule au lieu de le décrire.
Le gain, ensuite en fidélité, et c'est le plus important. Sur une maquette, la contrainte technique se découvre à la livraison, et c'est le design qui plie pour s'y adapter. En prototypant en code, elle se découvre pendant la conception, quand il est encore possible d'arbitrer. Le produit qui part en production ressemble à ce qui a été conçu, pas à ce qu'il en restait après négociation.
Un sélecteur de contexte dans le header plutôt que deux applications.
Le produit a deux faces : un back-office pour l'opérateur, un espace pour le client final. Le besoin est apparu à l'usage : chaque démonstration devait montrer les deux dans la même séance, quel que soit l'auditoire.
Le vrai utilisateur de cette fonction n'est donc ni l'opérateur ni son client, c'est la personne qui démontre. En production, chacun aurait son propre compte et le passage d'une face à l'autre n'existerait pas. Mais en démonstration, se déconnecter et se reconnecter devant une salle coûte trente secondes et un écran de login : le fil est rompu. J'ai placé la bascule sur l'avatar du header.
Le coût : deux contextes cohabitent dans une seule application, et rien n'empêche d'agir dans le mauvais périmètre. La couleur du side panel, claire côté back-office et sombre côté client, est aujourd'hui le seul signal permanent, et c'est insuffisant pour un produit de gestion de commandes. En production, ce serait une affaire de comptes et de rôles, pas un bouton.
Le gain : on passe d'une face à l'autre sans rupture, et le pattern — un sélecteur de compte sur l'avatar — est assez banal dans les produits B2B pour ne pas trahir la démonstration. Une audience qui le voit voit une fonctionnalité, pas une maquette. C'est l'inverse exact du bouton de réinitialisation de Demo Kit, qu'il fallait cacher. Accessoirement, une seule base de code à maintenir pour les développeurs.
Résultats
Ce que le prototype a produit
7 semaines
supprimées du cycle : 5 de handoff, 2 d'idéation.
avec des consultants dédiés pour installer les outils
Zéro handoff
le frontend écrit pendant les démonstrations est celui qui part en production.
5
démonstrations, dont deux devant de vrais clients, à l'origine de la décision d'industrialiser.
portées par le PM seul, jamais distribué au-delà
Le statut.Le produit est en cours de déploiement et sera commercialisé. Pas encore de données d'usage réel.
Ce que j'en retiens
Le design-to-code ne fait pas gagner du temps partout : il le déplace. En amont, il en coûte, il faut écrire les règles que l'IA doit suivre, et découvrir en chemin toutes celles que personne n'avait jamais eu besoin de formuler. En aval, il en rend beaucoup : là où se trouvait le handoff, il n'y a plus rien à traduire.
Sa limite est exactement à l'endroit de son coût. On ne peut encoder que les règles qui existent déjà. Partout où le design system était silencieux, l'IA produisait des choix par défaut qu'il fallait arbitrer à la main, un par un. Et un prototype écrit pour durer ne décide pas seul de son industrialisation, mais il enlève la principale raison de ne pas le faire.