Une cliente habite Paris et commande un cadeau pour sa sœur, à Lyon. Le colis doit partir à Lyon. La facture doit porter les coordonnées de la cliente, à Paris.
La boutique de cet exemple est fictive. Son logiciel ne conserve qu’une adresse par commande. L’étiquette du colis et la facture sont produites à partir de cette même donnée.
| Adresse enregistrée | Étiquette du colis | Facture |
|---|---|---|
| Paris | Paris, mauvaise destination | Paris, conforme à la demande |
| Lyon | Lyon, bonne destination | Lyon, mauvaises coordonnées |
Aucune valeur ne satisfait les deux demandes. Le problème existe avant le premier changement de code. L’ajout d’un champ dans le formulaire ne le résoudra que si le logiciel apprend aussi à distinguer les deux usages.
Le deuxième champ existe, mais la facture lit toujours le premier
Le développeur ajoute une adresse de facturation. La commande contient maintenant Lyon pour la livraison et Paris pour la facture. Le formulaire est correct, les deux valeurs sont enregistrées.
À l’impression, la facture indique encore Lyon. Le programme qui la produit lit toujours le champ historique. Il n’a aucun moyen de deviner qu’un second champ vient de changer la signification du premier.
La correction consiste à faire lire Paris au programme de facturation, tout en laissant Lyon à celui qui prépare les colis. L’export comptable utilise lui aussi l’adresse historique. Il faut le modifier séparément, sinon le PDF et l’export décriront la même commande avec des coordonnées différentes.
Nous avons déjà trois modifications derrière la demande « ajouter une adresse » : enregistrer la nouvelle valeur, l’utiliser sur la facture et l’utiliser dans l’export. L’étiquette de livraison doit, elle, conserver son comportement. Le temps passé à retrouver ces lectures dans le logiciel est une partie du coût que la maquette ne montre pas.
Les anciennes commandes n’ont pas la nouvelle donnée
La nouvelle version sait traiter les commandes créées avec deux adresses. Une commande passée la veille n’en possède toujours qu’une. Si le programme de facturation exige le nouveau champ, rééditer sa facture échoue.
Dans cet exemple, la règle de reprise est la suivante : en l’absence d’adresse de facturation, utiliser l’adresse enregistrée sur la commande ancienne. Cette règle préserve son comportement antérieur. Elle ne reconstitue pas une adresse différente qui n’aurait jamais été enregistrée.
Reste le déménagement de la cliente. Si une réédition va chercher l’adresse actuelle dans sa fiche, une facture de janvier peut changer en octobre. Le document doit donc retrouver les coordonnées conservées pour cette vente, indépendamment de celles utilisées pour les prochaines commandes.
Un test limité à la nouvelle commande cadeau laisserait passer ces deux défauts. Le coût de la reprise vient aussi des ventes déjà présentes dans le système.
Quatre commandes suffisent à rendre la discussion précise
Avant d’estimer la reprise, l’équipe peut fixer quatre cas et les résultats attendus. Pour cette boutique, la liste tient dans un tableau.
| Cas à vérifier | Résultat attendu |
|---|---|
| Achat pour soi | Colis et facture à la même adresse |
| Cadeau Paris → Lyon | Colis à Lyon, facture à Paris |
| Commande ancienne | Facture rééditée avec les coordonnées conservées |
| Cliente qui déménage | Facture ancienne inchangée |
Une recrue peut exécuter ces cas et comparer les documents obtenus. Elle n’a plus besoin de deviner ce que signifie « ne pas casser les anciennes commandes ». Les tests automatisés peuvent reprendre ces mêmes cas, avec une vérification de l’export comptable.
Cela ne dispense pas d’examiner le code. Cela évite au moins que chaque développeur doive redécouvrir, par une conversation ou un incident, ce que l’équipe entend préserver.
Ce qui permet de terminer la reprise
Le chantier peut être considéré comme terminé lorsque les quatre cas passent, que le PDF et l’export concordent, et que l’impression du colis utilise toujours l’adresse de livraison. Aucune de ces vérifications ne demande de reconstruire le catalogue des produits ou le paiement.
Cette limite distingue une reprise ciblée d’une réécriture générale. Elle permet aussi de refuser une fausse fin de chantier : deux champs visibles dans le formulaire, mais un export encore branché sur l’ancien.
La prochaine demande de livraison disposera alors d’une donnée identifiée et de cas de vérification. Elle pourra introduire d’autres difficultés, mais la séparation entre le destinataire du colis et celui de la facture n’aura plus à être inventée.
Chez Gridky, l’ampleur des incidents nous a conduits à un chantier plus large, raconté dans le Drynuary. L’article sur les cinq visages de la dette technique distingue cette difficulté dans le code des attentes produites par l’organisation.