Quand la recette d'un système hérité a-t-elle un sens ?

La recette n'est ni une réunion, ni une signature, ni une semaine calme après la mise en production. Un système réécrit est acceptable lorsque l'acheteur peut prouver qu'il conserve les comportements utiles à l'entreprise, explique chaque écart financier, survit à un retour arrière répété et peut être exploité sans la présence de l'équipe de réécriture.

Cette exigence paraît sévère jusqu'à l'échec d'une réécriture. Les preuves manquantes surgissent alors d'un coup : personne ne sait si un résultat différent correspond à un défaut corrigé ou à une régression, des totaux divergent de quelques centimes sur des milliers d'enregistrements, la page de retour arrière décrit des commandes que personne n'a exécutées et les ingénieurs repreneurs découvrent que le nouveau service dépend de ses auteurs sans que cela soit documenté. La recette doit révéler ces faits tant que le projet peut encore agir.

La recette commence par un contrat de preuve

Définissez la recette avant l'implémentation, car l'équipe qui écrit le nouveau système doit connaître les affirmations qu'elle devra prouver. Une exigence telle que « fonctionne comme l'ancien système » ne se teste pas. Remplacez-la par des règles observables, des jeux de données nommés, des tolérances, des approbateurs responsables et des preuves qui survivront à la décision.

Le contrat doit séparer quatre décisions que les organisations confondent souvent. La parité fonctionnelle demande si une même requête valide produit le même résultat métier. Le rapprochement financier vérifie que les écritures, soldes, taxes, arrondis et répartitions concordent au niveau exigé par la comptabilité. La recette opérationnelle vérifie que les exploitants savent déployer, superviser, restaurer et inverser le système. La recette de propriété vérifie qu'ils pourront le modifier sans danger après le départ de l'équipe de réécriture.

Chaque décision exige un responsable nommé. Le produit ou les opérations peuvent approuver les changements de comportement intentionnels. La finance fixe les tolérances financières et signe le rapprochement. Le responsable du service accepte les procédures d'exploitation et les risques résiduels. La sécurité examine les frontières de confiance et chemins d'accès modifiés. Un comité de pilotage peut recevoir ces décisions, mais ne peut pas les fabriquer en faisant la moyenne des avis.

Écrivez le contrat sous forme d'une petite matrice, pas d'un long document narratif. Pour chaque affirmation, consignez la source de preuve, la règle de réussite, le traitement des exceptions, l'approbateur et le lieu de conservation. « 99 % des cas concordent » n'est pas une règle tant que le contrat n'explique pas quel pour cent peut différer. Un seul écart dans un rapport réglementaire peut peser plus que dix mille différences d'espacement sans conséquence.

Figez le contrat de recette avec le processus normal de gestion des changements. Un cas limite découvert peut justifier une nouvelle règle, mais l'équipe ne doit pas assouplir une tolérance parce que la réécriture la rate. Consignez qui a changé la règle, pourquoi et quels résultats antérieurs deviennent invalides. Sinon, la cible bouge chaque fois que l'implémentation devient gênante.

Définissez l'environnement de recette avec la même précision. Consignez les images de système d'exploitation, extensions de base de données, données régionales, base de fuseaux horaires, réglages du courtier de messages, indicateurs de fonctionnalité et données de référence. Un résultat obtenu dans un environnement anonyme ne se reproduit pas plus tard. N'acceptez pas « proche de la production » comme description. Donnez un identifiant à l'environnement et ajoutez l'empreinte de sa configuration à chaque dossier de preuve.

La performance entre dans le contrat quand le temps modifie le résultat métier. Fixez la charge, la concurrence, le volume de données, le préchauffage et les règles de percentile à la vraie frontière. Un traitement nocturne qui livre les bons totaux après l'heure limite matinale du système aval a échoué. Même verdict pour une interaction si lente que l'appelant réessaie et crée des doublons. Gardez les preuves de performance séparées de la parité fonctionnelle, car l'une n'excuse pas l'autre.

Le contrat a aussi besoin d'un non-objectif explicite : la nouvelle architecture ne doit pas ressembler à l'ancienne. Parité comportementale et parité d'implémentation sont deux affirmations différentes. Reproduire l'organisation d'un batch COBOL dans un service Go peut conserver une structure accidentelle tout en rendant le nouveau système plus difficile à reprendre. Recettez le comportement observable aux frontières stables, puis jugez les nouveaux composants internes selon les pratiques d'ingénierie actuelles.

