Chez Gridky, un mois et demi sans nouvelles fonctionnalités

Chaque matin chez Gridky, je dédoublonnais à la main les exceptions qui arrivaient dans Slack. Il y en avait des centaines par jour. Plusieurs messages pouvaient correspondre au même défaut. Il fallait retrouver les répétitions avant de choisir les corrections.

L’équipe était séparée en deux : une partie traitait les incidents et les correctifs, le run, pendant que l’autre développait les fonctionnalités, le build. Les demandes d’un client prioritaire continuaient d’arriver avec une forte pression sur les livraisons.

Le Drynuary a suspendu les nouvelles fonctionnalités pour consacrer toute l’équipe à la stabilisation. Prévu pour un mois, il en a duré un et demi.

La séparation run/build permettait de répondre aux bugs tout en continuant les fonctionnalités. Elle avait un coût visible dans la répartition du travail : les développeurs affectés aux incidents n’étaient pas disponibles pour le reste du produit.

Le tri des exceptions ajoutait une tâche récurrente. Le monitoring envoyait les messages, mais nous manquions de temps et d’outillage pour exploiter ce volume facilement. Mon dédoublonnage aidait à choisir les corrections du jour, sans empêcher les erreurs de revenir tant que leurs causes restaient présentes.

La cible du chantier était de pouvoir réunifier l’équipe et reprendre la roadmap métier. Une baisse du nombre de messages, à elle seule, n’aurait pas suffi à constater ce résultat.

La décision a été négociée avant le début du chantier. Notre CTO a discuté avec le CEO pour réserver un mois de roadmap à la stabilisation, aux tests et à la reprise du code existant.

Les développeurs, le produit et les commerciaux partageaient le besoin d’un produit stable. Le périmètre convenu ne prévoyait aucune nouvelle fonctionnalité pendant la pause, y compris pour le client prioritaire.

Cette règle changeait l’affectation du travail. Les développeurs qui auraient réalisé ces demandes rejoignaient les corrections. Le temps de stabilisation ne devait plus être prélevé uniquement entre deux fonctionnalités ou laissé à la partie de l’équipe déjà chargée des incidents.

Nous avons commencé par recenser les bugs et examiner la couverture de tests, encore faible. Ce travail donnait les sujets de départ du chantier et indiquait les comportements peu vérifiés.

La règle retenue s’appliquait au code modifié, y compris au code ancien. Une correction devait être accompagnée de tests. Le fait qu’une fonction ait été écrite avant cette règle ne l’en exemptait pas dès lors qu’elle était touchée.

L’application de cette règle pouvait être constatée en revue de code. Si une modification ne respectait pas les exigences, son intégration pouvait être bloquée.

Nous avions une équipe senior et convaincue du chantier. Chacun pouvait choisir le sujet qu’il souhaitait traiter dans le périmètre de stabilisation. La criticité et la fréquence des exceptions donnaient des repères pour prioriser.

Les erreurs qui revenaient souvent étaient aussi, dans plusieurs cas, rapides à corriger. Les traiter réduisait les répétitions dans le reporting. Il devenait alors plus facile de voir les autres problèmes.

J’ai participé aux corrections, au monitoring et au refactoring aux côtés des autres développeurs. L’arbitrage du calendrier appartenait au CTO et au CEO, tandis que le traitement des sujets reposait sur l’équipe. Ces contributions ne se confondent pas.

Avant le Drynuary, la transition vers Kubernetes avait déjà permis plusieurs déploiements par jour. Les corrections pouvaient donc rejoindre la production en quelques heures, parfois quelques minutes.

Le reporting servait ensuite à regarder si les exceptions concernées revenaient. Le code intégré et son effet en production pouvaient être suivis dans un délai court, au lieu d’attendre une livraison groupée plusieurs semaines plus tard.

Au terme du mois prévu, la liste des sujets n’était pas épuisée. La direction avait cependant vu davantage de tests, des fonctionnalités critiques plus stables et une diminution des exceptions dans le reporting.

Ces résultats ont permis de convenir d’une prolongation. Le chantier a finalement duré un mois et demi. La nouvelle échéance a été discutée avec la direction, au lieu d’être repoussée au fil des tickets restants.

Le changement le plus directement observable dans mon travail a été la fin du dédoublonnage manuel chaque matin. Nous avions aussi réuni l’équipe. Les bugs résiduels se corrigeaient entre deux tickets de développement.

Avant la stabilisation	Après la stabilisation
Équipe séparée entre run et build	Équipe réunifiée
Tri manuel des exceptions chaque matin	Ce tri quotidien n’était plus nécessaire
Une partie de l’équipe affectée aux correctifs	Bugs résiduels traités entre les tickets de développement

J’estime la baisse des bugs en production à environ 80 %. L’étude de cas Gridky donne un autre repère, environ 10 bugs par semaine puis 1 à 2 par mois en six mois. Ces estimations ne constituent pas une série de mesures permettant de calculer l’une à partir de l’autre. Les six mois dépassent la durée de la pause.

Les centaines d’exceptions quotidiennes sont encore un autre comptage, puisqu’un défaut peut générer plusieurs messages. Je ne les utilise donc pas pour calculer un taux de réduction des bugs. Le tableau décrit les changements d’organisation que je peux rapporter directement.

Après la reprise des fonctionnalités, les exigences de tests sont restées en vigueur. Les revues de code pouvaient toujours bloquer l’intégration d’une modification qui ne les respectait pas. L’équipe avait vu les effets de cette discipline et la maintenait.

C’est ce qui distingue ce chantier d’un stock de bugs simplement fermé avant de revenir au fonctionnement précédent. De nouveaux développements entraient à nouveau, mais le code touché restait soumis à la règle de vérification adoptée pendant la stabilisation.

Chez Gridky, nous avions obtenu un arrêt des demandes de fonctionnalités, réuni l’équipe sur les corrections et maintenu une exigence de tests après la reprise. Le résultat a été de pouvoir travailler de nouveau sur la roadmap métier sans conserver la division run/build.

Les cinq visages de la dette technique distinguent les difficultés de code, d’outillage et d’organisation qui peuvent se retrouver dans une décision de ce type.