# 🏗️ Penser un Système avant le Code — Vision avant exécution **System Thinking** = comprendre le **système global** (acteurs, flux, contraintes, interactions) **avant** de coder la première ligne. > **Code sans vision = bricolage. Vision puis code = architecture.** --- ## 🎯 Le principe ### ❌ Approche code-first (mauvaise) --- ### ✅ Approche system-first (bonne) > 💡 **L'invariant** : "Comprendre le problème avant de coder la solution." --- ## 🧠 Pourquoi c'est crucial ? Sans system thinking : - **Code déconnecté** de la réalité métier - **Refactorings constants** (vision floue) - **Bugs systémiques** (interactions non anticipées) Avec system thinking : - **Code aligné** avec les besoins réels - **Architecture cohérente** - **Évolutions fluides** (fondations solides) --- ## 📊 Les 3 niveaux de compréhension --- ## 🔍 Exemple concret ### Contexte : Système de paiement e-commerce #### ❌ Sans System Thinking ```ts // Développeur reçoit : "On veut accepter les paiements" // Il code directement : async function processPayment(amount: number) { const stripe = require("stripe")(API_KEY); const charge = await stripe.charges.create({ amount }); return charge; } ``` **Problèmes découverts après** : - Besoin de plusieurs providers (PayPal, Apple Pay) - Besoin de remboursements - Besoin d'historique - Besoin de retry en cas d'échec - Besoin de webhooks Stripe - Besoin de TVA par pays → **Refactoring complet** --- #### ✅ Avec System Thinking **1. Comprendre les acteurs** ``` - Client (achète) - Vendeur (reçoit l'argent) - Payment Provider (Stripe, PayPal) - Admin (gère litiges) - Comptable (besoin de rapports) ``` **2. Modéliser les flux** ```mermaid graph LR A[Client] -->|initiate| B[Payment] B -->|process| C[Provider] C -->|confirm| B B -->|notify| D[Vendeur] B -->|record| E[DB] E -->|report| F[Comptable] G[Webhook] -->|update status| B ``` **3. Identifier les contraintes** ``` - Multi-providers (Stripe, PayPal, etc.) - Multi-devises (EUR, USD, GBP) - TVA par pays (19 taux différents) - Retry automatique (réseau instable) - Idempotence (pas de double charge) - Audit trail (traçabilité) ``` **4. Architecture résultante** ```ts // Interface abstraite (multi-providers) interface IPaymentProvider { charge(amount: Money, metadata: PaymentMetadata): Promise; refund(chargeId: string): Promise; } // Value Object pour l'argent class Money { constructor(public amount: number, public currency: Currency) {} } // Service de paiement class PaymentService { constructor( private providers: Map, private paymentRepo: IPaymentRepository, private taxCalculator: ITaxCalculator ) {} async processPayment(order: Order): Promise { // 1. Calculer TVA const tax = this.taxCalculator.calculate(order); // 2. Créer payment (état: PENDING) const payment = await this.paymentRepo.create({ orderId: order.id, amount: order.total, tax, status: "PENDING", idempotencyKey: order.idempotencyKey, }); try { // 3. Charger via provider const provider = this.providers.get(order.paymentMethod); const result = await provider.charge(order.total, { orderId: order.id, customerId: order.customerId, }); // 4. Mettre à jour statut await this.paymentRepo.update(payment.id, { status: "SUCCESS", providerTransactionId: result.id, }); return payment; } catch (error) { // 5. Gérer échec await this.paymentRepo.update(payment.id, { status: "FAILED", errorMessage: error.message, }); throw error; } } } ``` **Bénéfices** : - ✅ Multi-providers (swap facile) - ✅ TVA gérée - ✅ Idempotence (via key) - ✅ Audit trail (DB) - ✅ Testable (interfaces) --- { console.log(msg); });`, description: "Coder sans poser de questions" }, problem: "Questions découvertes après : historique ? notifications ? fichiers ? groupes ?", solution: "Poser les questions d'architecture AVANT de coder", goodExample: { code: `// Questions à poser AVANT : // - Chat 1-to-1 ou groupes ? // - Historique persisté combien de temps ? // - Fichiers/images supportés ? // - Notifications push ? // - Chiffrement end-to-end ? // - Présence en ligne ? // → Architecture adaptée aux réponses`, description: "Comprendre le système global d'abord" } }, { title: "Ignorer les acteurs du système", badExample: { code: `// Feature : système de réservation // Dev pense uniquement "user réserve" class Booking { create(userId: string, date: Date) { // ... } }`, description: "Oubli des autres acteurs" }, problem: "Et l'admin qui annule ? Le fournisseur qui valide ? Le comptable qui facture ?", solution: "Identifier TOUS les acteurs et leurs interactions", goodExample: { code: `// Acteurs identifiés : // - User (réserve) // - Admin (annule, modifie) // - Provider (accepte/refuse) // - Accountant (facture) // - System (rappels auto) class BookingService { // User create(userId, date) {} cancel(userId, bookingId) {} // Admin adminCancel(adminId, bookingId, reason) {} // Provider approve(providerId, bookingId) {} reject(providerId, bookingId, reason) {} }`, description: "Architecture qui reflète tous les acteurs" } }, { title: "Ne pas modéliser les flux", badExample: { code: `// Dev code sans diagramme function checkout() { // ... 200 lignes de code spaghetti }`, description: "Pas de modélisation visuelle" }, problem: "Impossible de voir les dépendances, bottlenecks, points de faille", solution: "Dessiner les flux AVANT de coder", goodExample: { code: `// Diagramme de flux : // User → Cart → Checkout → Payment → Inventory → Shipping → Notification // Identification des points critiques : // - Payment peut échouer → retry // - Inventory peut être épuisé → réservation // - Shipping peut être indisponible → fallback`, description: "Vision claire des dépendances" } } ]} /> --- ## 🧪 Framework de System Thinking ### 1. **Poser les 5W** ``` Who? (Qui utilise/interagit ?) What? (Quoi fait le système ?) When? (Quand les événements se produisent ?) Where? (Où les données vivent ?) Why? (Pourquoi cette feature ?) ``` --- ### 2. **Identifier les entités et relations** ```mermaid erDiagram USER ||--o{ ORDER : places ORDER ||--|{ ORDER_ITEM : contains ORDER ||--|| PAYMENT : has ORDER ||--o| SHIPPING : has PRODUCT ||--o{ ORDER_ITEM : includes ``` --- ### 3. **Modéliser les états et transitions** ```mermaid stateDiagram-v2 [*] --> PENDING PENDING --> CONFIRMED : payment_success PENDING --> CANCELLED : user_cancel CONFIRMED --> SHIPPED : shipping_start SHIPPED --> DELIVERED : delivery_confirm DELIVERED --> RETURNED : user_return CANCELLED --> [*] DELIVERED --> [*] ``` --- ### 4. **Anticiper les cas limites** ``` - Que se passe-t-il si le paiement échoue ? - Que se passe-t-il si l'API externe est down ? - Que se passe-t-il si 2 users achètent le dernier stock ? - Que se passe-t-il si le user annule pendant le paiement ? ``` --- --- --- ## 🗺️ Carte mentale de synthèse --- ## 🚀 Résultat attendu En maîtrisant le System Thinking, tu deviens capable de : - **Comprendre** le système global avant la première ligne de code - **Anticiper** les complexités cachées - **Concevoir** des architectures cohérentes - **Éviter** les refactorings massifs Et surtout : Tu cesses de coder à l'aveugle. **Tu construis avec vision.** Code sans vision = bricolage. Vision puis code = architecture.