Livrer est devenu un événement que l'on évite plutôt le vendredi. Une erreur est corrigée, deux semaines plus tard elle est de retour – ou une autre qui lui ressemble étrangement. Votre équipe ne travaille pas moins, elle travaille simplement de plus en plus souvent aux mêmes endroits. Les nouvelles fonctionnalités reculent parce que la capacité part dans les correctifs. Et à chaque correctif, plus personne n'ose toucher à quelque chose de plus grand. La confiance dans votre propre code baisse plus vite que le nombre d'erreurs.
Ce qu'il faut faire maintenant
Les erreurs récurrentes relèvent rarement de la négligence. Elles sont un symptôme – de structures où une modification se répercute à trois autres endroits, et d'un chemin de livraison qui ne rend les ruptures visibles que chez vos clients. Traiter les tickets un à un n'y change rien.
Nous cherchons donc le motif derrière les signalements, pas le prochain bug. Ce dont dépend votre activité est sécurisé en premier ; ensuite, nous amenons les tests et la livraison assez loin pour qu'une rupture se voie avant la mise en production. Nous le faisons avec votre équipe, pas à côté d'elle : le code doit finir par vous appartenir, pas à nous.
Un coup d'œil à votre historique d'incidents et à deux ou trois endroits critiques suffit pour une évaluation honnête de la profondeur du problème. Ce que vous en faites ensuite vous appartient.