Avant de refactor, observe : le réflexe SRE qui sauve des sprints

Un service est lent. Un service tombe deux fois par semaine sans qu’on sache pourquoi. Le réflexe d’équipe, presque toujours, c’est : “il faut le réécrire”. Quelqu’un sort un tableau blanc, propose une nouvelle archi, et trois sprints plus tard on a un service neuf qui a les mêmes problèmes.

Le réflexe SRE est l’inverse : avant de refactor, observe. Pas par dogme, par expérience.

Le coût caché du refactor sans données

Refactorer sans données, c’est faire trois paris en aveugle :

Que vous avez identifié le bon problème. Le service est lent ? Lent où ? Sur quel endpoint ? Pour quel type de requête ? À quel moment de la journée ?
Que la nouvelle archi va résoudre ce problème précis. Sans baseline, vous ne saurez même pas si c’est mieux après.
Qu’aucun nouveau problème n’apparaît. Refactor = re-bug. Si vous n’avez pas instrumenté l’ancien, vous ne pourrez pas comparer.

Trois paris, trois chances de se planter. Statistiquement, vous perdez au moins un.

Ce que “observer” veut dire concrètement

Observer, ce n’est pas “ajouter quelques logs”. C’est livrer un sous-projet d’observabilité qui répond à des questions précises avant de toucher au code métier.

Pour un service lent, je veux a minima :

Latence par endpoint, par percentile (p50, p95, p99). La moyenne ment.
Décomposition du temps de réponse : combien dans la DB, combien dans les appels externes, combien dans la logique applicative. Tracing distribué si possible.
Taux d’erreur par endpoint et par code (5xx ne veut rien dire, 502 vs 504 vs 500 raconte des histoires différentes)
Saturation des ressources : CPU, RAM, descripteurs de fichiers, connexions DB
Latence des dépendances côté client (pas seulement les métriques que la dépendance expose elle-même)

Pour un service instable :

Logs structurés avec request ID propagé pour reconstituer un parcours complet
Profiling continu quand c’est faisable (Pyroscope, profiler intégré au runtime)
Dashboards d’incident pré-construits, qu’on n’invente pas pendant la crise à 3h du matin
Replays des requêtes problématiques en pre-prod

Le moment “ah”

À chaque fois que j’ai pris la peine de faire ça, le diagnostic réel a été différent du diagnostic supposé.

Le service “lent” était lent parce qu’un endpoint sur 47 rapatriait 80 % du trafic et faisait un N+1 sur la DB. Le reste du service allait très bien.
Le service qui “tombait” tombait parce qu’un cron job mensuel explosait la mémoire à un moment précis. Personne ne soupçonnait le cron parce que personne ne le voyait dans les graphes.
Le service “saturé” CPU n’était pas saturé CPU : il était bloqué sur des locks de DB parce qu’une migration en cours tournait dix fois plus longtemps qu’attendu.

Aucun de ces diagnostics n’aurait été corrigé par un refactor générique. Tous ont été résolus par un fix ciblé et chirurgical, qui a tenu en quelques heures de dev.

Quand refactorer quand même

Observer ne veut pas dire ne jamais refactorer. Ça veut dire refactorer avec des données et un objectif mesurable. Le refactor légitime, c’est :

“Le p99 sur cet endpoint est à 4s, on vise 400 ms, on a tracé que 90 % du temps est dans la sérialisation d’un blob géant qu’on charge à chaque requête, on va le mettre en cache.”
“On a 12 incidents par mois liés au coupling DB partagée entre service A et B, on va isoler les schémas.”
“Les coûts cloud ont doublé en six mois, on a tracé que 70 % vient de logs verbeux qu’on n’utilise jamais, on coupe.”

Trois exemples, trois refactors qui marchent. Pourquoi ? Parce que la donnée précède l’action, et la cible est mesurable.

Le contre-argument

“Mais on n’a pas le temps d’instrumenter, c’est urgent.”

C’est précisément quand c’est urgent qu’il faut instrumenter en premier. Un sprint perdu à observer, c’est moins coûteux que trois sprints perdus à refactorer le mauvais service. Si l’observabilité prend deux jours, ces deux jours sont les plus rentables que vous passerez sur le projet.

Et si l’observabilité est tellement absente que vous avez besoin de plusieurs semaines pour la mettre en place, c’est que c’est ça le vrai projet. Pas le refactor.

Le résumé en une phrase

Quand un service est cassé, la première livraison ne devrait jamais être du code métier. Ça devrait être la capacité à voir où il est cassé. Le reste suit naturellement.