Ce qu'est vraiment l'architecture Frontend (et ce qu'elle n'est pas)

L’erreur de diagnostic la plus courante dans le développement Web moderne ressemble à ceci : “Notre architecture frontend est React avec Tailwind.”

React est une bibliothèque d’interface utilisateur. Tailwind est un système de style. Aucun des deux n’est une architecture.

Si vous croyez que votre framework est votre architecture, vous cesserez de prendre des décisions structurelles. Vous laisserez le routeur de fichiers par défaut du framework dicter votre flux de données. Vous laisserez vos composants récupérer leurs propres données, gérer leur propre logique de domaine et gérer leur propre style, tout cela dans le même fichier. Ce n’est pas de l’architecture. C’est un amas indompté de complexité accidentelle qui attend de s’ossifier.

L’Architecture Frontend est la conception intentionnelle de frontières.

L’architecture comme un système de frontières

Une bonne architecture permet aux équipes de modifier une partie d’un système sans tout casser. Elle le fait en imposant des frontières.

La frontière du composant (Séparation des préoccupations)

La Séparation des préoccupations classique signifiait diviser HTML, CSS et JavaScript dans des fichiers séparés. Le développement moderne axé sur les composants a changé cela : nous regroupons désormais le code par fonctionnalité, et non par type de fichier.

Cependant, la préoccupation existe toujours. Un composant d’interface utilisateur ne devrait pas assembler des URL d’API, analyser du JSON brut en objets de domaine, appliquer des règles métier et rendre le balisage tout à la fois.

graph TD
    subgraph Le Blob (Architecture Accidentelle)
        B1[Composant Bouton] -->|Récupère les Données| B2(Réponse Réseau Brute)
        B1 -->|Analyse| B3(Logique de Domaine)
        B1 -->|Rend| B4(UI)
    end

    subgraph La Frontière (Architecture Disciplinée)
        D1[Couche de Données] -->|Normalise| D2[Couche de Domaine]
        D2 -->|Passe les Props| P1[Couche de Présentation]
    end

Un exemple d’architecture accidentelle : Un composant React UserProfile appelle fetch(), vérifie manuellement si user.age > 18, puis renvoie un badge rouge si la vérification échoue. Si la règle d’âge passe à 21, vous devez traquer chaque composant de l’interface utilisateur qui vérifie manuellement l’âge. Un exemple de discipline de frontière : Un module de domaine User dédié exporte une fonction canDrinkAlcohol(user). Le composant UserProfile importe cette fonction. L’interface utilisateur sait comment rendre le badge rouge ; le module de domaine connaît les règles.

La frontière de l’état

L’état doit être limité à la frontière la plus étroite possible.

1. État Local : Préoccupations éphémères de l’interface utilisateur. Cette liste déroulante est-elle ouverte ? Qu’est-ce qui est tapé dans cette entrée ? (Appartient au composant).
2. État de Fonctionnalité : État partagé au sein d’un domaine de fonctionnalité spécifique. (Appartient à un fournisseur de contexte ou à un magasin à portée de fonctionnalité).
3. État Global : L’état que l’application entière doit connaître, comme l’utilisateur actuellement connecté ou le thème sélectionné. (Appartient à un magasin global).

Le mode d’échec : Placer un booléen comme isDropdownOpen dans un magasin Redux global. Cela couple un détail microscopique de l’interface utilisateur à l’architecture globale, forçant des re-rendus inutiles.

La frontière du rendu

Tous les pixels ne sont pas créés égaux. L’architecture nécessite de décider où et quand le code se transforme en HTML.

Si vous traitez un site marketing et un tableau de bord SaaS complexe de la même manière, vous échouez en architecture. Un site marketing exige une Stratégie de Rendu statique pour le référencement et la vitesse. Un tableau de bord SaaS exige une interactivité côté client. Choisir la mauvaise frontière de rendu impose des pénalités de performance permanentes.

Les quatre modes d’architecture

Différentes formes de produits exigent des systèmes de frontières entièrement différents.

1. La publication de contenu (ex: Interface Atlas)

• Frontière Principale : Le modèle de contenu (Architecture de l’information).
• État : Minimal à inexistant.
• Rendu : HTML statique avec des îlots interactifs sélectifs.
• Objectif de l’Architecture : S’assurer que le contenu est découplé des composants de mise en page afin de pouvoir être interrogé et réutilisé.

2. L’application monopage (SPA)

• Frontière Principale : État côté client et routage.
• État : Caches clients complexes et hautement normalisés.
• Rendu : CSR ou SSR/Hydratation de page entière.
• Objectif de l’Architecture : Gérer la synchronisation entre la base de données du serveur et la mémoire côté client.

3. Le système de conception (Design System)

• Frontière Principale : Le contrat d’API des composants de l’interface utilisateur.
• État : État de l’interface utilisateur locale strictement contrôlé ; totalement agnostique aux données de domaine.
• Rendu : Doit prendre en charge plusieurs environnements (React, Vue, Web Components).
• Objectif de l’Architecture : Cohérence, accessibilité et prévention des changements cassants pour les équipes consommatrices.

Heuristique Finale

Le test de votre architecture frontend n’est pas de savoir si elle utilise le dernier framework. Le test est ce qui se passe lorsque les exigences changent.

Si la modification de la structure de données de votre backend nécessite la réécriture de vos composants d’interface utilisateur, vos frontières ont échoué. L’architecture est la discipline qui consiste à protéger l’interface utilisateur de la base de données, et à protéger la base de données de l’interface utilisateur.

Guides et termes associés

Pour une exploration plus approfondie, voir :

• Architecture de l’information et architecture de contenu — Comment la structure des connaissances pilote l’UI.
• Les performances Web en tant qu’architecture — Comment les décisions de rendu affectent les performances.
• Choisir la bonne pile — Comment mapper la forme du produit à la pile technologique.