Le product design est en train de changer

• Les outils d’IA utilisent directement les design systems pour générer des UI, ce qui fait évoluer le rôle du designer, de la simple conception visuelle vers un rôle centré sur la stratégie et la coordination
• La vraie question n’est plus « qui prend le travail de qui », mais comment le processus change
• Les tâches invisibles comme le code, les PRD ou les résumés sont faciles à automatiser, mais les tâches visibles comme l’UI ou les flows, que les utilisateurs voient et manipulent directement, présentent de grands écarts de qualité ; l’automatisation du design ne progresse donc pas encore aussi vite que l’ingénierie
• La traduction des maquettes Figma en code était le plus gros goulot d’étranglement, mais si les designers designent directement dans un environnement de code, ce gaspillage lié au handoff peut être totalement éliminé
• À l’ère de l’IA, la valeur clé du designer ne réside plus dans le travail au pixel, mais dans la capacité d’orchestration : décider quoi construire, évaluer de manière critique les sorties de l’IA et piloter le travail
• Les entreprises qui investissent dans de petites équipes autonomes et dans des design systems lisibles par machine finiront par surpasser les grandes organisations en mode feature factory

---

Le contexte de cette transformation du design produit

• Depuis la création de son premier site web avec Dreamweaver en 1999, l’auteur a travaillé selon un modèle consistant à concevoir avec Photoshop, Sketch ou Figma, puis à transmettre le résultat aux développeurs
• Récemment, il a connecté Claude Code au design system de son entreprise et a généré une UI réellement fonctionnelle en seulement trois prompts, en sautant l’étape classique de conception visuelle
• Cette expérience lui a montré que la valeur du designer se déplace de la capacité d’exécution vers le goût et le jugement stratégique
• Avec une IA capable d’implémenter un flux « prompt → génération → déploiement » à partir d’un design system, une transformation profonde du product design est en cours

Le faux débat : ce n’est pas une question d’effectifs, mais de processus

• Le discours actuel sur l’IA et les métiers du produit reste focalisé sur des luttes de territoire centrées sur les effectifs, du type « les designers vont-ils perdre leur emploi ? » ou « les ingénieurs vont-ils être remplacés ? »
• La vraie question concerne le processus : l’IA ne supprime pas ces fonctions, elle change qui fait quoi, à quelle vitesse, et où se déplacent les goulots d’étranglement
• Les tâches invisibles (invisible work) comme le code, la rédaction de PRD ou l’analyse de données sont faciles à automatiser, car les écarts de qualité restent cachés derrière l’UI
  • Même si le code est brouillon, personne ne s’en soucie tant que l’application fonctionne ; et si un PRD est généré par une IA, cela importe peu tant que la définition du problème est correcte
• À l’inverse, les tâches visibles (visible work) comme l’interface utilisateur, les flows ou l’expérience exposent immédiatement les écarts de qualité, que les utilisateurs perçoivent tout de suite
• Quand construire devient plus rapide et moins coûteux, le problème le plus difficile n’est plus « comment le faire », mais « qu’est-ce qui mérite vraiment d’être construit »
• L’accélération permise par l’IA dans le design restera forcément en retard par rapport à celle de l’ingénierie, et cette asymétrie va reconfigurer l’ensemble du processus de développement produit et la façon de composer les équipes

Le travail visible : le design n’est pas derrière le mur, il est le mur lui-même

• L’ingénierie peut être comparée à de la plomberie : elle est cachée derrière le mur, et tant que l’eau sort du robinet, la structure interne importe peu
  • Boris Cherny fait tourner 4 à 5 agents de code en parallèle et a obtenu un gain de vitesse supérieur à 400 % ; dans la Silicon Valley, les ingénieurs passent d’une logique d’écriture directe du code à une logique d’orchestration d’équipes d’agents
