Design to code : comment l'IA redéfinit les rôles entre design et développement

Chez un fournisseur de solutions 3D web, la collaboration entre designers et développeurs, c'est le cœur du réacteur. C'est aussi, soyons honnêtes, une source de friction chronique : des intentions créatives qui se perdent en chemin, des cycles de validation qui s'étirent, des allers-retours qui s'accumulent. Ce n'est la faute de personne. C'est la faute du processus. Depuis qu'on intègre l'IA dans le workflow des équipes avec lesquelles je travaille, ce processus a changé.

Les frictions ont (presque) disparu et chacun est satisfait de travailler sur ce sur quoi il apporte de la valeur.

Ce changement ne touche pas seulement le design et l'intégration : il intervient dès la phase UX. C'est toute la chaîne de production qui se réorganise, pour plus d'efficacité et de satisfaction des équipes, des utilisateurs et du client !

Des prototypes avancés pour des décisions UX éclairées

C'est sûrement là que le changement est le plus profond, et pourtant le moins visible de l'extérieur.

Avant, pour valider une idée d'expérience un peu complexe, on avait deux options : pousser très loin un prototype Figma, ce qui prenait des heures/jours, ou se lancer dans le design et l'intégration et découvrir les problèmes en cours de route. Sur une interface 3D ou une expérience pensée pour le mobile, ce deuxième scénario coûte cher. Les vrais soucis d'ergonomie, on ne les voit pas sur une image fixe. On les ressent quand on manipule.

Aujourd'hui, on peut prototyper directement et facilement avec Figma Make, qui s'appuie sur le modèle Claude. En quelques heures, on a une maquette interactive, qu'on peut manipuler, et surtout partager par un simple lien et faire tester.

Un cas concret : itérer plus rapidement concernant l'UX d'un planner 3D sur mobile

Sur un projet de planner 3D, je devais imaginer comment l'utilisateur allait naviguer dans un espace en trois dimensions, depuis son téléphone. Le genre de défi où une maquette statique ne sert pas à grand-chose.

J'ai donc construit un prototype manipulable. Le client l'a testé lui-même, depuis chez lui, sur son propre téléphone, via un lien qu'on lui a envoyé. Il a validé la direction avant qu'on écrive la moindre ligne de code de production.

Ce que ça nous a évité :

• Découvrir trop tard que la navigation ne fonctionne pas bien sur mobile
• Refaire des choix d'architecture coûteux en fin de projet
• Faire valider au client un concept qu'il a du mal à se représenter sans le toucher

Et il y a un bonus de taille : ce genre de prototype, c'est aussi un formidable outil pour convaincre. Un POC qu'on manipule a bien plus d'impact qu'une présentation de slides, que ce soit pour emporter l'adhésion d'un client ou défendre une idée en interne !

Du design au prototype

Une fois l'expérience validée, on garde la même logique : réduire au maximum la distance entre l'intention créative et ce qui s'affiche dans le navigateur.

Par exemple, j'ai pu créer, intégrer et mettre en ligne le site wanadevmedia.com en 2 jours, à partir d'une présentation commerciale Google Slides. Pour cela, à partir de cette dernière, j'ai implémenté dans Claude Code mon Design system, puis je lui ai donné les directions : animations, optimisation des images, mise en ligne. Les instructions ressemblent à ce qu'on dirait à un collaborateur installé à côté de soi :

• "Remplace le picto par une caméra et mets cette image-là."
• "Aère la mise en page et ajoute des marges autour du bento."
• "Réduis le logo et centre-le mieux dans le carré."

Pas de spécification technique. Pas de fichier annoté. La conversation, c'est la spec. Claude lance un serveur en local, on voit le résultat en direct, on réagit. Le cycle d'itération passe de 2 jours à 2 minutes.

Plus le brief de départ est riche, moins vous corrigez ensuite. Donnez les vrais assets, la charte, des références précises : c'est ce contexte initial qui fait la différence entre un résultat juste et un rendu générique.

Et le développeur dans tout ça ? Sur ce projet, il a fait une relecture finale. Dix minutes. Parce que le site était assez simple (une landing page) et que les choix techniques ne touchaient pas à son cœur de métier.

Cette méthode permet de rendre aux devs du temps pour ce qui compte vraiment : la solidité, la performance, la sécurité, les intégrations métier. Tout ce qu'aucune IA ne maîtrise, et que seul un professionnel expérimenté gère pour de bon.

Redonner de la capacité opérationnelle à certains métiers sans déresponsabiliser les rôles

