Aller au contenu principal

37. Créer de la sécurité avant de changer l'existant

Pourquoi ce chapitre existe

Dans un système peu testé ou mal observable, chaque modification ressemble à un pari. La réponse tentante est de différer tout changement jusqu'à disposer d'une couverture parfaite. Cette attente fige le système sans réduire ses risques immédiats. La bonne stratégie consiste à construire juste assez de sécurité autour du comportement que l'on doit modifier : caractériser, isoler, observer et préparer la récupération.

Les idées essentielles

  • La sécurité de changement est locale et progressive : elle s'investit d'abord autour du prochain risque réel.
  • Les tests de caractérisation capturent le comportement actuel sans prétendre dire ce qui est souhaitable à long terme.
  • Les points de couture — interfaces, adaptateurs, configurations — permettent d'isoler une zone sans réécriture globale.
  • L'observation et la récupération compensent les zones que les tests ne peuvent pas encore couvrir.

Construire une zone de travail sûre

Avant de modifier une règle opaque, établir un exemple représentatif, des invariants ou des données de référence qui décrivent ce qu'elle fait aujourd'hui. Ajouter ensuite une manière de détecter le changement en environnement contrôlé ou en production limitée. L'objectif n'est pas de connaître tout le système : il est de savoir si la zone touchée a dévié de manière dangereuse.

BesoinPremière protection possible
Règle difficile à comprendreTests de caractérisation et exemples de données
Dépendance non contrôlableAdaptateur avec contrat et comportement de repli
Données fragilesSauvegarde vérifiée, migration additive, comptes de contrôle
Effet invisibleMétrique métier, journal d'audit ou rapprochement
Déploiement inquiétantLot limité, flag, plan de désactivation et observation

Introduire des points de couture avec une intention

Un point de couture est un endroit où le comportement peut être remplacé, testé ou observé sans modifier tout le système. Il peut s'agir d'une interface vers une dépendance, d'une fonction de décision isolée ou d'une configuration explicitée. Il n'est pas une couche générique ajoutée partout : il doit réduire la difficulté précise du changement à venir.

Anti-patterns

Exiger une couverture totale avant toute amélioration

La couverture totale est rarement atteignable et peut immobiliser les corrections dont les utilisateurs ont besoin. Cibler la zone de changement, documenter les angles morts et limiter l'exposition est plus honnête et plus efficace.

Ajouter une abstraction sans mesure de sécurité

Une nouvelle interface peut rendre le code plus complexe tout en ne protégeant aucun comportement. Chaque couche doit être justifiée par une preuve qu'elle facilite : test, contrat, remplacement, observation ou séparation de responsabilité.

Corriger un legacy en production sans voie de retour

L'urgence peut imposer une intervention rapide. Elle n'annule pas le besoin de mesurer le résultat, de sauvegarder l'état ou de préparer la désactivation. Dans un système fragile, ces protections sont souvent plus importantes, pas moins.

Bonnes pratiques

Faire de la caractérisation un livrable du changement

Lorsqu'une règle inconnue doit évoluer, les exemples et tests qui la rendent explicite doivent être revus comme le code. Ils deviennent la base sur laquelle la prochaine personne pourra distinguer une régression d'une correction volontaire.

Réduire l'incertitude par étapes réversibles

Isoler une dépendance, comparer en lecture seule, écrire dans une projection, activer une cohorte puis retirer l'ancien chemin crée une séquence de décisions corrigibles. Chaque étape doit apporter une information qui justifie l'étape suivante.

Checklist — La zone legacy est-elle assez sûre pour être modifiée ?

  • Quel comportement, donnée ou effet de bord doit être protégé ?
  • Quelle caractérisation, invariant ou exemple fournit un point de départ ?
  • Où introduire un point de couture qui réduit vraiment le risque ?
  • Comment détecter une divergence avant un dommage important ?
  • Quel mécanisme limite l'exposition et permet une récupération ?
  • Quels angles morts restent assumés et comment seront-ils surveillés ?

À retenir

La sécurité dans un système existant ne vient pas d'une refonte préalable parfaite. Elle se construit autour du prochain changement par des preuves ciblées, des frontières utiles, de l'observation et des chemins de retour concrets.