Penser systèmes : la méthode

Prérequis : tout le cursus.

Pourquoi

Dernier cours : la méthode qui reste quand on oublie les patterns. Face à un système nouveau (ou à concevoir), toujours la même démarche — elle tient sur une carte.

Concepts : la carte en 6 cases

1. Besoin : volumes, latence, criticité, budget. Chiffres, pas adjectifs (« rapide » ne veut rien dire, « p95 < 300 ms à 1k rps » si).
2. Découpage : contextes bornés (ch. 3), un morceau = une raison de changer.
3. Modèle : agrégats + événements + projections (ch. 3-4).
4. Flux : synchrone (réponse immédiate) vs async (file), par besoin (ch. 4-5).
5. Pannes : timeouts, retries, breakers, saga, rollback — pour chaque flèche du schéma (ch. 6-7).
6. Évolution : versions, dépréciations, ADR (ch. 8).

• Et la question qui tue à chaque case : « et si ça rate ici ? ».

Exemple : 30 minutes sur un coin de table

Besoin : 10k users, pics ×5, RPO 1 h, budget 1 VPS.
→ Monolithe modulaire (YAGNI !) + file Postgres + projections + backups 3-2-1
→ ADR : pas de microservices avant 10× (date de réévaluation notée)

Cas réel

Startup qui a « microservicé » à 4 devs : 12 repos, 0 déploiement serein, 6 mois perdus. Refonte en monolithe modulaire + ADR de réévaluation : vélocité ×3. L'architecture suit la taille, pas l'ego.

Pièges

• Commencer par la techno (« on fait du Kafka ») : besoin d'abord, techno ensuite. Toujours.
• Confondre simple et facile : simple = peu de pièces (dur à concevoir), facile = vite écrit (souvent fragile).
• Oublier l'équipe : la meilleure archi que personne ne comprend est une mauvaise archi (loi de Conway, documentation, revues).

À retenir

Besoin chiffré → découpage → modèle → flux → pannes → évolution ; « et si ça rate ici ? » partout.