Ce workflow ne sert pas qu'à partir de zéro. On peut aussi repartir d'un projet existant. C'est ce que j'ai fait pour la mise à jour du site WanadevDigital.

Il m'a suffi de récupérer une copie du projet existant pour travailler dessus dans un espace isolé, sans jamais toucher au site en ligne. C'est là que j'ai fait mes ajustements visuels via Claude, en lui donnant un fichier de brand bible que j'avais créé en amont sur Figma.

J'ai pu ajouter des animations CSS, des interactions, et surtout remettre le site au goût du jour ! Théo, qui s'occupe plutôt de la partie communication, a travaillé de son côté sur le discours, en suivant la même méthode. Que ce soit pour une animation CSS, une faute à corriger, un loader animé à partir du logo en SVG, un visuel à changer, un petit effet en Three.js : je décris ce dont j'ai besoin, Claude l'implémente sur ma branche locale, l'œil du DA valide, le dev vérifie le code et valide la mise en production. Chacun à son rôle bien défini.

Et si je peux me permettre d'aller aussi vite, c'est parce que je travaille dans un environnement technique fiable. Des leads dev, un CTO, une architecture pensée, des projets bien structurés. C'est ce socle qui rend mes itérations possibles sans tout casser. Quand je pousse une modification, quelqu'un derrière sait lire le code, repérer ce qui cloche, garantir que ça tiendra en production. Ce que j'accélère en surface repose entièrement sur des fondations que je n'ai pas à construire seule. C'est une vraie chance, et ça change tout.

Attention, le farwest n'est pas loin : l'IA n'est pas une solution miracle !

Les discours du type "l'IA s'occupe de tout" font plus de mal que de bien. L'IA accélère, elle ne décide pas à votre place. Sans direction précise et sans relecture, on obtient du tiède, voire des erreurs.

L'IA n'a pas de goût. Ses propositions sont souvent génériques. C'est le DA qui fait la différence, par son exigence et sa connaissance de la marque. Sans direction précise, on obtient du tiède.

L'IA ne code pas parfaitement. Ce qu'elle génère est un excellent point de départ, pas un livrable qu'on met en ligne sans relecture. Le développeur reste le garant de la qualité technique.

L'IA ne remplace pas la recherche utilisateur. Elle propose des interfaces, elle ne comprend pas vos utilisateurs. Les vrais enseignements viennent toujours du terrain.

L'IA ne remplace pas le copywriter. Les textes générés sont à relire systématiquement. Même si vous avez donné un texte mot pour mot à intégrer, parfois l'IA se permet des modifications voire des aberrations.

Soyons clairs : l'IA accélère la production, elle ne remplace ni l'expertise technique, ni le sens créatif, ni la connaissance d'un vrai projet. Croire l'inverse, c'est le meilleur moyen d'échouer.

Dans ma mission de directrice de création, quelques apprentissages :

• Donner les vrais assets, pas des descriptions floues : le SVG, la typo, les codes hex exacts, bref : travailler en amont
• **Illustrer la direction voulue avec des références précises, ses précédents drafts, croquis, chartes, plutôt que des mots flous comme "moderne" ou "épuré"
• Y aller un changement à la fois, sinon l'IA vous fait un mélange de tout et c'est contre productif
• Relire tous les textes, c'est là que l'IA se trahit le plus
• Garder la décision créative de son côté, Claude exécute une vision, il n'en n'a pas
• Impliquer le dev tôt, lui montrer le prototype en amont évite les mauvaises surprises plus tard

L'IA accélère, elle ne décide pas. C'est une opportunité, à condition de savoir s'en servir

Ce qu'on a gagné au sein de l'équipe, c'est de la vélocité. Une idée se teste en quelques heures versus plusieurs jours. Un prototype convaincant arrive entre les mains du client avant même qu'on ait mobilisé l'équipe de dev.

Cette vélocité peut changer la donne sur le plan commercial. On répond plus vite aux appels d'offres, avec des supports plus concrets. On itère davantage sur une même enveloppe budgétaire.

Et surtout, cette efficacité ne se paie pas par une baisse de qualité, au contraire. Parce que le DA reste dans la boucle du début à la fin, parce que le dev se concentre sur ce qui demande vraiment son expertise, le résultat final est souvent meilleur.

La question n'est plus de savoir si ces outils vont s'imposer dans nos métiers. Ils s'imposent déjà. La vraie question, c'est de savoir quelle équipe va développer le réflexe et l'exigence pour en tirer le meilleur. Pas pour remplacer ses experts, mais pour les libérer du superflu et les concentrer là où ils font vraiment la différence.