Un plan de retour doit survivre à la première écriture

Un plan de retour n'est crédible que si l'ancien système peut recevoir les écritures du nouveau sans les perdre, les dupliquer ni les remettre dans le désordre. Rebasculer un répartiteur de charge est la partie facile. La difficulté commence avec la première commande, le premier paiement, le premier dossier, la première écriture comptable ou le premier changement d'état enregistré après la bascule.

Le retour est donc un problème de données et d'autorité, pas une fonction de déploiement. Avant la bascule, l'équipe doit savoir quel système détient l'autorité d'écriture à chaque instant, comment les écritures ultérieures reviendront dans l'ancien modèle, quels effets externes ne peuvent pas être annulés et qui peut ordonner le retour. Si ces réponses restent dans la tête de quelqu'un ou dépendent d'un code jamais exécuté, il n'existe aucun plan de retour. Il reste seulement l'espoir que le nouveau système tombe en panne avant qu'une opération importante ne survienne.

La bascule transfère l'autorité d'écriture

Une bascule sûre confie l'autorité d'écriture à un seul système à la fois. Les deux systèmes peuvent servir des lectures, comparer des résultats, consommer des événements copiés ou faire des calculs en mode fantôme. Ils ne doivent pas accepter séparément des modifications faisant autorité sur le même enregistrement métier. Deux auteurs créent des conflits qu'un changement de routage ne peut pas résoudre.

L'autorité d'écriture dépasse la connexion principale à la base de données. Un parc ancien accepte souvent des changements par fichiers batch, files de messages, écrans opérateur, tâches planifiées, transferts partenaires, procédures stockées et corrections directes du support. J'ai vu des équipes bloquer l'application web pendant qu'un traitement nocturne comptabilisait discrètement des ajustements avec un autre compte. La migration semblait stable, puis les deux grands livres ont divergé le lendemain matin.

Construisez l'inventaire des écritures autour des opérations métier, pas des tables. Pour chacune, consignez le point d'entrée, l'identité, la frontière transactionnelle, l'identifiant généré, la source de l'heure, les effets en aval et le système qui en est responsable avant et après la bascule. «Mettre à jour le client» reste trop vague. «Changer l'adresse postale, émettre l'avis de conformité et mettre le travail d'impression en file» précise assez ce que le retour doit préserver.

Le contrôle du routage a lui aussi besoin d'un seul propriétaire. Le DNS seul est un mauvais mécanisme d'urgence, car les résolveurs et les clients conservent leur cache au-delà du moment où les opérateurs pensent le changement terminé. Préférez un contrôle sur une passerelle, un proxy, un consommateur de file, un courtier de connexions ou un autre point où l'équipe peut observer la route active. Consignez la valeur courante du contrôle et la commande qui la modifie. Une capture d'écran de console ne donne pas au responsable d'incident une action reproductible.

Définissez clairement les états d'autorité: OLD_WRITES, DRAINING, NEW_WRITES et ROLLING_BACK suffisent à de nombreux systèmes. Chaque état doit autoriser un ensemble connu d'auteurs. La transition doit refuser un auteur inattendu, pas seulement le journaliser, car un avertissement découvert après le retour ne peut pas effacer une transaction.

Les conditions préalables exigent un verdict

La bascule ne doit commencer que lorsque chaque condition de retour possède un test nommé, un résultat actuel et un responsable capable d'arrêter l'opération. Un document qui dit «réplication saine» laisse place au débat pendant l'incident. Un test indiquant que la position rejouée atteint ou dépasse la position capturée, avec la requête exacte et son résultat, donne un fait à l'équipe.

Utilisez un contrat de préparation court. C'est une barrière, pas une intention:

• L'ancienne version peut lire chaque modification de schéma introduite pour la bascule.
• L'ancien système est déployé, joignable, corrigé et capable de s'authentifier auprès de ses dépendances.
• Le chemin de capture ou de réplication a traité une charge de forme comparable à la production sans dépasser le retard convenu.
• Tous les auteurs de l'inventaire respectent le contrôle d'autorité, y compris les chemins batch et opérateur.
• L'équipe a restauré une sauvegarde récente dans un environnement isolé et vérifié son démarrage.

