Architecture angulaire pratique pour la vraie vie

La plupart des cours d'architecture angulaire enseignent la théorie. Pas celui-ci.

Ici, vous apprenez à détecter des problèmes réels, à prendre des décisions situées et à construire des systèmes qui durent lorsque l'équipe s'agrandit, que le produit change et que le temps passe.

Vingt modules. Orienté vers la pratique. Pas de rembourrage.

---

INDEX — Architecture angulaire pratique pour la vraie vie

---

Module 0 — Base du système

Le point 0 n'est pas un module de contenu. C’est la manière de voir que vous utiliserez tout au long de la feuille de route.

Avant de parler de problèmes spécifiques dans Angular, vous devez répondre à une question :

Comment regarder une application que vous ne connaissez pas et décider si elle est bonne ou mauvaise ?

Il existe quatre compétences de base pour cela.

---

1. Analysez une application sans toucher au code

La première lecture d'une application ne se fait pas dans l'éditeur. C'est dans la structure. Avant d'ouvrir un seul fichier, vous pouvez extraire des informations :

• Comment s'appellent les dossiers ? Les noms disent-ils ce qu'ils font ?
• Existe-t-il un dossier shared qui pèse plus que tout le reste ?
• Combien de niveaux d'imbrication la structure comporte-t-elle ?
• Les modules ou fonctionnalités ont-ils des noms de domaine ou des noms techniques ?
• Où sont les services ? Loose ou dans les fonctionnalités ?

Cela vous en dit déjà long sur la question de savoir si celui qui a créé l'application a pensé en termes commerciaux ou en termes de couches techniques.

---

2. Revoir l'architecture de manière pratique

Réviser, ce n'est pas lire le code de haut en bas. Il pose des questions avec des critères :

• Où réside la logique métier ?
• Qui sait quoi dans chaque couche ?
• Combien de sites devez-vous modifier pour ajouter une nouvelle fonctionnalité ?
• Y a-t-il des dépendances qui vont dans le mauvais sens ?

Un architecte senior ne commence pas par le composant le plus complexe. Commencez par les points à risque les plus élevés : les services partagés, l’état global et la couche d’accès aux données.

---

3. Détecter les problèmes avant de programmer

La plupart des dommages architecturaux surviennent lors de décisions précoces qui semblent hors de propos :

• "Je mets ça sur un service partagé pour l'instant"
• "Le composant parent gère cet état, puis on le déplace"
• "On utilise NgRx pour tout, donc c'est cohérent"

Ces décisions ont de réelles conséquences des mois plus tard. Le critère architectural est de savoir ce que chaque décision achète et quelle dette elle contracte.

---

4. Convertissez la théorie en une véritable liste de contrôle

Chaque concept que nous verrons dans cette feuille de route — composants intelligents/idiots, placement d'état, services divins, etc. — doit se terminer par une question que vous pouvez vous poser en examinant le vrai code :

• Ce composant sait-il d'où proviennent les données ?
• Ce service a-t-il plus d'une raison de changer ?
• Cet état existe-t-il à deux endroits différents ?

Si vous ne parvenez pas à transformer un concept en question de révision, vous ne l'avez pas encore intériorisé.

---

Module 1 — Comment analyser une application Angular sans toucher au code

La première revue architecturale a lieu avant l'ouverture de l'éditeur. À partir de la structure des dossiers et des noms de fichiers, vous pouvez déjà extraire des signaux clairs de qualité. C’est ce que ferait un architecte senior pendant les 10 premières minutes avec une application inconnue.

Pourquoi est-ce important ?

• Si vous mettez beaucoup de temps à détecter les problèmes architecturaux, le coût de leur correction augmente de façon exponentielle.
• Une structure mal conçue dès le premier jour devient une dette technique qui bloque l'équipe des mois plus tard.
• Développer un jugement visuel rapide vous permet de prendre de meilleures décisions avant d'écrire une seule ligne de code.

Étape 1 — Lire la structure des dossiers sous forme de carte

