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
- 2 mois jusqu'à la première version
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. Première version livrée en 2 mois au lieu de 6, à équipe constante, avec un frontend repris tel quel en production.
- La validation : pas de recherche amont. Cinq démonstrations, dont deux devant de vrais clients, ont décidé l'industrialisation.
- Mon rôle : Product Designer, seule designer, dans une équipe de six.
Nomad · opérateur fictif
Deux faces, une seule application
L'équipe de l'opérateur gère les comptes partenaires et les commandes. Le partenaire consulte son catalogue de profils. Les deux ne doivent jamais voir la même chose : un sélecteur sur l'avatar du header fait passer de l'un à l'autre, sans déconnexion.
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 sur l'avatar pour basculer. Reconstruction sur « Nomad », un opérateur inventé : aucune donnée, marque ou interface réelle.
D'un test d'interface à un mandat produit
eSIM Simple est né d'un petit prototype React que j'avais codé pour tester une nouvelle direction d'interface. Le PM y a vu un produit. La hiérarchie nous a alors confié un mandat : mener un produit de bout en bout en s'appuyant sur l'IA à chaque étape. Des consultants dédiés ont installé l'outillage.
Le produit sert deux publics. Le back-office opérateur et l'espace client partagent les mêmes objets (comptes, lots de profils, commandes), avec des droits et des priorités de lecture différents. Je les ai conçus ensemble, comme un seul système vu sous deux angles.
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 en code, jusqu'au frontend livré. Chaque écran partait d'esquisses et de mockups du parcours dans FigJam, validés avec le PM, puis se construisait directement en code.
La validation : cinq démonstrations
Ce projet n'a pas eu de phase de recherche utilisateur : le besoin était cadré en amont. La question était ailleurs : le produit tient-il quand on le manipule avec de vraies données ?
Le PM a porté seul les cinq démonstrations : devant les équipes commerciales, devant la hiérarchie, et deux fois devant de vrais clients. Elles ont décidé l'industrialisation. Le produit est aujourd'hui en cours de déploiement.
La décision clé : prototyper en code un produit livrable
Une maquette ne se branche pas à de vraies données : des centaines de profils, des états contradictoires, des cas limites qu'on ne dessine jamais. J'ai prototypé directement en code, avec les composants du design system, les états d'erreur, le responsive et l'accessibilité, comme si le prototype devait partir en production.
Le coût : cadrer l'IA, qui produisait spontanément du code hors design system (une table importée de Material, un bleu absent de la palette). Les règles du système n'étaient écrites nulle part : j'ai ouvert un chantier parallèle pour les encoder. Apprendre à une IA un design system qu'elle n'a jamais lu.
Le gain : le prototype a servi de spécification. Au handoff, il n'y avait plus rien à traduire, donc rien à interpréter. Et les contraintes techniques sont apparues pendant la conception, quand on pouvait encore arbitrer. Le produit livré ressemble à ce qui a été conçu.
Une autre décision : un sélecteur de contexte sur l'avatar
Chaque démonstration devait montrer les deux faces dans la même séance. Le vrai utilisateur de cette fonction, c'est la personne qui démontre : se déconnecter devant une salle coûte trente secondes et casse le fil. J'ai placé la bascule sur l'avatar du header, un pattern courant en B2B qu'une audience lit comme une fonctionnalité.
Le coût : deux contextes cohabitent, et seule la couleur du side panel signale où l'on se trouve. C'est insuffisant pour un produit de gestion de commandes. En production, ce serait une affaire de comptes et de rôles.
Résultats
Ce que le prototype a produit
6 → 2 mois
première version livrée en 2 mois au lieu de 6, à équipe constante, sur un projet d'envergure comparable
avec des consultants dédiés pour installer les outils
Zéro handoff
le frontend écrit pour 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
D'où viennent les 4 mois.5 semaines de handoff et 2 semaines de réunions d'idéation supprimées. Le reste vient du développement, qui a repris le frontend du prototype au lieu de le réécrire, et des allers-retours sur les complications techniques, réglés pendant la conception plutôt qu'au handoff.
Le statut.En cours de déploiement, commercialisation prévue. 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, car il faut écrire les règles que l'IA doit suivre et découvrir celles que personne n'avait formulées. En aval, il en rend beaucoup, puisque le handoff n'a plus rien à traduire.
Sa limite est à l'endroit de son coût : on n'encode que les règles qui existent. Là où le design system était silencieux, l'IA faisait des choix par défaut qu'il fallait arbitrer un par un.