Ce qu'est réellement Carbon
IBM décrit Carbon comme son design system open source pour ses produits et ses expériences numériques, avec l'IBM Design Language comme fondation, comprenant du code fonctionnel, des outils et ressources de design, des directives d'interface humaine et une communauté de contributeurs. Il est financé et conçu par IBM pour les besoins métier d'IBM, et publié ouvertement pour que chacun puisse l'utiliser et y contribuer.
Ce modèle de financement mérite que l'on s'y attarde, car il détermine ce que vous adoptez réellement. Carbon n'est pas un projet communautaire qui se trouve avoir des utilisateurs en entreprise ; c'est un système d'entreprise qui se trouve être open source. Les décisions de la roadmap servent les produits d'IBM. En pratique, c'est principalement un avantage — cela signifie que le système est véritablement maintenu plutôt que d'être abandonné lorsqu'un mainteneur change d'emploi — mais cela signifie aussi qu'une fonctionnalité dont votre produit a besoin, mais pas ceux d'IBM, est peu susceptible d'apparaître.
Le nom est une métaphore que l'équipe assume directement : le carbone dans la nature construit des structures complexes à partir de composés plus simples, reflétant la manière dont les styles et les composants individuels se combinent. Une information utile car elle 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 digne d'intérêt est qu'il ne s'agit pas d'un système unique. IBM publie une pile technologique, et la séparation entre les niveaux est explicite dans la navigation du site lui-même.
| Ce qu'elles contiennent | Qui les fait évoluer | |
|---|---|---|
| IBM Design Language | Fondation de la marque : le langage visuel et expressif pour l'ensemble d'IBM | La marque IBM, rarement, et jamais pour la commodité d'un produit |
| Carbon Design System | Tokens, composants, patterns, directives d'interface humaine, code | L'équipe Carbon plus les contributeurs open source |
| Systèmes de domaine | Carbon for IBM Products, Carbon for Cloud, Carbon for IBM.com — des composants spécifiques à un contexte donné | L'équipe de ce domaine, sans toucher au cœur |
C'est la même structure que celle adoptée par Spotify avec Encore, atteinte par une approche différente, et elle résout le même problème : où va un composant lorsqu'un seul produit en a besoin? Sans couche de domaine, la réponse est soit « dans le cœur, ce qui alourdit le système pour tout le monde », soit « en dehors du système, où il finit par s'égarer ». Avec une couche de domaine, le travail spécialisé dispose d'un foyer qui ne peut pas fuir dans le reste du système.
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 distincts. 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 être promu dans la fondation par simple facilité.
Le support des frameworks n'est pas uniforme, et la doc le précise
Carbon prend en charge plusieurs implémentations de code, et la documentation répertorie chacune d'elles avec son mainteneur. Cette liste est l'élément le plus important en pratique sur le site si vous évaluez l'adoption :
| 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 et applications d'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 quel problème 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 écarts et les retouches. 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 (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 parcourant les trois principaux design systems d'entreprise publiés en open source, on remarque que cette même stratégie est apparue trois fois en dix-huit mois, exécutée de manières différentes :
| La stratégie | 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, couplée à un linter qui valide le markup par rapport aux règles | Le système doit être suffisamment personnalisable pour une UI générée, et les violations doivent être détectées mécaniquement |
| Shopify Polaris | React déprécié au profit de web components agnostiques vis-à-vis du framework et servis via un CDN | Le format de diffusion ne doit pas présumer du framework ayant généré la page |
Trois paris différents, une prémisse commune : le consommateur d'un design system n'est plus seulement un développeur humain lisant de la documentation. Cette prémisse n'est plus controversée, mais le fait que les trois acteurs y aient répondu en un an et demi est un phénomène que la littérature sur les design systems n'a pas encore pleinement intégré.
MCP et DESIGN.md répondent à deux besoins distincts
Il est tentant de voir dans le MCP de Carbon une obsolescence de l'aide au design basée 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 dépôt | |
|---|---|---|
| Réponses | Comment utiliser ce composant correctement? | À quoi ce produit devrait-il ressembler? |
| Source de vérité | Les mainteneurs de la bibliothèque | Vous |
| Chargé | À la demande, lorsque l'agent le demande | À chaque session, comme contexte |
| Couvre | Surface d'API, props, accessibilité, exemples | Rôles, échelle, interdictions, motifs, ce qu'il ne faut pas faire |
| 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 doté du MCP de Carbon mais sans guide de design produit des composants Carbon techniquement corrects, agencés dans une interface sans identité visuelle. Un agent doté d'un guide de design robuste mais sans MCP produit une mise en page cohérente appelant des props renommées en v11. Vous avez besoin des deux, et ils ne se chevauchent pas.
Nous avons échantillonné 299 fichiers DESIGN.md publiés pour être lus par des agents, et les chiffres montrent quelle moitié est actuellement négligée : 86 % spécifient les couleurs sous forme de hex brut sans rôle sémantique, 76 % ne mentionnent aucune interdiction, 57 % ne définissent aucun motif distinctif et 69 % ne disent rien sur le mode sombre. Cela correspond à la deuxième colonne — les questions auxquelles un serveur MCP ne répondra jamais.
Les design kits d'Identity Forge comblent cette lacune : rôles de couleurs sémantiques pour les modes clair et sombre, une échelle de typographie et d'espacement, des motifs, ainsi qu'une liste explicite de ce qu'il faut faire et ne pas faire, sérialisée dans un DESIGN.md qui accompagne n'importe quelle bibliothèque de composants que vous utilisez. Parcourir les kits, ou lire ce qu'est un fichier DESIGN.md.
Devriez-vous adopter Carbon?
Carbon est un excellent système, mais l'adopter est souvent une erreur. Le facteur décisif est de savoir si vous souhaitez qu'une opinion de design vous soit fournie.
| Adopter Carbon | Ne pas adopter | |
|---|---|---|
| Type de produit | Outils internes, administration d'entreprise, applications à forte densité de données | Tout produit dont la différenciation visuelle fait partie de la valeur |
| Avantages | 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'indicateur | "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. Des efforts considérables ont été investis dans l'accessibilité des composants de Carbon pendant des années, avec le soutien des pratiques d'accessibilité 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 inverse 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 à combattre ces choix qu'à définir votre propre système.
Ce qu'il faut en retenir, 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 rythmes de mise à jour différents. 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 appartient à une couche supérieure au cœur du système, et non à l'intérieur ou en dehors de celui-ci.
- 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.
- 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 pour votre système. La seule question est de savoir s'il s'appuiera 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 de tous pour être utilisé et enrichi. 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 de s'engager.
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 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 basé sur leurs 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 ?
En partie. 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 davantage que leurs capacités techniques.