La structure des dossiers est la première décision architecturale visible. Il vous raconte comment l'équipe a organisé son monde mental : pense-t-elle en termes de technologie ou en termes de business ?

Qu'est-ce qu'une fonctionnalité ?

Une fonctionnalité est une fonctionnalité métier complète. Pas un type de fichier. Pas une couche technique.

Pensez à une application de commerce électronique. Les fonctionnalités sont :

• Le catalogue produits
• Le panier
• Le processus de paiement
• Le profil utilisateur
• Gestion des commandes

Chacune de ces activités est une affaire qui a du sens en soi. Un utilisateur entre, parcourt le catalogue, ajoute au panier, vérifie. Ce sont des fonctionnalités.

Modèle 1 — Organisation par couches techniques (problématique à grande échelle)

C’est ce que presque tout le monde fait au début parce que cela semble sympa :

src/app/
  components/
    product-card.component.ts
    product-list.component.ts
    cart-item.component.ts
    checkout-form.component.ts
    user-profile.component.ts
  services/
    product.service.ts
    cart.service.ts
    checkout.service.ts
    user.service.ts
  models/
    product.model.ts
    cart.model.ts
    user.model.ts

Le vrai problème : il faut modifier le flux de paiement. Pour comprendre ce que cela implique, vous naviguez entre trois dossiers différents : vous recherchez le composant dans components/, le service dans services/, le modèle dans models/. S'il existe un canal de paiement spécifique, il se trouve dans pipes/ mélangé à des canaux provenant d'autres fonctionnalités.

Pour modifier une seule fonctionnalité, vous naviguez dans toute l’application. C'est un couplage par structure. Lorsque l'équipe s'agrandit, deux personnes travaillant sur des fonctionnalités différentes touchent constamment les mêmes dossiers → conflits dans git, difficulté à savoir à qui appartient quoi.

Modèle 2 — Organisation par fonctionnalités (à quelles échelles)

src/app/
  features/
    catalog/
      components/
        product-card.component.ts
        product-list.component.ts
      services/
        product.service.ts
      models/
        product.model.ts
      catalog.routes.ts
    cart/
      components/
        cart-item.component.ts
        cart-summary.component.ts
      services/
        cart.service.ts
      cart.routes.ts
    checkout/
      components/
        checkout-form.component.ts
        order-confirmation.component.ts
      services/
        checkout.service.ts
      checkout.routes.ts
  shared/
  core/

Pourquoi cela fonctionne : lorsque vous appuyez sur le paiement, tout ce qui se trouve dans la caisse est réuni. Un nouveau développeur sait exactement où chercher. Une seule personne peut posséder une fonctionnalité entière. Vous pouvez supprimer une fonctionnalité entière en supprimant uniquement son dossier. Les conflits Git entre différentes fonctionnalités disparaissent presque complètement.

La règle générale essentielle : si vous supprimez une fonctionnalité, pouvez-vous supprimer l'intégralité de son dossier sans rien toucher d'autre ? Si la réponse est oui, la fonctionnalité est bien isolée. Si vous devez chercher des pièces dans toute l’application, ce n’est pas le cas.

Étape 2 — Lisez les noms

Les noms sont de la documentation. Une mauvaise réputation cache l’intention et ajoute une charge cognitive à chaque personne qui lit le code.

shared/ — ce qu'il doit contenir et ce qu'il ne doit pas contenir

shared/ est destiné aux éléments utilisés par plusieurs fonctionnalités et qui n'ont PAS leur propre logique métier.

Corriger en shared/ :

shared/
  components/
    button/
    modal/
    spinner/
    avatar/
  pipes/
    date-format.pipe.ts
    truncate.pipe.ts
  directives/
    click-outside.directive.ts
  validators/
    email-validator.ts

Ce sont des éléments d’interface utilisateur réutilisables ou de purs utilitaires. Ils ne connaissent rien du métier. Un ButtonComponent ne sait pas s'il s'agit d'un bouton de paiement ou d'un profil utilisateur. Il sait seulement être un bouton.