Le trafic de production enregistré est une preuve, pas une suite complète

Le trafic de production enregistré fournit le meilleur échantillon disponible de ce que font réellement les appelants, mais il ne prouve que le comportement présent pendant la période d'enregistrement. Utilisez la relecture comme vaste corpus de caractérisation, puis ajoutez les chemins rares, destructifs, saisonniers et juridiquement sensibles absents de l'échantillon.

Dans Working Effectively with Legacy Code, Michael Feathers présente les tests de caractérisation comme des tests qui décrivent ce que fait actuellement un système. L'idée convient bien à une réécriture, car l'ancienne implémentation est souvent la dernière spécification précise. J'y apporte une réserve importante : la sortie enregistrée prouve le comportement actuel, pas son exactitude.

Capturez les requêtes à une frontière qui a un sens métier. Une passerelle HTTP peut convenir à un monolithe web. Ailleurs, la vraie frontière sera un sujet de messages, une entrée batch, une transaction de terminal, un dépôt de fichier, un appel de procédure stockée ou une invocation de contrôle de travaux. Capturez assez de contexte pour reproduire le routage, la classe d'autorisation, la langue, la date métier effective et l'état fonctionnel pertinent. Ne collectez pas des secrets simplement parce qu'ils sont accessibles. Tokenisez les identifiants de compte, retirez les informations d'authentification et ne gardez une table contrôlée que si la relecture exige une identité stable entre appels.

Chaque cas capturé a besoin d'un identifiant immuable et d'une provenance. Conservez au minimum la version du système source, l'heure de capture, la forme de la requête, l'instantané d'état choisi, les sorties observables attendues et la transformation d'assainissement. Calculez l'empreinte de la capture originale et du scénario normalisé. Un examinateur peut ainsi déterminer si le test ou le système a changé.

Une enveloppe de scénario utile ressemble à ceci :

{
  "case_id": "close-004812",
  "captured_at": "2026-03-31T23:58:14Z",
  "business_date": "2026-03-31",
  "request": {"operation": "post_invoice", "invoice_ref": "TKN-8821"},
  "state_snapshot": "sha256:7d3f...",
  "expected": {
    "status": "posted",
    "ledger_delta_minor": 18425,
    "events": ["invoice.posted"]
  }
}

Le scénario stocke l'argent en unités mineures, car la virgule flottante binaire constitue une mauvaise frontière de recette. Il nomme l'événement sans exiger un identifiant de message ou un horodatage identique. Ces champs volatils relèvent de la politique de comparaison.

Les échantillons de production ont des angles morts prévisibles. Les clôtures mensuelle et annuelle peuvent manquer la fenêtre. Les reprises peuvent masquer les chemins d'erreur. Les administrateurs effectuent parfois de rares corrections dans une interface distincte. Une capture peut ne contenir aucune date bissextile, fichier vide, longueur maximale, message dupliqué, annulation, expiration après validation ou lot partiellement écrit. Ajoutez des cas tirés des procédures, incidents, tickets de support et contraintes de schéma. Demandez aux personnes qui clôturent les comptes quelles entrées les inquiètent. Elles savent généralement où le code ment.

La relecture ne doit pas reproduire les effets externes. Dirigez courriels, paiements, transferts de fichiers et messages aval vers des doublures déterministes ou des points de test isolés. Si une requête ne peut être rendue inoffensive, comparez-la dans un chemin fantôme qui bloque les validations. Un harnais de relecture capable de facturer un client n'est pas un outil de recette.

La parité exige une politique de comparaison explicite

Deux sorties méritent rarement une comparaison brute octet par octet. Définissez donc avant l'exécution du corpus quelles différences ont un sens métier. La politique normalise les champs volatils, compare exactement les champs significatifs et classe chaque écart restant sans le cacher.

Commencez par tout le résultat observable : réponse, modifications de base, messages émis, fichiers, journaux nécessaires à l'audit et comportement temporel visible. Une réécriture peut renvoyer le même JSON tout en omettant une écriture comptable. Elle peut écrire les bonnes lignes mais émettre des événements dans un ordre qui casse un consommateur. Comparer seulement la surface la plus facile crée une confiance trompeuse.

La normalisation doit rester étroite et vérifiable. Remplacez les identifiants générés uniquement si leur identité n'a aucun sens en aval. Réduisez les horodatages à une précision convenue seulement si l'ordre inférieur n'importe pas. Triez les collections uniquement si le contrat dit que l'ordre n'est pas observable. Ne retirez jamais un champ de la comparaison parce qu'il change souvent. Décidez d'abord si les appelants en dépendent, puis consignez la règle.

