Des écrans individuels aux systèmes réutilisables.
L’IA n’a pas changé ma façon de penser le produit. Elle a changé où je passe mon temps : je suis passé de la production manuelle d’écrans à la construction de systèmes réutilisables qui me permettent d’explorer, valider et livrer plus vite, sans abaisser le niveau d’exigence sur les preuves.
Ce n’est pas une vitrine d’outils ou de prompts. C’est le compte-rendu d’un changement que j’ai opéré dans ma pratique du design produit : pourquoi cela a changé, comment je travaille réellement aujourd’hui, et où je pense que cela nous mène — encore en évolution, et ancré dans de vrais projets plutôt que dans des démonstrations.
La découverte et la recherche n’ont jamais été le problème. La production était la partie coûteuse.
Le design produit traditionnel repose encore largement sur la production manuelle : reconstruire des maquettes, remplir des données fictives, refaire des motifs courants, et préparer les livrables de transfert avant même que l’ingénierie puisse commencer. Rien de tout cela n’est de la réflexion. C’est du travail à faible valeur ajoutée. Le diagramme ci-dessous ne vise pas à remplacer Figma, les designers ou le code : il montre où se situe le poids du travail.
La découverte, la recherche et la réflexion produit occupaient déjà la majorité de mon temps. La production était simplement la partie la plus coûteuse du processus.
↔ Balayez pour voir toutes les étapesLa découverte et la recherche disposent de plus de temps désormais, pas de moins — la réflexion occupe l’espace que la production occupait autrefois. La production coûte une fraction de ce qu’elle coûtait, ce qui laisse le prototypage et la validation croître pour combler l’espace restant.
L’IA n’a pas changé mon processus de design. Elle en a changé l’économie.
En zoomant sur la façon dont cela est concrètement orienté :
- Problème ou opportunité
- Quel est le niveau d’incertitude ? Comprendre et évaluer
-
Incertitude élevée Découverte & recherche Réduire l’incertitude avant d’investir.Incertitude faible Réutilisation & exploration assistée par IA Réutiliser des modèles éprouvés. Accélérer en toute confiance.
- Prototypage Explorer, valider et affiner rapidement des idées grâce à des systèmes réutilisables et à l’assistance de l’IA.
- Valider & affiner Tester avec des utilisateurs, réunir des preuves et bâtir la confiance avant la livraison.
- Ingénierie Livrer des solutions prêtes pour le développement, avec clarté et confiance.
Je n’applique pas le même processus à chaque problème. Avant toute chose, j’évalue le niveau d’incertitude. Les problèmes réellement incertains commencent toujours par la découverte, la recherche et la synthèse. Les problèmes bien compris peuvent avancer plus rapidement grâce à des modèles réutilisables et à l’exploration assistée par IA. Les deux parcours se rejoignent dans le Playground, où je prototype, valide et affine rapidement les idées avant de les transmettre à l’ingénierie avec une confiance accrue. Pour les correctifs les plus simples et les moins risqués, cette même évaluation peut envoyer le travail directement à l’ingénierie, en sautant complètement le design et la découverte. L’IA n’a pas changé la façon dont je prends mes décisions de design. Elle a changé la rapidité avec laquelle je peux transformer ces décisions en quelque chose de réel.
Les composants réutilisables sont devenus de l’intelligence réutilisable.
Système de design, éditeur de code, prototype et documentation forment un seul système connecté, et non quatre outils distincts reconstruits à la main à chaque fois. Je compose une interface à partir de ce qui existe déjà (add bar-chart-tile, pas la capture d’écran d’un composant), en dirigeant Claude Code et OpenAI Codex dans VS Code, avec GitHub Copilot en suggestion en ligne, à partir d’une bibliothèque de composants partagée et d’un ensemble de règles en Markdown, afin que le résultat corresponde au système par construction. Deux agents lisant les mêmes règles documentées constituent aussi un contrôle croisé utile : quand ils sont en désaccord, c’est généralement la documentation qu’il faut préciser, pas le code.
Système de design, éditeur de code, prototype et documentation vivaient autrefois dans des outils séparés, chacun reconstruit à la main pour chaque projet. À l’intérieur du Playground, ils forment un seul système connecté : les composants, les tokens, les règles d’accessibilité et les modèles d’interaction existent déjà, si bien qu’au lieu de décrire une interface à partir de zéro, je la compose — en nommant le composant exact que je veux (add bar-chart-tile, pas la capture d’écran d’un composant), afin que le résultat corresponde au système par construction, et non par hasard.
Les agents qui composent sont Claude Code et OpenAI Codex, tous deux exécutés dans VS Code et lisant la même bibliothèque de composants et les mêmes règles Markdown, avec GitHub Copilot qui gère les suggestions en ligne pendant que je tape. ChatGPT intervient en parallèle pour la réflexion qui se déroule en dehors de l’éditeur : cadrer un problème, travailler les données, rédiger la documentation que les agents liront ensuite. Deux agents sur un même système documenté constituent aussi un contrôle croisé utile ; quand ils sont en désaccord, c’est généralement la documentation qu’il faut préciser, pas le code.
Un changement a compté plus que je ne m’y attendais : des données réalistes. Plutôt que de remplir les écrans de lorem ipsum, j’ai construit des jeux de données fictifs et réutilisables (enseignes, produits et clients inventés, modélisés sur des schémas opérationnels réels) qui alimentent automatiquement les prototypes. Un concept promotionnel testé sur une campagne fictive de Coupe du Monde et des produits inventés a paru tout aussi réel aux participants qu’un produit en production, sans qu’une seule donnée commerciale ne quitte l’entreprise.
Ces données fictives sont suffisamment bonnes pour concevoir et tester, mais pas pour être mises en production. Le prototype et la fonctionnalité en production partagent les mêmes composants et la même structure de données ; seule la source change, les enregistrements inventés étant remplacés par un flux réel et autorisé au moment de l’intégration, de sorte que l’interface se comporte de façon identique une fois les données réelles branchées.
Il y a aussi un argument commercial, pas seulement un argument de métier. Deviner une interface à partir de rien coûte plus cher que la composer : plus de générations, plus de cycles de correction, plus de tokens dépensés pour arriver au même résultat. Réutiliser un système éprouvé y arrive en moins d’étapes, ce qui veut dire une facture IA plus basse pour un résultat identique, pas seulement plus rapide.
Le travail d’hygiène et le fait de rattraper un concurrent sont deux raisons légitimes de construire quelque chose, mais la version que je veux voir plus souvent est la troisième : quelque chose dont l’utilisateur ignorait avoir besoin jusqu’à ce qu’il l’utilise. Je continue d’arbitrer cela par un rapport effort/bénéfice, une méthode de notation ancienne et simple, parce qu’au fond c’est toujours une question du retour que mérite l’investissement dans un travail donné. Une fois en production, la même rigueur héritée de mon expérience en CRO s’applique : ce sont les tests qualitatifs et quantitatifs qui décident si le travail a mérité sa place, pas le simple fait qu’il ait été livré.
- Ce qui déclenche le travail Une feuille de route pilotée par les données et la recherche, alignant les besoins de l’entreprise et des clients.
- De quoi cela a-t-il besoin ? Un modèle existant, une fonctionnalité, ou du neuf — le parcours dépend de la réponse.
- Déjà dans le système de design Construction directe VS Code — Claude Code et OpenAI Codex comme agents (construisant avec ce qui existe déjà), GitHub Copilot suggérant en ligne. Aucun passage en design nécessaire.
-
Nouveau ou incertain
Découverte & livraison, en boucle
Parcourus dans n’importe quel ordre, pas selon une séquence fixe :
FigJam · Lucid — blueprints de service et flux, d’abord. Figma — un prototype rapide à tester, ou un travail de conception détaillé quand le modèle n’existe pas encore. VS Code — Claude Code, OpenAI Codex et GitHub Copilot, la livraison avançant pendant que la découverte clarifie la forme.
- Contrôle de cohérence UX, accessibilité & règles de contenu — les fichiers MD — pour repérer tout chevauchement ou effet de bord avant la mise en production.
-
Livraison
Un dépôt GitHub, avec une base de données branchée selon les besoins.
Déploiement Vercel Projets personnels, mis en production directement.Transfert à l’ingénierie Brambles & équipes clientes — dépôt, code front-end & prototype fonctionnel.
Le parcours dépend de ce dont le travail a besoin, pas d’une séquence fixe : un petit changement utilisant des modèles déjà présents dans le système de design part directement en construction, sans passage en design nécessaire. Quelque chose de réellement nouveau ou incertain entre au contraire dans une boucle de découverte et de livraison — blueprints de service, prototypes ou travail de conception détaillé dans Figma, parcourus entre VS Code et Figma dans l’ordre que le problème exige. Les deux parcours passent un contrôle de cohérence face aux mêmes règles d’UX, d’accessibilité et de contenu avant la mise en production — directement en production pour mes propres projets, ou transmis à l’ingénierie avec un prototype fonctionnel pour Brambles et les équipes clientes.
- Dans le code Composants Construits une fois, réutilisables — un bar-chart-tile, un date-picker, déjà présents dans la bibliothèque.
- Dans les MD & tokens Règles Variantes, états & espacements, ainsi que les règles d’UX, d’accessibilité & de contenu, consignées.
- Ensemble Claude Code, OpenAI Codex & GitHub Copilot Composent uniquement à partir de ce qui est nommé et déjà autorisé — jamais un prompt vide.
Aucune des deux sources ne suffit seule : des composants sans règles finissent mal utilisés, des règles sans composants restent théoriques. Ensemble, c’est ce que signifie “Lit : fichiers MD” dans le diagramme ci-dessus.
Quelques artefacts tirés du Playground lui-même — d’autres viendront s’ajouter à mesure que la pratique évolue :
Là où cela s’est concrètement passé.
Des données complexes, explorées comme quelque chose de réel plutôt que décrites.
Les tableaux de bord clients ont commencé sous forme d’esquisses et de flux, avant de passer dans le Playground sous forme de prototypes interactifs pilotés par des graphiques. Des composants de graphiques réutilisables et des tokens de design ont permis aux parties prenantes de réagir à quelque chose qu’elles pouvaient réellement utiliser, pas à une maquette statique.
En savoir plus →Deux autres exemples, Carte de la page d’accueil et Promotions retail, se trouvent dans la version complète.
Faire évoluer une expérience cartographique sans la redessiner à la main.
Une expérience de page d’accueil basée sur la localisation devait fonctionner sur plusieurs produits et régions. L’exploration initiale a commencé dans Figma ; une fois le modèle d’interaction validé, le Playground m’a permis de le reconstruire sous forme de modèle cartographique fonctionnel et réutilisable, de sorte que l’étendre à un second produit signifiait réutiliser le modèle, pas le reconcevoir.
En savoir plus →Assez réaliste pour être testé, assez sûr pour être partagé.
Un concept de promotions retail exploré presque entièrement à l’intérieur du Playground, avec très peu de travail statique dans Figma. Des composants réutilisables et des jeux de données fictifs et dynamiques (enseignes inventées, produits inventés, campagne promotionnelle fictive pour la Coupe du Monde) ont permis au prototype de paraître réel lors des tests d’utilisabilité, sans exposer la moindre donnée commerciale.
En savoir plus →Chaque résultat devient le point de départ suivant.
Rien de tout cela ne repart de zéro à chaque nouvelle tâche. Les mêmes fichiers markdown de travail — décisions, preuves, règles du système de design — se transmettent d’une session assistée par IA à la suivante, si bien que chacune démarre plus avancée que la précédente, au lieu de réexpliquer le même contexte depuis le début. C’est le même principe fondé sur les preuves qui sous-tend le travail lui-même : plus le système capture d’informations issues des systèmes de design, des insights utilisateurs, des modèles UX et de la recherche, plus il a de matière pour raisonner, et meilleur devient son jugement avec le temps.
Le même principe de réutilisation que dans le Playground. Simplement appliqué à la connaissance, pas aux composants.
Le même principe, entre d’autres mains.
Un designer que je mentore, Dmytro Ivanchenko, a poussé le même principe plus loin : il a composé un agent IA directement à partir des composants existants de notre système de design et de leurs règles d’usage documentées, et a construit séparément un plugin qui convertit un design entre les breakpoints automatiquement.
Composer à partir d’un système éprouvé se transmet : d’autres peuvent s’en emparer et avancer avec.
Ce que j’ai appris
L’IA n’a pas remplacé mon jugement. Elle a changé où je passe mon temps.
- Moins de temps à reproduire des écrans, plus de temps à comprendre les problèmes.
- La réutilisation s’accumule : chaque composant construit une fois se rentabilise de nombreuses fois.
- Des données réalistes comptent autant que des interfaces réalistes.
- Les prototypes qui fonctionnent suscitent des retours plus tranchants que les prototypes qui semblent simplement terminés.
- L’écart entre “conçu” et “réalisable” se réduit quand le design et l’ingénierie partagent les mêmes composants.
Le métier du design n’a disparu nulle part : il s’est déplacé, de la production d’écrans individuels à l’orchestration des systèmes, des preuves et de la réutilisation qui les sous-tendent.
Où cela nous mène, et comment je compte m’adapter.
Les chiffres plus haut sur cette page — production en baisse, découverte et validation en hausse — sont un aperçu grossier d’un phénomène plus large : près de 60 % du travail mécanique de design revient désormais à l’IA, et les 40 % restants — l’affinement, le jugement, savoir ce qu’un contexte exige réellement — sont là où la valeur s’est déplacée, pas là où elle a disparu. Je préfère suivre ce ratio délibérément et planifier en fonction de son évolution, plutôt que de le constater avec un an de retard. Voici la version honnête de ce plan :
- Maintenant · 2026 ~60 % IA, 40 % jugement L’IA rédige les flux, les maquettes et les premiers jets. Je vérifie : les règles des fichiers MD, le contrôle croisé entre agents, le contrôle de cohérence avant toute mise en production.
- 12 prochains mois ~65 % IA, 35 % jugement Diriger plusieurs chantiers IA à la fois, en arbitrant ce qu’ils produisent plutôt qu’en le rédigeant moi-même.
- Dans deux ans ~70 % IA, 30 % jugement Moins tout revoir avec la même intensité. Plus de tri : décider en amont ce qui a réellement besoin d’une vérification approfondie.
- Cinq ans et au-delà Boussole, pas prévision Moins impliqué dans un seul outil. Plus centré sur la définition des problèmes, avec assez de précision pour vérifier rapidement la production d’un agent.
Une chronologie honnête, pas un argumentaire commercial : les étapes proches s’appuient sur ce qui évolue déjà, avec les chiffres mêmes de cette page ; la plus lointaine est une boussole, pas une prévision — je préfère le dire clairement plutôt que feindre une précision que je n’ai pas.
Le raisonnement derrière chaque étape, et ce qui reste constant même quand le ratio évolue, se trouve dans la version complète.
C’est aussi pourquoi le contrôle de cohérence, les fichiers MD, le contrôle croisé entre agents comptent pour moi autant que les diagrammes qui génèrent le travail en premier lieu. À mesure que la couche mécanique se délègue davantage, ce qui ne s’automatise pas, c’est la responsabilité de veiller à ce qu’une décision à conséquences soit la bonne. C’est la même rigueur qui sous-tend l’UX Governance et le Design QA ailleurs sur ce site, appliquée à un ensemble de livrables qui évolue plus vite, pas une nouvelle compétence que j’acquiers en partant de zéro.
Au-delà de la génération d’interfaces, je m’intéresse de plus en plus à la façon dont l’IA peut rendre les connaissances produit validées et la recherche plus faciles à découvrir, réutiliser et appliquer tout au long du développement produit.
Un domaine que j’explore avec notre équipe de recherche est la façon dont cela pourrait faire partie du Playground lui-même, non pas pour remplacer la recherche, mais pour réduire le temps passé à rechercher des preuves, afin que les équipes puissent s’appuyer sur ce qu’elles savent déjà plutôt que de repartir de zéro.
Découvrez la même rigueur fondée sur les preuves appliquée à une direction produit validée.