Ce qu'est réellement Carbon
IBM décrit Carbon comme son design system open source pour les produits et les expériences numériques, fondé sur l'IBM Design Language. Il se compose de code opérationnel, d'outils et de ressources de design, de guides d'interface humaine et d'une communauté de contributeurs. Il est financé et construit par IBM pour répondre aux besoins business d'IBM, et publié ouvertement pour que quiconque puisse l'utiliser et y contribuer.
Ce modèle de financement mérite réflexion, car il détermine ce que vous adoptez. Carbon n'est pas un projet communautaire qui aurait par hasard des utilisateurs corporate ; c'est un système corporate qui se trouve être ouvert. Les décisions de roadmap servent les produits IBM. En pratique, c'est globalement positif (cela signifie que le système est réellement maintenu plutôt qu'abandonné lorsqu'un mainteneur change de poste), mais cela signifie aussi qu'une fonctionnalité nécessaire à votre produit, mais pas à ceux d'IBM, a peu de chances d'arriver.
Le nom est une métaphore explicitement citée par l'équipe : dans la nature, le carbone construit des structures complexes à partir de composés plus simples, reflétant la manière dont les styles et composants individuels se combinent. C'est un point essentiel car cela explique la préférence du système pour la composition plutôt que pour la prescription.
Les trois couches
La décision structurelle qui rend Carbon intéressant à étudier est qu'il ne s'agit pas d'un seul système. IBM publie une pile, et la séparation entre les niveaux est explicite dans la navigation même du site.
| Contenu | Responsable des modifications | |
|---|---|---|
| IBM Design Language | Fondation de marque : le langage visuel et expressif commun à tout IBM | La marque IBM, rarement, et jamais pour le confort d'un produit |
| Carbon Design System | Tokens, composants, patterns, guides d'interface humaine, code | L'équipe Carbon et les contributeurs open source |
| Systèmes de domaine | Carbon for IBM Products, Carbon for Cloud, Carbon for IBM.com : composants spécifiques à un contexte | L'équipe du domaine concerné, sans toucher au cœur |
C'est la même structure que celle adoptée par Spotify avec Encore, atteinte par un chemin différent, et elle résout le même problème : où placer un composant quand un seul produit en a besoin ? Sans couche domaine, la réponse est soit « dans le cœur, ce qui l'alourdit pour tout le monde », soit « hors du système, où il finit par diverger ». Avec une couche domaine, le travail spécialisé a un foyer sans polluer le reste.
Si vous construisez un système pour plus d'un produit, c'est l'élément le plus transférable de Carbon. Vous n'avez pas besoin de trois sites publiés. Vous avez besoin d'une règle définissant à lequel de vos trois niveaux appartient une décision donnée, et de la discipline nécessaire pour ne pas laisser un besoin spécifique à un produit remonter dans la fondation par simple facilité.
Le support des frameworks n'est pas uniforme, et la documentation le précise
Carbon supporte plusieurs implémentations de code, et la documentation liste chacune d'elles avec son mainteneur. Cette liste est l'élément le plus crucial du site si vous évaluez l'adoption du système :
| Mainteneur | Ce que cela signifie pour vous | |
|---|---|---|
| Éléments | Équipe Carbon | First-party. Tokens, typographie, couleurs, icônes, grille |
| React | Équipe Carbon | First-party et la plus complète. Le choix par défaut |
| Web Components | Équipe Carbon | First-party. Agnostique vis-à-vis du framework, viable si vous n'utilisez pas React |
| Angular | Communauté | Évaluez la cadence des versions et la réactivité face aux bugs avant de vous engager |
| Vue | Communauté | Même mise en garde |
| Svelte | Communauté | Même mise en garde |
La mention « maintenu par la communauté » n'est pas une critique, mais c'est un risque que vous assumez plutôt qu'IBM. Avant d'adopter une implémentation communautaire, vérifiez la date de la dernière version, son retard par rapport au cœur du système et la rapidité de réponse aux tickets. Un design system qui accuse un retard de deux versions majeures représente une migration que vous n'avez pas budgétisée.
Cette honnêteté mérite d'être soulignée comme une bonne pratique de documentation en soi. De nombreux design systems listent des packages de frameworks sans préciser qui en est responsable, laissant les utilisateurs découvrir la différence lors d'un incident.
Carbon MCP : la partie dont personne n'a parlé
Carbon MCP est disponible en préversion publique. Il s'agit d'un serveur Model Context Protocol qui donne aux agents IA et aux applications IA un accès direct à la base de connaissances de Carbon : éléments de base, iconographie, pictogrammes, directives, documentation d'utilisation et bibliothèques de composants pour React et Web Components, ainsi que la bibliothèque Carbon for IBM Products.
Les outils documentés sont précis, et leur lecture indique exactement le problème qu'IBM cherche à résoudre :
| Ce qu'il recherche | |
|---|---|
docs_search | Documentation de Carbon et d'IBM Products : guides des composants, utilisation, accessibilité, référence |
code_search | Exemples de code Carbon React et Web Components, icônes et pictogrammes, sous forme de fichiers d'application d'exemple complets |
get_charts | Exemples de Carbon Charts pour React, Angular, Vue, Svelte, JS vanilla et HTML |
labs_search | Composants expérimentaux de Carbon Labs : AnimatedHeader, Processing, Resizer, WhatsNew, Labs UIShell |
Les raisons invoquées par IBM sont l'accès instantané de l'IA aux standards de Carbon, une génération de code plus fidèle grâce à des exemples réels et une meilleure cohérence via une source de vérité partagée qui réduit les dérives et les refontes. L'accès pendant la préversion est immédiat pour les employés d'IBM ; les autres doivent en faire la demande via un formulaire d'accès anticipé.
L'importance ne réside pas dans le fait qu'IBM ait créé une intégration. C'est ce que l'existence même du serveur admet : les données d'entraînement d'un modèle ne sont pas une source fiable pour l'API actuelle d'un design system, et lui demander d'écrire du code Carbon de mémoire produit des composants plausibles mais erronés. Le serveur existe parce que la récupération d'informations (retrieval) l'emporte sur le rappel (recall).
Le serveur existe parce que la mémoire d'un modèle concernant l'API de vos composants est assurément obsolète, et qu'un nom de prop erroné ressemble exactement à un nom correct.
Carbon n'est pas seul dans ce cas
En analysant les trois grands design systems d'entreprise publiés en open source, on constate que la même stratégie a été adoptée trois fois en dix-huit mois, bien que mise en œuvre différemment :
| L'initiative | Le pari | |
|---|---|---|
| IBM Carbon | Un serveur MCP exposant la documentation et des exemples de code | Les agents doivent récupérer le système au moment de la génération |
| Salesforce Lightning (SLDS 2) | Une architecture CSS découplée du style visuel, accompagnée d'un linter qui valide le balisage selon des règles précises | Le système doit être suffisamment thémisable pour l'UI générée, et les violations doivent être détectées mécaniquement |
| Shopify Polaris | React abandonné au profit de web components agnostiques vis-à-vis du framework, servis via un CDN | Le format de livraison ne doit pas présumer du framework ayant généré la page |
Trois paris différents, un postulat commun : le consommateur d'un design system n'est plus seulement un développeur humain lisant de la documentation. Ce postulat n'est plus controversé, mais le fait que ces trois acteurs aient réagi en un an et demi est un point que la littérature sur les design systems n'a pas encore pleinement intégré.
MCP et DESIGN.md résolvent deux problématiques distinctes
On pourrait être tenté de penser que Carbon MCP rend obsolètes les guides de design basés sur des fichiers. Ce n'est pas le cas, car les deux répondent à des questions différentes.
| Un serveur MCP | Un fichier DESIGN.md dans le repo | |
|---|---|---|
| Réponses | Comment utiliser ce composant correctement ? | À quoi ce produit doit-il ressembler ? |
| Source de vérité | Les mainteneurs de la bibliothèque | Vous |
| Chargement | À la demande, lorsque l'agent le sollicite | À chaque session, en tant que contexte |
| Couvre | Surface API, props, accessibilité, exemples | Rôles, échelles, interdictions, motifs, erreurs à éviter |
| Sans cela | L'agent invente des props qui n'existent pas | L'agent invente un design qui n'est pas le vôtre |
Un agent équipé de Carbon MCP mais sans guide de design produit des composants Carbon techniquement corrects, organisés dans une interface sans aucune direction artistique. Un agent avec un guide de design solide mais sans MCP produit une mise en page pertinente, mais appelle des props renommées dans la v11. Vous avez besoin des deux, et ils sont complémentaires.
Nous avons analysé 299 fichiers DESIGN.md publiés pour les agents, et les chiffres montrent quelle partie est actuellement négligée : 86 % spécifient les couleurs en hexadécimal brut sans rôle sémantique, 76 % n'énoncent aucune interdiction, 57 % ne définissent aucun motif distinctif et 69 % ne mentionnent rien sur le mode sombre. Tout cela relève de la seconde colonne : les questions auxquelles un serveur MCP n'a jamais été destiné à répondre.
Les kits de design d'Identity Forge comblent ce manque : rôles sémantiques des couleurs pour les modes clair et sombre, échelles de typographie et d'espacement, motifs et liste explicite de recommandations (do's and don'ts), le tout sérialisé dans un fichier DESIGN.md placé aux côtés de la bibliothèque de composants que vous utilisez. Parcourez les kits ou découvrez ce qu'est un fichier DESIGN.md.
Devriez-vous adopter Carbon ?
Carbon est un excellent système, et pourtant, l'adopter est souvent une erreur. Le facteur déterminant est de savoir si vous souhaitez qu'une opinion design vous soit imposée.
| Adopter Carbon | Ne pas adopter | |
|---|---|---|
| Type de produit | Outils internes, administration d'entreprise, applications à forte densité de données | Tout produit où la différenciation visuelle fait partie de la valeur ajoutée |
| Ce que vous gagnez | Accessibilité déjà traitée, vaste ensemble de composants, maintenance réelle | Une interface qui ressemble à celle d'IBM, car elle l'est |
| Composition de l'équipe | Aucune ressource design dédiée, les ingénieurs prennent les décisions d'UI | Un designer avec une vision forte qui passera six mois à tout modifier |
| L'indice révélateur | "Nous avons besoin que ce soit utilisable et cohérent, et rapidement" | "Nous avons besoin que cela nous ressemble" |
L'argument de l'accessibilité mérite toute son attention. Les composants de Carbon ont bénéficié d'un investissement massif en matière d'accessibilité pendant des années, soutenu par l'expertise d'IBM. Reproduire cela dans votre propre bibliothèque de composants est un engagement sur plusieurs années que la plupart des équipes entament avant d'abandonner. Si votre produit est un outil interne, adopter Carbon est presque une victoire gratuite.
L'argument opposé est qu'un design system véhicule une identité, et celle de Carbon est celle d'IBM. Le fait d'être personnalisable ne signifie pas être neutre : la densité, le langage des formes, le traitement typographique et les idiomes d'interaction encodent tous des décisions prises pour les produits IBM. Si votre produit mise en partie sur son ressenti, vous dépenserez plus d'énergie à lutter contre ces choix qu'à définir votre propre système.
Ce qu'il faut s'inspirer, même sans l'installer
- Séparez le langage de marque de l'implémentation. L'IBM Design Language et Carbon sont des documents différents, avec des responsables et des cycles de mise à jour distincts. Les fusionner signifie que chaque ajustement de composant devient une discussion sur l'image de marque.
- Attribuez une couche de domaine au travail spécifique. Un composant dont un seul produit a besoin doit se situer au-dessus du cœur du système, et non à l'intérieur ou en dehors du système.
- Publiez l'identité du mainteneur de chaque implémentation. Les utilisateurs prennent une décision basée sur le risque. Permettez-leur de le faire avec des faits concrets.
- Exposez délibérément le système aux agents. Qu'il s'agisse de MCP, d'un export de tokens lisible par machine ou d'un fichier bien structuré dans le dépôt, l'agent finira par écrire du code basé sur votre système. La seule question est de savoir s'il s'appuie sur votre documentation ou sur ses données d'entraînement.
Le Carbon Design System est-il gratuit ?
Oui. Carbon est open source, financé et construit par IBM, mais mis à disposition pour que tout le monde puisse l'utiliser et y contribuer. Vérifiez la licence dans le dépôt pour connaître les conditions actuelles avant tout déploiement commercial, car la licence s'applique par package et non à l'ensemble du projet.
Quelle implémentation de framework Carbon dois-je utiliser ?
React si possible. C'est la version la plus complète et elle est maintenue par l'équipe Carbon. Web Components si vous n'utilisez pas React et souhaitez une maintenance native. Angular, Vue et Svelte sont maintenus par la communauté, ce qui est viable, mais nécessite de vérifier la cadence des versions et la réactivité face aux bugs avant d'y engager un produit.
Qu'est-ce que Carbon MCP et en ai-je besoin ?
Il s'agit d'un serveur Model Context Protocol, actuellement en préversion publique, qui permet aux agents d'IA d'interroger directement la documentation de Carbon, les exemples de code des composants, les graphiques et les composants expérimentaux de Labs. Vous en avez besoin si des agents écrivent du code Carbon dans votre dépôt ; sans cela, ils génèrent du code à partir de données d'entraînement, lesquelles sont souvent obsolètes concernant les noms de props et les imports.
Puis-je faire en sorte que Carbon ne ressemble pas à IBM ?
Partiellement. Les tokens vous permettent de modifier les couleurs, la typographie et certaines propriétés de forme. Ce que vous ne pouvez pas facilement changer, c'est la densité, les idiomes d'interaction et la composition des composants, là où réside une grande partie de l'identité perçue. Si le fait que "cela doit nous ressembler" est une exigence réelle, prévoyez l'effort nécessaire avant l'adoption.
Comment Carbon se compare-t-il à Polaris et Lightning ?
Tous trois sont de vastes systèmes d'entreprise publiés ouvertement et conçus pour un produit parent spécifique. Carbon est le plus pluraliste en termes de frameworks et le seul à proposer un serveur MCP. Polaris a abandonné sa bibliothèque React au profit de web components agnostiques. SLDS 2 a reconstruit son architecture CSS autour de propriétés personnalisées pour découpler la structure du style visuel. Leurs philosophies de design divergent plus que leurs capacités techniques.