Codex + un outil secret, c'est le workflow de design qu'on utilise dans notre agence… et le résultat est vraiment d'un autre niveau.
Je le dis depuis des mois. Si ton appli a l'air d'une daube d'IA, ce n'est pas un problème de Codex. C'est un problème de workflow.
La plupart des builders tournent en rond. Ils livrent des fonctionnalités avec l'IA. Le backend marche. La logique est solide. Mais l'interface ressemble à toutes les autres apps « vibe codées ». Les utilisateurs décident en deux secondes si ça fait pro.
L'ancienne solution, c'était d'embaucher un designer. Attendre des semaines pour des fichiers Figma. Puis regarder ton développeur interpréter ces maquettes et les recoder. Le temps que le design soit en ligne, tu avais perdu l'élan et brûlé du cash inutilement.
Tout ce processus est désoptionnel.
Pour ce tuto, j'ai construit Haven, un concept d'appli immobilière mobile. Système de design complet en 20 minutes. Chaque écran designé en moins d'une heure. Code de production livré via Codex sans réécrire une seule ligne de CSS.
C'est le workflow que j'utilise maintenant. Et tous les builders qui livrent avec l'IA doivent comprendre comment ça marche.
Ce qu'est vraiment Moonchild
L'outil secret, c'est Moonchild.
J'ai testé presque tous les outils de design IA lancés cette année. La plupart donnent un premier écran correct, puis s'effondrent dès qu'on crée une deuxième page. La cohérence est le problème. Moonchild le résout comme rien d'autre.
C'est un canvas de design piloté par chat qui démarre à partir de ton système de design. Pas d'un prompt vide. Pas d'une capture d'écran. De ton vrai système. Tu importes ton système de trois façons :
→ Import depuis Figma, GitHub ou une URL en ligne
→ Décris ta marque à son Agentic Design System Builder
→ Dépose des inspirations design depuis Dribbble ou ailleurs
Une fois le système en place, tu ne fais plus des prompts design à l'ancienne. Tu colles un PRD. Il génère des écrans complets en respectant ton système. Tu fais du « art direction » à partir de là.
Et c'est l'export qui boucle la boucle. Moonchild livre un connecteur MCP qui envoie directement tes designs dans Codex en sortie structurée. Pas une capture d'écran à interpréter. Les vraies données design. Composants, tokens, mise en page, tout.
C'est ça, le workflow. Maintenant, voici comment l'utiliser concrètement.
Le problème avec la façon dont la plupart des builders utilisent l'IA pour le design
Voilà ce que la plupart des builders font.
Ils demandent à Codex de coder une nouvelle fonctionnalité. Ça sort. Ça a l'air correct. Puis ils demandent la fonctionnalité suivante. Ça a l'air un peu différent. À la cinquième fonctionnalité, l'appli ressemble à cinq produits différents assemblés.
C'est ce que les gens veulent dire quand ils disent que le design IA est mauvais.
Le modèle n'est pas mauvais. C'est le workflow.
Codex n'a aucune idée de ton langage de design. Chaque prompt est un contexte frais. Chaque écran est une supposition. Chaque composant dérive du précédent. Les couleurs dérivent. La typographie dérive. Tout s'accumule.
La solution est simple. Donne à Codex un système à suivre. Puis donne-lui le vrai design à coder.
La plupart des workflows ne donnent qu'un des deux. Moonchild plus la connexion MCP donne les deux en même temps.
Étape 1 : Construis ton système de design d'abord. Toujours.
C'est l'étape que tout le monde saute. Et c'est la plus importante.
Chez @ignytlabs, on construit un système de design pour chaque client avant de toucher à un écran. Avant, ça prenait deux jours à un designer. Moonchild le fait en environ 20 minutes.
Pour ce tuto, j'ai construit Haven, un concept d'appli immobilière mobile. Il y a plusieurs façons d'importer un système de design dans Moonchild. Tu peux importer depuis Figma, GitHub ou une URL en ligne. Tu peux décrire ta marque à l'Agentic Design System Builder. Pour Haven, j'ai fait ce que je fais d'habitude quand je pars d'une vibe. De l'inspiration design depuis Dribbble. J'ai déposé trois captures d'écran d'applis immobilières mobiles qui avaient le rendu que je voulais, et une courte description de ce qu'est Haven et à qui ça s'adresse. L'outil a extrait le langage de design et a construit le système de zéro.
Ce qui m'a surpris, c'est à quel point tout est prévisualisable. La plupart des outils IA, y compris le workflow Google Stitch dont j'ai parlé dans mon dernier article, te donnent un fichier de tokens plat. Couleurs. Polices. Peut-être les espacements. Lui fait quelque chose de différent. Il construit une bibliothèque de composants complète et une galerie. Chaque badge, bouton, carte et chip rendu tel qu'il apparaîtra dans ton appli. Clique sur n'importe quel composant et tu le vois en direct, avec des contrôles pour tester les variantes et les tailles. Juste en dessous de la prévisualisation, tu as le JavaScript, le CSS, les exemples et les dépendances réels de ce composant. Prêt à être intégré dans le code.
La galerie, c'est la partie qui change vraiment la façon dont tu designes. Au lieu de deviner à quoi ressemble un « badge de marque » ou un « badge d'évaluation » en contexte, tu les vois tous côte à côte. À vendre. À louer. En vedette. Toute la famille d'un coup. Tu prends des décisions de design éclairées avant même qu'un seul écran soit généré.
C'est la différence entre une feuille de style et un vrai système.
Étape 2 : Du PRD à l'interface
Une fois ton système de design en place, tu ne fais plus des prompts design à l'ancienne.
Tu colles un PRD.
Un brief d'une page sur une fonctionnalité. Un spec produit. Un énoncé d'objectif. Tout ce que tu as.
Pour Haven, j'ai collé un PRD structuré couvrant la présentation du produit, les objectifs, les utilisateurs cibles et leurs rôles, les fonctionnalités clés et le périmètre MVP, les parcours utilisateur complets, la stack technique et la direction design. Environ une page. Suffisamment précis pour donner un vrai contexte à l'outil. Suffisamment structuré pour qu'il extraie les bonnes infos dans les bons écrans.
Ensuite, j'ai fait quelque chose que la plupart des gens sautent.
J'ai brainstormé avec avant de générer le moindre écran.
C'est le déclic que la plupart des builders manquent. Le mode chat garde tout le contexte du PRD. Au lieu de balancer le PRD et de cliquer sur générer, tu parles d'abord du produit. Tu confirmes la liste des écrans. Tu verrouilles le schéma de navigation. Tu pré-définis la hiérarchie des écrans clés avant qu'un pixel n'existe.
Pour Haven, j'ai demandé :
→ « D'après ce PRD, quels écrans recommandes-tu de construire en premier ? Est-ce qu'il me manque quelque chose pour une appli immobilière ? »
→ « La navigation principale devrait-elle être une barre d'onglets en bas avec Accueil, Recherche, Favoris, Profil ? Ou autre chose ? »
→ « Avant de générer, explique-moi l'ordre de priorité pour l'écran Détail d'une propriété. Photos d'abord, puis nom et prix, puis specs, puis équipements, puis agent. Confirme ou améliore. »
→ « OK, maintenant génère ces écrans en mode clair et en mode sombre, en respectant le système de design que j'ai attaché. Assure-toi de parcourir l'intégralité du parcours utilisateur et de créer tous les écrans. »
Au moment où j'ai cliqué sur générer, l'outil connaissait déjà le produit mieux que la plupart des designers après leur premier appel client.
Maintenant, une petite note sur les variantes. Lis ça attentivement.
Une fonctionnalité sympa : tu peux créer différentes variantes de tes écrans. Il suffit de le mentionner explicitement à Moonchild et il s'en occupe. Pour Haven, je voulais trois directions esthétiques différentes pour toute l'appli avant de m'engager sur l'une d'elles. Voici le prompt exact que j'ai utilisé :
« Je veux que tu génères 3 concepts d'interface mobile complets pour Haven :
Concept 1 - Éditorial chaleureux : fonds crème, espacements généreux, polices à empattement pour les noms de propriétés, ombres douces, traitement d'image type magazine.
Concept 2 - Moderne audacieux : mode sombre, contraste élevé, sans empattement partout, angles droits, photos en pleine largeur.
Concept 3 - Minimaliste premium : palette neutre (blanc cassé, charbon, un seul accent), typographie raffinée, beaucoup d'espace, micro-interactions subtiles.
Utilise le système de design connecté comme base, mais laisse chaque concept tirer le système dans une direction esthétique différente. Génère des écrans complets, pas juste des sections. Qu'est-ce que tu vas faire ? »
Remarque le « Qu'est-ce que tu vas faire ? » à la fin. C'est le petit détail qui fait fonctionner. Au lieu de générer tout à l'aveugle, l'outil est revenu avec un plan.
Il a dit qu'il construirait d'abord 5 écrans représentatifs par concept. Je passerais en revue les trois directions côte à côte. Une fois que j'aurais choisi celle que je voulais, il irait designer toute l'appli dans cette direction.
Ça change complètement l'équation des coûts. Tu ne paies pas pour trois constructions complètes. Tu paies pour trois échantillons rapides, puis une seule construction complète dans la direction que tu choisis.
J'ai choisi l'éditorial chaleureux. L'ensemble complet des écrans est revenu ensuite.
Maintenant, la partie qui m'a vraiment surpris.
Chaque écran généré par Moonchild est interactif en mode prévisualisation. Pas une maquette statique. Réellement interactif.
Tu peux cliquer dans les champs de saisie. Appuyer sur les boutons. Passer d'un écran à l'autre comme un vrai utilisateur testant le prototype avant qu'aucun code ne soit écrit. Pour Haven, j'ai repéré deux problèmes de flux en prévisualisation qui auraient sinon été livrés à Codex. L'écran de détail de la propriété n'avait pas de moyen évident de revenir à la navigation. L'appel à l'action pour contacter l'agent était trop bas dans la page. Les deux auraient été livrés si j'avais envoyé le design à Codex sans cliquer d'abord.
C'est le déclic. Tu testes le produit avant qu'aucun code ne soit écrit.
La boucle d'affinage est la dernière pièce.
Quand un écran a besoin de travail, tu ne refais pas un prompt de zéro. Tu sélectionnes l'écran, tu dis à l'outil ce qu'il faut changer, et il génère une v2 sur place. Tu veux un hero plus cinématographique ? v2. Tu veux remplacer une disposition en cartes par une vue en liste ? v3. Les variantes s'empilent pour que tu puisses comparer et choisir la meilleure.
Pour l'écran de détail de la propriété de Haven, j'ai fait trois itérations. La v1 avait le bloc agent trop haut. La v2 a corrigé la hiérarchie mais la galerie photo semblait petite. La v3 a réussi les deux. Environ 8 minutes d'échanges.
Tu ne crées pas à partir d'une page blanche. Tu affines une direction réelle. C'est la partie qui ressemble le plus à un travail avec un designer senior.
Étape 3 : Connecte Moonchild à Codex via MCP
C'est là que le workflow devient DINGUE.
Le système de design donne les règles à Codex. La connexion MCP donne à Codex quelque chose de plus puissant : un accès direct au résultat du design. Pas des captures d'écran. Pas des descriptions textuelles du design. Des données de design structurées que Codex peut lire et reconstruire.
Voici la configuration :
→ Va dans Paramètres Moonchild, puis MCP
→ Copie la commande d'installation pour ta configuration
→ Ouvre Codex CLI
→ Colle la commande d'installation
→ Authentifie-toi avec ton compte Moonchild
→ Terminé
Une fois connecté, Codex voit à la fois ton système de design et les écrans spécifiques de Haven que tu as designés.
Étape 4 : Codex livre le code
Maintenant, tu donnes un prompt à Codex comme ceci :
Récupère le projet Haven Real Estate Mobile App en utilisant le MCP Moonchild, et dis-moi quels écrans nous avons à l'intérieur.
Ce premier prompt fait deux choses. Il confirme que le MCP est bien connecté. Et il donne à Codex une visibilité totale sur chaque écran que tu as designé.
Un conseil rapide avant de laisser Codex faire quoi que ce soit de plus lourd. Reste en mode planification. Codex montre ce qu'il s'apprête à faire avant d'exécuter. Lis le plan à chaque fois. Assure-toi qu'il comprend quels écrans tu veux, dans quel ordre et avec quel niveau de détail. C'est la différence entre Codex qui code ce dont tu as réellement besoin et Codex qui code ce qu'il pense que tu veux.
Une fois que tu as revu le plan et pointé vers l'écran que tu veux, Codex extrait les données de design directement de Moonchild, fait référence à ton système de design et écrit le code. Il ajoute même les états de survol, les transitions et la gestion des cas limites parce qu'il travaille à partir de vraies données de design plutôt que de deviner à partir d'un prompt.
Le résultat : une UI de qualité production dans ta véritable base de code, correspondant exactement au design, en quelques minutes.
Chez @ignytlabs, on budgétait deux semaines pour le design sur chaque MVP client. Un designer construisait le fichier Figma. Un développeur l'interprétait. L'interprétation dérivait. On corrigeait. Cycle. Avec ce workflow, toute la boucle se réduit à un seul après-midi de travail. Même qualité. Marge plus élevée. Beaucoup moins de changements de contexte.
Quand utiliser ce workflow
Ce n'est pas le bon workflow pour toutes les équipes. Sois honnête sur les cas où il s'applique.
Utilise-le quand :
→ Tu livres des MVP en tant que builder solo ou petite équipe
→ La cohérence du design ne cesse de se dégrader entre les écrans
→ Tu ne veux pas maintenir un pipeline Figma → designer → développeur séparé
→ Tu as déjà un système de design et tu veux qu'il soit appliqué partout
Saute-le quand :
→ Tu es à grande échelle avec une équipe de design interne complète et une bibliothèque Figma mature
→ Tu as besoin d'un transfert pixel-perfect pour un site marketing ou un travail de marque où chaque ombre compte
→ Ta base de code a des motifs d'interface très personnalisés qui nécessitent un travail de design sur mesure
Pour 80 % des builders qui livrent des MVP et des produits SaaS, ce workflow couvre tout ce dont tu as besoin.
Ce à quoi il faut faire attention
Quelques signaux honnêtes avant de te lancer.
La qualité de ton système de design détermine la qualité de ton résultat. Déchets en entrée, déchets en sortie. Un fichier Figma à moitié fini avec trois tokens de couleur produira des écrans médiocres. Passe du temps sur le système en amont. Il te le rendra sur chaque écran.
La qualité du PRD compte. Un brief vague donne des écrans génériques. Un PRD spécifique avec des parcours utilisateur, des cas limites et une hiérarchie claire donne des designs utiles. Ce n'est pas une limitation de l'outil. C'est une limitation de la réflexion.
Tu as toujours besoin de goût. L'outil produit. Tu diriges. Choisir la bonne variante et l'affiner, c'est là que ton jugement intervient. Si tu sautes l'étape de curation, tu reviens au design par aura.
Certains composants nécessitent des ajustements manuels. Les états animés complexes, les motifs d'interaction personnalisés, tout ce qui sort du système de design nécessite un passage manuel dans Codex. Le MCP t'amène à 90 %. Les 10 % restants, c'est ton goût.
Ce que ça signifie vraiment
Voilà mon avis honnête.
Le goulot d'étranglement dans la livraison de produits construits par l'IA n'a jamais été le code. L'IA peut écrire le code. Le goulot a toujours été la couche design. La cohérence, le goût, le système qui lie tout ça.
Ce goulot vient de s'effondrer.
Dans notre agence, on budgétait deux semaines pour le design sur chaque MVP client. Embauche d'un designer. Attente des fichiers Figma. Le développeur qui interprète. Cycle. Ce qui prenait deux semaines prend maintenant deux jours. Même qualité. Livraison plus rapide. Marge plus élevée.
C'est le workflow que les équipes financées ont déjà avec leur pipeline Figma + designer + développeur. La différence, c'est que maintenant les builders solo, les agences indépendantes et les petits studios ont le même levier sans les effectifs.
2026 va être INJUSTE pour les agences et les builders qui comprennent ça en premier.
TLDR
→ Arrête de blâmer Codex pour les mauvaises interfaces. Codex n'est pas le problème. C'est ton workflow.
→ Étape 1 : Construis ton système de design dans Moonchild. Importe depuis Figma, GitHub ou une URL en ligne. Ou décris ta marque. Ou dépose des inspirations Dribbble comme je l'ai fait pour Haven.
→ Étape 2 : Colle ton PRD. Fais un brainstorming en mode chat avant de générer. Verrouille d'abord la liste des écrans et le schéma de navigation.
→ Par défaut, génère une variante. Demande explicitement plusieurs variantes sur les écrans hero avec des ambiances différentes spécifiées.
→ Utilise la prévisualisation interactive pour tester le flux avant d'écrire le moindre code. Affine les écrans avec des itérations v2, v3 sur place.
→ Étape 3 : Connecte Moonchild à Codex via MCP. Cela donne à Codex de vraies données de design, pas des captures d'écran.
→ Étape 4 : Demande à Codex de construire chaque écran via le MCP. Une interface de qualité production est livrée en quelques minutes.
→ La qualité de ton système de design détermine la qualité de ton résultat. Investis là-dessus.
→ Le cycle Figma → transfert → développeur est mort. Un seul workflow gère désormais le design et le code ensemble.
ON Y VA.