Le harnais doit produire un résultat compréhensible sans lecture de son code source :

{
  "case_id": "close-004812",
  "result": "FAIL",
  "comparisons": [
    {"path": "$.status", "expected": "posted", "actual": "posted", "rule": "exact"},
    {"path": "$.ledger_delta_minor", "expected": 18425, "actual": 18424, "rule": "exact"},
    {"path": "$.processed_at", "expected": "<timestamp>", "actual": "<timestamp>", "rule": "normalized"}
  ]
}

Conservez quatre résultats : réussite, changement attendu, défaut connu et écart inexpliqué. « Assez proche » n'est pas un résultat. Un changement attendu renvoie à une décision approuvée et à son nouveau test. Un défaut connu renvoie à un responsable et à son traitement. Un écart inexpliqué bloque l'affirmation concernée.

Mesurez la couverture par dimensions métier plutôt que par nombre de cas. Étiquetez les cas par opération, catégorie de compte ou de client, canal d'entrée, chemin d'autorisation, devise, limite de date, classe d'erreur et type d'effet externe lorsque ces dimensions s'appliquent. Signalez ensuite les intersections vides. Dix mille consultations de facture ne compensent aucune annulation d'avoir.

Exécutez l'ancien et le nouveau système depuis un état initial contrôlé. S'ils partagent un état mutable, le premier passage peut changer les conditions du second. Restaurez un instantané ou utilisez des copies isolées. Figez si possible horloges, graines aléatoires, tables de change et configuration. Si l'ancien système lit une source externe mutable, capturez sa réponse dans le cas.

N'utilisez pas la nouvelle implémentation pour fabriquer ses propres résultats attendus. J'ai vu des équipes relire le trafic dans la réécriture, approuver la sortie à l'œil et l'enregistrer comme référence. Cela vérifie la répétabilité, pas la parité. L'oracle doit venir de l'ancien système, d'une règle métier approuvée indépendamment ou de comptes rapprochés.

Rapprochez l'argent à la frontière comptable

La recette financière exige une égalité exacte à la frontière comptable et une explication documentée de chaque différence voulue. Des totaux agrégés ne révèlent ni des erreurs qui se compensent, ni des doublons, ni de mauvaises dates, ni des montants corrects affectés aux mauvais comptes.

Comparez l'argent dans la représentation utilisée par la règle métier. Si la source stocke des centimes entiers, comparez des centimes entiers. Si elle utilise des décimaux fixes avec une échelle par devise, conservez ces échelles dans le harnais. Ne faites pas passer les calculs de recette par des tableurs qui convertissent silencieusement les types ou affichent des arrondis tout en gardant d'autres nombres dessous.

Rapprochez par couches. Comparez d'abord le nombre de transactions et les identifiants métier uniques. Comparez ensuite chaque ligne selon l'entité, le compte, la devise, la date d'effet, le sens débit ou crédit et le montant. Après l'accord ligne par ligne, comparez les totaux de contrôle selon les dimensions utilisées par la finance. Comparez enfin soldes et rapports obtenus. Chaque couche détecte une panne différente et réduit la zone de recherche.

Une anti-jointure révèle les écritures manquantes ou supplémentaires, et un regroupement révèle les écarts de montant. Adaptez cette requête Postgres à la vraie identité métier plutôt que d'inventer un numéro de ligne :

WITH old_totals AS (
  SELECT entity_id, account_code, currency, effective_date,
         SUM(amount_minor) AS amount_minor, COUNT(*) AS line_count
  FROM old_postings
  GROUP BY entity_id, account_code, currency, effective_date
),
new_totals AS (
  SELECT entity_id, account_code, currency, effective_date,
         SUM(amount_minor) AS amount_minor, COUNT(*) AS line_count
  FROM new_postings
  GROUP BY entity_id, account_code, currency, effective_date
)
SELECT COALESCE(o.entity_id, n.entity_id) AS entity_id,
       COALESCE(o.account_code, n.account_code) AS account_code,
       COALESCE(o.currency, n.currency) AS currency,
       COALESCE(o.effective_date, n.effective_date) AS effective_date,
       o.amount_minor AS old_amount, n.amount_minor AS new_amount,
       o.line_count AS old_lines, n.line_count AS new_lines
