Builder d'Architecture

Construisez une architecture logicielle étape par étape en choisissant les composants, les couches et les connexions selon les exigences du système.

Objectif

Dans ce laboratoire, vous allez concevoir une architecture logicielle à partir de zéro. Vous partirez d’un ensemble d’exigences métier et techniques, et vous devrez choisir les composants, les couches et les connexions qui résolvent le mieux le problème posé.

L’objectif n’est pas d’arriver à « la bonne réponse » — mais de pratiquer le processus de prise de décisions architecturales avec discernement.

Scénario : Plateforme d’e-commerce

Imaginez qu’on vous demande de concevoir l’architecture d’une plateforme de commerce électronique répondant aux exigences suivantes :

Utilisateurs concurrents : jusqu’à 10 000 simultanés
Catalogue : 50 000 produits avec recherche et filtres
Paiements : intégration avec au moins 2 prestataires externes
Notifications : email et push en temps réel
Disponibilité : 99,9 % d’uptime

Étape 1 — Choisir le style architectural

Avant de penser aux technologies, définissez le style général :

Style	Avantages	Inconvénients	Quand le choisir ?
Monolithe modulaire	Simple à déployer, facile à déboguer	Mise à l’échelle limitée, couplage interne	Petites équipes, MVP
Microservices	Mise à l’échelle indépendante, déploiement autonome	Complexité opérationnelle, latence réseau	Grandes équipes, domaines clairs
Hybride	Équilibre entre simplicité et scalabilité	Exige de la discipline sur les frontières	Croissance progressive

Exercice

Compte tenu du scénario, quel style choisiriez-vous ? Prenez en compte :

La taille de l’équipe disponible
Le besoin de mettre à l’échelle des composants de façon indépendante (catalogue vs paiements)
La complexité opérationnelle que vous pouvez assumer

Étape 2 — Définir les couches du système

Une fois le style choisi, définissez les couches principales :

Couche de présentation

SPA, SSR ou site statique ?
Avez-vous besoin d’un BFF (Backend for Frontend) ?
Comment gérez-vous l’authentification côté frontend ?

Couche applicative

De combien de services avez-vous besoin ?
Comment communiquent-ils entre eux (sync vs async) ?
Où réside la logique métier critique ?

Couche de données

Une base de données ou plusieurs ?
SQL, NoSQL ou les deux ?
Avez-vous besoin d’un cache ? Où ?

Couche d’infrastructure

Cloud, on-premise ou hybride ?
Conteneurs, serverless ou VMs ?
Comment gérez-vous les secrets et la configuration ?

Étape 3 — Connecter les composants

Définissez comment communiquent les différentes pièces :

[Frontend SPA]
    │
    ▼
[API Gateway / BFF]
    │
    ├──► [Service de Catalogue] ──► [PostgreSQL + Redis Cache]
    │
    ├──► [Service de Commandes] ──► [PostgreSQL]
    │         │
    │         ▼
    │    [Event Bus]
    │         │
    │         ├──► [Service de Paiements] ──► [Prestataire Externe]
    │         └──► [Service de Notifications] ──► [Email/Push]
    │
    └──► [Service d'Auth] ──► [Redis Sessions]

Questions clés

Que se passe-t-il si le service de paiements ne répond pas ?
Comment garantissez-vous qu’une commande ne soit pas traitée deux fois ?
Où implémentez-vous les circuit breakers ?
Comment gérez-vous la cohérence à terme (eventual consistency) entre les services ?

Étape 4 — Évaluer les compromis

Toute décision architecturale comporte des compromis. Documentez les vôtres :

Décision	Compromis accepté	Atténuation
Microservices pour le catalogue et les paiements	Complexité opérationnelle accrue	Kubernetes + CI/CD automatisé
Event bus pour la communication async	Cohérence à terme	Idempotence + retry avec backoff
Redis comme cache du catalogue	Données potentiellement obsolètes (stale)	TTL de 5 minutes + invalidation par événements
PostgreSQL pour les données transactionnelles	Mise à l’échelle verticale limitée	Read replicas + partitionnement

Étape 5 — Valider par rapport aux exigences

Vérifiez que votre architecture satisfait chaque exigence initiale :

Supporte-t-elle 10 000 utilisateurs concurrents ? Où se situe le goulot d’étranglement ?
La recherche dans le catalogue est-elle rapide ? Utilisez-vous des index ou un moteur de recherche ?
Les paiements sont-ils résilients face aux pannes du prestataire ?
Les notifications arrivent-elles en temps réel ?
Pouvez-vous atteindre 99,9 % d’uptime avec cette architecture ?

Réflexion

En terminant, posez-vous ces questions :

Quelle décision a été la plus difficile ? Pourquoi ?
Que changeriez-vous si l’équipe comptait 3 personnes au lieu de 15 ?
Que changeriez-vous si les exigences de disponibilité étaient de 99,99 % ?
Y a-t-il un composant que vous pourriez supprimer sans perdre de fonctionnalité critique ?

L’architecture parfaite n’existe pas — mais une architecture bien raisonnée et bien documentée est inestimable.