Gouvernance
Un Design System ne vaut que si les équipes l'adoptent. La gouvernance organise cette adoption : qui décide, comment on contribue, comment le système évolue sans casser les produits qui l'utilisent.
Trois modèles d'organisation
Une équipe dédiée
Cohérence forte et décisions rapides, mais risque de goulot d'étranglement et d'éloignement des besoins réels.
Les équipes produit
Proche du terrain, mais la cohérence s'érode sans arbitre et la maintenance n'appartient à personne.
Un noyau et des contributeurs
Une équipe cœur garantit la qualité et la vision ; les équipes produit contribuent selon un processus clair.
Contribuer
Toute équipe peut proposer un composant, un variant ou une correction. Le processus est le même pour tous et ses délais sont publics.
Vérifier l'existant
Le besoin est-il couvert par un composant, un variant ou un pattern ? La moitié des demandes se règle ici.
Ouvrir une demande
Cas d'usage, équipes concernées, maquettes, impact sur l'accessibilité. Une demande portée par plusieurs équipes est prioritaire.
Revue hebdomadaire
L'équipe cœur accepte, propose une alternative ou refuse, toujours avec une justification écrite.
Construction accompagnée
Le contributeur construit avec le binôme design et développement de l'équipe cœur : tokens, états, tests, documentation.
Publication
Version mineure, note de version, annonce dans le canal du Design System. La note de version crédite le contributeur.
Rôles et responsabilités
| Activité | PM Design System | Équipe cœur | Équipes produit | Accessibilité |
|---|---|---|---|---|
| Feuille de route | R · A | C | C | I |
| Nouveau composant | A | R | C | C |
| Contribution externe | I | A | R | C |
| Conformité AA | A | R | I | C |
| Changement cassant | A | R | C | I |
| Mesure de l'adoption | R · A | C | C | I |
R : réalise · A : approuve · C : consulté · I : informé.
Versions et dépréciations
Le système suit le versionnage sémantique. Les équipes produit doivent pouvoir mettre à jour sans crainte.
| Type | Exemple | Engagement |
|---|---|---|
patch 2.0.1 | Correction de focus | Mise à jour sans risque, à appliquer dès que possible. |
minor 2.1.0 | Nouveau composant, nouveau variant | Rétrocompatible. |
major 3.0.0 | Renommage de token, suppression d'un variant | Annoncé une version à l'avance, alias et guide de migration fournis. |
Règle de dépréciationUn élément déprécié reste disponible pendant au moins une version majeure, affiche un avertissement en développement et figure dans le guide de migration.
Rituels
Revue des contributions
Trente minutes, ouvertes à tous, décisions écrites.
Permanence
Une heure pour répondre aux questions des équipes, sans rendez-vous.
Démonstration
Nouveautés, contributions remarquables, retours d'équipes produit.
Revue de la feuille de route
Priorités ajustées avec les responsables produit, à partir des indicateurs.
Mesurer l'adoption
Les indicateurs ci-dessous sont ceux que je suis sur un Design System à l'échelle d'un groupe. Les valeurs de l'accueil (12+ équipes adoptantes, 87 % de couverture, 78 % de réutilisation, NPS interne de 72) en sont l'application.
| Indicateur | Définition | Source |
|---|---|---|
| Équipes adoptantes | Produits qui utilisent la bibliothèque dans leur version maintenue. | Dépendances des dépôts |
| Couverture composants | Part des besoins d'interface couverts par un composant du système. | Inventaire des écrans |
| Taux de réutilisation | Part des composants utilisés issus du système, par rapport au code spécifique. | Analyse statique du code |
| Contributeurs actifs | Personnes ayant contribué sur les douze derniers mois. | Historique des demandes |
| Conformité WCAG AA | Part des composants conformes au niveau AA. | Audits |
| NPS interne | Recommandation du système par les équipes qui l'utilisent. | Enquête semestrielle |
| Détachements | Composants copiés puis modifiés localement : signal d'un besoin non couvert. | Outil de design, code |
Pour aller plus loin : Mesurer l'adoption d'un Design System sans se mentir.
Modèle de maturité
Inventaire
Des composants existent, éparpillés, sans source unique.
Bibliothèque
Une source unique en design et en code, documentation minimale.
Système
Tokens en couches, accessibilité intégrée, versions maîtrisées.
Produit
Feuille de route, contribution ouverte, adoption mesurée.
Plateforme
Le système alimente les outils, le CMS et l'IA : il devient l'infrastructure de l'interface.
Évaluez votre propre système avec l'auto-diagnostic de maturité.
Et la gouvernance de l'IA ?
Les mêmes mécanismes s'appliquent : registre, règles écrites, revue proportionnée au risque, indicateurs d'usage. La page Gouvernance de l'IA détaille le modèle.