Cto

Dédramatisation “Lisez la doc.” Mais quelle doc ? Celle écrite il y a 2 ans et obsolète depuis 18 mois ? Cette situation n’est pas une fatalité. Voici comment créer une documentation que les développeurs vont réellement lire et maintenir. Ce que j’ai observé : le problème Doc obsolète inexistante. Symptômes classiques (README.md Last updated 2021 Run npm install Mais projet utilise pnpm depuis 2023 Ou pire Fichier user.service.ts 500 lignes Commentaire Aucun README “Le code se documente lui-même” Résultat Nouveaux devs perdus Bugs incompréhension Temps perdu reverse-engineer). Documentation n’est pas optionnelle. C’est multiplier : Onboarding 3x plus rapide Bugs -50% meilleure compréhension Contributions facilitées. Principes : Code self-documenting d’abord, Documenter “Pourquoi”, Rester proche code, Tester maintenir. Commencer petit : README Quick Start 1h, Guides essentiels 1 jour, CI check docs 2h, Iterate feedback. ...

Situation réelle “On doit changer ce endpoint mais 500 clients l’utilisent.” Cette situation n’est pas une fatalité. Le versioning d’API résout ce problème. Ce que j’ai observé : 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 API sans casser existant). Versioning d’API n’est pas optionnel. C’est promesse clients : Stabilité, Prévisibilité, Temps migration. Best practices : URL versioning /api/v1 /api/v2, Backward compatible quand possible, Deprecation graduelle 6 mois minimum, Communication proactive, Monitoring usage. Éviter breaking changes : Additive changes only, GraphQL si possible, BFF pattern. ...

Situation réelle “Pourquoi la prod est lente ?” Sans observability, impossible de répondre. Cette situation n’est pas une fatalité. L’observability moderne permet de comprendre le comportement d’un système en production et de diagnostiquer les problèmes rapidement. Ce que j’ai observé : beaucoup d’équipes confondent monitoring et observability. Monitoring approche classique (Savoir QUAND ça casse → Alertes métriques connues → “CPU > 80%” → Alerte, Limite ne répond pas au “Pourquoi ?”). Observability approche moderne (Comprendre POURQUOI ça casse → Investiguer comportements émergents → Corréler métriques + logs + traces, Exemple Alerte API latency increased +200ms Monitoring classique “La latency est haute” Restart service ? Observability Trace montre DB query lente Logs montrent Lock contention Metrics montrent Connexions DB saturées → Root cause Missing index table users). L’observability n’est pas un luxe. C’est une nécessité : réduire MTTR de 90%, comprendre comportements prod, anticiper problèmes. ...

Situation réelle 10 millions de users, 1TB de data, votre database PostgreSQL rame. Sharding ? Peut-être. Mais avant, explorons toutes les alternatives (plus simples). Ce que j’ai observé : sharding n’est pas premier choix. Alternatives plus simples : Vertical scaling augmenter machine DB actuelle 8 CPU 32GB RAM DB upgradée 32 CPU 256GB RAM Coût $500/mois → $2000/mois Effort 1 heure migration Jusqu’où Machines jusqu’à 128 CPU 4TB RAM existent, Read replicas scaling lecture Master Primary Writes Read replicas R1 R2 R3 Reads Cas usage 90% reads 10% writes Effort 1 semaine, Partitioning même DB tables séparées Partition par date CREATE TABLE orders_2024 PARTITION OF orders FOR VALUES FROM ‘2024-01-01’ TO ‘2025-01-01’ CREATE TABLE orders_2025 PARTITION OF orders FOR VALUES FROM ‘2025-01-01’ TO ‘2026-01-01’ Performance Queries 10x plus rapides partition Effort 1 semaine, Caching agressif Redis cache Requêtes fréquentes Sessions Rate limiting Hit rate 80%+ → Reduce DB load 80%. Quand sharding devient nécessaire : Vertical scaling maxed out Machine biggest available Coût prohibitif >$10k/mois, Write throughput saturé Master CPU >80% Write lag croissant Read replicas suffisent plus, Data size >1TB Backups trop longs >6h Restore impossible RTO Queries lentes malgré index, Geographic distribution Users worldwide Latency critique Data residency laws GDPR. Sharding n’est pas premier choix. Alternatives plus simples : Vertical scaling Read replicas Caching Partitioning. Mais si nécessaire : Choisir bonne stratégie hash range geo, Migration progressive 6-12 mois, Monitoring intensif. Complexité réelle : Cross-shard queries Transactions distribuées Resharding. Commencez simple. Shardez seulement si vraiment requis. ...