• Le design logiciel, lui, est à la fois le mur, le robinet et la poignée ; même si l’IA le produit, les utilisateurs restent très sensibles à son apparence et à son ressenti d’usage
• L’IA peut suivre les standards et patterns présents dans ses données d’entraînement, mais elle gère mal des décisions fondées sur une recherche utilisateur massive, nourrie par des dizaines d’entretiens, des enquêtes, des analyses d’usage ou des audits concurrentiels, car le contexte est trop vaste
• Il existe aussi un goulot d’étranglement appelé ingestion problem : même si l’IA génère d’énormes volumes de code ou de synthèses de réunion, les humains doivent encore les lire, les intégrer et les évaluer de manière critique pour pouvoir raisonner et décider
  • La revue de code devient un goulot d’étranglement réel, et il s’agit d’une limite liée à la vitesse humaine qu’aucun modèle ne peut contourner
• L’IA excelle dans la génération et la synthèse de contenu, mais sa capacité à créer du vraiment nouveau ou à démontrer du goût (taste) reste encore à prouver

Designer dans le code, pas dans Figma

• Le plus grand goulot d’étranglement du développement produit est le passage de la maquette Figma au code de production, c’est-à-dire le handoff entre designers et développeurs
  • On dessine une représentation du logiciel, on ajuste les pixels, on la transmet aux ingénieurs, puis la QA compare le code à la maquette et rejette les PR pour des différences de typo ou d’espacement : une énorme inefficacité
• L’IA peut résoudre ce goulot d’étranglement, mais seulement si les designers designent directement dans l’environnement de code
• Certains designers commencent réellement à résilier leur abonnement Figma pour passer à des outils d’IA ; l’argument central est que la maquette n’est pas le produit, mais un artefact parallèle qui demande traduction, revue et ajustements
  • Chaque pixel poussé dans Figma est une promesse qu’un ingénieur doit respecter dans un médium totalement différent, et plus l’outil de design est éloigné du code de production, plus le gaspillage du handoff augmente
• Une expérimentation consistant à pointer Claude Code vers le dépôt du design system et à produire une UI fonctionnelle en trois prompts l’a confirmé
  • Pour atteindre une fiabilité à l’échelle, il faut une documentation robuste, des règles explicites et une orchestration d’agents, mais les fondations sont déjà là
• Exemple de l’équipe d’ingénierie de Monday.com : lors d’un premier essai consistant à coller un lien Figma dans Cursor, le code généré n’utilisait pas les composants du design system, les couleurs étaient codées en dur et la typographie écrasait les valeurs par défaut du système
  • Leur solution a été de construire un MCP de design system (Model Context Protocol) — en rendant les composants, tokens, règles d’accessibilité et patterns d’usage lisibles par machine, puis en structurant le contexte du modèle avec un workflow agentique de 11 nœuds
  • L’approche ne consiste pas à laisser l’agent écrire directement le code, mais à lui faire construire une compréhension de ce que le code doit être, avant de transmettre cela à l’agent de code du développeur : « de l’orchestration, pas de la magie »
• Chez Anthropic, des designers soumettent déjà directement des pull requests avec Claude Code sur le produit Console et les déploient en production — c’est déjà une réalité en février 2026

Ce qu’il reste aux humains : orchestration et jugement

• Si l’IA peut générer du code, rédiger des PRD, résumer la recherche et prototyper des interfaces, ce qu’il reste aux humains, c’est l’orchestration
  • Les modèles sont déjà suffisamment compétents ; le goulot d’étranglement, c’est la personne au clavier — savoir quoi demander, comment découper le travail et quand rejeter le résultat du modèle devient essentiel
• Kyle Zantos, designer qui passe 70 % de son temps de travail dans le terminal, souligne qu’il vaut mieux apprendre une philosophie et une approche que des réglages d’outils précis, car les recommandations d’il y a quatre mois sont déjà obsolètes
• Arin Bhowmick, Chief Design Officer chez SAP, explique qu’une interface visuellement soignée peut masquer des problèmes profonds comme des sorties peu fiables, des décisions opaques ou un comportement fragile sur les edge cases
  • Les responsables design doivent traiter la confiance, la clarté et la fiabilité comme des livrables de design de premier ordre, et non se limiter à la qualité de surface
• Selon Vlad Derdeicea, environ 80 % du temps d’un design lead est consacré à la communication, à l’alignement et à la justification, contre seulement 20 % pour le travail de design hands-on
  • Chaque décision de design supporte une « taxe de justification » (justification tax) : le temps passé à expliquer, documenter et défendre des choix qui, dans d’autres disciplines, seraient réglés en quelques échanges
  • L’IA devrait viser ces 80 %, et non le travail de maquette : synthèse de comptes rendus, brouillons de communication avec les parties prenantes, résumés de recherche, prototypes rapides pour trancher avec des données plutôt qu’avec des opinions
