Encore : à quoi ressemble un design system déployé sur 45 plateformes

En 2019, la direction de Spotify a voulu rendre l'audio disponible et cohérent sur n'importe quel appareil. Les chiffres publiés par l'équipe design sont frappants : 45 plateformes uniques et plus de 2 000 types d'appareils répartis sur 200 marques. Un utilisateur lance une playlist sur la télévision du salon, la continue dans sa voiture et la reprend sur son ordinateur portable le lendemain matin.

Il ne s'agit pas simplement d'une version agrandie du problème habituel des design systems. C'est un problème différent. Un téléviseur se regarde à trois mètres, une montre doit tout condenser, un ordinateur de bureau dispose d'un espace conséquent et une voiture impose des contraintes légales sur l'interaction. Aucune bibliothèque de composants unique ne peut répondre à tous ces besoins, et aucune documentation ne peut compenser cela.

Encore a été lancé avec deux segments. Encore Consumer Mobile était décrit comme incroyablement flexible, un vaste catalogue de composants en croissance constante pour les expériences centrées sur le mobile. Encore Web desservait une gamme plus large de produits web. Sous ces deux segments se trouvaient les design tokens couvrant les décisions fondamentales comme les palettes de couleurs et les styles typographiques.

Le modèle publié est concentrique. La foundation est au centre. Le Web et le Mobile se situent au-dessus en tant que sous-systèmes pairs avec une parité de plateforme. Plus loin se trouvent les sous-systèmes plus spécialisés — Content Web Platform, Advertising Web, Consumer Mobile — chacun divergeant progressivement du cœur.

L'intérêt de cette structure est que la divergence est bornée et localisée. Un composant dont seule la publicité a besoin réside dans l'anneau publicité, où il ne peut pas s'infiltrer dans l'application grand public. Une décision de couleur réside dans la foundation, où elle ne peut être modifiée localement. L'alternative — une bibliothèque plate unique pour tous — force chaque besoin spécialisé soit à être absorbé par le cœur, l'encombrant, soit à être construit en dehors du système, ce qui est le début de la fin pour tout design system.

Voici un point rarement abordé dans les écrits sur les design systems, car il s'agit d'un aveu. En 2022, l'équipe a jugé que le pendule avait trop basculé vers la flexibilité et qu'un recalibrage était nécessaire.

Le scénario est classique. Consumer Mobile était délibérément flexible, alors les équipes produit ont demandé des composants toujours plus raffinés, et le système a toujours accepté. Une flexibilité qui commence comme un atout devient une obligation : chaque besoin spécifique d'une équipe se transforme en un nouveau composant dont le système est responsable, et le catalogue croît plus vite que n'importe qui ne peut le maintenir de manière cohérente.

La correction apportée par Spotify est intéressante. Ils n'ont pas restreint Consumer Mobile ni commencé à rejeter les demandes. Ils ont formé une équipe pour créer des composants réutilisables pour Encore Mobile — insérant ainsi une nouvelle couche entre Consumer Mobile et la fondation. La description officielle de son objectif est précise : elle sert de première ligne de défense, réduisant la pression sur Consumer Mobile pour fournir chaque composant lui-même, tout en créant une plus grande parité de plateforme sur le reste du système.

Cela recadre un problème de gouvernance en un problème structurel. Lorsqu'un sous-système reçoit des demandes qui ne lui sont pas réellement spécifiques, le problème ne vient pas des demandes, mais de l'absence d'une couche partagée. Dire non aurait poussé ces équipes à construire en dehors du système. L'ajout de cette couche a permis de capturer ce travail.

Le récit du processus de travail de l'équipe est suffisamment concret pour être copié, et le changement crucial qu'ils soulignent est que les composants multiplateformes sont désormais conçus comme tels dès le départ, et non comme une adaptation après coup.

1. 1

   Réunir toutes les plateformes

   Les représentants d'iOS, d'Android et du Web ensemble, avant toute phase de conception. Leur argument sur la nécessité de cette approche est pertinent : il est rare de trouver quelqu'un d'expert à la fois en web et en mobile, l'expertise doit donc être assemblée plutôt que présumée.

2. 2

   Chaque plateforme audite et schématise ce qui est unique à son interface

   Le desktop dispose de plus d'espace. La télévision est différente en raison de la distance de visionnage. Une montre nécessite que toutes les informations soient condensées. Ces éléments sont posés comme des faits liés à l'interface avant même que l'on ne débatte du composant.

3. 3

   S'aligner sur les termes, les états et l'interaction des propriétés

   Le groupe de travail définit la nomenclature, les états existants et la manière dont les propriétés se combinent. C'est l'étape qui est souvent sautée, et c'est précisément pour cela que deux plateformes finissent avec un composant qui partage un nom, mais rien d'autre.

