“Fais-le toi-même, ce sera plus rapide.” Erreur classique. La délégation mal faite coûte 40% de productivité à long terme. Voici comment déléguer efficacement sans devenir un goulot d’étranglement. Le piège : “Je le fais mieux moi-même” Coût réel du micro-management Métriques observées sur 6 équipes : Micro-managers : 60% de leur temps passé en contrôle direct Résultat : Team velocity -35%, turnover +80% Délégation efficace : 20% de temps managérial, velocity +25% Les 3 erreurs qui tuent la délégation 1. Déléguer sans contexte ...
“Lisez la doc.” Mais quelle doc ? Celle écrite il y a 2 ans et obsolète depuis 18 mois ? Voici comment créer une documentation que les développeurs vont réellement lire et maintenir. Le problème : Doc obsolète ou inexistante Symptômes classiques # README.md (Last updated: 2021) ## Setup Run `npm install` (Mais le 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 : ...
Un bon développeur qui met 2 semaines à être productif = 2 semaines perdues + frustration. Voici comment passer à 2 jours avec un onboarding structuré. Le coût d’un mauvais onboarding Situation classique Jour 1 : Setup machine (bloqué sur accès) Jour 2 : Setup encore (doc obsolète) Jour 3 : Premier build (fail, dépendances) Jour 4 : Essayer de comprendre archi Jour 5 : Première PR (rejected, standards) ... Jour 10 : Enfin productif Coût : ...
“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. ...
Code review : rituel quotidien qui peut faire progresser l’équipe… ou créer de la frustration. Voici comment en faire un outil de croissance plutôt qu’un goulot d’étranglement. Le problème : Code Review frustrantes Symptômes classiques Pour l’auteur : 09h00 : Crée PR 16h30 : Pas de review Lendemain 14h : Enfin review 16h00 : Corrige commentaires Lendemain 11h : 2ème review avec nouveaux comments ... 5 jours pour merger 200 lignes Pour le reviewer : ...
“Pourquoi la prod est lente ?” Sans observability, impossible de répondre. Voici comment implémenter les 3 piliers pour debug efficace en production. Monitoring vs Observability Monitoring (approche classique) Savoir QUAND ça casse → Alertes sur 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 sur table users Les 3 piliers 1. Métriques (Metrics) Qu’est-ce que c’est ? ...
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é. ...
“Notre système est résilient.” Vraiment ? L’avez-vous testé ? Le Chaos Engineering consiste à casser volontairement la prod pour vérifier qu’elle survit. Retour d’expérience après 1 an de pratique. Le problème : Fausse résilience Ce qu’on croit ✅ 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 la résilience que pendant les incidents. ...
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 : ...