Situation réelle “Il faut tout réécrire !” Cette proposition revient régulièrement face à une codebase legacy. Elle semble séduisante : repartir de zéro, faire les choses bien cette fois. Mais la réalité est différente. Les réécritures complètes échouent 80% du temps : 6 mois deviennent 18 mois, le budget triple, les features manquent, les bugs nouveaux apparaissent, parfois le projet est abandonné. Ce que j’ai observé : il est possible d’améliorer progressivement une codebase legacy sans Big Bang rewrite. Le pattern Strangler Fig permet de remplacer progressivement l’ancien système par du nouveau code, fonctionnalité par fonctionnalité. Cette approche progressive évite les risques du Big Bang et permet de continuer à livrer de la valeur pendant la migration. ...

Situation réelle “Notre système est résilient.” Vraiment ? L’avez-vous testé ? Cette situation n’est pas une fatalité. Le Chaos Engineering consiste à casser volontairement la prod pour vérifier qu’elle survit. Ce que j’ai observé : beaucoup d’équipes croient que leur système est résilient (Redondance serveurs, Auto-scaling configuré, Health checks en place, Backups automatiques → “Le système est résilient !”). La réalité (Premier incident critique Auto-scaling ne scale pas config obsolète Health checks passent mais app bugue Backup restore jamais testé ne marche pas Cascading failure tout tombe → Downtime 4 heures Problème On ne teste résilience que pendant incidents). Chaos Engineering n’est pas destruction pour fun. C’est assurance : Tester résilience avant incidents réels, Découvrir faiblesses conditions contrôlées, Build confidence équipe système. Commencer petit : GameDay staging 1 scénario simple, Fixer ce qui casse, Répéter jusqu’à confiance, Progresser vers prod. En 6 mois : Système vraiment résilient. ...

Situation réelle Pourquoi cette décision a été prise ? Qui l’a validée ? La documentation ne le dit pas… ou elle est obsolète. Cette situation n’est pas une fatalité. Les ADR et RFC résolvent ce problème de façon élégante. Ce que j’ai observé : beaucoup d’équipes ont une documentation morte. Symptômes classiques (README.md last updated 2 years ago “We use microservices…” mais personne ne sait pourquoi microservices quelles alternatives considérées qui a décidé). Résultat : décisions refaites plusieurs fois, contexte perdu, nouveaux arrivants perdus. Avec ADR/RFC, documentation vivante : toujours à jour archives immutables, contexte préservé, décisions traçables. Métriques adoption mesurée (Avant ADR/RFC décisions documentées 10% “Pourquoi ?” répondu rarement onboarding nouveau 2 semaines, Après ADR/RFC décisions documentées 95% “Pourquoi ?” dans ADR toujours onboarding nouveau 3 jours). ...

Situation réelle Déployer un vendredi soir ? Avec les Feature Flags, c’est possible. Cette situation n’est pas une fatalité. Les Feature Flags transforment le déploiement : avant (Deploy = stress, Rollback = 15-30min, Testing en prod = impossible), après (Deploy = routine, Rollback = 1 seconde, Testing en prod = safe). Ce que j’ai observé : beaucoup d’équipes ont un problème traditionnel. Déploiement = Release (git push → CI/CD → Deploy prod → 🤞 Si bug rollback complet → redéploy entier → 15-30 minutes downtime). Résultat : déploiements le mardi matin uniquement, freeze 2 jours avant weekend, stress maximum. Avec Feature Flags (git push → CI/CD → Deploy prod feature OFF → Test interne feature ON pour admins → Rollout 5% users → 100% users Si bug Toggle flag OFF instantané). Résultat : deploy n’importe quand, rollback <1 seconde, zero stress. Investissement minimal, impact maximum. ...

Situation réelle 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. Ce que j’ai observé : le problème qu’un Service Mesh résout. Sans Service Mesh (Service A HTTP Service B Retry logic dans code Circuit breaker dans code Metrics dans code mTLS dans code Load balancing dans code Résultat Logique dupliquée partout). Avec Service Mesh (Service A → Sidecar Proxy → Sidecar Proxy → Service B Toute logique réseau ici Promesse Abstraire networking sécurité observabilité). Un Service Mesh n’est pas silver bullet. C’est trade-off : Gain Networking abstrait sécurité observability, Coût Complexité overhead expertise requise. Mon conseil : Commencer sans K8s Ingress + SDK libraries, Identifier pain points réels, Tester Service Mesh 1 namespace, Mesurer impact vs effort, Décider avec data. Pour 80% projets : Commencez par Linkerd si Service Mesh requis. Simple rapide fiable. ...

Situation réelle Terraform domine le marché IaC depuis des années. Pulumi arrive avec la promesse d’utiliser de vrais langages de programmation. Après avoir utilisé les deux en production, voici mon retour sans bullshit. Ce que j’ai observé : il n’y a pas de mauvais choix. Terraform et Pulumi sont tous deux excellents pour faire de l’IaC en 2025. Le vrai critère : votre équipe. Équipe infra/ops → Terraform, Équipe dev → Pulumi, Équipe mixte → Terraform plus facile pour tout le monde. Mon conseil : Faire POC 1 feature simple, Mesurer vitesse dev bugs satisfaction équipe, Décider avec vraie data. ...