Retour d’expérience sur la mise en place d’un Design System augmenté par l’IA chez un Asset Manager de référence.
Dans l’asset management, l’expérience utilisateur n’est pas un luxe, c’est un signal de confiance. Quand vos investisseurs consultent leur portefeuille ou que vos équipes pilotent des opérations à plusieurs milliards d’euros, chaque incohérence visuelle, chaque friction d’interface érode cette confiance.
C’est avec cette conviction que nous avons accompagné le leader mondial de l’investissement privé, dans la refonte de son Design System affectant le portail investisseurs et son back-office métier.
L’objectif : construire un socle suffisamment robuste pour garantir la cohérence, et suffisamment intelligent pour accélérer radicalement la production d’interfaces.
Le problème initial : cohérence vs vélocité
Comme beaucoup d’organisations en croissance, nous avons du faire face à un dilemme classique :
- D’un côté, des équipes métier avec des besoins qui évoluent vite, des fonctionnalités à livrer rapidement
- De l’autre, une dette design qui s’accumule : composants dupliqués, variantes non documentées, écarts entre maquettes Figma et implémentation réelle
Le résultat ? Des allers-retours interminables entre designers et développeurs. Des incohérences visuelles qui passent en production. Le développement de nouvelles features restreint par des composants non optimisés. Un onboarding laborieux pour chaque nouveau membre de l’équipe.
Nous avons pris le parti d’attaquer le problème à la racine : bâtir un Design System qui ne soit pas qu’une bibliothèque de composants, mais un véritable système de décision partagé.
Un Design System pensé comme une infrastructure
Une gouvernance claire
Un DSM sans gouvernance devient vite un cimetière de composants. Nous avons mis en place une structure tripartite :
- DSM Owner (designer) : garant de la cohérence globale, valide les décisions design, gère le backlog et la documentation
- Product Owner : porte les priorités produit, arbitre la valeur vs. l’effort
- Développeur référent : garant de la faisabilité technique, évite la dette d’implémentation, maintient le Storybook
Cette trinité assure que chaque composant répond à un vrai besoin, est techniquement viable, et s’intègre dans l’écosystème existant.
Des instances ritualisées
La gouvernance ne vit que si elle est incarnée dans des rituels concrets :
- DSM Discovery (ad hoc) : qualification et priorisation des nouvelles demandes. Un composant entre dans le système ou est fusionné/rejeté.
- DSM Review (1-2 par semaine) : suivi de l’avancée des composants dans le tracker, validation des passages d’étapes.
- DSM Sync (mensuel) : communication aux équipes des nouveaux composants, dépréciations, bonnes pratiques, roadmap.
Des tokens à trois niveaux
L’architecture des design tokens est ce qui différencie un DSM fragile d’un DSM scalable :
- Primitives : les valeurs brutes (couleurs hex, tailles en pixels)
- Alias / Semantic : les intentions (color-text-primary, spacing-section)
- Component-specific : les décisions contextuelles (button-background-primary)
Cette hiérarchie permet de propager un changement de charte graphique en quelques minutes, sans toucher à un seul composant. Elle garantit aussi que l’ensemble du système « parle » un vocabulaire cohérent, un point crucial pour la suite.
Une définition stricte de « Released »
Un composant n’est considéré livré que s’il coche toutes les cases :
✓ Design validé
✓ Ajouté à la librairie Figma
✓ Implémenté et testé (Storybook)
✓ Documenté (Do/Don’t, cas d’usage)
✓ Ajouté au changelog
✓ Communiqué aux équipes sur les canaux Teams dédiés
Cette rigueur élimine les zones grises qui polluent tant de Design Systems.
L’IA comme accélérateur, non comme remplacement
Une fois ce socle en place, nous avons franchi une étape supplémentaire : faire du Design System le langage que l’IA comprend.
Le DSM nourrit l’IA
Nous avons structuré l’ensemble de la documentation, tokens, composants, guidelines en fichier markdown pour qu’elle soit consommable par des outils de génération d’interface (Lovable aujourd’hui, Claude Code en transition).
Concrètement, l’IA dispose :
- De l’inventaire complet des composants disponibles et leurs variantes
- Des règles de composition (layout, patterns, …)
- Des Do/Don’t pour chaque élément
Résultat, quand on lui demande de générer une interface, elle produit du code qui respecte nativement le Design System. Pas d’approximation, pas de « ça ressemble à peu près », c’est une conformité réelle.
Des ateliers métier transformés
C’est ici que l’impact devient tangible pour les équipes business.
Avant : un atelier de conception impliquait des wireframes papier ou des maquettes préparées en amont. Le métier donnait son feedback, le designer repartait itérer, nouvelle présentation quelques jours plus tard. Cycle classique.
Maintenant : nous arrivons en atelier avec une proposition réalisée en quelques minutes, puis nous générons et ajustons les interfaces en direct avec les équipes métier. Elles voient leur besoin prendre forme sous leurs yeux, nous faire des demandes d’ajustements et voir le changement immédiatement.
La dynamique des échanges changent, le métier devient co-créateur et non un simple validateur.
Et parce que l’IA s’appuie sur notre DSM, ces interfaces générées en live ne sont pas des prototypes jetables, elles constituent une base de travail réellement exploitable par les développeurs.
Les résultats mesurés
Après plusieurs mois de mise en œuvre, les gains sont quantifiables :
Indicateur |
Avant |
Après |
Gain |
Création d’un composant (design → dev → doc) |
~5 jours |
~2 jours |
÷2.5 |
Maquettage d’une nouvelle page |
2-3 jours |
Quelques heures |
÷3 à 5 |
Allers-retours design/dev par feature |
Nombreux |
Résiduels |
-70% |
Onboarding d’un nouveau développeur |
~2 semaines |
2-3 jours |
÷5 |
Onboarding d’un nouveau designer |
~1 semaine |
2 jours |
÷3 |
La vision : Figma réservé aux composants
Nous sommes convaincus que le workflow traditionnel, spécifications → maquettes Figma → développement est en train de devenir obsolète pour la production d’interfaces courantes.
Notre trajectoire :
- Aujourd’hui : le DSM structure tout, l’IA (Lovable) génère les interfaces conformes, Figma reste l’outil de conception des composants et de l’exploration créative
- Demain : transition vers Claude Code pour une génération encore plus intégrée au workflow développeur, directement depuis les spécifications fonctionnelles
Figma ne disparaît pas, il se recentre sur ce qu’il fait de mieux : la création et l’itération sur les briques fondamentales du système. La production d’écrans, elle, est déléguée à l’IA qui parle couramment le langage du Design System.
Ce que cette expérience nous enseigne
Trois convictions émergent :
- Un DSM robuste est un prérequis, pas une option
Sans gouvernance claire, sans tokens bien architecturés, sans documentation rigoureuse, l’IA ne peut pas produire de résultats exploitables. La qualité de l’output dépend directement de la qualité du système qui le nourrit. - L’IA amplifie, elle ne remplace pas
Le designer reste essentiel pour les décisions structurantes, la création de nouveaux patterns, l’exploration créative. L’IA lui permet de démultiplier son impact sur la production courante. - Le vrai ROI est dans la boucle métier
Les gains de temps design/dev sont significatifs. Mais le changement le plus profond est dans la relation avec les équipes métier : des cycles plus courts, une co-création réelle, une adoption plus forte des solutions livrées.
On en parle ?
Chez Kanbios, nous accompagnons les organisations qui veulent transformer leur approche produit, en structurant leurs fondations design et en intégrant intelligemment l’IA dans leurs workflows. Si ce retour d’expérience résonne avec vos enjeux, parlons-en.