4. 4

   Concevoir le composant en tenant compte de tous ces éléments simultanément

   Il ne s'agit pas de créer la version d'une plateforme puis de l'adapter. C'est un seul composant dont les variantes étaient connues avant même d'être dessinées.

La troisième étape est celle qu'il vaut la peine d'emprunter, quel que soit votre nombre de plateformes. La plupart des dérives de composants commencent par une dérive du vocabulaire : le « secondaire » d'une équipe est le « ghost » d'une autre, l'état désactivé de l'une est le mode lecture seule de l'autre, et le temps que quelqu'un s'en aperçoive, les deux sont déjà en production.

En cherchant le design system de Spotify, l'un des premiers résultats est le guide public « Design & Branding Guidelines » sur le site développeur. Il est important de préciser qu'il ne s'agit pas d'Encore, ni d'un design system au sens habituel. C'est un document de conformité.

Sa structure le trahit : attribution, utilisation du contenu Spotify, navigation dans le contenu, liens vers Spotify, vues de lecture, affichage d'entités, utilisation du logo, utilisation des couleurs, restrictions de logo et de nom, polices. La raison invoquée pour les règles d'attribution est que le contenu disponible via Spotify appartient à de nombreux ayants droit différents ; ainsi, toute utilisation des métadonnées de Spotify — noms d'artistes, d'albums et de pistes, visuels, lecture audio — doit être accompagnée de la marque Spotify. La page précise que l'utilisation de ces ressources implique l'acceptation des conditions d'utilisation du développeur.

Cette distinction est cruciale si vous construisez un produit qui intègre le contenu ou la marque d'un tiers. Ces règles sont contractuelles, et l'argument « c'était plus joli sans le logo » n'est pas recevable. C'est également important en tant que catégorie : si votre produit est consommé par les produits d'autres personnes, vous pourriez avoir besoin de ce document en plus d'un design system, et ce ne sont pas les mêmes exercices de rédaction.

Le modèle concentrique se transpose directement aux guides de design rédigés pour les agents de code IA, et il résout un problème qui apparaît dès qu'un projet possède plus d'un type d'interface.

L'échec classique consiste à utiliser un seul fichier DESIGN.md pour couvrir à la fois un site marketing, le shell d'une application et un tableau de données dense. Les règles finissent par être nuancées — « espacement généreux, bien que les tableaux puissent être plus denses » — or une règle nuancée n'est pas une règle. Le modèle doit trancher, et il tranche différemment à chaque fois.

La superposition de couches fonctionne de la même manière que dans Encore :

# DESIGN.md          <- foundation: tokens, roles, prohibitions
                        applies everywhere, never overridden

# app/marketing/DESIGN.md
   Extends the root. Spacing scale shifted up one step.
   Hero type may use the display scale (48px+).
   Cards may use shadow elevation.

# app/dashboard/DESIGN.md
   Extends the root. Compact spacing (8-12px controls).
   Elevation is surface steps + hairline, never shadow.
   Table rows: 32px, no vertical padding above 8px.

Chaque fichier est sans ambiguïté dans son propre périmètre. La racine ne contient que ce qui ne doit absolument pas varier — rôles de couleurs, famille typographique, interdictions — et les feuilles contiennent les décisions qui diffèrent légitimement. Un agent travaillant dans app/dashboard/ lit deux fichiers et obtient une réponse unique et claire, plutôt qu'un seul fichier truffé de réserves.

Nous avons analysé 299 fichiers DESIGN.md publiés pour être lus par des agents. 44 % ne contenaient aucune valeur de taille concrète et 54 % s'appuyaient sur au moins un adjectif vague — « clean » dans 39 % des cas, « moderne » dans 36 %. C'est l'exemple extrême du problème de nuance : un fichier qui ne s'engage jamais sur un chiffre ne peut pas être en contradiction avec lui-même, mais il ne peut pas non plus produire une interface cohérente.

Vous n'avez probablement pas 45 plateformes. Vous avez peut-être trois surfaces, dont deux ont divergé discrètement, et une équipe qui demande sans cesse un composant que personne d'autre ne veut. C'est le même problème, à une échelle réduite, et les solutions d'Encore s'appliquent également à cette taille.

Placez ce qui ne doit pas varier dans une fondation et rendez-le véritablement non modifiable. Laissez les besoins spécialisés dans des couches spécialisées plutôt que de les forcer dans le cœur du système ou de les en exclure totalement. Lorsqu'une couche est submergée de demandes, cherchez la couche manquante en dessous avant de commencer à refuser. Et concevez pour toutes les surfaces simultanément, car un composant adapté a posteriori est un composant qui divergera.