Incorrect dans shared/ :

shared/
  services/
    cart.service.ts           ← lógica de negocio aquí
    user-auth.service.ts      ← pertenece a auth/core
    product-filter.service.ts ← pertenece a catalog
    report-generator.service.ts ← pertenece a reporting

Lorsque vous voyez des services avec une logique métier dans shared/, cela signifie que quelqu'un ne savait pas où les placer et ne les y a pas placés. Au fil du temps, shared/ devient le fourre-tout de l'application.

core/ — ce que c'est et ce que ce n'est pas

core/ est destiné à l'infrastructure singleton qui nécessite l'intégralité de l'application, une fois.

Corriger en core/ :

core/
  services/
    auth.service.ts
    logger.service.ts
    error-handler.service.ts
  interceptors/
    auth.interceptor.ts
    error.interceptor.ts
  guards/
    auth.guard.ts
  models/
    user-session.model.ts

Incorrect dans core/ :

core/
  components/
    dashboard.component.ts  ← eso es una feature
    home.component.ts       ← igual
  services/
    product.service.ts      ← pertenece a catalog
    report-generator.service.ts ← pertenece a reporting

Ce sont des éléments qui sont instanciés une seule fois et affectent l’ensemble de l’application. L'intercepteur d'authentification intercepte toutes les requêtes HTTP pour l'ensemble de l'application, c'est pourquoi il réside dans core/.

Noms vagues – signaux d'alarme

Un nom vague est une décision différée. Lorsque quelqu'un crée data.service.ts, il n'a pas décidé de quelles données ce service parle.

ce que tu vois	Ce que cela peut signifier
shared/ très gros	Tout ce qui ne rentre nulle part ailleurs. Cela devient un sac mélangé.
common/	Identique à shared/, mais pire nommé. Sans critères de ce qui entre.
utils/ avec services	Logique métier déguisée en utilité. Un sérieux drapeau rouge.
helpers/	Identique à utils/. Le nom ne dit rien sur la responsabilité.
components/ à la racine	Aucune organisation par domaine. Tous les composants ensemble.
core/ avec 40 fichiers	Noyau mal défini. shared/ a été utilisé comme deuxième.
app.service.ts	Un service divin qui attend de grandir. Signal d'alarme maximum.
data.service.ts	Des données sur quoi ? Responsabilité indéfinie du nom.
helper.service.ts	Cela finit par être un service avec des méthodes indépendantes.
main.component.ts	Qu'est-ce que "principal" ? Nom générique qui cache une réelle responsabilité.

Règle de nom : Si le nom du fichier ne vous indique pas exactement ce qu'il fait, le fichier en fait probablement trop ou est mal localisé.

Exemples concrets de noms vagues et de ce qu’ils cachent :

• utils/format.ts avec 800 lignes : mix formatage de date + validation de formulaire + transformation API.
• helper.service.ts : finit par être un service divin avec des méthodes sans rapport.
• app.service.ts : un service appelé l'ensemble de l'application qui a des responsabilités pour l'ensemble de l'application.

Étape 3 — Comptez et mesurez sans ouvrir de fichiers

Avant de lire le code, vous pouvez faire ces observations directement à partir de la structure :

Taille du composant comme signe

Signe	Qu'est-ce que cela indique ?
+300-400 lignes dans un seul composant	Vous en faites presque toujours trop. Ce n’est pas une règle absolue mais cela mérite d’être étudié.
+10 entrées et sorties	API trop complexe. Candidat à diviser en plusieurs composantes.
Appels HTTP directs dans le composant	Mélangez présentation et accès aux données. Couche de service manquante.
1 à 2 composants par fonctionnalité	Ils en font probablement trop. Manque de division interne.
+20 fournisseurs mondiaux	Trop de logique étatique et centralisée. Tout n’a pas besoin d’être mondial.

Services mondiaux : le danger de providedIn: 'root'