Le dernier point révèle une substitution fréquente: la réussite d'une sauvegarde ne vaut pas réussite d'une restauration. Un traitement de sauvegarde au vert prouve que des octets ont été copiés quelque part. Il ne prouve pas que la clé de chiffrement est disponible, que l'archive est complète, que le moteur peut la lire ou que l'application démarre dessus. Conservez la commande de restauration, sa durée, la somme de contrôle et le résultat du test applicatif avec le dossier de bascule.

Capturez un point de contrôle des données juste avant le transfert d'autorité. Avec la réplication physique en continu de PostgreSQL, une équipe peut comparer la position WAL courante du primaire avec la position rejouée sur le secondaire. Le manuel PostgreSQL définit une LSN comme une position dans le journal d'écriture et précise que pg_last_wal_replay_lsn() renvoie la dernière position rejouée pendant la récupération. Une collecte minimale ressemble à ceci:

/* On the primary */
SELECT pg_current_wal_lsn();
 pg_current_wal_lsn

 7A3/91F2C6D0
(1 row)

/* On the standby */
SELECT pg_last_wal_replay_lsn();
 pg_last_wal_replay_lsn

 7A3/91F2C6D0
(1 row)

Cette valeur illustre la forme de la sortie, ce n'est pas un seuil magique. Une égalité à un instant ne prouve pas que chaque écriture métier peut être annulée, et une différence en octets ne se convertit pas directement en durée. Le contrôle établit un seul fait précis: le secondaire a rejoué le journal jusqu'à la position capturée. Vos preuves ont aussi besoin de comptages applicatifs, d'invariants et d'échantillons de dossiers qui ont du sens dans le métier.

Gardez l'ancien système chaud tant que les données ne peuvent pas revenir

L'ancien système doit rester chaud jusqu'à ce que l'équipe prouve qu'il peut ingérer chaque modification postérieure à la bascule, ou renonce officiellement au retour au profit d'une réparation en avant. Un nombre fixe de jours paraît ferme, mais ignore le volume des transactions, les tâches différées, les cycles de règlement et les changements de schéma. Fixez la période selon des conditions de sortie observables, puis ajoutez une limite calendaire pour gérer les effectifs et le coût.

«Chaud» signifie exécutable sous la pression d'un incident. L'ancienne application dispose de capacité de calcul, d'une configuration actuelle, de secrets valides, d'un accès réseau, de contrats de dépendance encore valides, d'espace de stockage, de supervision et d'opérateurs qui savent toujours s'en servir. Une machine virtuelle éteinte avec un certificat expiré est une archive. Ce n'est pas une cible de retour.

Gardez-la chaude pendant au moins un cycle métier complet susceptible de révéler un comportement différé. Ce cycle peut comprendre une comptabilisation nocturne, une limite de facturation, un fichier partenaire, un planning de fin de semaine ou une clôture de période. Ne recopiez pas une règle générique de sept ou trente jours. Un système de sinistres qui reçoit des pièces tardives et un service de caisse qui règle chaque nuit demandent des fenêtres de preuve différentes.

Les conditions de sortie doivent couvrir le comportement et la capacité de récupération. Exigez que le nouveau système termine les tâches différées, rapproche les accusés externes, respecte les limites d'erreur et de latence sous trafic réel et produise un flux de changements consommable par l'ancien système. Exigez aussi une répétition réussie du retour avec des données capturées après une bascule simulée. Si l'équipe supprime le chemin inverse, applique un changement destructeur de schéma ou laisse expirer le contrat d'une ancienne dépendance, consignez l'instant exact où le retour prend fin.

Maintenir l'ancien système chaud coûte et crée un risque. Des services non corrigés, des planificateurs en double et des identifiants actifs augmentent la surface de panne. Réduisez-la délibérément: bloquez le trafic utilisateur, désactivez chaque planificateur sauf celui nécessaire au retour testé, limitez les accès opérateur et surveillez toute tentative de connexion. Chaud ne veut pas dire abandonné en fonctionnement.

Les écritures après la bascule dictent la stratégie

Chaque écriture postérieure à la bascule doit recevoir l'un de quatre traitements: la reproduire dans l'ancien système, la conserver pour un rejeu ultérieur, compenser son effet ou reconnaître qu'elle rend le retour impossible. Réunir les quatre sous le terme «synchronisation des données» masque les décisions importantes. Le traitement dépend de la sémantique métier, surtout de l'ordre et des effets externes.

