100 %
d'intégration du design system par les équipes
16 %
de vélocité de développement en plus
En bref
La plateforme de La Ruche qui dit Oui ! sert quatre publics aux besoins très différents : Membres, Producteurs, Responsables de Ruche et Admin. Elle avait grandi sans design system. J’ai piloté la création du premier socle commun au design et au développement, du diagnostic jusqu’à son adoption par toutes les équipes.
Le résultat : 100 % d’intégration par les équipes et +16 % de vélocité de développement.
L’enjeu
Des années d’évolutions, de correctifs et de nouveaux écrans sans référentiel partagé avaient produit :
- une multiplication des styles et des composants ;
- des incohérences visuelles et fonctionnelles entre les interfaces Membres, Producteurs, Responsables de Ruche et Admin ;
- une expérience fragmentée selon les parcours et les contextes d’utilisation.
Le coût n’était pas seulement esthétique. Chaque équipe avait développé ses propres pratiques, et la cohérence devenait impossible à tenir dans la durée.
La question que j’ai posée : comment créer un design system partagé et scalable, qui aligne les équipes, accélère la delivery et rend les parcours cohérents pour les quatre publics ?
Diagnostiquer avant de construire
Plutôt que de concevoir des composants d’emblée, j’ai commencé par mesurer ce dont les équipes avaient réellement besoin. Un design system que personne n’utilise est un coût, pas un actif.
Un questionnaire aux PM et aux développeurs a objectivé leur rapport à l’existant : fréquence d’usage des composants, temps moyen d’intégration, difficultés quotidiennes. Il a confirmé l’absence de structure partagée.
Des entretiens qualitatifs ont fait ressortir deux attentes critiques, la documentation et la nomenclature, et un point de friction majeur : le handoff. Sans instructions claires, chaque développeur interprétait les composants à sa façon, et les incohérences apparaissaient en production.
Un atelier avec les équipes PM, Marketing et Communication a élargi le périmètre au-delà du duo design-développement. Il a fait émerger un besoin que les seuls développeurs n’auraient pas exprimé : savoir, en un coup d’œil, ce qui était disponible et utilisable immédiatement.
L’observation d’un développeur en train d’implémenter un composant a rendu les frictions concrètes : nomenclature peu lisible côté code, documentation insuffisante sur les cas de modification, aucune consigne de handoff.
Décider avec l’équipe, pas à sa place
La recherche a produit 69 insights. Je les ai regroupés en six axes : rôle perçu du design system, freins à l’adoption, usage quotidien, handoff et collaboration, gouvernance et communication, mesure et amélioration continue.
J’ai filtré et priorisé ces insights en 23 tâches actionnables, classées par impact et difficulté. L’IA a servi d’outil de synthèse ; aucune décision n’est entrée dans le backlog sans être validée avec l’équipe.
J’ai ensuite ouvert la priorisation à toute l’équipe : chacun votait pour les chantiers à traiter en premier. C’est ce qui a créé l’alignement dès le départ : l’équipe ne recevait pas une feuille de route, elle l’avait choisie.
Le backlog vivait dans Notion : chaque tâche portait ses parties prenantes, sa priorité et sa difficulté estimée. Ma règle de pilotage : traiter d’abord ce qui avait le plus d’impact pour le moins d’effort.
Ce que j’ai construit
Une architecture modulaire. Les composants sont organisés en atomes, molécules et organismes. Les designers trouvent ce dont ils ont besoin, et la gestion des niveaux de composants reste maîtrisable à mesure que le système grandit.
Des propriétés et des variables pour faire évoluer un système en pleine croissance, et une nomenclature uniforme qui a garanti la cohérence entre les composants.
Une documentation par composant, écrite pour les designers et les développeurs : configuration, usages, cas de modification.
Faire adopter
Livrer un design system ne suffit pas : l’adoption est un chantier à part entière, et je l’ai piloté comme tel.
Des points hebdomadaires avec les développeurs et la PM ont suivi l’avancement sprint par sprint, pour que le design system reste une priorité dans un contexte produit où d’autres urgences s’accumulaient.
Une communication continue : chaque mise à jour était annoncée sur un canal Slack dédié et dans une newsletter interne. Le projet restait visible, et toutes les équipes disposaient d’un canal de retour ouvert.
Résultats
- 100 % d’intégration du design system par les équipes.
- +16 % de vélocité de développement.
- Un socle unique pour les quatre publics de la plateforme.
Ce que j’en retiens
Co-construire le système dès le départ avec les développeurs et la PM a été le facteur décisif de son adoption. L’ancrer dans des besoins réels et immédiats, plutôt que de créer un design system « pour avoir un design system », et avancer par petits incréments a maintenu l’engagement de l’équipe dans la durée.
Ce que je ferais autrement : mettre en place un changelog dès le premier jour, pour donner aux équipes une visibilité continue sur les évolutions du système.
Trois convictions que je garde :
- Un design system vit grâce aux équipes qui l’utilisent, pas grâce à sa documentation.
- Évangéliser est un travail continu, pas une phase de projet.
- Penser la scalabilité dès le début est une décision d’architecture autant que de design : ce qui fonctionne pour 3 composants ne fonctionnera pas forcément pour 30.