Un service global signifie que n’importe quel composant de n’importe quelle fonctionnalité peut l’injecter et l’utiliser. Cela crée des dépendances invisibles entre des fonctionnalités qui devraient être indépendantes.

// Servicio que DEBERÍA ser local a la feature de catalog:
@Injectable({ providedIn: 'root' })  // ← señal de problema
export class ProductFilterService { ... }

// Ahora cualquier componente de cualquier feature puede usarlo.
// Si catalog cambia su lógica de filtrado, puede romper
// algo en una feature aparentemente no relacionada.

Étape 4 — app.module.ts ou app.config.ts : que rechercher

Dans les applications avec modules (Angular < 17 ou Legacy)

@NgModule({
  imports: [
    BrowserModule,
    HttpClientModule,
    RouterModule,
    AuthModule,       // ← bien, infraestructura singleton

    ProductModule,    // ← señal de problema
    CartModule,       // ← señal de problema
    CheckoutModule,   // ← señal de problema
    UserModule,       // ← señal de problema
    DashboardModule,  // ← señal de problema
    // Si hay 15+ módulos de features aquí,
    // el lazy loading no está funcionando.
  ],
  providers: [
    ProductService,   // ← si hay 20+ providers aquí,
    CartService,      // hay demasiada centralización
    UserService,
    AuthService,
  ]
})

Les modules de fonctionnalités doivent être chargés paresseux (à la demande), et non importés directement dans le module racine. S'ils sont tous là, ils sont tous chargés au démarrage même si l'utilisateur n'en a jamais besoin.

Dans les applications autonomes (Angular 17+)

// app.config.ts
export const appConfig: ApplicationConfig = {
  providers: [
    provideRouter(routes, withLazyLoading()),   // ← correcto
    provideHttpClient(withInterceptors([authInterceptor])),
    provideAnimations(),

    ProductService,   // ← esto NO debería estar aquí
    CartService,      // ← pertenece a la feature de cart
  ]
}