La réplication inverse fonctionne lorsque le modèle cible sait représenter le nouveau changement et que l'outil de réplication conserve les frontières transactionnelles requises. Elle devient dangereuse si le système moderne répartit une ligne ancienne dans plusieurs enregistrements, remplace un état modifiable par des événements, change la génération des identifiants ou durcit la validation. Un copieur de lignes peut livrer des données syntaxiquement valides que l'ancienne application interprète mal.

Un journal de changements uniquement complété est souvent plus facile à raisonner. Attribuez à chaque commande acceptée un identifiant d'opération immuable, une clé métier, une séquence source, une version de schéma, un acteur, une heure d'acceptation, une charge utile et un résultat. L'importateur de retour enregistre l'identifiant appliqué afin que les nouvelles tentatives ne répètent pas l'acte métier. L'idempotence se place à la frontière métier: «définir l'adresse à X» peut être rejoué, tandis que «ajouter 10 au solde» demande une identité d'opération unique et le refus des doublons.

La double écriture dans le code applicatif est populaire parce qu'elle paraît immédiate. Je la déconseille pour la plupart des bascules. La requête peut être validée dans la nouvelle base puis expirer avant sa validation dans l'ancienne, laissant l'appelant dans le doute et les systèmes divergents. Inverser l'ordre change seulement le système qui gagne la panne. Une boîte d'envoi transactionnelle ou un flux de changements de base lie la capture à la validation faisant autorité et permet à un consommateur séparé de retenter la livraison.

Certaines écritures ne doivent pas revenir automatiquement. Si le nouveau système autorise un état impossible à représenter dans l'ancien schéma, placez l'opération en quarantaine et rendez le nombre visible avant la bascule. Il en va de même lorsque les règles de validation diffèrent. Ne forcez pas la valeur, ne supprimez pas un champ et ne cachez pas un sens nouveau dans un ancien champ libre dans le seul but d'obtenir zéro au compteur de rapprochement.

Le runbook doit déplacer les données et le trafic

Un runbook de retour exécutable gèle les nouvelles écritures, établit une frontière finale, vide les changements capturés dans l'ancien modèle, vérifie l'état métier, puis seulement rend le trafic. Rebasculer le trafic d'abord permet aux utilisateurs de créer d'autres changements pendant que l'importateur rattrape son retard. La frontière continue alors de bouger pendant l'incident.

Une séquence pratique contient des arrêts explicites et des preuves:

1. Déclarer ROLLING_BACK, refuser les nouvelles requêtes de modification, suspendre les consommateurs et consigner l'heure ainsi que le dernier identifiant accepté. Les lectures peuvent continuer uniquement si elles ne déclenchent aucune écriture cachée.
2. Attendre la fin des transactions en cours ou les interrompre selon une règle documentée. Capturer la position du journal source, les offsets des files et le nombre d'entrées de journal non traitées.
3. Appliquer le flux inverse jusqu'à la frontière consignée. Arrêter si une opération n'a pas de correspondance, viole un invariant ancien ou produit une référence externe différente.
4. Exécuter les requêtes de rapprochement et des lectures métier échantillonnées sur l'ancien système. Faire passer une transaction synthétique par chaque point d'entrée critique, tout en envoyant les notifications externes vers un récepteur contrôlé.
5. Rétablir l'autorité d'écriture ancienne, relâcher progressivement le trafic, reprendre seulement les anciens planificateurs et surveiller les compteurs de doublons, de rejets et de retard.

Placez la sortie attendue à côté de chaque commande. 0 rows peut signifier un succès pour une recherche d'orphelins et un désastre pour un comptage de commandes. Indiquez le sens applicable. Gardez les procédures d'identification et d'approbation près des commandes sans inclure les secrets dans le runbook. Si l'exécutant doit chercher un chemin dans le coffre de mots de passe, nommez l'entrée et vérifiez son accès pendant la répétition.

Chronométrez chaque étape séparément. Le temps total de récupération ne suffit pas. L'équipe doit connaître la durée du gel des écritures, la vitesse à laquelle le consommateur inverse vide le volume de pointe et la validation qui domine la pause. Si 500 000 opérations prennent plus de temps à rejouer que l'entreprise ne peut le tolérer, le plan échoue même si une petite répétition passe. Testez au niveau haut attendu, avec une marge.

La compatibilité préserve le chemin du retour

