Un système bien conçu peut quand même mourir

Quand un Design System s'éteint, on cherche souvent la cause dans sa conception : des composants trop rigides, une palette mal choisie, une documentation confuse. C'est rarement la vraie raison. La plupart des systèmes que j'ai vus décliner étaient correctement dessinés et correctement codés. Ils sont morts parce que plus personne ne s'en occupait comme d'un produit.

Le scénario est presque toujours le même. Un projet de refonte finance la création du système. L'équipe livre une bibliothèque solide, la présente, puis le budget du projet s'arrête. Le système continue d'exister, mais il n'évolue plus au rythme des produits qui l'utilisent. Les équipes contournent, puis copient, puis oublient.

Quatre signaux à surveiller

Les détachements se multiplient

Un détachement, c'est un composant copié puis modifié localement. Un ou deux, c'est normal : ils signalent un besoin que le système ne couvre pas encore. Quand ils se comptent par dizaines, c'est que les équipes ont cessé d'attendre le système. Elles construisent leur propre version, qui divergera à chaque mise à jour.

La documentation décroche

Une page de documentation qui décrit un comportement que le code n'a plus, un exemple qui ne fonctionne pas, un composant récent absent de la liste. Chacun de ces écarts coûte un peu de confiance. Au bout de quelques mois, les équipes ne consultent plus la documentation et posent leurs questions sur la messagerie interne, ou ne les posent plus du tout.

L'équipe cœur ne fait plus que du support

Quand l'équipe passe ses journées à répondre aux mêmes questions et à corriger des urgences, elle n'a plus de temps pour faire évoluer le système. Le retard s'accumule, les demandes s'empilent, et les équipes produit en concluent que le système ne suit pas.

Personne ne sait qui décide

Qui valide un nouveau variant ? Qui peut déprécier un composant ? Si la réponse change selon la personne interrogée, le système n'a pas de gouvernance. Les décisions se prennent alors par défaut, c'est-à-dire qu'elles ne se prennent pas.

La cause commune : un projet au lieu d'un produit

Ces quatre signaux ont une origine commune. La direction a financé et piloté le Design System comme un projet, avec un début, une fin et un livrable. Or un système d'interface a des utilisateurs, les équipes produit, dont les besoins changent en permanence. Il a besoin d'une feuille de route, d'arbitrages, de mesures et de quelqu'un qui en répond. Il a besoin d'être géré comme un produit.

Un Design System ne vaut que si les équipes l'adoptent. Sinon, c'est juste une bibliothèque que personne n'ouvre.

Cinq actions pour inverser la courbe

Nommer un responsable produit

Une personne qui porte la vision, arbitre les priorités et rend compte de l'adoption. Ce rôle peut être à temps partiel au début, mais il doit exister et être connu de tous.

Mesurer l'usage réel

Nombre d'équipes qui utilisent la version maintenue, couverture des besoins d'interface, taux de réutilisation, satisfaction des équipes. Ces chiffres transforment des impressions en décisions et donnent des arguments pour défendre le budget.

Ouvrir la contribution

Une équipe cœur ne pourra jamais couvrir tous les besoins seule. Un processus de contribution écrit, avec des délais publics et une revue hebdomadaire, transforme les équipes produit en co-auteurs du système. Les détachements deviennent des propositions.

Distribuer là où l'on travaille

Le meilleur système du monde ne sert à rien s'il faut quitter son outil pour le trouver. Les composants doivent être disponibles dans l'outil de design, dans le gestionnaire de paquets, dans le CMS, et aujourd'hui dans le contexte des assistants d'IA.

Rendre le travail visible

Démonstrations mensuelles, notes de version lisibles, contributions créditées. Un système dont on parle reste vivant. Les équipes jugent abandonné un système silencieux, même quand il ne l'est pas.

Un plan de reprise en 90 jours

  1. Semaines 1 à 3 : inventaire des détachements, entretiens avec cinq équipes produit, liste des irritants.
  2. Semaines 4 à 6 : remise à niveau de la documentation des dix composants les plus utilisés, publication du processus de contribution.
  3. Semaines 7 à 9 : traitement des trois demandes les plus partagées, première démonstration ouverte.
  4. Semaines 10 à 13 : premier tableau de bord d'adoption, feuille de route du semestre présentée aux responsables produit.

Ce plan ne règle pas tout. Il montre en revanche aux équipes que le système a de nouveau quelqu'un aux commandes, et c'est souvent ce qui manquait le plus.

Ce qu'il faut retenir

Un Design System ne meurt pas d'un coup. Il s'éteint lentement, à mesure que la confiance des équipes s'érode. Les signaux sont visibles des mois à l'avance pour qui les cherche. La bonne nouvelle, c'est que ces actions coûtent peu : un responsable, quelques mesures, un processus écrit et un peu de communication. La mauvaise, c'est qu'aucun d'eux ne fonctionne si le système reste traité comme un projet terminé.