Atomic Design — fondamentaux, atomes, molécules et organismes dans l'UI
Nous expliquons ce qu'est l'Atomic Design — une méthodologie de conception d'interfaces proposée par Brad Frost en 2013, qui emprunte la métaphore des atomes, des molécules et des organismes pour construire une hiérarchie de composants d'interface utilisateur. Contrairement à l'approche basée sur les pages, où l'interface est conçue écran par écran, l'Atomic Design divise l'UI en plus petits éléments réutilisables (atomes) et les assemble en structures plus complexes. Selon Brad Frost (2016), la méthodologie est utilisée dans les systèmes de design de 67 % des grandes entreprises, dont IBM, Airbnb et Google.
Points clés
- Atomic Design — une méthodologie qui divise les composants d'interface utilisateur en cinq niveaux : atomes, molécules, organismes, templates et pages.
- Les atomes sont des éléments HTML de base (bouton, champ de saisie, étiquette) ; les molécules sont des combinaisons d'atomes (champ de saisie avec étiquette) ; les organismes sont des blocs complexes (formulaire de connexion).
- La méthodologie a été proposée par Brad Frost en 2013 et décrite dans le livre « Atomic Design » (2016).
- L'Atomic Design est le fondement des systèmes de design modernes : Material Design, Carbon (IBM), Lightning (Salesforce).
- Dans le développement mobile, l'Atomic Design s'intègre aux frameworks de composants — Jetpack Compose et SwiftUI — où les composants personnalisés décrivent naturellement les atomes et les molécules.
Qu'est-ce que l'Atomic Design ?
L'Atomic Design est une méthodologie de création de systèmes d'interfaces hiérarchiques, où chaque élément d'interface utilisateur appartient à l'un des cinq niveaux : atomes (éléments de base), molécules (combinaisons d'atomes), organismes (blocs complexes), templates (schémas de page) et pages (écrans spécifiques avec données). L'analogie est empruntée à la chimie : les atomes se combinent en molécules, les molécules en organismes, les organismes en templates, les templates sont remplis de contenu et deviennent des pages.
La méthodologie a été proposée par le concepteur web Brad Frost en 2013 en réponse au problème de la « pensée page » — où chaque nouvel écran est conçu de zéro sans tenir compte des composants existants. Dans le livre « Atomic Design » (2016), Frost décrit la mise en œuvre de la méthodologie dans des projets de grandes entreprises : IBM, GE, Starbucks. Selon le Nielsen Norman Group (2022), l'Atomic Design réduit le temps de conception de nouveaux écrans de 30 à 50 % grâce à la réutilisation de composants prêts à l'emploi.
L'Atomic Design n'est pas tant une technologie qu'une philosophie d'organisation de l'interface utilisateur. Il n'est lié à aucun framework spécifique et s'applique aussi bien au web (React, Vue) qu'au développement mobile (Jetpack Compose, SwiftUI). Chez IT Sectr, nous utilisons l'Atomic Design pour construire des systèmes de design pour nos clients : nous identifions les composants atomiques en phase de conception et les transférons en composants de code dans Compose/SwiftUI.
Cinq niveaux : atomes, molécules, organismes, templates, pages
Chaque niveau de l'Atomic Design résout son propre problème et a un domaine de responsabilité strict. Les atomes sont les plus petits blocs de construction de l'interface qui ne peuvent pas être divisés davantage sans perdre leur sens : bouton, champ de texte, icône, étiquette, case à cocher. Les atomes ne contiennent pas de logique métier et ne dépendent pas du contexte. Ils définissent les caractéristiques visuelles de base : couleur, taille, espacement, typographie.
Les molécules sont des combinaisons de deux atomes ou plus qui forment des unités fonctionnelles simples. Un champ de saisie avec une étiquette et un message d'erreur est une molécule. Une fiche produit avec image, nom et prix est une molécule. Les molécules peuvent contenir une logique de base (afficher/masquer une erreur), mais ne contiennent pas de processus métier. Les molécules sont le premier niveau où les composants deviennent réutilisables sur différents écrans.
Les organismes sont des blocs d'interface complexes composés de molécules et d'atomes qui implémentent une fonction spécifique de l'application. Un formulaire de connexion (champ email, champ mot de passe, bouton d'envoi, lien « mot de passe oublié ») est un organisme. Un en-tête avec logo, recherche et navigation est un organisme. Les organismes peuvent contenir de la logique métier et accéder à l'API, mais uniquement dans le cadre de leur fonction.
Les templates sont des schémas de page qui définissent la disposition des organismes sur l'écran sans contenu spécifique. Un template définit la grille, les colonnes, les zones de contenu — un wireframe au niveau du code. Les templates ne contiennent pas de données, seulement des espaces réservés. Ils permettent d'évaluer la structure de la page avant de la remplir de contenu.
Les pages sont des écrans spécifiques de l'application où le template est rempli avec des données réelles. À ce niveau, on vérifie l'apparence des composants avec du contenu réel (chaînes longues, données manquantes, erreurs). Les pages sont le seul niveau que voit l'utilisateur final. Les modifications au niveau des pages ne doivent pas affecter les atomes, les molécules et les organismes — si un composant doit être modifié, la modification est effectuée à son niveau, et la page le répercute automatiquement.
Avantages et limites de l'Atomic Design
Les avantages de l'Atomic Design deviennent évidents lors du passage à l'échelle des interfaces. Une bibliothèque de composants unique garantit la cohérence visuelle : un bouton a le même aspect sur tous les écrans car c'est le même atome. Selon Brad Frost (2016), les entreprises qui ont implémenté l'Atomic Design réduisent le temps de développement de nouveaux écrans de 30 à 50 % grâce à la réutilisation de molécules et d'organismes prêts à l'emploi.
| Caractéristique | Atomic Design | Approche basée sur les pages |
|---|---|---|
| Réutilisation des composants | Élevée (atomes, molécules, organismes) | Faible (chaque écran de zéro) |
| Cohérence visuelle | Garantie | Contrôle manuel |
| Vitesse de création de nouveaux écrans | Élevée (assemblage à partir de blocs prêts) | Faible (conception + balisage de zéro) |
| Complexité de mise en œuvre | Élevée (nécessite un catalogue de composants) | Faible (modèle familier) |
| Testabilité | Élevée (chaque atome est isolé) | Intégration (écran entier à la fois) |
Limites — l'Atomic Design ne décrit pas comment gérer l'état de l'application. La méthodologie répond uniquement à la question « comment organiser les composants d'interface utilisateur » mais n'aborde pas la logique métier, le routage ou la gestion des données. La deuxième limite est la difficulté de définir les limites : où se termine une molécule et où commence un organisme ? En pratique, les limites sont floues et différentes équipes peuvent classer le même composant différemment. Il est recommandé d'établir des règles dans les jetons de conception et un catalogue de composants (Storybook, Jetpack Compose Preview).
La troisième limite est une abstraction excessive pour les petits projets. Si une application se compose de 5 écrans, créer une hiérarchie d'atomes et de molécules est un travail inutile. L'Atomic Design devient bénéfique lorsque le nombre d'écrans dépasse 20 et que les composants sont réutilisés sur différentes pages.
Atomic Design vs Feature-Sliced Design
L'Atomic Design et le Feature-Sliced Design (FSD) résolvent des problèmes différents et peuvent être utilisés ensemble. L'Atomic Design est une méthodologie pour organiser les composants d'interface utilisateur, le FSD est une méthodologie pour organiser les couches métier et l'application dans son ensemble. L'Atomic Design répond à la question « comment diviser l'interface utilisateur en parties réutilisables », le FSD répond à « comment organiser le code autour des fonctionnalités métier ». Ils ne sont pas en concurrence : on peut avoir une structure FSD avec des couches features et entities, et à l'intérieur de chaque couche utiliser l'Atomic Design pour organiser les composants d'interface utilisateur.
| Critère | Atomic Design | Feature-Sliced Design |
|---|---|---|
| Domaine | Composants d'interface utilisateur | Architecture d'application |
| Unité de regroupement | Métaphore chimique (atome → molécule → organisme) | Fonctionnalité métier (slice) |
| Dépendances | Des atomes vers les pages (ascendant) | De l'application vers shared (descendant) |
| Gestion des données | Non décrite | Via les segments model + api |
| Passage à l'échelle | Horizontal (plus de composants) | Vertical (plus de fonctionnalités) |
Combinaison typique : le FSD définit la structure modulaire de l'application (couches, slices), l'Atomic Design définit la structure interne des composants d'interface utilisateur à l'intérieur de chaque slice. Par exemple, le slice feature.auth contient des molécules (LoginForm, PasswordInput) et des organismes (AuthPage) assemblés selon les règles de l'Atomic Design. La couche shared contient des atomes (Button, Input, Label) réutilisés dans toutes les fonctionnalités.
Atomic Design dans les applications mobiles : Compose et SwiftUI
Jetpack Compose et SwiftUI prennent naturellement en charge la hiérarchie de l'Atomic Design grâce à la composition de composants. Les atomes dans Compose sont des fonctions @Composable de base : AppButton, AppTextField, AppCheckbox. Chaque fonction accepte des paramètres de personnalisation (couleur, taille, état) et ne contient pas de logique métier. Les atomes sont définis dans la couche shared et exportés en tant que kit d'interface utilisateur.
Les molécules sont des fonctions @Composable qui combinent plusieurs atomes : LabeledTextField (étiquette + champ de saisie + message d'erreur), ProductCard (image + nom + prix). Les molécules peuvent contenir un état de base (validité du champ) mais n'accèdent pas à l'API ou à la ViewModel. Elles sont réutilisées dans différents organismes.
Les organismes sont des fonctions @Composable au niveau des fonctionnalités : LoginForm (LabeledTextField pour l'email + LabeledTextField pour le mot de passe + AppButton d'envoi + lien de récupération). Les organismes travaillent avec la ViewModel via des fonctions Intent et peuvent contenir de la logique métier. Dans SwiftUI, une hiérarchie similaire est construite via @ViewBuilder et des structures View personnalisées.
Dans SwiftUI, un atome est une structure View personnalisée AppButton, une molécule est un champ de saisie avec étiquette sur HStack, un organisme est un formulaire de connexion. Cette structure permet de réutiliser les composants sur tous les écrans — modifier un atome (couleur du bouton) s'applique automatiquement à tous les écrans. La combinaison de l'Atomic Design avec un système de design garantit la cohérence de l'interface sans contrôle manuel de chaque écran.
Foire aux questions
Faut-il suivre strictement les cinq niveaux de l'Atomic Design ?
Les cinq niveaux sont une recommandation, pas une loi. De nombreux systèmes de design (Material Design, IBM Carbon) utilisent 3 ou 4 niveaux : composants de base, composants composites et templates. La règle principale est que chaque composant appartient à un niveau et peut être réutilisé aux niveaux supérieurs. Si vous constatez que les niveaux « molécule » et « organisme » dans votre projet ne se distinguent pas — fusionnez-les. Les atomes et les pages sont les seuls niveaux obligatoires.
Comment tester les composants de l'Atomic Design ?
Les atomes sont testés visuellement (tests de snapshot, Compose Preview) — on vérifie qu'un bouton avec des propriétés données s'affiche correctement. Les molécules sont testées comme combinaison d'atomes — on vérifie l'état (erreur, succès, désactivé). Les organismes nécessitent des tests d'intégration — on vérifie l'interaction avec la ViewModel (soumission de formulaire, chargement de données). Chez IT Sectr, nous utilisons Compose Test pour Android et XCTest pour iOS ; pour les tests visuels — Paparazzi (Android) et SnapshotTesting (iOS).
Peut-on utiliser l'Atomic Design sans système de design ?
On le peut, mais l'efficacité diminue. Sans système de design et jetons de conception, les atomes n'ont pas de style unifié — chaque développeur crée ses propres atomes avec des couleurs et des espacements arbitraires, ce qui entraîne une incohérence visuelle. L'Atomic Design et le système de design sont des concepts complémentaires : l'Atomic Design définit la hiérarchie, le système de design définit le langage visuel. Il est recommandé de les mettre en œuvre ensemble : d'abord les jetons de conception (couleurs, typographie, espacements), puis les atomes, puis les molécules et les organismes.
Comment gérer la « zone atomique » (trop d'atomes) ?
La « zone atomique » est une situation où le nombre d'atomes dépasse les limites raisonnables (100+) et où trouver le composant nécessaire prend plus de temps que de l'écrire de zéro. La solution est la colocalisation des atomes par fonctionnalités : un atome utilisé par une seule fonctionnalité doit être stocké à l'intérieur de cette fonctionnalité, pas dans shared. Dans shared, seuls les atomes globaux (Button, Text, Input) sont placés. Selon Brad Frost, la colocalisation réduit le nombre d'atomes partagés de 60 à 70 % sans perte de réutilisation.
L'Atomic Design est-il seulement pour l'interface utilisateur ou aussi pour le code ?
L'Atomic Design était à l'origine une méthodologie de conception d'interfaces, mais dans la pratique moderne, il est également utilisé pour organiser le code. Dans les outils de conception (Figma, Sketch), les atomes sont des composants de bibliothèque ; dans le code, ce sont des fonctions et des classes. La méthodologie ne fait pas de distinction entre la conception et le code — l'atome est le même dans la maquette et dans l'implémentation. Chez IT Sectr, nous utilisons supernova.io pour synchroniser les atomes de conception et les atomes de code, éliminant ainsi les écarts entre la maquette et l'interface finale.
Résumé
- L'Atomic Design est une méthodologie d'organisation hiérarchique des composants d'interface utilisateur, utilisant la métaphore des atomes, molécules, organismes, templates et pages.
- Les atomes sont des éléments de base (bouton, champ de saisie) ; les molécules sont leurs combinaisons (champ avec étiquette) ; les organismes sont des blocs complexes (formulaire de recherche).
- Les templates définissent la structure, les pages — le remplissage spécifique avec des données.
- L'Atomic Design ne gère pas l'état ni la logique métier — il ne s'occupe que de l'organisation de la couche d'interface utilisateur.
- Dans le développement mobile, les atomes sont naturellement décrits par des fonctions @Composable (Android) et des structures View (iOS).
- L'Atomic Design se combine bien avec le FSD : le FSD définit l'architecture, l'Atomic Design organise l'interface utilisateur à l'intérieur des slices.
- Les principaux avantages sont la réutilisation des composants, la cohérence visuelle et la rapidité de création de nouveaux écrans.
Nous développerons une application mobile clé en main
IT Sectr crée des applications iOS et Android pour les startups et les entreprises depuis 2017. Nous vous conseillerons et vous proposerons la meilleure solution.
Lisez aussi