Comment aborder le design system d'un géant mondial comme Veolia
Comment garantir une cohérence visuelle absolue et rationaliser la production digitale d'un groupe de l'envergure de Veolia, tout en offrant une liberté technique totale à des dizaines d'équipes autonomes ? Voilà un challenge auquel Jujotte a été confronté, à l’occasion de la structuration du Design System multi-thèmes de Veolia.
L'écosystème digital de Veolia souffrait d'une fragmentation historique importante.
Les équipes de conception et de développement naviguaient à vue, sans réelle passerelle pour suivre les évolutions de part et d'autre. Pour ajouter à la complexité, le projet s’est ouvert dans un contexte de rush temporel intense, marqué par des mouvements structurels en interne.
"On est dans un vrai rush, mais on a un besoin critique de confiance, de guidance et de clarté. Il faut que nous puissions prouver de manière irréfutable que structurer ce Design System est un investissement hautement rentable pour le groupe."
Architecture sacralisée
en 3 briques Figma
(Core Master, Templates Layouts, UI KIT Veolia.com) pour séparer les fondations atomiques des livrables de mise en page.
Composants stratégiques industrialisés
et suivis par niveau de priorité (du Date Picker aux structures complexes de Dataviz ou Map Canvas).
Zéro rupture Design-Dev
grâce au déploiement de Storybook Angular et d'un workflow automatisé d’export de tokens CSS directement branché sur GitHub.
Les 3 piliers de notre intervention
L'architecture sacralisée sur Figma et la gestion multi-thèmes
Veolia doit composer avec plusieurs identités visuelles et thématiques internes. Pour éviter de multiplier les fichiers et d'exploser les coûts de maintenance, nous avons pris de la hauteur en organisant l'espace Figma en trois référentiels distincts : le Design System Core Master pour les éléments atomiques, le Templates Layouts pour standardiser la mise en page, et l'UI KIT Veolia.com pour l'écosystème web grand public. Nous avons également repensé la page "Style" historique pour la transformer en un espace "Fondations" global.
Pour résoudre l’impossibilité chronique qu'avaient les développeurs de suivre les modifications des designers, nous avons intégré le plugin Token Variable export. Les variables Figma sont désormais extraites automatiquement en tokens CSS puis poussées vers GitHub, assurant une flexibilité graphique optimale en conception comme en développement.
Industrialisation de +40 composants "Ready to Code" sous Storybook Angular
Le cahier des charges exigeait une flexibilité technique totale pour s'adapter à la Stack technique de chaque équipe produit, tout en s'appuyant sur la structure de la librairie NG-ZORRO (Ant.Design). Nous avons donc mené un grand chantier de nettoyage et d'inventaire sur plus de 40 composants clés (incluant Date Picker, Input, Dropdown, Table, Stepper, etc.). Toutes les design properties ont été remplies avec un niveau de détail poussé, et les sous-composants parasites ont été éradiqués.
Cette base saine est directement synchronisée avec l'environnement de développement via Storybook Angular, garantissant des composants fiables, testés et immédiatement intégrables. Ce travail a permis d'accompagner sereinement le groupe sur des chantiers UX/UI complexes, comme la modélisation industrielle du sous-système dédié aux formulaires web (Webforms), détaillant l'ensemble des types de champs et de leurs états systématiques (par défaut, focus, erreur, désactivé).
Documentation 2.0, choix théoriques fondamentaux et UX Research
Pour pallier le déficit d'alignement du passé, Jujotte a instauré une gouvernance solide matéraitisée par des points hebdomadaires et un workflow de contribution strict basé sur les API de Figma (Création ➔ Merge ➔ Publication).Mais un Design System ne vit que s'il est compris. Nous avons conçu un template de documentation 2.0 ultra-détaillé sur la plateforme Zeroheight.
C'est ici que nous avons tranché et documenté des arbitrages théoriques structurants (comme la règle d'usage des boutons rounded vs pill) pour tuer définitivement les débats esthétiques stériles qui ralentissent les équipes. Enfin, notre UX Researcher est allé réaliser des tests sur le terrain auprès des designers et développeurs de Veolia pour évaluer en conditions réelles la bonne compréhension de la documentation ZH et de l'usage des tokens, aboutissant à la création d'un mini-guide d'usage et de "starter packs" d'accueil optimisés .
Ce qu’on a refusé de faire.
Non à la conservation des sous-composants obsolètes
Par habitude ou par crainte de casser l'existant, certaines équipes souhaitaient conserver une granularité excessive et de vieux circuits de validation de composants. Nous avons opposé un refus pragmatique en élaguant drastiquement les sous-composants inutiles pour garantir un système évolutif, léger et scalable.
Non à la couche UI prématurée en plein rush documentaire
Face à l'urgence d’une première deadline, la tentation était forte de vouloir designer de nouveaux écrans complexes pour rassurer visuellement la direction. Nous avons refusé de brûler les étapes : pas un pixel n'a été poussé tant que la taxonomie des tokens, la structure de l'arborescence et les templates de pages ZH n'étaient pas rigoureusement validés. Un composant esthétique qui repose sur des fondations techniques mouvantes est une erreur critique qui détruit la confiance des développeurs.
Chaque composant a une raison d’être.
Le petit mot de Jujotte
Un groupe, aussi grand soit-il, a toujours besoin de prendre de la hauteur quant à ses enjeux produit, et notamment pour chercher à réduire sa dette technique/design. Notre rôle de partenaire n’a pas été de simplement dessiner des bibliothèques de composants, mais de concevoir une véritable culture de la gouvernance, des choix théoriques limpides et une architecture 'Ready to Code' pour que le Design System devienne le moteur premier de leur efficacité opérationnelle.
