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 s'en aperçoit |
| 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 | À peu près aussi efficace que le gratuit |
| Linting | Signaler les violations dans l'éditeur et les rejeter en CI | Investissement réel en outillage, plus un ensemble de règles maintenu parallèlement au système | Élevé. C'est ici que se trouve la majeure partie du retour sur investissement de la 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 disposent de 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 check CI qui échoue dès qu'une valeur de couleur littérale est utilisé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 dans 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 manque d'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 particulier. 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 former 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 rythme : une personne propose un changement, une personne le examine, la cadence est limitée par le débit humain. Cette hypothèse n'est plus valable.
Un agent écrit quarante écrans entre deux revues. Il n'a aucun souvenir de vos conventions d'une session à l'autre, aucun intérêt à prendre des raccourcis et aucune possibilité de demander à un collègue quel gris utiliser. 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 bien plus lourde. Le volume de code écrit en s'appuyant sur le système a augmenté, mais la capacité de revue n'a pas suivi. |
| Ambiguïté dans le système | Beaucoup plus coûteux. Un humain qui hésite sur le token à utiliser pose la question ; un modèle choisit silencieusement, dans chaque fichier. |
| Convention non documentée | Inutile. Tout ce qui ne réside que dans l'esprit des gens est désormais simplement absent. |
La dernière ligne représente le changement le plus brutal. La plupart des design systems ont toujours été composés en partie d'écrits et en partie de folklore ; ce folklore fonctionnait parce qu'un développeur ayant vu les dix écrans précédents l'assimilait. Ce mécanisme de transmission n'existe pas pour un agent : chaque convention non écrite devient donc une lacune que le modèle comble avec ses données d'entraînement.
Nous avons analysé 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 en hexadécimal brut sans rôle sémantique, 69 % ne définissent aucun mode sombre et 44 % n'indiquent 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 d'Identity Forge sont l'artefact gouverné en ce sens : rôles sémantiques de couleurs 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, le tout sérialisé dans un DESIGN.md que chaque agent lit avant d'écrire. Parcourez les kits ou découvrez comment documenter un système pour l'IA.
Gouvernance minimale viable
La plupart des conseils en gouvernance supposent l'existence d'une équipe plateforme dédiée, ce que la majorité des équipes n'ont pas. Voici à quoi ressemble le même travail sans équipe dédiée.
- 1
Consignez ce qui appartient au cœur du système
Un paragraphe. Ce qui ne doit jamais être modifié (rôles de couleurs, échelle typographique, échelle d'espacement, interdictions) et ce qui peut varier selon l'interface. La plupart des débats sur la contribution sont en réalité des débats sur cette frontière, 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 seul contrôle est plus efficace qu'un processus de contribution, et ne coûte qu'une après-midi de travail.
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 unique, pas un comité
Quelqu'un capable de dire oui en une journée. Un système qui met deux semaines à approuver un changement est un système que les équipes contourneront, et ce contournement est irréversible. Le travail s'effectue alors hors de vue, là où vous ne pouvez plus le contrôler.
- 4
Révisez par interface, pas par composant
Une fois par trimestre, ouvrez trois écrans d'une même interface côte à côte. La dérive est invisible fichier par fichier, mais évidente en 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 différents ou que la couche sémantique est incomplète. Traitez la demande, puis corrigez la cause. Une règle qui nécessite trois exceptions est une règle mal écrite.
L'étape quatre est celle que les équipes sautent, et pourtant c'est celle qui est la plus fructueuse. Examiner une pull request vous indique si ce fichier est cohérent avec lui-même. Seule la comparaison d'écrans terminés vous indique si le produit est cohérent avec lui-même, et c'est précisément ce que le système doit 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 appliquée. La plupart des discussions traitent minutieusement 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 fédérée ?
Centralisée : une équipe dédiée possède le système et les équipes produit demandent des modifications ; qualité élevée, mais risque de goulot d'étranglement. Fédérée : des contributeurs répartis dans plusieurs équipes possèdent des parties du système selon des normes communes ; meilleur débit, mais risque d'érosion de la cohérence. Hybride : une équipe cœur gère les fondations et la revue, tandis que 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 les bloque en CI est plus efficace que n'importe quelle documentation. Mieux encore, supprimez la possibilité de dévier (par exemple, via une API de stylisation limitée aux tokens) là où vous contrôlez l'interface. La documentation seule n'a pratiquement aucune valeur d'application.
Mon équipe design system est submergée par les demandes. Devrions-nous refuser plus souvent ?
Vérifiez d'abord si une couche ne manque pas. 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 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 écrit en s'appuyant sur celui-ci augmente sans que la capacité de revue ne suive, augmentant ainsi la charge de contrôle. L'ambiguïté devient également plus coûteuse : là où un humain hésitant sur le token à utiliser pose une question, un modèle fait un choix silencieux dans chaque fichier qu'il modifie.