FROM old_totals o
FULL OUTER JOIN new_totals n USING (entity_id, account_code, currency, effective_date)
WHERE o.amount_minor IS DISTINCT FROM n.amount_minor
   OR o.line_count IS DISTINCT FROM n.line_count;

La sortie attendue est zéro ligne pour les dimensions déclarées exactes. Si la finance permet une tolérance sur une répartition dérivée, encodez cette exception par règle et catégorie de compte. N'appliquez jamais une tolérance globale. Un centime d'écart sur chacune d'un million d'écritures n'est pas une petite erreur, et un écart net nul peut cacher deux affectations aux mauvais comptes.

L'arrondi mérite ses propres cas. Précisez si la règle arrondit au supérieur, au pair, tronque ou suit une méthode propre à la devise, et à quelle étape. round(sum(x), 2) et sum(round(x, 2)) peuvent diverger. L'ancien programme peut conserver les fractions pendant la répartition puis affecter le reliquat à une ligne désignée. La réécriture doit reproduire ce résultat sauf approbation d'une nouvelle politique par la finance.

La preuve de rapprochement doit inclure l'identifiant de l'instantané d'entrée, la version de la requête ou du programme, les nombres de lignes, lignes sans correspondance, différences groupées, totaux de rapport, identité de l'exécutant et approbation. Stockez l'ensemble réel des exceptions, pas la capture d'un résumé vert. La finance doit pouvoir remonter d'un total affiché aux écritures sans demander à l'équipe de migration de reconstruire l'exécution.

La parité ne naturalise pas tous les anciens défauts

Un ancien résultat qui surprend le métier exige une classification, pas une conservation automatique. La recette doit distinguer comportement requis, toléré, accidentel et interdit, puis rattacher une décision à chaque divergence.

Le comportement requis couvre les calculs contractuels, formats consommés par d'autres systèmes, processus approuvés et contrôles. Un comportement toléré peut sembler étrange mais rester utilisé, comme l'acceptation d'un identifiant ancien précédé d'espaces. Un comportement accidentel n'a aucun consommateur connu et contredit la règle voulue. Un comportement interdit enfreint une politique actuelle ou crée un risque de sécurité, juridique ou comptable inacceptable.

Les équipes disent souvent qu'une réécriture permet de tout nettoyer. Le conseil plaît parce que les défauts deviennent visibles et que le nouveau code paraît facile à modifier. C'est une mauvaise stratégie de recette. Mélanger des changements de comportement à un changement de plateforme rend chaque écart ambigu et agrandit le problème de retour arrière. Conservez le comportement requis, isolez les corrections approuvées derrière des décisions explicites et remettez le nettoyage sans rapport après l'établissement d'une base opérationnelle stable.

Pour chaque changement voulu, conservez l'ancien cas, marquez son ancienne sortie, citez le responsable qui approuve et ajoutez la nouvelle sortie attendue. Le rapport de parité peut afficher « changement attendu » au lieu de prétendre que le cas réussit. Les responsables aval doivent confirmer qu'ils acceptent le contrat modifié. Une correction de taxe reste une rupture si un importateur de rapports attend les anciens champs.

Certaines corrections de sécurité ne peuvent pas attendre. Si l'ancien système révèle des données à un rôle non autorisé ou accepte une entrée dangereuse, ne reproduisez pas cela pour verdir le rapport. Consignez l'écart comme changement de contrôle requis, testez le refus et le chemin permis, puis assurez-vous que le retour arrière ne réintroduit pas l'exposition sans décision explicite sur le risque.

Cette classification évite aussi la translittération silencieuse. Une équipe peut préserver le comportement externe requis tout en remplaçant des tables de préparation batch par des files durables, en découpant un monolithe par responsabilité métier ou en plaçant les calculs dans un noyau numérique Rust. La recette doit observer des contrats stables et leurs effets. Elle ne doit pas forcer la nouvelle conception à copier des structures mortes invisibles aux appelants.

Le journal de décisions doit rester lisible. Une ligne par différence significative vaut mieux qu'un document par scénario. Incluez les identifiants concernés, ancien et nouveau comportements, motif, approbateur, impact aval, traitement au retour arrière et date. Si des centaines d'entrées inexpliquées s'accumulent, la réécriture n'est pas acceptable parce que quelqu'un les a renommées « différences connues ».

Une répétition du retour arrière doit modifier l'état réel