• Le cadrage de Jan Tegze : ne cherchez pas à simplement mieux faire votre travail actuel ; identifiez les contraintes du domaine qui existent à cause des limites humaines et éliminez-les avec des agents — il s’agit moins d’accélérer l’existant que de rendre possible ce qui ne l’était pas auparavant
  • « Il ne s’agit pas de rivaliser avec les agents, mais de créer de nouvelles capacités qui nécessitent à la fois vous et les agents. »
• Les designers juniors avec moins de cinq ans d’expérience sont davantage en danger, car ils manquent souvent du jugement nécessaire pour évaluer les sorties de l’IA et de l’expérience permettant d’en détecter les erreurs ; le seuil minimal de compétence est en train de monter

Petites équipes, grand levier

• La plupart des entreprises logicielles ont aujourd’hui une structure inadaptée, avec des feature factories surchargées en PM, où chaque squad reçoit un PM, qu’il y ait ou non un véritable besoin de soutien design dédié
  • Les PM ont explosé à l’ère du ZIRP parce qu’ils sont proches du revenu et que leurs effectifs croissent avec la complexité organisationnelle
  • Marty Cagan appelle cela le « théâtre du product management » : une inflation de PM inefficaces qui ne sont guère plus que des chefs de projet surpayés, produisant des roadmaps et animant des standups
• À Davos, Andrew Ng a prédit que si l’IA fait exploser la productivité de l’ingénierie, le ratio PM/ingénieurs pourrait s’inverser, en passant de 1:8 vers 1:1
  • Si les agents d’IA écrivent l’essentiel du code de production, la large base d’ingénierie se réduit et la spécification et le jugement deviennent les ressources rares
• Airbnb a fusionné product management et product marketing en un rôle « full-stack »
  • Brian Chesky : « Si vous ne savez pas parler d’un produit, vous ne pouvez pas le construire. » — il fait du storytelling et de la communication externe des composantes de premier plan du rôle de PM
  • Il repositionne les designers comme des « architectes » qui pilotent le produit aux côtés des ingénieurs, et non comme un service subalterne qui exécute des tickets
  • Le travail de coordination, qui gonflait auparavant les effectifs PM, est transféré à des program managers dédiés
• Cela rappelle le modèle organisationnel fonctionnel d’Apple : des experts dirigent des experts, le CEO est le point d’intégration, et il n’y a pas de PM jouant le rôle de « mini-CEO » d’une business unit
• L’équipe idéale à l’ère de l’IA est une petite équipe autonome composée de 2 à 3 ingénieurs, 1 PM et 1 designer
  • Le design system devient une infrastructure clé ; sans design system dans le code et sans documentation, l’IA prend de mauvaises décisions sur l’UI et son implémentation
  • Les entreprises qui investiront dans des design systems lisibles par machine et dans de petites équipes autonomes surpasseront celles qui conservent des squads de 15 personnes et trois niveaux de validation

Effet composé : l’écart entre orchestrateurs et pousseurs de pixels

• Depuis l’expérience consistant à générer, via Claude Code, un écran fonctionnel à partir du design system, l’auteur améliore en continu la documentation, la rigueur des règles de composants et la clarté des consignes de composition
  • À chaque cycle, le résultat devient plus rapide et plus proche du niveau production, et les progrès des modèles, l’affinement des compétences et l’amélioration de la direction se cumulent de manière composée
• L’écart entre un « designer qui orchestre l’IA » et un designer qui pousse des pixels dans Figma devrait devenir énorme dans les 12 prochains mois
  • Ce n’est pas que le pousseur de pixels manque de talent ; c’est que l’orchestrateur opère à une vitesse et avec une portée fondamentalement différentes — pendant que d’autres livrent des maquettes pour des réunions de handoff, lui déploie des UI fonctionnelles
• L’auteur enseigne déjà cette manière de travailler à son équipe, non parce que le métier va disparaître, mais parce qu’il devient un métier où le goût, le jugement et la capacité à diriger le travail comptent davantage que la capacité à dessiner des écrans