Analyse indépendante de la documentation publique de Salesforce et des écrits de son équipe design. Identity Forge n'est pas affilié à Salesforce et n'est pas approuvé par celle-ci. Salesforce, Lightning et Agentforce sont des marques déposées de leurs propriétaires respectifs. Les détails de la version reflètent la documentation au moment de la rédaction.
Le problème de SLDS 1
SLDS 1 a été lancé en 2015 et, selon les termes de Salesforce, a établi la norme du design d'entreprise de l'époque. C'est un framework CSS : importez-le, utilisez ses classes, et vos composants web Lightning personnalisés ressemblent à Lightning Experience. C'est exactement ce qu'une plateforme d'entreprise recherchait en 2015, quand l'objectif était la cohérence entre des milliers d'organisations et que l'on supposait que la cohérence signifiait l'uniformité.
La raison invoquée pour cette reconstruction est double. La demande des clients pour une personnalisation plus poussée a augmenté, et l'IA générative a commencé à remodeler les expériences utilisateur. Ces deux pressions convergent vers le même constat : un framework dont les décisions visuelles sont figées dans les définitions de classes ne peut être thémé en profondeur et ne peut constituer une cible stable pour l'UI générée.
C'est un aveu assez brutal de la part d'un fournisseur concernant son propre système phare vieux de dix ans. C'est également exact, et le même diagnostic s'applique à un grand nombre de design systems internes pour lesquels cela n'a jamais été formulé explicitement.
Ce que SLDS 2 a changé
L'affirmation architecturale est précise : la nouvelle architecture CSS est découplée du style visuel par défaut de Salesforce, ce qui signifie que vous n'êtes plus prisonnier de choix de design prédéfinis pour les composants, notamment les boutons, les modales, les polices et les bordures. Le mécanisme repose sur les styling hooks globaux — des propriétés CSS personnalisées — qui remplacent les valeurs codées en dur dans les règles du framework.
| SLDS 1 | SLDS 2 | |
|---|---|---|
| Lieu des décisions visuelles | Dans les règles CSS du framework | Dans des propriétés CSS personnalisées configurables |
| Modifier un rayon de bordure partout | Surcharger les sélecteurs, lutter contre la spécificité, espérer | Définir une seule propriété personnalisée |
| Profondeur du thémage | Couleurs de marque et logo, approximativement | Boutons, modales, polices, bordures, espacements |
| Mode sombre | Non réalisable | La voie tracée pour l'avenir |
| Ce qu'affirme le framework | Structure et apparence | Structure ; l'apparence est fournie |
La phrase utilisée par Salesforce pour justifier l'avantage est à citer comme principe de design : un seul changement met tout à jour. Au lieu de modifier les composants individuellement, les styling hooks permettent d'ajuster les valeurs en un seul endroit pour des mises à jour globales instantanées.
Cette phrase est la définition même d'un système de tokens, et c'est le test à appliquer au vôtre. Si modifier le rayon des bordures de votre marque implique d'éditer plus d'un seul endroit, vous avez des variables, pas des tokens. La différence réside dans le fait que la valeur possède un seul foyer ou plusieurs copies.
Autour de l'architecture se trouvent les changements visibles. Salesforce Cosmos est le nouveau thème par défaut de SLDS 2, décrit comme offrant un espacement adaptable, des vues d'un coup d'œil, une palette de couleurs enrichie, une échelle typographique lisible et une charge cognitive réduite. La fonctionnalité étendue « Thèmes et Branding » dans la Configuration permet aux administrateurs d'appliquer des couleurs de marque, des logos et des images sans code, avec neuf nouvelles options de couleurs d'accentuation.
La séparation no-code/pro-code est délibérée et assumée : les administrateurs bénéficient d'un design basé sur le clic, tandis que les designers et les développeurs disposent d'un contrôle pro-code via les styling hooks. C'est une véritable décision de gouvernance de design system — décider quel public accède à quelle interface — et la plupart des systèmes ne construisent jamais que la partie pro-code.
La bibliothèque Figma qui correspond exactement au code
Un détail mérite d'être isolé car il résout un problème que presque tous les design systems rencontrent et que presque aucun ne résout correctement. La bibliothèque Figma de SLDS 2 utilise la même convention de nommage sémantique pour les styling hooks que le code — les exemples de Salesforce sont radius-border-4 et font-scale-4 — ainsi, les designs correspondent un pour un au code réel.
L'effet annoncé est un vocabulaire partagé faisant le pont entre le design et le développement. L'effet pratique est que le handoff de design cesse d'être un exercice de traduction. Quand un designer dit font-scale-4 et que le développeur tape font-scale-4, toute la catégorie de questions du type « quel gris voulais-tu dire » disparaît.
La bibliothèque contient également toutes les variables et propriétés que l'on peut basculer, afin que les composants puissent être modifiés directement dans Figma plutôt qu'en alternant entre le site de documentation et le fichier de design pour mettre à jour les composants un par un. C'est un petit détail d'outillage avec une conséquence comportementale majeure : cela élimine la friction qui pousse les designers à sortir du système.
Quand un designer ditfont-scale-4et que le développeur tapefont-scale-4, toute une catégorie de bugs de handoff cesse d'exister.
L'application : le linter
SLDS 2 livre des outils qui valident les composants par rapport aux règles SLDS plutôt que de simplement les décrire. SLDS Linter est l'outil d'analyse de code ; SLDS Validator scanne le markup, le valide par rapport à une base de données et propose des recommandations de correction. Salesforce liste de nouveaux ensembles de règles, un guidage en ligne et un linting en masse.
C'est le même instinct que le kit UI d'application de Stripe qui refuse le CSS arbitraire, atteint par un chemin différent. Stripe supprime la capacité ; Salesforce ne le peut pas, car SLDS est du CSS dans l'org d'un client et le client peut toujours écrire davantage de CSS. Il fait donc la meilleure chose suivante : rendre les violations visibles mécaniquement.
| Mécanisme | Coût | |
|---|---|---|
| Documentation | Écrire ce qui est correct et espérer | Gratuit, et environ aussi efficace que gratuit |
| Linting | Signaler les violations dans l'éditeur et dans la CI | Investissement réel en outillage ; nécessite une base de règles maintenue parallèlement au système |
| Suppression de la capacité | Rendre l'erreur impossible à exprimer | Chaque nouveau besoin réel devient une requête adressée aux propriétaires du système |
La plupart des équipes ne tentent que la première ligne. La ligne du milieu est celle où le retour sur effort est le plus élevé, et elle est suffisamment ingrate pour être rarement priorisée jusqu'à ce que quelqu'un compte le nombre de valeurs hexadécimales dans la base de code.
La partie agentique, selon les propres mots de Salesforce
La description de SLDS 2 par Salesforce est directe : c'est le fondement du design system agentique pour les produits Salesforce bâtis sur la Lightning Platform. Le blog l'annonçant précise que la nouvelle architecture pose les bases des expériences agentiques et du mode sombre, et décrit une réinvention du fonctionnement des design systems, tant dans le flux de travail design-développement que dans les expériences utilisateur générées dynamiquement.
C'est cette dernière phrase qu'il faut analyser. Expériences utilisateur générées dynamiquement. Il ne s'agit pas de « l'IA aide les développeurs à écrire du code plus vite » — l'interface elle-même est assemblée au moment de l'exécution, par utilisateur et par contexte, par quelque chose qui n'est pas un designer.
Si c'est votre hypothèse, un design system qui intègre l'apparence dans les définitions de composants est structurellement incapable de répondre à ce besoin, car le générateur n'a rien à faire varier. Ce dont une interface générée a besoin est exactement ce que fournit SLDS 2 : un vocabulaire structurel stable avec des décisions visuelles exposées sous forme de valeurs nommées et configurables.
Il est intéressant de noter qui avance cet argument. Il ne s'agit pas d'une startup vendant des outils de design IA. C'est un fournisseur de plateforme entreprise avec dix ans de parc installé et tout intérêt à ne pas reconstruire un framework fonctionnel, qui publie néanmoins qu'il l'a fait et explique pourquoi.
Le même mouvement, trois fois
SLDS 2 n'est pas un cas isolé. Trois des plus grands design systems d'entreprise publiés ouvertement se sont restructurés en environ dix-huit mois, chacun misant différemment sur la même prémisse.
| Ce qui a changé | Le pari | |
|---|---|---|
| Salesforce Lightning (SLDS 2) | Architecture CSS découplée du style visuel ; styling hooks ; linter et validator | La structure et l'apparence doivent être séparées, et les violations doivent être détectées mécaniquement |
| IBM Carbon | Un serveur MCP exposant la documentation et des exemples de code aux agents | Les agents devraient récupérer le système au moment de la génération plutôt que de s'appuyer sur leur mémoire |
| Shopify Polaris | React abandonné au profit de composants web agnostiques vis-à-vis du framework, servis via un CDN | La livraison ne doit pas présumer de ce qui a généré la page |
Rien de tout cela n'a été coordonné. Trois entreprises avec des produits et des contraintes différents sont arrivées à des conclusions compatibles dans la même fenêtre temporelle, ce qui est généralement le signe que le changement sous-jacent est réel et non simplement une mode.
Ce qu'il faut en retenir si vous n'utilisez pas Salesforce
L'architecture de SLDS 2 est une réponse vaste et spécifique à une question que la plupart des équipes ne se sont pas encore posée : un acteur autre qu'un designer peut-il produire une interface respectant l'image de marque à partir de votre design system ? Quatre principes sont transposables, quelle que soit la plateforme.
- 1
Séparer la structure de l'apparence
Chaque décision visuelle qui est actuellement une valeur littérale dans la règle d'un composant est une décision qu'un générateur ne peut pas faire varier et qu'un client ne peut pas thématiser. Remontez-les dans des propriétés personnalisées nommées. C'est un refactoring ingrat mais dont le gain est immense, et c'est également le prérequis pour le mode sombre.
- 2
Nommer les hooks sémantiquement et utiliser les mêmes noms dans l'outil de design
radius-border-4dans Figma etradius-border-4en CSS. Un seul vocabulaire, deux rendus. Chaque décalage entre les noms de l'outil de design et les noms du code est une étape de traduction où le sens se perd. - 3
Imposer mécaniquement, et non éditorialement
Un linter qui signale une valeur hexadécimale brute dans une pull request fait plus pour la cohérence que n'importe quelle documentation. Si vous ne pouvez pas construire une base de données de règles, commencez par une règle unique interdisant les valeurs de couleur littérales en dehors du fichier de tokens.
- 4
Définir quelle est la surface no-code
Salesforce a fait une distinction explicite : les administrateurs thématisent via des clics, les développeurs via des hooks. Si votre système implique des parties prenantes non-développeurs qui doivent modifier des éléments, leur donner une surface délimitée est le seul moyen de leur éviter de demander des overrides ponctuels.
Il y a un cinquième point que SLDS 2 ne couvre pas, et c'est celui dont la plupart des équipes ont le plus besoin. Les hooks de style indiquent à un générateur ce qui peut varier. Ils ne lui indiquent pas quelles sont les bonnes valeurs, ce que signifie chaque rôle, ou ce qui est interdit.
Nous avons analysé 299 fichiers DESIGN.md écrits pour donner précisément ces directives aux agents IA. 86 % spécifiaient les couleurs en hexadécimal brut sans rôle sémantique, 76 % ne contenaient aucune interdiction, 69 % ne mentionnaient rien sur le mode sombre et 57 % ne définissaient aucun motif. Un générateur à qui l'on fournit un ensemble de hooks et un tel fichier se retrouve avec une API de thématisation vide et aucun argument sur ce qu'il doit y mettre.
Les kits de design d'Identity Forge sont cet argument, sous une forme qu'un agent peut exécuter : des rôles de couleurs sémantiques pour les modes clair et sombre, des échelles de typographie et d'espacement, des motifs, ainsi que des directives explicites sur ce qu'il faut faire ou ne pas faire, le tout sérialisé dans un DESIGN.md. Parcourez les kits ou découvrez ce qu'est un fichier DESIGN.md.
Notes pratiques sur la migration
Salesforce précise explicitement que le passage à SLDS 2 n'est pas obligatoire et que les organisations peuvent l'adopter à leur propre rythme. Le site SLDS 2 propose un guide de transition vers SLDS 2, et la documentation de SLDS 1 se trouve désormais sur v1.lightningdesignsystem.com plutôt que sur le domaine principal — une information utile si vous avez des favoris ou des liens dans votre documentation interne pointant vers les anciennes URL.
Si vous maintenez des composants web Lightning personnalisés, le linter est le point de départ logique, quel que soit le moment de votre migration : lancez-le, constatez quelle part de votre CSS affirme des choses que le framework s'apprête à ne plus affirmer, et utilisez ce chiffre pour évaluer honnêtement la charge de travail.
Quelle est la différence entre SLDS 1 et SLDS 2 ?
SLDS 1 est un framework CSS dans lequel les décisions visuelles de Salesforce sont intégrées aux règles. SLDS 2 le restructure autour de propriétés CSS personnalisées, de sorte que la structure demeure et que l'apparence est fournie via des hooks de style. C'est ce qui rend possibles la thématisation profonde et le mode sombre, et ce que Salesforce décrit comme le fondement des expériences agentiques.
Dois-je migrer vers SLDS 2 ?
Non. Salesforce précise que vous n'êtes pas tenu de changer et que vous pouvez adopter le système à votre propre rythme. Le site SLDS 2 publie un guide de transition vers SLDS 2, et la documentation de SLDS 1 reste disponible sur v1.lightningdesignsystem.com.
Que sont les hooks de style SLDS ?
Des propriétés CSS personnalisées exposées par le framework qui vous permettent de définir des valeurs telles que la couleur, le rayon et la typographie globalement, plutôt que de surcharger les sélecteurs composant par composant. Ils sont le mécanisme qui découple l'architecture de SLDS 2 de son style visuel par défaut.
SLDS 2 prend-il en charge le mode sombre ?
Salesforce décrit le chemin vers le mode sombre comme commençant par la transition vers SLDS 2 — l'architecture par propriétés personnalisées en est le prérequis. Consultez les notes de version actuelles pour savoir ce qui a été réellement déployé, car ce type de déclaration de roadmap est sujet à évolution.
Que signifie réellement « design system agentique » ici ?
Salesforce l'utilise pour des interfaces assemblées dynamiquement plutôt que conçues écran par écran, dans le cadre de sa plateforme Agentforce. Structurellement, cela signifie que le design system doit exposer ses décisions visuelles sous forme de valeurs nommées et configurables, car un générateur produisant une interface au moment de l'exécution a besoin d'éléments variables et d'éléments fixes.