On voit se répandre une idée séduisante : puisque l’IA sait produire du code, des écrans et même des parcours “propres”, la phase de design devient secondaire, voire inutile. C’est compréhensible. Le rendu est immédiat, souvent esthétique, et donne l’impression qu’on a “avancé”. Mais cette impression repose sur une confusion : produire une interface n’est pas comprendre un usage. L’IA accélère la fabrication de formes. Le design, lui, clarifie un problème, arbitre des priorités, réduit l’incertitude et sécurise des décisions. Quand on confond les deux, on ne gagne pas du temps : on le décale. On économise quelques jours de maquettes pour les repayer en semaines de rework, en tickets de support, en conversions en baisse ou en adoption interne qui plafonne. Le sujet n’est donc pas de défendre un outil ou une méthode “à l’ancienne”. Le sujet est de rappeler ce qui fait la valeur d’un produit : la capacité à résoudre une situation réelle, dans un contexte réel, avec des contraintes réelles.
Non, l’IA ne remplace pas la phase de design. Elle remplace surtout… la mise en forme sans recul.
Une interface générée par IA peut être parfaitement utilisable en théorie et pourtant inutile en pratique.
Elle peut respecter des patterns standards, aligner des composants, proposer des libellés plausibles… tout en s’appuyant sur de mauvaises hypothèses. C’est là que l’angle mort devient coûteux : l’IA ne sait pas ce qui compte vraiment pour vos utilisateurs dans votre organisation, avec vos processus, vos risques, vos exceptions. Elle ne sait pas pourquoi un conseiller en agence contourne un champ obligatoire, pourquoi un opérateur de terrain n’a pas de réseau à l’endroit critique, pourquoi une équipe finance refuse un certain workflow, pourquoi le “simple” bouton de validation déclenche en réalité une cascade de contrôles.
Elle peut générer un écran de création de compte, mais elle ne peut pas décider si votre produit doit être pensé pour un usage quotidien ou occasionnel, pour un utilisateur expert ou contraint, pour un environnement calme ou sous pression.
Elle peut proposer un flux de commande, mais elle ne peut pas arbitrer entre rapidité, conformité, traçabilité et satisfaction.
Le design commence justement là : avant l’écran, au moment où l’on clarifie l’objectif, les frictions, les contraintes métiers, les risques légaux, les dépendances opérationnelles.
Si cette compréhension est absente, vous pouvez générer mille interfaces : vous industrialisez surtout la production d’erreurs.
Le piège se renforce parce que la génération d’interface donne des preuves visibles.
Une maquette, un prototype, un écran “cliquable” rassurent. Ils créent une impression de maîtrise et alimentent un biais classique en produit : confondre livrable et impact.
Les décideurs voient un résultat tangible et concluent que l’équipe avance, que le budget est bien utilisé, que la roadmap tient.
Pourtant, la vraie question n’est pas “est-ce que ça ressemble à une app ?” mais “est-ce que ça résout le bon problème, pour les bonnes personnes, dans les bonnes conditions ?”.
Dans beaucoup d’organisations, la phase de design a déjà été réduite à une production d’écrans et de composants.
L’arrivée de l’IA accélère cette dérive : si le design est perçu comme “faire des écrans”, alors oui, il devient remplaçable. Mais c’est un design appauvri, centré sur la sortie graphique et pas sur la décision.
Le design utile à la performance produit, lui, formalise des hypothèses, expose des arbitrages, met en évidence les zones d’incertitude, et propose des tests rapides pour trancher.
Ce design-là n’est pas un luxe : c’est un dispositif de réduction de risque.
Concrètement, ce que l’IA ne fait pas (et que vous payez si personne ne le fait), c’est l’enquête et la mise en cohérence.
Comprendre les usages, ce n’est pas “demander ce que les gens veulent” :
c’est observer ce qu’ils font, ce qu’ils évitent, ce qu’ils contournent, ce qu’ils bricolent pour atteindre leur objectif.
C’est identifier les moments où la valeur se crée et ceux où la confiance se perd.
C’est cartographier les contraintes : données disponibles ou non, règles de gestion, dépendances SI, exigences de sécurité, niveaux d’habilitation, auditabilité, temps de formation acceptable, charge cognitive supportable.
C’est aussi prendre en compte le modèle économique : une interface peut être fluide et pourtant ruiner la marge si elle génère trop de demandes au support, trop d’erreurs de saisie, trop d’exceptions à traiter manuellement.
L’IA peut aider à formuler, synthétiser, prototyper, traduire en UI. Mais elle ne remplace pas la responsabilité de décider ce qui doit être vrai pour que le produit marche.
Sans cette responsabilité, on obtient des produits “jolis mais fragiles” : ils fonctionnent en démo, puis cassent au premier contact avec la réalité.
Pour les décideurs, la bonne lecture est la suivante : l’IA déplace la rareté.
Avant, produire des écrans et du code coûtait cher et prenait du temps ; aujourd’hui, cela devient de plus en plus rapide.
La rareté se trouve ailleurs : dans la clarté du problème, la qualité des hypothèses, la connaissance des utilisateurs, la définition des critères de succès, et la capacité à arbitrer entre des objectifs contradictoires.
C’est exactement le terrain du design au sens fort.
Dans une startup, cette clarté fait la différence entre un MVP qui apprend et un MVP qui gaspille.
Dans un grand compte, elle évite de déployer une solution “standard” que personne n’adopte, ou qui déclenche des coûts cachés de conduite du changement, de formation et de contournement.
Dans une direction innovation, elle permet de passer d’expérimentations séduisantes à des produits industrialisables, compatibles avec l’exploitation et la conformité. Le risque, sinon, est d’accélérer la production sans accélérer l’apprentissage, et donc d’aller plus vite… dans la mauvaise direction.
La conséquence opérationnelle est simple : plus la production est facile, plus l’amont doit être rigoureux.
Pas lourd, pas bureaucratique, mais rigoureux.
Vous n’avez pas besoin de semaines de “design thinking” générique. Vous avez besoin de quelques décisions explicites :
qui est l’utilisateur prioritaire, dans quel contexte, avec quel objectif mesurable ;
quels sont les moments critiques du parcours où l’erreur coûte cher ;
quelles sont les contraintes non négociables ;
quelles hypothèses sont risquées et doivent être testées avant d’investir ;
quel niveau de qualité et de sécurité est requis dès le départ.
Ensuite, oui, l’IA peut accélérer énormément : variations d’écrans, alternatives de wording, prototypes, tests de structure d’information, génération de composants, assistance au code.
Elle devient un moteur de production au service d’une direction claire. Sans direction claire, elle devient un amplificateur de bruit : beaucoup d’options, peu de conviction, et une équipe qui itère sur des détails parce que le fond n’est pas stabilisé.
Si vous utilisez l’IA pour “remplacer le design”, vous remplacez surtout la compréhension des usages par de la production d’interface. C’est une économie de court terme qui se transforme en dette produit.
La voie actionnable est de repositionner le design comme un travail de décision et de réduction de risque, puis d’utiliser l’IA comme accélérateur d’exécution.
Trois actions immédiates :
1) Exigez, avant tout écran, une définition d’usage prioritaire en une page (utilisateur, contexte, objectif, contraintes, métrique de succès).
2) Identifiez 3 à 5 hypothèses à fort risque et testez-les en moins de deux semaines (entretiens ciblés, observation, prototype rapide, test de compréhension).
3) Autorisez la génération d’UI et de code uniquement après ces arbitrages, en demandant que chaque écran soit rattaché à une hypothèse validée et à une métrique.
Vous verrez alors l’IA pour ce qu’elle est vraiment : une force de production. Et le design pour ce qu’il doit rester : une discipline de compréhension et de choix.
Et si on échangeait ?
Cela fait sens pour vous et
vous souhaitez comprendre comment on peut
l’appliquer dans votre contexte ?