Le retour dépend de la compatibilité ascendante des bases, messages, API, fichiers et mécanismes d'authentification. L'ancien binaire doit fonctionner sur l'état de la bascule. Si une migration supprime une colonne, réutilise une valeur d'énumération, modifie le sens d'un message ou renouvelle un identifiant au-delà des capacités de l'ancien client, le chemin du retour peut disparaître sans bruit.

La description du Parallel Change par Danilo Sato divise un changement incompatible en trois phases: extension, migration et contraction. Ce modèle aide parce que le retour appartient à la phase étendue, pendant laquelle les anciens et les nouveaux consommateurs fonctionnent encore. Les équipes se mettent en difficulté quand elles traitent la contraction comme du ménage et retirent l'ancien champ ou point d'accès dès que le nouveau trafic paraît sain. La contraction met volontairement fin au retour et mérite son propre dossier de changement.

Les modifications additives de schéma sont nécessaires, mais pas suffisantes. Même une colonne nullable peut casser l'ancien code si un déclencheur change, si une requête emploie des insertions positionnelles ou si une procédure stockée renvoie une nouvelle forme de résultat. Testez la vraie ancienne version sur un clone du schéma de bascule. Exercez lectures et écritures, y compris les valeurs rares, lots vides, tailles maximales de champs et chemins d'erreur.

Les messages ont aussi besoin d'une règle de compatibilité. Les consommateurs doivent ignorer les champs inconnus, mais refuser un nouveau sens caché sous un ancien nom de champ. Conservez les anciens types d'événements pendant la période chaude ou fournissez un convertisseur descendant testé. Versionnez ce convertisseur et stockez la charge utile d'origine afin qu'un opérateur puisse reproduire une correspondance contestée.

Les échecs d'authentification sont particulièrement gênants, car ils sont évitables. Conservez les anciennes identités de service, chaînes de certificats, compatibilités cryptographiques et routes réseau aussi longtemps que le retour reste possible. Testez-les depuis l'ancien environnement d'exécution, pas depuis le poste d'un administrateur.

Les effets externes demandent une compensation

Un retour ne peut pas rappeler un e-mail déjà reçu, un fichier bancaire déjà accepté, une étiquette déjà imprimée ou une instruction partenaire déjà exécutée. Ce sont des effets externes et le plan doit définir une règle pour chacun avant la bascule. La parité de la base ne les règle pas.

Attribuez une clé d'idempotence à chaque action sortante et conservez l'accusé du destinataire avec elle. Pendant le retour, l'ancien système doit apprendre quelles actions ont déjà eu lieu afin de ne pas les renvoyer. Si le destinataire accepte les requêtes idempotentes, réutilisez la même clé. Sinon, placez l'action derrière un registre interne qui refuse un second envoi.

Une compensation est une nouvelle opération métier, pas une suppression. Un paiement comptabilisé peut exiger une écriture inverse. Une instruction d'entrepôt envoyée peut demander une annulation qui peut elle-même échouer. Une notification client peut réclamer une correction rédigée par une personne. Consignez qui autorise chaque compensation, le délai et la conduite à tenir si le tiers ne peut pas annuler l'effet.

Les tâches planifiées créent un risque de doublon plus discret. Lorsque les deux parcs restent chauds, deux planificateurs peuvent sélectionner les mêmes lignes échues et émettre la même action. Le contrôle d'autorité doit couvrir les tâches aussi fermement que les requêtes HTTP. En fonctionnement normal, le planificateur inactif ne doit pouvoir obtenir ni bail ni identifiant de production. Pendant le retour, les opérateurs transfèrent le bail seulement après l'arrêt du nouveau travailleur et l'identification de son dernier élément terminé.

Rapprochez les effets par identifiant métier et accusé, pas par profondeur de file locale. Une file vide peut signifier que tout a réussi, que tout a échoué dans une file de rebut non surveillée ou qu'un filtre n'a rien sélectionné. Un rapport utile réunit actions prévues, tentatives, réponses du destinataire et compensations en une ligne par événement métier.

Une répétition doit provoquer l'échec gênant

Une répétition ne prouve le retour que si elle emploie des écritures postérieures à la bascule, casse volontairement un élément et rétablit le service avec les mêmes contrôles que l'équipe de production. Une réunion où chacun lit le runbook teste le texte. Une bascule en préproduction sans données représentatives teste le routage. Aucune ne démontre la récupération.

