Design System Core & Extended
Comment transformer une fragmentation post-fusion en une architecture de tokens sémantiques scalable pour 5 marques.
Description
En 2023, le rachat d’Explore par Intescia réunit 5 designers et 10 développeurs. Le défi technique était double : d’un côté, une dette technique majeure (systèmes pré-variables) et de l’autre, une hétérogénéité des méthodes. Chaque produit possédait sa propre architecture de composants, rendant toute collaboration ou maintenance globale impossible. J’ai co-piloté la création d’un socle unique « Extended » pour unifier les pratiques et les produits.
PROBLÉMATIQUES & SOLUTIONS
Rigidité du système
Problème
Solution
Objectiver le débat et utiliser les « Figma Modes » Pour dépasser les opinions personnelles et fédérer l’équipe, j’ai réalisé un benchmark des architectures leaders de l’industrie (Google Material 3, Atlassian, Adobe Spectrum). La réponse était unanime : il fallait une architecture sémantique à plusieurs niveaux. J’ai donc conçu une architecture où la sémantique est au centre :
- Primitives (Cachées) : La source de vérité absolue (palettes de couleurs, échelles).
- Sémantiques (Alias) : La couche publiée « Intescia » qui donne son sens au composant (ex: in-background/error).
- Figma Variables Modes : Grâce à la puissance des modes Figma, chaque produit enfant peut désormais surcharger uniquement les variables sémantiques qui lui sont propres, sans jamais toucher à l’architecture globale des composants.
L'Adoption Équipe
Problème
Le défi du « Change Management » L’aventure s’est révélée bien moins technique qu’humaine. Comment réorganiser des workflows globaux et aligner 5 designers aux niveaux de maturité très différents (dont certains en pleine transition d’Adobe XD vers Figma), sans perdre leur adhésion ?
Solution
La pédagogie et l’implémentation granulaire Au lieu d’imposer un déploiement « Big Bang » qui aurait pu créer du rejet, j’ai opté pour une approche orientée Change Management. J’ai instauré des rituels de synchronisation réguliers et une documentation claire. Nous avons migré les composants petit à petit, en testant chaque itération sur le terrain avec les designers. L’objectif était de prouver par l’usage que la nouvelle logique de « Tokens » simplifiait réellement leur quotidien, transformant ainsi la réticence initiale en une adoption totale du nouveau standard.
De la valeur brute au Token d'usage
L’approche initiale (Lead) : Une architecture basée sur des variables globales. On attribuait une couleur à un élément (ex: Grey-200 pour un fond).
Le défaut : Trop rigide. Si on changeait le gris pour une marque, ça cassait tout ailleurs car la variable n’avait pas de « sens », juste une valeur.
Ma Solution (In-component) : Une architecture sémantique à trois niveaux.
Primitives
La couleur pure (ex: color/red-500).
Sémantique
In-component
L’usage final (ex: button/danger/background).
Mon Processus
01
02
03
04
05
05
01
Audit & Benchmark
Vaincre la friction par la donnée Face aux divergences d’opinions sur la structure à adopter post-fusion, j’ai mené un audit de l’existant couplé à un benchmark approfondi des Design Systems de classe mondiale (Salesforce Lightning, Material 3). Cela m’a permis d’objectiver nos choix architecturaux et d’aligner la direction produit, les designers et les 10 développeurs sur une vision technique commune et pérenne.
02
Stratégie de Tokenisation
03
Acculturation & Alignement
Création de rituels et de documentation pour aligner les deux équipes (Figma vs ex-Adobe XD) sur une même méthode de travail.
04
Implémentation Dev
Mise en place d’un workflow de handoff avec le Lead Dev pour une intégration plateforme par plateforme.
04
Maintenance & Évolution
Un Design System est un produit vivant. On a défini des processus de contribution pour permettre au système d’évoluer sans créer de dette technique, assurant ainsi la pérennité de l’outil et sa scalabilité face aux futurs besoins métiers.
Les points de friction
Dette Technique
Des systèmes historiques rigides, créés avant l’arrivée des variables Figma, bloquant toute automatisation.
Architectures Divergentes
Chaque produit utilisait une nomenclature et une logique de construction différente, empêchant la navigation fluide des designers.
Fragmentation Dev
Une perte de productivité critique pour les 10 développeurs, contraints de recréer manuellement des composants pour chaque plateforme.
Résultats & Impact
- 30 %
Temps de maintenance réduit sur les composants multi-plateformes
100 %
Des tokens sémantiques désormais alignés entre le design et le code
Carte highlight : Scalabilité Éprouvée
Unification réussie des 5 marques sous un seul langage technique, garantissant une cohérence visuelle totale du groupe Intescia.
Ce que j'ai appris
Challenger une architecture par la preuve du Benchmark.
L’importance de la pédagogie dans le changement d’outils (XD vers Figma).
Penser le design comme une base de données (Tokens).
La patience opérationnelle : tester avant de déployer massivement.
Le design system est un produit vivant, pas une bibliothèque figée.