TDD — Typo Driven Debugging

Vous connaissez sûrement TDD, le vénérable Test Driven Development. Celui qu’on met dans les CV pour montrer qu’on fait les choses “dans les règles”. Mais il existe un autre TDD. Moins académique. Moins glorieux. Et pourtant… redoutablement efficace dans certains cas.

Nous vous présentons : Typo Driven Debugging. Oui, une simple typo. Une bête faute de frappe. Le genre de truc que d’habitude on traque comme la peste. Mais cette fois-ci, c’est elle qui a tout changé.

📉 L’alerte : “On va dans le mur”

Comme tous les bons incidents, tout commence par une journée où nous faisons un petit check des métriques, histoire de. Nous utilisons Supabase avec une instance PostgreSQL managée par Supabase, et nous avons ajouté une stack d’observabilité autour (Prometheus + Grafana), parce que bon… même un SaaS, il faut le surveiller.

Et là : boum. L’espace disque système se fait siphonner. Les I/O explosent, le CPU monte en flèche, la RAM chauffe, et Postgres commence à écrire de la swap comme s’il essayait de miner des bitcoins. Bref, ça sent pas bon.

👀 Première règle : toujours regarder ce que fait la base

Nous nous connectons et listons les sessions SQL actives. Et nous tombons sur plusieurs requêtes ouvertes depuis plus de 36 heures. Pas des petites requêtes de rien du tout. Non, des SELECT bien costauds, avec des CASE, du ::text, et surtout, ce petit détail qui change tout : un champ nommé camapgne_nom.

Oui. C-A-M-A-P-G-N-E. Une typo. Une faute de frappe. Qui ne devrait pas exister. Et c’est grâce à cette erreur que nous avons retrouvé la vue SQL fautive. Sans elle, nous aurions probablement galéré des heures à croiser logs, sessions, vues, code frontend… Là, nous avons eu la lumière.

🀰 L’effet domino : perf, coût, disponibilité

Ce n’est pas qu’une histoire de requêtes qui traînent. C’est bien plus vicieux que ça.

1. Pression sur les ressources : Une requête SQL bloquée (ou inefficace) dans Supabase continue de consommer. Les sessions restent ouvertes, Postgres écrit des fichiers temporaires, et les I/O disques deviennent un champ de bataille. Et comme c’est du managé, on ne voit pas toujours ce que Postgres fait… sauf si on a une stack d’observabilité à côté (spoiler : nous en avions une, heureusement).

2. Effet cliquet sur le pricing : Supabase, dans sa grande bonté, ne bloque pas directement votre instance (c’est bien). En revanche, quand la consommation dépasse les quotas de l’offre actuelle, ils vous migrent automatiquement vers l’offre du dessus. Et pas de retour automatique en arrière. Même si la charge redescend, le tarif reste. Donc si vous ne réagissez pas vite : vous payez.

3. Disponibilité de l’app : Si l’espace disque se sature complètement, l’instance Supabase devient indisponible. Notre appli frontend ? En PLS. Nos APIs ? Timeout. Et pour les utilisateurs ? De la frustration !

🙃 Leçon n°1 : La stack d’observabilité, c’est pas du luxe

Nous le redisons : même sur du SaaS managé, il est primordial d’avoir une vraie stack d’observabilité. Nous avons branché Prometheus sur les métriques exposées par Supabase, avec des dashboards Grafana qui remontent les I/O, le CPU, l’espace disque, etc. C’est ce qui nous a permis de détecter l’incident avant que Supabase ne coupe ou ne scale de force. Sans ça ? La prod serait tombée, et la facture aurait bien piqué.

🙃 Leçon n°2 : Tuer les requêtes, ça soulage (immédiatement)

Une fois les sessions problématiques identifiées, nous avons balancé un petit pg_terminate_backend(pid) sur les coupables. Résultat ? L’espace disque s’est libéré en quelques secondes. Comme quoi, parfois, un bon gros KILL SQL, c’est thérapeutique.

(Et oui, nous avons aussi fixé la vue SQL fautive, pour éviter que ça ne se reproduise.)

🙃 Leçon n°3 : La typo, cette héroïne insoupçonnée

Le plus drôle dans tout ça ? C’est que sans cette typo (camapgne_nom au lieu de campagne_nom), nous n’aurions probablement jamais trouvé la vue fautive aussi vite.

C’est en recherchant ce champ “bizarre” que nous avons remonté la piste, testé les vues concernées, reproduit le bug, et identifié la source exacte du problème. Une faute de frappe nous a sauvé plusieurs heures de debug, de downtime et d’argent. Comme quoi… des fois, la dette technique, elle vous rend service.

---

🎯 Conclusion : TDD, à appliquer avec modération

Ce Typo Driven Debugging, évidemment, ce n’est pas une méthode que nous vous recommandons pour vos process internes 😅. Mais il a eu le mérite de nous rappeler plusieurs choses :

• Avoir une stack d’observabilité, même (et surtout) en SaaS, c’est vital.
• Les effets de bord d’un bug SQL, surtout côté perf, peuvent être dramatiques.
• Et parfois, ce sont les petits accidents qui vous montrent le chemin vers la solution.

Alors oui, le vrai TDD (celui avec les tests) reste une bonne idée. Mais parfois… une bête faute de frappe peut vous sauver la vie.

Merci à Michaël Perrin à qui l’on doit l’excellent jeu de mot sur le TDD 😎