Utilisez un clone de forme comparable à la production ou un environnement de rejeu isolé, avec des enregistrements nettoyés et du trafic capturé. Démarrez les anciennes et nouvelles versions, activez le vrai contrôle d'autorité et chargez assez d'historique pour que migrations et index aient un comportement crédible. CodeHero utilise un banc de parité face au trafic de production enregistré lors de la réécriture des systèmes anciens. Le même corpus de trafic peut donc révéler des écarts de comportement avant la répétition du retour.

Provoquez ensuite une panne après que le nouveau système a accepté un ensemble varié d'opérations. Incluez une mise à jour arrivée deux fois, deux commandes ordonnées sur le même compte, une frontière de lot, une valeur refusée, une opération ayant un effet externe capturé dans un récepteur et une tâche active pendant le gel. Tuez le consommateur inverse à mi-chemin puis redémarrez-le. Les identifiants d'opération doivent empêcher les doublons et la frontière doit rester stable.

Un échec bien connu mérite une attention particulière. L'importateur inverse ne signale aucun retard, le trafic revient vers l'ancien système et les comptages simples concordent. Quelques heures plus tard, un partenaire refuse le fichier du jour, car le système moderne a produit des identifiants dans un format tronqué par l'ancien export. Le retour a déplacé les lignes correctement, mais perdu un comportement à la frontière du fichier. Une vraie répétition exécute l'export, l'analyse avec le contrat du destinataire et compare les identifiants de bout en bout.

Recueillez des preuves qu'une personne autre que l'auteur de la migration peut juger: identifiants acceptés, positions source et appliquée, résultats des requêtes d'invariant, nombres de doublons, correspondances en quarantaine, entrées du registre des effets externes, durée des étapes et état final d'autorité. Conservez aussi la répétition ratée. Un plan qui ne réussit qu'après une correction manuelle des données doit intégrer cette correction comme étape contrôlée ou la supprimer par un changement de code.

L'observation doit révéler la justesse métier

Les signaux de retour doivent rendre compte de la justesse métier, pas seulement de processus vivants. Un nouveau service peut répondre vite tout en attribuant des numéros de facture en double, en sautant une règle de comptabilisation ou en laissant un export définitivement en file. Les graphiques d'infrastructure aident à localiser une panne, mais disent rarement au décideur si la poursuite des écritures reste sûre.

Définissez les invariants à partir du comportement ancien avant la bascule. Un invariant peut établir que chaque paiement accepté possède une écriture comptable, chaque expédition une commande acceptée, chaque dossier clos un motif de clôture ou chaque fichier sortant un total de contrôle correspondant. Exprimez chacun comme une requête ou un rapport que les deux systèmes peuvent produire. Quand les schémas diffèrent, comparez une projection métier canonique au lieu de forcer l'égalité des tables.

La projection doit normaliser les différences sans effet sur le comportement et conserver les autres. Convertir les horodatages vers un fuseau unique avant comparaison est raisonnable. Ignorer les centimes parce qu'un système stocke des décimales et l'autre des unités mineures entières ne l'est pas. Décidez ces règles avec les responsables du dossier métier, puis versionnez-les avec le code de migration. Sinon, un ingénieur peut faire passer un résultat rouge au vert en élargissant un filtre pendant l'incident.

Les comptages ont besoin de dénominateurs et de frontières. «Douze écarts» signifie peu sans le nombre examiné, les types d'opération et l'intervalle d'acceptation. Un compteur à zéro peut aussi mentir si le travail de comparaison s'est arrêté à la partition d'hier. Chaque résultat doit indiquer frontière source, frontière cible, nombre sélectionné, nombre comparé, écarts, plus ancienne opération sans correspondance et heure de fin.

Employez des signaux de fraîcheur qui suivent le vrai chemin de rejeu. La profondeur d'une file masque une partition bloquée si les autres continuent à se vider. La présence du consommateur masque un message empoisonné qui réessaie sans fin. Rapportez la plus ancienne opération non appliquée et son âge, la dernière séquence source vue, la dernière séquence cible validée, le nombre en quarantaine, les tentatives par opération et le débit d'évacuation. Un retard stable sous trafic constant peut être sain au quotidien, mais condamner un retour qui doit atteindre zéro pendant le gel.

