Mes conseils de non-expert issus d'une mission d'optimisation réussie
Un peu de contexte
L'API est centrale pour un programme de migration. Problème : des latences critiques bloquent sa mise en production.
Les symptômes : CPU MongoDB à 150%, connexions qui passent de 400 à 1500, taux d'erreurs élevé, requêtes dépassant 30 secondes.
Voici la démarche que j'ai suivie et ce que j'en retiens.
Comment attaquer ce genre de sujet ?
Avant de foncer, j'ai rassemblé un maximum d'informations : audits existants, interviews, dashboards de monitoring, historique de bugs. J'ai complété par une revue de code pour évaluer la complexité, repérer les anti-patterns et identifier des quick wins.
🤖 Accélérateur IA : L'agent a scanné le codebase, identifié les anti-patterns et documenté la structure. Il m'a aidé à construire une vision macro du système.
En m'appuyant sur le framework Cynefin, j'ai identifié qu'on était dans le cadrant Complexe : plusieurs facteurs interconnectés, impossible de prédire l'impact d'une optimisation sans l'essayer.
D'où l'approche : Probe → Sense → Respond — expérimenter, observer, ajuster.
Une stratégie itérative : Probe → Sense → Respond
Sans outillage, pas de données. Sans données, pas de stratégie. J'ai utilisé un outil de test de charge et plusieurs solutions de monitoring pour collecter un maximum d'informations.
Smoke Test
Probe : Chaque tir utilise un profil simple et identique : montée progressive jusqu'à 500 utilisateurs virtuels, plateau de 15 minutes, puis descente.
Sense : Trop d'erreurs 504, MongoDB instable — résultats inexploitables. En cause : le scénario réutilisait les mêmes identifiants (write conflicts) et le code contenait des requêtes sans index.
Résultat : Non exploitable (trop d'erreurs pour mesurer)
Respond :
- Création d'index sur les champs critiques
- Amélioration du scénario de test (randomisation, distribution réaliste)
- Création d'un environnement dédié aux tests
🤖 Accélérateur IA : L'agent a identifié les champs à indexer et généré les scripts de test.
Définir une référence
Probe : Tir de charge avec le scénario corrigé sur l'environnement dédié.
Sense : Premiers résultats exploitables. Latence élevée, mais mesures fiables.
Résultat (baseline) : 101 req/s, 2.56% erreurs, P99 9.9s, moyenne 3.15s
Respond :
- Ajustement de l'autoscaling Kubernetes (HPA)
- Augmentation du nombre de replicas
Tester le scaling horizontal ⚠️
Probe : Nouveau tir de charge.
Sense : Les pods saturent avant que l'autoscaling réagisse.
Résultat : 82 req/s, 4.17% erreurs, P99 12.3s, moyenne 4.09s ⚠️
⚠️ Régression ! Plus de replicas = plus de connexions MongoDB concurrentes = plus de contentions. On déplace juste le problème.
Respond :
- Augmentation des ressources CPU et RAM par pod
Tester le scaling vertical
Probe : Nouveau tir de charge.
Sense : L'observabilité révèle des erreurs Out Of Memory et des restarts fréquents.
Résultat : 162 req/s, 0.68% erreurs, P99 5.86s, moyenne 1.58s
✅ Débit +60%, erreurs -73%. Mais la latence reste élevée — le problème est maintenant côté code.
Respond :
- Optimisation des requêtes MongoDB (suppression des agrégations coûteuses)
- Refactoring des algorithmes critiques
- Optimisation des paramètres d'écriture
🤖 Accélérateur IA : L'agent a généré des tests de non-régression et assisté le refactoring du code.
Tester les optimisations applicatives
Probe : Nouveau tir de charge.
Sense : Les optimisations portent leurs fruits.
Résultat final ✅ : 200 req/s, ~0% erreurs, P99 0.67s, moyenne 233ms
✅ Débit doublé par rapport à la baseline, P99 passé de 9.9s à 0.67s.
Exit — Savoir quand s'arrêter
200 req/s, P99 sous la seconde, erreurs quasi-nulles : les contraintes de la MEP sont respectées.
Dans Cynefin, c'est le passage du cadrant Complexe au cadrant Compliqué : on a suffisamment appris, les prochaines optimisations deviennent prévisibles. Sans données de production, aller plus loin serait de l'optimisation prématurée.
Conclusion
Cette mission montre qu'une approche Probe → Sense → Respond permet des gains rapides sur un système complexe. Les agents IA n'ont pas remplacé l'expertise — c'est l'humain qui observe et décide — mais ils ont accéléré chaque cycle. Plus on itère vite, plus on apprend vite.
Ce que je retiens
Mesurer avant et après chaque changement. L'intuition ne suffit pas, et une optimisation peut faire pire.
Soigner le scénario de test. Un scénario non représentatif donne des résultats trompeurs.
Naviguer entre les couches. Infra, code, base de données forment un système. Savoir lire des métriques Kubernetes, profiler MongoDB et refactorer du code dans la même journée est un atout décisif.
S'outiller correctement. Sans outils de test de charge, d'observabilité et de profiling, l'optimisation est aveugle.
Utiliser des agents IA pour accélérer. Ils ne remplacent pas l'expertise, mais ils amplifient la vélocité d'exécution.
Définir un critère d'arrêt. Les SLOs définissent quand c'est "assez bien". Sans eux, on risque de sur-optimiser.
Bonus : une Platform Engineering mature reste un prérequis pour que ces gains se concrétisent.
Top comments (0)