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és le présupposent. 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 faire le lien 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 porteuses de sens | 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 |
La ligne « molécule » n'est pas un détail de puriste. Demandez à cinq ingénieurs si une carte avec une image, un titre et un bouton est une molécule ou un organisme, et vous aurez une conversation de quarante minutes sans aucune conséquence concrète. Tout niveau de taxonomie dont la limite ne peut être décidée rapidement et qui ne modifie pas ce que les développeurs construisent est une surcharge.
Une simplification pratique vers laquelle la plupart des équipes convergent de manière indépendante : 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 limites décidables en cinq secondes, et la même discipline de composition.
Le compromis de composition
Il existe une critique plus forte que « les labels sont trop pointilleux », et elle vient d'une équipe qui avait les ressources pour implémenter l'atomic design correctement et qui 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 les éléments d'un organisme vivant : chacun avec une fonction et une personnalité, définis par un ensemble de propriétés, capables de coexister et d'évoluer ou de disparaître indépendamment. Leur objectif affiché était d'éviter un réseau complexe de pièces 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 exister de manière identique partout | Plus facile, seul le contrat doit correspondre |
| Mode de défaillance | Un changement casse silencieusement quatre surfaces | Deux composants s'écartent sans que cela soit remarqué |
Aucune des deux colonnes n'est correcte de manière générale. Un produit web monoplateforme avec une base de code unique tire une réelle valeur 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 chacun d'eux, ce qui n'arrivera pas. Airbnb disposait de quatre plateformes.
Component specimen · Button
Folio Index
Live renderThe button primitive in Folio Index, across 4 states.
Default
Hover
Focus
Disabled
Ce qui change lorsqu'un agent assemble l'interface
Voici la partie qui est véritablement nouvelle, et elle tranche dans une direction inattendue.
La principale contribution de l'atomic design a été un vocabulaire partagé. Il permettait à un designer, un ingénieur et un product manager de désigner la même chose et de vouloir dire la même chose. 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 un niveau de détail énorme, dans chaque framework que vous pourriez utiliser. Le problème de nommage résolu par l'atomic design n'est pas un problème pour un agent.
Ce qui manque à un agent se trouve ailleurs :
| L'atomic design vous apporte | Ce dont l'agent a réellement besoin | |
|---|---|---|
| Vocabulaire | Des noms pour les niveaux de composition | Il les possède déjà. Dans chaque framework |
| Structure | Une hiérarchie de composants | 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 hex 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 de composition, 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, oubliez 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 discussions sans fin.
- 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 set de design 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 savoir laquelle appliquer.
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 de ce qu'il faut faire ou ne pas faire) 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 cette formulation n'est pas utile. L'atomic design a soutenu que les interfaces sont des systèmes composés. Cet argument est désormais si largement accepté qu'il est devenu invisible. Il est intégré dans React, dans chaque outil de design, dans 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 est 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 header 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 s'écharpent à ce sujet 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, un mode sombre défini, des motifs précisant les intentions du design et une liste d'interdictions explicites. La hiérarchie peut être conservée, mais elle n'est plus l'élément moteur.