Sa véritable utilité
L'atomic design proposait de concevoir les interfaces comme une hiérarchie : les atomes (un label, un champ de saisie, un bouton), les molécules (un formulaire de recherche), les organismes (un header de site), les templates (la mise en page au niveau de la page, sans contenu) et les pages (un template avec du contenu réel).
Il est important de rappeler le contexte. En 2013, la majeure partie du travail front-end était basée sur la page. Les designers livraient des maquettes de pages individuelles ; les développeurs construisaient des pages individuelles ; le même bouton existait sous onze formes légèrement différentes et personne ne savait nommer le problème. L'atomic design a donné aux équipes un vocabulaire commun et, plus important encore, l'argument selon lequel les interfaces devraient être composées à partir d'un système plutôt que dessinées page par page.
Cet argument a totalement gagné. Chaque framework basé sur des composants, chaque design system et chaque couche de design tokens actuellement utilisée le présuppose. Quand on dit que l'atomic design est mort, on veut généralement dire que sa conclusion est devenue la norme et sa terminologie optionnelle — ce qui est précisément la définition du succès pour une méthodologie.
La conclusion de l'atomic design est devenue la norme et sa terminologie est devenue optionnelle. C'est ainsi qu'une méthodologie gagne.
Les niveaux qui ont fait leurs preuves
Les cinq niveaux ne sont pas également utiles, et prétendre le contraire est une perte de temps pour les équipes. Classés selon le volume de débats générés par unité de valeur :
| Valeur | Coût | |
|---|---|---|
| Atomes | Élevée. Un bouton, un champ de saisie, un label — tout le monde est d'accord | Faible. La frontière est évidente |
| Molécules | Faible. La catégorie existe principalement pour se situer entre deux autres | Élevé. Chaque équipe s'écharpe dessus, en permanence |
| Organismes | Élevée. Un header, une carte, un tableau de données — des unités significatives | Moyen. La frontière avec la molécule est floue de ce côté aussi |
| Templates | Élevée. La mise en page sans contenu est une abstraction réellement utile | Faible, et désormais largement absorbée par les primitives de layout des frameworks |
| Pages | Élevé. Le contenu réel révèle les erreurs du template | Faible |
L'exemple de la ligne « molécule » n'est pas un détail. Demandez à cinq ingénieurs si une carte avec une image, un titre et un bouton est une molécule ou un organisme, et vous obtiendrez une conversation de quarante minutes sans aucune conséquence concrète. Tout niveau de taxonomie dont la frontière ne peut être définie rapidement et qui ne change pas la manière de construire est une surcharge.
Une simplification pratique vers laquelle la plupart des équipes convergent indépendamment : les primitives (blocs de construction non stylisés ou minimalement stylisés), les composants (ce que les ingénieurs produit importent réellement) et les layouts. Trois niveaux, des frontières décidables en cinq secondes, et la même discipline de composition.
Le compromis de la composition
Il existe une critique plus forte que « les labels sont fastidieux », et elle provient d'une équipe qui avait les ressources pour implémenter l'atomic design correctement et a choisi de ne pas le faire.
L'équipe design d'Airbnb a publié qu'au lieu de s'appuyer sur des atomes individuels, ils traitaient les composants comme des éléments d'un organisme vivant — chacun ayant une fonction et une personnalité, définies par un ensemble de propriétés, capables de coexister et d'évoluer ou de disparaître indépendamment. L'avantage déclaré était d'éviter un réseau complexe de parties interconnectées.
C'est un véritable arbitrage, pas une préférence :
| Composition atomique | Composant autonome | |
|---|---|---|
| Duplication | Minimale — c'est tout l'intérêt | Certaine, acceptée délibérément |
| Modifier un atome partagé | Se propage partout, y compris là où personne n'a vérifié | Modifie une seule chose |
| Multiplateforme | Difficile — l'arbre d'atomes doit être identique partout | Plus facile — seul le contrat doit correspondre |
| Mode de défaillance | Une modification casse silencieusement quatre surfaces | Deux composants divergent sans que personne ne s'en aperçoive |
Aucune des deux colonnes n'est correcte dans l'absolu. Un produit web mono-plateforme avec une seule base de code tire une valeur réelle d'une réutilisation maximale et peut absorber le risque de propagation. Un système s'étendant sur quatre plateformes ne le peut pas, car l'arbre d'atomes doit être reproduit à l'identique dans chacune d'elles, ce qui n'arrive jamais. Airbnb avait quatre plateformes.
Component specimen · Button
Folio Index
Live renderThe button primitive in Folio Index, across 4 states.
Default
Hover
Focus
Disabled
Ce qui change quand un agent assemble l'interface
Voici la partie véritablement nouvelle, et elle s'attaque à un angle inattendu.
La contribution principale de l'atomic design a été d'apporter un vocabulaire partagé. Cela permettait à un designer, un ingénieur et un product manager de désigner la même chose avec le même mot. Un agent de code n'en a pas besoin. Il sait déjà ce qu'est un bouton, une carte, une barre de navigation et un tableau de données, avec une précision extrême, et ce pour tous les frameworks que vous pourriez utiliser. Le problème de nommage résolu par l'atomic design n'est pas un problème que rencontre un agent.
Ce qui manque à un agent se situe tout autre part :
| L'atomic design vous apporte | L'agent a réellement besoin de | |
|---|---|---|
| Vocabulaire | Des noms pour les niveaux de composition | Les possède déjà. Dans tous les frameworks |
| Structure | Une hiérarchie de parties | Utile, et il en déduit la majeure partie de toute façon |
| Contraintes | Rien | C'est là que se situe la lacune. Qu'est-ce qui est interdit ? |
| Intention | Rien | À quoi sert ce design ? Qui le lit ? |
| Valeurs | Rien — les atomes sont une catégorie, pas une spécification | L'échelle réelle, les rôles réels, les chiffres réels |
Les trois dernières lignes sont vides à gauche, et ce n'est pas une critique de la méthodologie — elle n'a jamais cherché à les remplir. C'est simplement une raison de ne pas s'attendre à ce qu'elle aide à résoudre le problème actuel.
Nous avons analysé 299 fichiers DESIGN.md rédigés pour guider les agents de code, et ce vide s'y retrouve également. 76 % ne contiennent aucune interdiction. 86 % spécifient les couleurs sous forme de codes hexadécimaux bruts sans rôle sémantique. 57 % ne définissent aucun motif distinctif. 44 % ne contiennent aucune valeur de taille concrète, et 54 % s'appuient sur au moins un adjectif vague — « clean » dans 39 % des cas, « moderne » dans 36 %.
Un fichier impeccablement organisé par atomes, molécules et organismes, mais dépourvu de ces éléments, produira une interface générique bien structurée. La taxonomie n'a jamais été la contrainte déterminante.
Le piège classique : les équipes considèrent le fait d'avoir une hiérarchie de composants comme la preuve que le design system est prêt pour les agents. C'est la preuve d'une bonne structure de code. Demandez-vous plutôt si un agent lisant votre système pourrait identifier ce qui est interdit ; vous constaterez généralement que rien ne l'est.
Ce qui le remplace
Pas une nouvelle taxonomie. La stratégie utile consiste à conserver la discipline compositionnelle — que tout le monde possède déjà — et à ajouter les couches que l'atomic design n'a jamais couvertes.
- 1
Gardez la hiérarchie, abandonnez le débat
Primitives, composants, layouts. Trois niveaux, décision instantanée. Si votre équipe s'accorde déjà sur les atomes/molécules/organismes et que cela ne coûte rien, gardez-les — le problème ne vient pas des labels, mais des débats qu'ils suscitent.
- 2
Définissez les composants par contrat, pas par composition
Listez les éléments requis, les éléments optionnels et les propriétés. « Une carte nécessite un titre et un texte de support, et optionnellement une image, un badge et une action de pied de page. » Cette déclaration survit à toute implémentation, y compris celle écrite par un agent dans un framework que vous n'aviez pas anticipé.
- 3
Ajoutez la couche de contraintes
La liste des choses à ne jamais faire. Pas de dégradés, pas d'élévation d'ombre, pas de graisse de police supérieure à 600, pas de couleur en dehors du jeu de tokens. C'est la couche qui influence le plus le résultat généré, et celle qui manque à la plupart des systèmes.
- 4
Ajoutez la couche d'intention
L'objectif du design et son public. Un outil dense pour des utilisateurs intensifs et une page marketing parcourue en quarante secondes nécessitent des décisions opposées, et aucune hiérarchie de composants ne permet de coder laquelle des deux vous visez.
La deuxième étape mérite d'être approfondie, car c'est celle qui se transpose le mieux au code écrit par un agent. Un contrat peut être satisfait par n'importe quelle implémentation ; un arbre de composition ne peut être satisfait qu'en reproduisant l'arbre. Lorsque l'implémenteur est un modèle susceptible d'adopter une structure différente de la vôtre, le contrat tient, alors que l'arbre échoue.
## Card
Required: title, supporting text
Optional: image, badge, footer action
Contains its own bottom divider; hidden when last in a list.
Padding 16px. Radius 12px. Border 1px --border-subtle.
Never uses a drop shadow — elevation is a surface step.
Never uses the accent colour for its border or background.Neuf lignes, et chacune d'elles est vérifiable. Notez la part importante d'interdictions. Ce ratio fait la différence entre une spécification et une description.
Les kits de design d'Identity Forge sont conçus comme ce type de contrat — rôles de couleurs sémantiques pour les modes clair et sombre, échelles de typographie et d'espacement, motifs, et consignes explicites (do's and don'ts) — sérialisés dans un DESIGN.md que l'agent lit avant d'écrire quoi que ce soit. Parcourez les kits ou commencez par ce qu'est un fichier DESIGN.md.
L'atomic design est-il donc mort ?
Non, et ce questionnement n'est pas productif. L'atomic design a soutenu que les interfaces sont des systèmes composés. Cet argument est aujourd'hui si largement accepté qu'il est devenu invisible — il est intégré à React, à chaque outil de design, à chaque design system publié depuis. Vous ne pouvez pas l'écarter, car vous évoluez déjà à l'intérieur.
Ce qui est obsolète, c'est l'idée que la taxonomie soit le livrable. Un système organisé en cinq niveaux nommés, mais sans contraintes, sans rôles et sans déclaration d'intention, n'est qu'un plan de classement. Il produira des interfaces cohérentes, bien structurées et entièrement interchangeables, ce qui n'a jamais été l'objectif.
Le travail restant est celui que l'atomic design a délibérément laissé de côté : décider à quoi sert votre design, ce qu'il refuse de faire, et consigner tout cela là où l'outil qui construit votre interface pourra réellement le lire.
L'atomic design est-il toujours pertinent ?
Son idée centrale est désormais l'hypothèse par défaut de tout framework de composants et de tout design system, donc oui, dans le sens où vous l'utilisez déjà. Sa taxonomie en cinq niveaux est optionnelle, et beaucoup d'équipes tirent plus de valeur d'une division plus simple en primitives/composants/layouts qui élimine les débats de frontière.
Quelle est la différence entre une molécule et un organisme ?
Conventionnellement, une molécule est un petit groupe d'atomes fonctionnant comme une unité (un label plus un champ de saisie plus un bouton) et un organisme est une section plus large et plus autonome (un en-tête de site, une grille de cartes produits). En pratique, la frontière n'est pas déterminable d'une manière qui modifierait la façon de construire, c'est pourquoi les équipes en débattent et pourquoi beaucoup abandonnent cette distinction.
Dois-je utiliser l'atomic design avec des agents de code IA ?
Cela n'aide ni ne nuit vraiment. Un agent sait déjà ce qu'est un bouton ou un en-tête, l'avantage d'un vocabulaire partagé ne s'applique donc pas. Ce qui influence réellement le résultat d'un agent, c'est la couche que l'atomic design n'a jamais couverte : les rôles sémantiques des couleurs, des valeurs numériques réelles pour les échelles et une liste explicite des interdictions.
Pourquoi Airbnb a-t-il rejeté l'atomic design ?
Leur raisonnement publié était que la composition de composants à partir d'atomes partagés crée un réseau complexe de parties interconnectées. Le fait de traiter chaque composant comme une unité autonome, avec des éléments requis et optionnels définis, permet aux composants d'évoluer indépendamment. Cela était d'autant plus crucial que le système devait exister simultanément en Swift, Kotlin et en code web.
Que doit contenir un design system s'il ne contient pas de taxonomie ?
Des contrats de composants (éléments requis, éléments optionnels, propriétés), des rôles sémantiques de couleurs plutôt que des valeurs brutes, des échelles de typographie et d'espacement avec des valeurs numériques réelles, un mode sombre défini, des motifs précisant les intentions du design et une liste d'interdictions explicite. La hiérarchie peut être conservée, mais elle n'est plus l'élément moteur.