Les trois modèles et leurs coûts réels
Toute analyse de ce sujet aboutit aux trois mêmes schémas. Ils sont réellement différents et le choix est important, mais la présentation occulte le fait que tous trois ne répondent qu'à une seule des trois questions de gouvernance.
| Fonctionnement | Coût | |
|---|---|---|
| Centralisé | Une équipe dédiée possède le système. Les équipes produit le consomment et demandent des modifications | L'équipe devient un goulot d'étranglement, et les équipes produit la contournent pour respecter les délais. La qualité est élevée ; le risque réside dans l'adoption |
| Fédéré | Des contributeurs répartis dans les équipes produit possèdent des parties du système, selon des standards partagés | La cohérence s'érode. Personne ne possède l'ensemble, donc les parties divergent et personne ne peut s'en apercevoir |
| Hybride | Une petite équipe cœur possède les fondations et la revue ; les équipes produit contribuent aux composants | La réponse la plus courante et la plus difficile à maintenir. Son efficacité dépend entièrement de la définition de la frontière entre le cœur et les contributions |
L'hybride est généralement la bonne approche, et son échec n'est pas dû au modèle. Il échoue quand personne n'a défini par écrit ce qui appartient au cœur ; chaque contribution devient alors une négociation et le cœur absorbe des éléments qu'il ne devrait pas.
La question à laquelle les modèles ne répondent pas
La gouvernance de la contribution décide comment le système évolue. La gouvernance de la conformité décide si quelqu'un le suit. C'est là que les systèmes meurent, et c'est un sujet à peine abordé car il manque de prestige.
Le symptôme est familier : un design system bien entretenu, un processus de contribution actif, et une base de code contenant quatre cents valeurs hexadécimales littérales. Personne n'a violé une règle délibérément. C'était un vendredi, le token ne convenait pas tout à fait, et ajouter une valeur hexadécimale était plus rapide qu'une discussion, trois cents fois de suite.
Personne n'a violé le système délibérément. Ajouter une valeur littérale était plus rapide qu'une discussion, trois cents fois de suite.
Il existe exactement trois mécanismes d'application, et un seul d'entre eux est gratuit :
| Mécanisme | Coût | Efficacité | |
|---|---|---|---|
| Documentation | Consigner ce qui est correct | Gratuit | Presque aussi efficace que le gratuit |
| Linting | Signaler les violations dans l'éditeur et les rejeter en CI | Investissement réel en outils, plus un ensemble de règles maintenu parallèlement au système | Élevé. C'est ici que l'on tire le meilleur profit de l'effort de gouvernance |
| Suppression de la capacité | Rendre l'erreur impossible à exprimer | Chaque nouveau besoin réel devient une demande adressée aux propriétaires du système | Totale, dans la limite du périmètre couvert |
Les deux lignes efficaces présentent des précédents publiés qui méritent d'être étudiés. Le SLDS 2 de Salesforce propose un linter et un validateur qui analysent le balisage par rapport à une base de données de règles et recommandent des corrections — c'est la ligne du milieu, à l'échelle d'une entreprise. Le kit UI d'application de Stripe adopte l'approche de la ligne du bas : sa prop css n'accepte que des tokens nommés et rien d'autre, plusieurs composants refusent totalement les overrides, et des contraintes de hiérarchie de composants restreignent ce qui peut en contenir un autre.
Si vous ne pouvez faire qu'une seule chose, ajoutez un unique contrôle CI qui rejette toute valeur de couleur littérale située en dehors de votre fichier de tokens. Cela prend une après-midi et stoppe définitivement la forme la plus courante de dérive. Tout le reste de la gouvernance est négociable ; ceci ne l'est pas.
La ligne du bas n'est disponible que sur les surfaces que vous contrôlez. Stripe peut supprimer cette capacité dans son propre tableau de bord, mais pas dans votre page de paiement — c'est pourquoi il y propose plutôt une échelle de personnalisation. La posture suit le périmètre, pas la préférence.
Quand un problème de gouvernance est un problème structurel
La leçon de gouvernance publique la plus utile est celle qu'une équipe a publiée sur sa propre erreur, et elle ne concerne pas du tout les règles.
Encore de Spotify a été lancé avec un sous-système mobile délibérément flexible. Les équipes produit demandaient des composants de plus en plus spécifiques, et le système acceptait tout. En 2022, l'équipe a jugé que le pendule avait trop penché vers la flexibilité et qu'un recalibrage était nécessaire.
La réponse évidente en termes de gouvernance aurait été de durcir le processus : critères d'acceptation plus stricts, barre plus haute pour les nouveaux composants, plus de revues. Ils ont fait autre chose. Ils ont construit une nouvelle couche entre le sous-système flexible et la fondation, décrite comme une première ligne de défense qui réduit la demande sur le sous-système spécialisé tout en augmentant la parité de la plateforme.
Cela recadre un problème de gouvernance en un problème d'architecture, et ce recadrage se généralise. Lorsqu'une partie d'un système est submergée de demandes, celles-ci ne lui sont généralement pas spécifiques — il manque une couche partagée en dessous. Les refuser pousse les équipes à construire en dehors du système, où vous perdez totalement de vue le travail effectué. Ajouter la couche permet de le capturer.
| Ressemble à | Est généralement | |
|---|---|---|
| Demandes constantes de nouveaux composants | Contributeurs ne respectant pas le processus | Une couche partagée manquante entre le cœur et le sous-système spécialisé |
| Équipes construisant en dehors du système | Manque de discipline dans l'adoption | Le système dit non plus vite qu'il ne dit oui |
| Multiplication des tokens de composants | Contributions négligées | La couche sémantique ignore un élément dont tout le monde a besoin |
| Règles nécessitant sans cesse des exceptions | Règles ignorées | Une règle couvrant deux surfaces qui diffèrent légitimement |
La dernière ligne mérite un examen attentif. Une règle avec une nuance — "espacement généreux, bien que les tableaux puissent être plus denses" — est en réalité deux règles qui prétendent n'en être qu'une. Chaque demande d'exception à son égard est correcte, et aucune mesure de gouvernance ne peut régler cela.
Ce qui change quand le contributeur est un modèle
Les cadres de gouvernance supposent un certain rythme : une personne propose un changement, une personne le examine, et la cadence est limitée par le débit humain. Cette hypothèse n'est plus valable.
Un agent écrit quarante écrans entre deux révisions. Il n'a aucune mémoire de vos conventions d'une session à l'autre, aucun intérêt à prendre des raccourcis et aucune capacité à demander à un collègue quel gris est le bon. Deux conséquences en découlent, et elles tirent dans des directions opposées.
| Effet | |
|---|---|
| Processus de contribution | Charge réduite. Les agents proposent rarement des modifications au système lui-même — ils le consomment. |
| Application de la conformité | Charge considérablement accrue. Le volume de code écrit par rapport au système augmente ; la capacité de revue, elle, n'évolue pas. |
| Ambiguïté dans le système | Coût bien plus élevé. Un humain incertain de l'utilisation d'un token posera la question ; un modèle choisit silencieusement, dans chaque fichier. |
| Convention non documentée | Inutile. Tout ce qui n'est conservé que dans l'esprit des collaborateurs est désormais tout simplement absent. |
La dernière ligne est le changement le plus radical. La plupart des design systems ont toujours été composés d'une partie de code et d'une partie de folklore, et ce folklore fonctionnait parce qu'un développeur ayant vu les dix écrans précédents l'absorbait. Ce mécanisme de transmission n'existe pas pour un agent ; ainsi, chaque convention non écrite devient une lacune que le modèle comble à partir de ses données d'entraînement.
Nous avons échantillonné 299 fichiers DESIGN.md écrits spécifiquement pour combler cette lacune. 76 % ne contiennent aucune interdiction de quelque nature que ce soit, 86 % spécifient les couleurs sous forme de code hexadécimal brut sans rôle sémantique, 69 % ne définissent aucun mode sombre et 44 % ne mentionnent aucune valeur de taille concrète. Ce sont des documents de gouvernance qui ne gouvernent rien — et contrairement à un wiki que personne ne lit, celui-ci est lu à chaque requête.
Les kits de design Identity Forge sont l'artefact gouverné en ce sens : rôles de couleurs sémantiques pour les modes clair et sombre, échelles de typographie et d'espacement, motifs, et une liste explicite de ce qu'il faut faire et ne pas faire, sérialisée dans un DESIGN.md que chaque agent lit avant d'écrire. Parcourir les kits, ou lire comment documenter un système pour l'IA.
Gouvernance minimale viable
La plupart des conseils de gouvernance publiés supposent l'existence d'une équipe dédiée au design system, ce que la plupart des équipes n'ont pas. Voici à quoi ressemble ce même travail sans une telle équipe.
- 1
Consignez ce qui appartient au cœur du système
Un paragraphe. Ce qui ne peut jamais être outrepassé — rôles de couleurs, échelle typographique, échelle d'espacement, interdictions — et ce qui est libre de varier selon la surface. La plupart des débats sur la contribution portent en réalité sur cette limite, sans que personne ne la nomme.
- 2
Ajoutez un contrôle CI
Faites échouer le build en cas de valeur de couleur littérale en dehors du fichier de tokens. Ce simple contrôle est plus efficace qu'un processus de contribution, et il ne coûte qu'un après-midi.
grep -rn --include='*.tsx' --include='*.css' -E '#[0-9a-fA-F]{3,8}\b' src \ | grep -v 'tokens\|globals.css' && exit 1 || exit 0 - 3
Nommez un responsable, pas un comité
Quelqu'un capable de dire oui en une journée. Un système qui met deux semaines pour approuver une modification est un système que les équipes contourneront, et le contournement est irrécupérable — le travail se fait alors en dehors de votre champ de vision.
- 4
Revue par surface, pas par composant
Une fois par trimestre, ouvrez trois écrans d'une même surface côte à côte. La dérive est invisible par fichier mais évidente par comparaison, c'est pourquoi la revue par pull request ne la détecte jamais.
- 5
Suivez les demandes d'exception comme des défauts du système
Chaque demande d'exception prouve qu'une règle couvre deux cas qui diffèrent, ou que la couche sémantique manque de précision. Traitez la demande, puis corrigez la cause. Une règle qui nécessite trois exceptions est une règle mal écrite.
La quatrième étape est celle que les équipes sautent et celle qui révèle le plus de problèmes. Réviser une pull request vous indique si ce fichier est cohérent avec lui-même. Seule la comparaison d'écrans finis vous indique si le produit est cohérent avec lui-même, et c'est précisément ce que le système est censé protéger.
Qu'est-ce que la gouvernance d'un design system?
L'ensemble des règles définissant qui peut modifier le système, comment les contributions sont proposées et acceptées, et comment la conformité est assurée. La plupart des discussions traitent en profondeur les deux premiers points et à peine le troisième, ce qui est regrettable car c'est là que les systèmes échouent généralement.
Quelle est la différence entre une gouvernance centralisée et une gouvernance fédérée?
La centralisation signifie qu'une équipe dédiée possède le système et que les équipes produit demandent des modifications — haute qualité, mais risque de goulot d'étranglement. La fédération signifie que des contributeurs issus de différentes équipes possèdent des parties du système selon des standards partagés — meilleur débit, mais risque d'érosion de la cohérence. L'approche hybride les sépare : une équipe centrale possède les fondations et la revue, les équipes produit contribuent aux composants.
Comment amener les équipes à réellement suivre le design system?
Mécaniquement. Un linter qui signale les violations dans l'éditeur et fait échouer le CI est plus efficace que n'importe quelle documentation ; et supprimer la possibilité de dévier — par exemple via une API de style limitée aux tokens — est encore plus puissant lorsque vous contrôlez la surface. La documentation seule n'a quasiment aucune valeur d'application.
Mon équipe design system est submergée par les demandes. Devrions-nous refuser plus souvent ?
Vérifiez d'abord s'il ne manque pas une couche. Spotify a rencontré ce problème avec Encore et a ajouté une couche partagée entre le sous-système flexible et la fondation plutôt que de durcir les critères d'acceptation, car les demandes n'étaient pas réellement spécifiques à ce sous-système. Refuser des demandes pousse les équipes à construire en dehors du système, rendant ainsi leur travail invisible.
La gouvernance change-t-elle maintenant que l'IA écrit la majeure partie de l'UI ?
L'équilibre bascule radicalement. Les agents proposent rarement des modifications au système, ce qui réduit la charge liée aux contributions, tandis que le volume de code généré augmente sans que la capacité de revue ne suive : la charge de contrôle s'alourdit donc. L'ambiguïté devient également plus coûteuse : là où un humain demande quel token utiliser en cas de doute, un modèle fait un choix silencieux dans chaque fichier qu'il modifie.