Architecture

“On doit changer ce endpoint mais 500 clients l’utilisent.” Le versioning d’API résout ce problème. Voici les stratégies qui fonctionnent vraiment en production. Le problème : Breaking changes Scénario classique // V1 API (1000 clients utilisent ça) GET /api/users/123 { "id": 123, "name": "Alice", "email": "alice@example.com" } // V2 : On veut séparer prénom/nom GET /api/users/123 { "id": 123, "firstName": "Alice", // Breaking change! "lastName": "Smith", "email": "alice@example.com" } // Résultat : 1000 clients cassés Besoin : Faire évoluer l’API sans casser l’existant. ...

10 millions de users, 1TB de data, votre database PostgreSQL rame. Sharding ? Peut-être. Mais avant, explorons toutes les alternatives (plus simples). D’abord : Avez-vous vraiment besoin de sharding ? Alternatives plus simples 1. Vertical scaling (augmenter la machine) DB actuelle : 8 CPU, 32GB RAM DB upgradée : 32 CPU, 256GB RAM Coût : $500/mois → $2000/mois Effort : 1 heure de migration Jusqu’où ? Machines jusqu’à 128 CPU, 4TB RAM existent. ...

“Il faut tout réécrire !” Non. Voici comment améliorer progressivement une codebase legacy sans Big Bang rewrite (qui échoue 80% du temps). Le mythe de la réécriture La proposition classique "Ce code est pourri, on va tout réécrire en 6 mois." Réalité : 6 mois → 18 mois Budget x3 Features manquantes Bugs nouveaux Parfois : Abandon du projet Exemples célèbres d’échecs : Netscape (réécriture → mort de l’entreprise) Basecamp (réécriture abandonnée) Strangler Fig Pattern : La solution Principe Remplacer progressivement l’ancien système par du nouveau code, fonctionnalité par fonctionnalité. ...

Pourquoi cette décision a été prise ? Qui l’a validée ? La documentation ne le dit pas… ou elle est obsolète. Les ADR et RFC résolvent ce problème de façon élégante. Le problème : Documentation morte Symptômes classiques # README.md (last updated: 2 years ago) ## Architecture We use microservices... // Mais personne ne sait : // - Pourquoi microservices ? // - Quelles alternatives ont été considérées ? // - Qui a décidé ? Résultat : ...

Un Service Mesh résout des problèmes réels de microservices. Mais il en crée aussi de nouveaux. Voici quand l’adopter (ou pas) après l’avoir utilisé en prod sur 3 projets différents. Le problème qu’un Service Mesh résout Sans Service Mesh Service A ──HTTP──> Service B │ ├─ Retry logic dans le code ├─ Circuit breaker dans le code ├─ Metrics dans le code ├─ mTLS dans le code └─ Load balancing dans le code // Résultat : Logique dupliquée partout Avec Service Mesh Service A ──> Sidecar Proxy ──> Sidecar Proxy ──> Service B │ │ └─ Toute la logique réseau ici Promesse : Abstraire networking, sécurité, observabilité. ...

WebAssembly (Wasm) promet des performances natives dans le navigateur. Après l’avoir utilisé en production sur plusieurs projets, voici ce qui fonctionne vraiment et ce qui relève du marketing. WebAssembly en 2 minutes Qu’est-ce que c’est ? WebAssembly est un format binaire exécutable dans les navigateurs modernes, offrant des performances proches du code natif. ┌─────────────┐ │ Rust/C/C++ │ │ Go, etc. │ └──────┬──────┘ │ Compile ┌──────▼──────┐ │ .wasm │ ← Binaire compact └──────┬──────┘ │ Load ┌──────▼──────┐ │ Browser │ ← Exécution rapide └─────────────┘ Promesses marketing vs Réalité Marketing : “Wasm est 20x plus rapide que JavaScript !” ...

Le Platform Engineering est LA tendance qui transforme le DevOps en 2025. Mais au-delà du buzzword, qu’est-ce qui change vraiment ? Retour d’expérience après avoir construit une plateforme interne pour 50+ développeurs. Le problème : DevOps n’a pas tenu ses promesses La promesse initiale “You build it, you run it” — Werner Vogels, Amazon CTO La réalité 5 ans après Développeurs noyés dans Kubernetes, Terraform, CI/CD Copier-coller de config entre projets 10 façons différentes de déployer Onboarding nouveau dev : 2 semaines d’infra Constat : Chaque équipe réinvente la roue. ...

GraphQL fait beaucoup parler depuis quelques années, présenté comme le successeur de REST. Mais est-ce vraiment le cas ? Après avoir implémenté les deux approches en production, voici un guide pragmatique pour faire le bon choix. La promesse GraphQL vs la réalité terrain Ce qu’on vous vend : “Plus d’overfetching/underfetching” “Un seul endpoint pour tout” “Les clients demandent exactement ce dont ils ont besoin” La réalité en production : Complexité de mise en cache accrue N+1 queries si pas bien géré Courbe d’apprentissage pour l’équipe Coût de monitoring et debugging plus élevé Quand REST est le meilleur choix 1. APIs publiques et third-party REST excelle pour les APIs publiques car : ...

L’edge computing transforme notre approche des applications distribuées. Au lieu de centraliser dans des data centers distants, nous rapprochons le traitement des utilisateurs finaux. Réduction de latence, résilience accrue, conformité locale : comment architecturer et déployer efficacement sur l’edge ? Comprendre l’Edge Computing moderne Du Cloud centralisé à l’Edge distribué L’évolution historique des architectures de calcul s’est faite par vagues successives, chacune répondant à de nouveaux besoins : 1960-1980 : L’ère mainframe ...

L’industrie tech consomme plus d’énergie que l’aviation civile. Chaque ligne de code a un impact environnemental. Comment développer des applications plus durables sans sacrifier les fonctionnalités ? Voici un guide pratique pour le développement logiciel éco-responsable. L’impact environnemental du numérique : comprendre pour agir Mesurer l’empreinte carbone de nos applications Le numérique représente 4% des émissions mondiales de CO2, avec une croissance de 8% par an. Chaque application a un impact mesurable qu’il faut quantifier pour l’optimiser. ...