Règle de configuration globale : La configuration globale ne doit avoir qu'une infrastructure qui affecte l'ensemble de l'application : routeur avec chargement paresseux, HttpClient avec intercepteurs globaux, animations, services d'infrastructure singleton (authentification, enregistreur, gestionnaire d'erreurs). Si vous voyez des services de fonctionnalités dans la configuration globale, quelqu'un enregistre les éléments globalement par commodité et non par nécessité.

Liste de contrôle complète — Première lecture d'une application Angular

Structure

• La structure est-elle organisée par fonctionnalités (domaine métier) ou par couches techniques ?
• Puis-je supprimer une fonctionnalité entière en supprimant uniquement son dossier sans rien toucher d'autre ?
• Les fonctionnalités ont-elles des noms de domaine professionnels (checkout, catalog) ou des noms techniques (list, form, detail) ?
• Y a-t-il des dossiers avec des noms vagues : utils, helpers, common, misc, data ?

shared/ et core/

• shared/ contient-il uniquement des composants et utilitaires d'interface utilisateur sans logique métier ?
• core/ contient-il uniquement une infrastructure singleton (intercepteurs, gardes, service d'authentification) ?
• Existe-t-il des services dotés d'une logique métier dans shared/ ?
• core/ possède-t-il des composants de fonctionnalités ou des services de domaine ?

Services et prestataires

• Les services professionnels sont-ils intégrés à vos fonctionnalités ou dispersés à l'échelle mondiale ?
• Existe-t-il plus de 20 fournisseurs mondiaux ?
• Le module racine ou app.config.ts importe-t-il les modules de fonctionnalités directement (sans paresseux) ?
• Existe-t-il des services avec providedIn: 'root' qui devraient être locaux pour une fonctionnalité ?

Noms

• Les noms de fichiers disent-ils exactement ce qu'ils font ?
• Existe-t-il des fichiers dont le nom pourrait s'appliquer à n'importe quelle partie de l'application ?
• Existe-t-il un fichier nommé app.service.ts, data.service.ts ou helper.service.ts ?
• Est-ce que shared/ pèse plus que n'importe quelle fonctionnalité individuelle ?

Exercice

Recherchez n’importe quel projet Angular public sur GitHub : il peut s’agir du vôtre ou d’un projet open source. Sans ouvrir aucun fichier, il suffit de regarder la structure et les noms des dossiers :

1. Quel modèle d’organisation utilisez-vous : fonctionnalités ou couches techniques ?
2. Quels noms vous donnent des doutes ou des soupçons ?
3. Où pensez-vous que se trouve la logique métier ?
4. Selon vous, quel dossier comporte le plus grand mélange de responsabilités ?
5. Pourriez-vous supprimer une fonctionnalité sans toucher à autre chose ?

Partagez ce que vous observez au cours de la séance et nous l’examinons ensemble comme le ferait un architecte senior.

---

Invite : analysez votre projet avec les 4 points

Copiez cette invite et utilisez-la avec n'importe quelle IA (ChatGPT, Claude, Copilot) en lui passant l'arborescence des dossiers de votre projet :

---

Analysez l'architecture du projet en appliquant ces 4 points du pilier 1 et générez un rapport.

POINT 1 — Structure des dossiers

Analysez apps/ et libs/ et répondez :

• L'organisation est-elle par fonctionnalités (domaine métier) ou par couches techniques ?
• Pouvez-vous supprimer une fonctionnalité entière en supprimant uniquement son dossier ?
• Les fonctionnalités ont-elles des noms de domaine (checkout, catalog) ou des noms techniques (list, form, detail) ?
• Existe-t-il des dossiers aux noms vagues : utils, helpers, common, misc, data ?
• Affiche l'arborescence réelle des dossiers que vous avez trouvés.

POINT 2 — Noms de fichiers et de dossiers

Recherchez l'ensemble du projet et listez :

• Fichiers aux noms vagues : data.service.ts, helper.service.ts, app.service.ts, main.component.ts, utils avec des services à l'intérieur.
• Services avec logique métier dans shared/. - Composants ou services de domaine dans core/. - shared/ pèse-t-il plus que n'importe quelle fonctionnalité individuelle ? Nombre de fichiers.

POINT 3 — Services mondiaux

Rechercher dans l'ensemble du projet :

• Tous les services avec providedIn: 'root' – répertorie de quels services il s'agit et s'ils doivent être locaux pour une fonctionnalité.
• Compte le nombre total de fournisseurs mondiaux.
• Identifie les services commerciaux enregistrés à l'échelle mondiale lorsqu'ils devraient figurer dans votre fonctionnalité.
• Recherchez des services dans libs/services/ qui appartiennent clairement à un domaine spécifique.

POINT 4 — Configuration globale (app.config.ts ou app.module.ts)

Recherchez le fichier de configuration racine de chaque application et analysez :

• Qu'est-ce qui est enregistré mondialement et qui ne devrait pas l'être ?
• Les modules de fonctionnalités sont-ils chargés avec un chargement différé ou sont-ils importés directement ?
• Y a-t-il des services métiers dans la configuration globale ?
• Combien de prestataires sont enregistrés au total dans le monde ?

FORMAT DU RAPPORT

Pour chaque point, utilisez cette structure exacte :

✅Qu'est-ce qui est bien

(liste concrète avec de vrais exemples de code)

⚠️ Signes à vérifier

(liste concrète avec chemin du fichier et pourquoi c'est un signe)

❌ Effacer les problèmes

(liste concrète avec chemin du fichier, problème et impact réel)

Au final il comprend :

Résumé exécutif

Un tableau avec les 4 points, un emoji de statut (✅ ⚠️ ❌) et une ligne de conclusion par point.

Prochaines étapes prioritaires

Liste de 5 actions spécifiques maximum classées par impact, avec le chemin exact du fichier ou dossier à toucher.

Soyez direct. N'expliquez pas ce qu'est une fonctionnalité ou une théorie. Analysez simplement ce projet spécifique et donnez de vrais résultats.