L'échantillonnage reste nécessaire parce que les invariants ne codent pas toutes les règles anciennes insolites. Sélectionnez les dossiers par critères déterministes pour que répétition et bascule de production examinent des cas comparables: plus grosses transactions, champs à leur taille maximale, dossiers rouverts, paiements annulés, devises non standard et opérations traversant une limite de date. Incluez le résultat métier et le document produit, pas seulement la ligne stockée. Une facture équilibrée dans la base mais rendue sans identifiant fiscal présente un écart de comportement.

Les alertes doivent correspondre directement aux décisions déclarées. Une violation d'invariant peut geler immédiatement les écritures. L'âge croissant du rejeu peut lancer un compte à rebours. Un bref pic de latence peut appeler une observation sans retour. Écrivez cette correspondance avant la bascule et joignez-la à l'alerte. Pendant un incident, une alerte nommée «migration défaillante» déclenche seulement un débat sur le sens de défaillante.

Conservez la télémétrie après la fin de la période chaude. Elle explique pourquoi l'équipe a retiré le chemin de retour et donne une référence fiable à la réparation en avant. Le dossier final doit montrer que les travaux différés ont fini, que les frontières de comparaison ont dépassé le cycle métier convenu, que les quarantaines sont résolues et qu'aucun effet externe inexpliqué ne reste. Cette preuve vaut mieux qu'un compte rendu disant que la migration semblait bonne.

Rendez le travail de comparaison indépendant de la route qu'il juge. Si la connexion à la base, le cache ou le code de sérialisation de la nouvelle application alimente aussi le vérificateur, un défaut peut corrompre à la fois le résultat et son contrôle supposé. Exécutez les rapprochements importants par un lecteur déployé séparément avec des droits limités, puis conservez la requête et la somme de contrôle du résultat dans le dossier. L'indépendance n'exige pas une seconde plateforme, mais un chemin de panne qui ne peut pas s'approuver silencieusement lui-même.

Testez aussi l'absence de télémétrie comme une panne. Arrêtez le consommateur du journal, retenez une partition source et faites refuser un accusé par le récepteur des effets externes. Le tableau doit montrer une frontière vieillissante et une comparaison incomplète, tandis que le contrôle d'autorité empêche de déclarer la réussite. Si un panneau vide ressemble à zéro écart, corrigez-le avant la bascule.

La décision de retour a besoin d'une horloge

La décision de retour doit suivre des déclencheurs déclarés, un responsable et un budget de temps fixés avant la bascule. Sans eux, les ingénieurs passent la fenêtre réversible à diagnostiquer pendant que les nouvelles écritures s'accumulent et que les effets externes se propagent. Quand la direction demande enfin de revenir, le rejeu peut prendre plus de temps qu'une correction en avant.

Choisissez des déclencheurs décrivant un dommage utilisateur ou comptable: refus d'opérations critiques, violation d'invariants, écart de rapprochement inexpliqué, file sans limite, absence d'accusés externes ou impossibilité de fermer un lot obligatoire. Le processeur et la latence peuvent étayer la décision, mais les symptômes d'infrastructure seuls disent rarement si les données restent sûres. Indiquez la période d'observation et la source de chaque signal.

Donnez à une personne l'autorité d'ordonner le retour et nommez un suppléant. Les responsables base, application, exploitation, métier et incident peuvent conseiller, mais le consensus est trop lent pendant l'arrivée des écritures. Nommez aussi la personne capable de déclarer le retour indisponible après le franchissement d'une frontière destructive. Cette déclaration doit faire passer le plan vers la réparation en avant et la compensation, pas laisser l'équipe débattre d'une option périmée.

L'horloge a besoin de deux limites. L'échéance de décision indique combien de temps l'équipe peut enquêter avant de geler les écritures ou choisir la réparation en avant. Le budget d'exécution indique combien de temps l'activité tolère la pause d'écriture et le rejeu. Déduisez les deux du rythme d'arrivée des transactions, du débit d'évacuation, des échéances externes et des effectifs, puis testez ces hypothèses pendant la répétition.

Une équipe prête pour la bascule peut donner le runbook à un opérateur qui ne l'a pas écrit, injecter une panne après de vraies écritures et rétablir l'ancien système dans ce budget. Si l'exercice exige une requête non écrite, un ingénieur particulier ou une correction manuelle de données, reportez la bascule. La production ne rendra pas ces dépendances plus indulgentes.