Les Design Systems sont devenus un enjeu majeur dans le paysage digital des grandes entreprises. À travers leurs retours d’expérience, cet article montre les coulisses de la réalité quotidienne des équipes Design System. Leurs stratégies, leurs apprentissages et les perspectives qui s’ouvrent, notamment avec l’essor de l’Intelligence Artificielle.
Chaque entreprise possède un ADN et un contexte unique qui lui sont propres. Si Julien Déramond (Design System Tech Lead) note des similitudes entre Orange et Thales en termes de taille/complexité d’entreprise et d’enjeux, les contraintes divergent significativement. « Chez Orange, la complexité était fortement liée au multimarque ». À l’inverse, Thales se confronte à une multitude de spécificités métiers différentes nécessitant un Design System très flexible en fonction des domaines (aérospatial, bancaire, etc.). Accor, de son côté, pousse vers l’adoption du DS par la nécessité de thématiser ses interfaces. L’idée est d’intégrer l’identité de ses nombreuses marques hôtelières. Airbus, quant à lui, cible principalement ses projets internes (outils d’ingénierie, dashboards). L’entreprise gère une diversité de technologies, notamment React et Angular.
Ces différences soulignent un point essentiel. Il n’existe pas de solution unique et prête à l’emploi pour relever les défis d’une organisation. Comme l’indique Estelle Pelleterat De Borde chez Thales, suivre les standards du marché « trop à la lettre» sans prendre en compte les spécificités et la culture de l’entreprise est une erreur. Le Design System doit être « user centric » avec beaucoup de recherche utilisateur et « frugal ». En bref, penser minimal et viser juste pour s’adapter à la réalité du terrain.
C’est un thème central qui traverse tous les témoignages. La collaboration entre les équipes de design et de développement est jugée essentielle pour le succès d’un design system.
« Chez Orange, on passeé d’une collaboration silotée à un rassemblement des équipes au sein équipe : core team DS. La tendance forte est à la co-construction des composants, même si cela peut s’avérer plus lent. Car l’objectif est d’atteindre une qualité dès le départ. Un aspect distinctif était le trio Design, Développement et Accessibilité pour la co-construction et la validation, des processus rendus obligatoires» nous partage Julien Déramond.
Augustin Ohannessian d’Engie souligne la nécessité d’un dialogue continu entre les équipes design et dev. Leur approche tend vers un « dev first ». Où le design propose des guidelines qui sont ensuite traduites en composants développés, car c’est le code qui est la finalité du Design System. L’utilisation d’outils comme Code Connect (Plugin FigmaFigma est un outil de design d'interface en ligne qui facilite la collaboration en temps réel entre les designers. Il offre des fonctionnalités pour le design, le prototypage et la création de systèmes de design. More) est un moyen de faciliter cet alignement. Il permet d’importer les composants du design system dans FigmaFigma est un outil de design d'interface en ligne qui facilite la collaboration en temps réel entre les designers. Il offre des fonctionnalités pour le design, le prototypage et la création de systèmes de design. More en les reliant à votre base de code.
Chez Airbus, Eric Hélier (Tech Lead Design System) a œuvré pour changer les mentalités et passer d’une culture waterfall où les designers pensaient pouvoir se contenter d’un hand-off aux développeurs, à une approche où maintenant « on itère ensemble ». Maintenir la synchronisation reste un défi, mais l’utilisation d’automatisations entre FigmaFigma est un outil de design d'interface en ligne qui facilite la collaboration en temps réel entre les designers. Il offre des fonctionnalités pour le design, le prototypage et la création de systèmes de design. More et GitHub, particulièrement pour les tokens, aide grandement. Eric appelle ça « le cœur de la consistance du design system ». Des pratiques comme le pair programming et le mob programming renforcent cette collaboration au sein de l’équipe core.
Malgré ces avancées, la collaboration reste un défi variable. Estelle Pelleterat De Borde (Design System Lead) chez Thales partage qu’il y a une nécessité d’éducation mutuelle. Selon elle, « Les designers doivent comprendre les contraintes du développement. Et les développeurs les principes du design, les outils mais surtout vouloir ensemble en tant qu’équipe produit, livrer les meilleures expériences utilisateurs. Tous les membres d’une équipe ont leur rôle à jouer pour contribuer au succès du produit ». Elle met en garde contre la tentation des designers de vouloir « donner le système aux développeurs sans avoir à interagir ». Elle juge cela comme un « très mauvais signal » qui va à l’encontre du travail d’équipe essentiel à la qualité.
Un point soulevé par Jean-Christophe Besson (Design System Lead Manager) chez Accor est la difficulté à trouver un « point de contrôle unique » avec de nombreux contributeurs. Il mentionne également que même si la co-conception au début d’un besoin est actée. Le temps nécessaire pour contribuer un composant utile à tous n’est pas encore bien identifié et bien anticipé dans les roadmaps.
La gouvernance d’un Design System repose souvent sur une équipe « core ». Cependant, pour scaler et répondre aux besoins d’une grande organisation, la contribution externe est cruciale.
Chez Orange, la contribution de personnes extérieures à la core team pour la co-construction des composants était jugée « difficile, voire impossible » en raison du temps requis et de la disponibilité. En revanche, la collaboration externe fonctionnait mieux sur des sujets transverses comme la dataviz. Julien Déramond pousse vers une gouvernance en cascade, avec la core team pour les éléments centraux et des équipes dans les entités pour des spécificités.
Airbus quant à eux, ont adopté un modèle inner source, gouvernance avec contribution. Eric Hélier rapporte un succès majeur : des projets entiers contribuent activement, prenant presque en charge l’implémentation pour certaines stacks comme Angular. Ils sont leurs « champions » design system.
Pour Thales, le Design System se structure en niveaux (Core, Business, Recipes à la Brad Frost) pour permettre un ownership partagé et une flexibilité locale (niveau Recipes), essentielle pour s’adapter aux besoins variés des produits. Cette structure hybride a évolué pour rouvrir la contribution après une période initiale plus contrôlée.
La priorisation des développements au sein de l’équipe core peut se gérer par un lead ayant une vision long terme (Engie) ou définie collectivement, tout en assurant l’alignement avec la marque (Airbus).
La manière de gérer les spécifications et la documentation varie. Chez Orange, les specs se trouvent principalement dans des issues de dev, ce qui est OK si l’information ne s’éparpillent pas… Chez Thales, elles sont plutôt sur FigmaFigma est un outil de design d'interface en ligne qui facilite la collaboration en temps réel entre les designers. Il offre des fonctionnalités pour le design, le prototypage et la création de systèmes de design. More.
La documentation est une préoccupation majeure. Si chez Orange la documentation développeur était « nickel », celle côté design n’était « pas à jour par manque de temps ». Thales et Engie mettent l’accent sur une documentation FigmaFigma est un outil de design d'interface en ligne qui facilite la collaboration en temps réel entre les designers. Il offre des fonctionnalités pour le design, le prototypage et la création de systèmes de design. More très à jour. Accor utilise plutôt Supernova comme « l’unique source de vérité » pour la documentation.
Un manque important identifié par Julien Déramond est le log des décisions et l’explication du « pourquoi, comment » certains choix sont faits. Cela est essentiel pour la maintenance lorsque les équipes changent « c’est notre mémoire collective ! »
L’avenir des outils et de la source de vérité est un sujet de réflexion. Eric Hélier (Airbus) et Julien Déramond (Orange) perçoivent une potentielle « fin de la domination de figmaFigma est un outil de design d'interface en ligne qui facilite la collaboration en temps réel entre les designers. Il offre des fonctionnalités pour le design, le prototypage et la création de systèmes de design. More ? ». Des outils moins propriétaires, axés sur les formats d’entrée/sortie comme Penpot, sont vus comme plus adaptés. La source de vérité pourrait évoluer pour être un élément indépendant (JSON ou similaire) géré en code, injectable dans différents outils (FigmaFigma est un outil de design d'interface en ligne qui facilite la collaboration en temps réel entre les designers. Il offre des fonctionnalités pour le design, le prototypage et la création de systèmes de design. More, code, etc.). Ca permet d’être moins dépendant d’une solution spécifique. C’est l’approche que Thales met en place avec son Design Token System. Il est conçu pour être agnostique des outils et basé sur les standards.
L’adoption d’un Design System dans un grand groupe est un processus progressif et souvent difficile. Les freins sont multiples : manque de connaissance, freins technologiques, refus délibéré, complexité organisationnelle ou politique. Comme l’indique Julien Déramond, « il y a certaines entités ou certains pays par exemple qui ne veulent pas utiliser un DS pour des raisons politiques ou parce qu’ils ont, eux aussi, envie de créer LEUR Design System. Ou l’ont déjà fait, ce qui rentre en collision avec celui propulsé par le Groupe par exemple ». Le coût de la migration des projets existants est également un obstacle majeur.
Pourtant, l’adoption peut grandir naturellement, comme l’a constaté Airbus pendant le COVID. « L’adoption grandissait sans que l’on ne fasse rien pour ! ». Impliquer les équipes dès le départ peut aider à convertir les détracteurs en supporters. L’évangélisation, la pédagogie et la création d’une communauté interne sont essentielles pour Engie.
Mesurer la valeur tangible d’un Design System n’est « pas facile ». Obtenir des KPIs vraiment tangibles est aussi difficile. On mesure souvent la réutilisation (contribution, téléchargements, visites doc) mais pas l’impact direct sur la valeur métier.
Les bénéfices concrets les plus souvent cités sont la cohérence de l’expérience utilisateur entre les applications, l’accessibilité (souvent renforcée par les obligations légales), la promotion des bonnes pratiques UX, un gain de temps et de la productivité/vélocité pour les équipes design et dev, et l’amélioration de la qualité perçue. Le Design System aide aussi à casser les silos dans les grandes structures comme Orange et à fédérer des équipes.
Augustin Ohannessian d’Engie mentionne l’utilisation d’un plugin Chrome “Fluidity » (Plugin interne) pour scanner les sites et identifier l’utilisation du Design System et les non-conformités, aidant les équipes à s’améliorer et à gagner en autonomie. Airbus a mis en place un scoring UX pour évaluer la qualité d’une application, même si le Design System seul ne peut pas garantir une bonne UX globale.
La satisfaction utilisateur est souvent difficile à mesurer via des questionnaires (peu de réponses chez Orange ou chez Accor), même si certains indicateurs comme le NPS sont encourageants (Engie, Thales).
L’avenir des Design Systems est marqué par plusieurs tendances fortes :
Le maintien d’un Design System reste un défi constant et un combat pour les budgets. Certaines entreprises se désengagent après la phase initiale, ne comprenant pas que le DS est un produit qui nécessite un entretien continu. Prouver sa valeur est donc une tâche permanente.
Les Design Systems dans les grandes organisations sont des initiatives stratégiques qui demandent un investissement continu, une collaboration étroite entre les différentes disciplines, et une capacité d’adaptation constante face à la diversité des besoins et l’évolution technologique.
L’essor de l’IA ouvre de nouvelles perspectives passionnantes, tout en renforçant le rôle crucial de l’expertise humaine pour garantir la qualité, la cohérence et l’accessibilité.
Le chemin est semé d’embûches, mais les bénéfices en termes d’expérience utilisateur, de productivité et de culture collaborative en font un pari essentiel pour l’avenir digital des entreprises.
Inscrivez-vous à notre prochain meetup : mercredi 11 juin 2025 » Design System : et si on devait tout refaire ? »
Retrouvez également notre livre : « The Design Tokens Book »