Un retour arrière ne devient crédible qu'après son exécution par l'équipe d'exploitation sur un déploiement comparable à la production, la restauration de l'état de référence et la preuve que le traitement reprend sans perte ni doublon. Lire un mode opératoire à voix haute ne teste ni permissions, artefacts, horloges, files, ni coordination humaine.

Choisissez l'unité de retour avant le lancement. Ce peut être tout un service, une part du trafic, une cohorte de clients, une famille de tâches ou un chemin de lecture. Définissez le dernier point de décision sûr et la transition d'état lorsque le trafic revient. La question difficile concerne les données : après des écritures du nouveau système, l'ancien sait-il les lire, peut-il les rejouer, ou faut-il arrêter le déploiement avant toute écriture incompatible ?

La double écriture est souvent proposée comme assurance. Elle peut aider, mais ajoute un troisième comportement à tester : comment récupérer si une écriture réussit et l'autre échoue ? Sans règles claires d'ordre, reprise et idempotence, elle augmente l'ambiguïté pendant un incident. Un journal durable des changements avec un chemin de relecture testé se raisonne souvent plus facilement que deux validations synchrones qui se prétendent une transaction.

Répétez avec les mêmes identités et contrôles qu'en production. L'ingénieur d'astreinte, pas l'auteur de l'automatisation, doit lancer l'opération. La sécurité ne doit pas accorder de droits généraux temporaires pour faire réussir l'exercice. Récupérez l'ancien artefact épinglé dans le vrai registre, appliquez le changement réel de routage, restaurez ou rejouez l'état et passez des transactions de contrôle dans le chemin récupéré.

Un bon relevé de répétition contient cinq faits :

1. Le déclencheur et la personne autorisée à décider le retour.
2. Les identifiants exacts des artefacts déployé et restauré.
3. La dernière transaction confirmée avant bascule et la première après reprise.
4. Le résultat du rapprochement sur l'intervalle de transition.
5. Le temps de reprise mesuré et toute intervention manuelle.

Injectez une complication réaliste. Laissez un message en vol, retardez un service dépendant, changez d'équipe opératrice ou faites écrire au nouveau schéma une donnée à annuler. L'objectif n'est pas le spectacle. La complication teste la frontière où les procédures bien rangées échouent d'habitude.

Après le retour du trafic, prouvez davantage que la santé des points d'accès. Comparez profondeur des files, tâches planifiées, totaux de contrôle, résultats d'autorisation et accusés aval. Vérifiez que les reprises n'ont rien dupliqué et que les caches ne servent pas encore des données du nouveau système au chemin restauré. Gardez le dossier avec les horodatages des systèmes concernés, pas avec un récit reconstruit après coup.

Si un retour complet devient impossible après un point de migration, appelez le plan par son nom : reprise en avançant. Définissez comment l'équipe désactive le chemin défaillant, répare l'état et déploie une correction. L'approbation peut rester rationnelle, mais personne ne doit signer une capacité de retour que le modèle de données rend fausse.

La passation prouve la propriété par l'action autonome

Les ingénieurs possèdent le système réécrit lorsqu'ils savent l'expliquer, l'exploiter, le diagnostiquer, le modifier, le déployer et le récupérer sans aide privilégiée de ses auteurs. Un dossier documentaire alimente la passation, mais ne prouve pas sa réussite.

L'équipe repreneuse doit effectuer les tâches de recette. Faites-lui suivre une requête de production à travers service, file, base et événement émis. Faites-lui diagnostiquer une panne injectée avec la télémétrie fournie. Demandez-lui de changer une petite règle métier, adapter son test, réussir le build, déployer dans un environnement contrôlé et annuler le changement. Laissez-la ensuite exécuter la répétition du retour et rapprocher les transactions touchées.

Ces exercices exposent vite les connaissances manquantes. Si l'équipe ne peut expliquer une normalisation de parité, elle ne possède pas la politique de comparaison. Si seul le prestataire peut régénérer un client ou renouveler un secret de signature, elle ne possède pas le build. Si le déploiement exige un compte absent de l'inventaire d'accès, elle ne possède pas l'exploitation.

Le dossier de passation doit contenir des artefacts exécutables et vérifiables :

• Dépôts sources avec fichiers de build, versions verrouillées, instructions de code généré et règles de propriété.
• Décisions d'architecture, contrats d'interface, modèles de données, hypothèses de menace et journal des différences.
• Procédures de déploiement, retour, sauvegarde, restauration, migration, rapprochement et incident avec commandes exactes.
• Tableaux de bord, alertes, objectifs de service, définition des champs de journal et requêtes de diagnostic connues.
• Inventaire des accès, rotation des secrets, licences, limites de support et risques non résolus.

Épinglez les versions d'outils et vérifiez un build propre dans un environnement contrôlé par l'organisation repreneuse. Archivez compilateurs et générateurs requis quand les licences le permettent. Un build qui ne passe que sur le poste d'un auteur reste inachevé. L'équipe doit aussi savoir quels artefacts générés vont dans le contrôle de source et lesquels doivent être recréés, avec la commande et le chemin de sortie prévu.

CodeHero rattache le comportement à l'original avec un harnais de parité sur le trafic de production enregistré tout en modernisant l'architecture. Ce harnais doit rejoindre la suite permanente de régression du client, pas devenir un accessoire jetable du projet. En environnement réglementé, une installation isolée dans le périmètre client modifie l'inventaire de passation : artefacts de modèle, propriété du matériel, procédure de mise à jour, contrôles d'accès et export des preuves ont besoin de responsables nommés.

La propriété a aussi un volet commercial. Listez chaque dépendance envers l'équipe de réécriture : service de build hébergé, paquet privé, licence, identifiant de déploiement, destination d'alerte, artefact de modèle ou approbation non documentée. Supprimez-la, transférez-la ou acceptez-la explicitement. « Appelez-nous si ça casse » peut être un contrat de support, pas un substitut à la propriété technique.

Terminez par une présentation inversée. Les ingénieurs repreneurs expliquent à l'équipe de réécriture l'architecture, les plus grands risques opérationnels, la frontière de retour, les exceptions de parité et les premières actions d'incident. Les malentendus apparaissent lorsque les nouveaux propriétaires doivent réenseigner le système. Transformez les lacunes en actions de recette avec responsables et dates.

La signature doit être une décision reproductible

La signature finale doit identifier la version exacte, les preuves, exceptions acceptées, risques résiduels et personnes responsables de chaque décision. Une personne absente doit pouvoir reconstruire pourquoi l'organisation a accepté le système et relancer les contrôles importants.

Créez un index de recette immuable. Il pointe vers les identifiants de commit source et cible, empreintes des artefacts, version du corpus, version de la politique, rapport de parité, dossier de rapprochement, examen de sécurité, preuve de performance, relevé de répétition du retour, résultats de passation, journal de décisions et registre des risques ouverts. Signez ou calculez l'empreinte de l'index et conservez-le selon la politique interne.

Ne laissez pas un pourcentage unique gouverner la décision. Rapportez les résultats par affirmation et dimension métier. Donnez le nombre de cas réussis, modifiés avec approbation, associés à un défaut connu ou inexpliqués, mais joignez l'ensemble réel. Pour les contrôles financiers, donnez lignes et montants exacts sans correspondance. Pour l'exploitation, joignez le résultat de répétition et ses écarts. Pour la propriété, listez les tâches réalisées par l'équipe repreneuse et les lacunes trouvées.

Le risque résiduel appartient au dossier de recette, pas au compte rendu d'une réunion. Décrivez la condition, l'impact, la méthode de détection, le confinement, le responsable et l'échéance ou date de révision. Un risque accepté a une personne responsable et une réponse opérationnelle. Une réserve sans propriétaire reste un travail inachevé.

Fixez des conditions d'expiration aux preuves périssables. Une nouvelle version, règle de normalisation, modification de schéma, nouveau canal de production ou changement de politique comptable peut invalider une partie de la recette. L'index doit préciser les contrôles à rejouer. La recette porte sur un système identifié dans des conditions identifiées, pas sur toute future version portant le même nom.

Gardez une barrière de lancement étroite. Aucun écart inexpliqué ne peut toucher un comportement requis. Le rapprochement doit respecter les règles approuvées par la finance. Le chemin de retour ou de correction en avançant doit avoir été exécuté. L'équipe repreneuse doit terminer les exercices de propriété. Toute exception exige un responsable autorisé à en accepter les conséquences.

Je refuserais une réécriture au code magnifique mais aux preuves faibles. J'en accepterais une avec une courte liste explicite de défauts si les comportements requis concordent, les comptes se rapprochent, la reprise fonctionne et les ingénieurs d'astreinte savent modifier le système seuls. La signature enregistre alors une décision déjà prouvée par les machines, les comptes et la pratique humaine.