Savoir remédier, pas seulement être prêt
Une répétition générale ne se juge pas au nombre d'anomalies, mais à la vitesse et à la propreté avec lesquelles on les corrige. Le soir de la bascule, il y aura des écarts : c'est une certitude, pas un risque.
Tout le monde dit être prêt à remédier. La vraie question est : comment ? Avec quel outil, sous quel profil, sur quels champs, et sans casser ce qui était juste. C'est ce qu'un DR doit tester, au même titre que les chargements.
Préparer la remédiation avant le DR
Une remédiation improvisée à 2 heures du matin coûte plus cher que l'anomalie elle-même. Elle se prépare en amont, comme un chargement.
- Un catalogue d'anomalies connues : pour chaque type d'écart déjà vu en test, la correction, l'outil et la personne qui la fait.
- Une fenêtre de temps réservée dans le plan de bascule, avec un responsable qui arbitre : corriger maintenant, après le go-live, ou déclencher le no-go.
- Des critères go/no-go chiffrés : nombre d'écarts de réconciliation tolérés, montants, types de records bloquants.
- Une trace de chaque correction : qui, quoi, quand, avant et après. L'audit et la conformité la demanderont.
La ligne de commande, outil de remédiation
Pendant une bascule, l'écran Browser est trop lent pour corriger des centaines de records. La ligne de commande permet de cibler, corriger et vérifier en masse, et de rejouer.
- Interroger, analyser d'abord : requêtes ciblées pour isoler précisément les records en écart avant d'y toucher.
- Corriger par OFS / DMD plutôt qu'en écrivant directement en base : la correction passe par les validations applicatives et laisse une trace.
- Rejouer un chargement ciblé : relancer un seul fichier DMD sur les records rejetés plutôt que tout recharger.
- Scripter et versionner chaque correction répétable, pour qu'elle soit identique au DR et au go-live.
Un profil dédié à la remédiation
Corriger avec l'utilisateur de chargement ou avec un compte personnel mélange les traces. Un profil dédié, préparé et testé avant le DR, règle le problème.
- Des droits limités aux applications à corriger, pas un accès total.
- Des overrides maîtrisés : savoir lesquels le profil peut accepter, et lesquels doivent rester bloquants.
- Une identification claire dans les champs d'audit (INPUTTER, AUTHORISER) : on distingue d'un coup d'œil le chargé du corrigé.
- Un double contrôle sur les corrections sensibles, avec une autorisation par une seconde personne.
- Une désactivation planifiée après la période d'hypercare.
Multi-valeurs et AA : corriger sans désaligner
Sur un record simple, corriger un champ suffit. Sur un arrangement AA ou un champ multi-valeurs, une correction mal placée décale toutes les valeurs associées.
- Respecter la position : dans un groupe de champs associés (VM/SM), la valeur n doit rester alignée avec la valeur n des autres champs du groupe. Insérer ou supprimer une valeur au mauvais rang corrompt silencieusement le record.
- Passer par les activités AA plutôt que modifier les records de condition directement : l'arrangement doit rester cohérent avec ses propriétés, ses dates d'effet et son historique.
- Penser aux dates d'effet : une correction de condition d'intérêt s'applique à partir d'une date, pas « en général ».
- Vérifier après coup : recalculer et rapprocher les soldes et les intérêts courus de l'arrangement corrigé.
Les takeover accounts : reprendre l'historique, puis le corriger
La reprise d'un compte ou d'un prêt existant n'est pas une création : on reprend un solde, des intérêts courus et des échéances déjà en vie. C'est là que se cachent les écarts les plus coûteux.
- Distinguer création et reprise : un compte repris porte une histoire que Transact doit accepter telle quelle, sans la recalculer.
- Rapprocher solde par solde : capital, intérêts courus, impayés, contre le système source arrêté à la date de migration.
- Corriger sans tout recharger : savoir ajuster un solde ou un courus sur un compte repris, plutôt que de le supprimer et le recréer, ce qui ferait perdre sa cohérence.
- Tester le premier COB : c'est le premier traitement de fin de journée qui révèle si la reprise tient.
Former et répéter : la remédiation s'apprend
Un outil que personne n'a pratiqué ne sert à rien à 3 heures du matin. La remédiation se forme et se répète, exactement comme les chargements.
- Former plusieurs personnes aux gestes de correction : la bascule ne doit pas reposer sur un seul expert, fatigué ou injoignable.
- Répéter les corrections pendant chaque DR, même quand l'anomalie aurait pu attendre : c'est le seul moyen de chronométrer et de fiabiliser le geste.
- Mettre à jour le catalogue après chaque répétition : chaque nouvel écart rencontré devient une correction documentée.
- Impliquer le métier : les équipes qui valideront les soldes le soir du go-live doivent avoir vu les corrections pendant les DR.
En résumé
Le go-live se prépare aussi par la remédiation. Avant la bascule, chaque équipe devrait pouvoir cocher ces points :
- Catalogue des anomalies connues et de leurs corrections à jour
- Scripts de correction testés, versionnés et identiques au DR
- Profil de remédiation créé, testé, avec double contrôle
- Règles de correction AA et multi-valeurs connues de l'équipe
- Méthode d'ajustement des comptes repris validée
- Au moins deux personnes formées à chaque geste
- Fenêtre de remédiation et critères go/no-go dans le plan de bascule
Knowing how to remediate, not just being ready
A dress rehearsal is not judged by the number of anomalies, but by how quickly and cleanly they are corrected. On cutover night, there will be discrepancies: that is a certainty, not a risk.
Everyone says they are ready to remediate. The real question is: how? With which tool, under which profile, on which fields, and without breaking what was right. That is what a DR needs to test, just as much as the loads.
Prepare remediation before the DR
A fix improvised at 2 am costs more than the anomaly itself. It needs to be prepared in advance, just like a load.
- A catalogue of known anomalies: for each type of discrepancy already seen in testing, the correction, the tool and the person who carries it out.
- A dedicated time window in the cutover plan, with a decision-maker who arbitrates: fix now, fix after go-live, or call a no-go.
- Quantified go/no-go criteria: number of reconciliation discrepancies tolerated, amounts, types of blocking records.
- A trace of every correction: who, what, when, before and after. Audit and compliance will ask for it.
The command line as a remediation tool
During a cutover, the Browser screen is too slow to correct hundreds of records. The command line lets you target, correct and verify in bulk, and replay.
- Query and analyse first: targeted queries to isolate exactly the records in error before touching them.
- Correct through OFS / DMD rather than writing directly to the database: the correction goes through the application validations and leaves a trace.
- Replay a targeted load: rerun a single DMD file on the rejected records rather than reloading everything.
- Script and version every repeatable correction, so that it is identical in the DR and at go-live.
A profile dedicated to remediation
Correcting with the load user or with a personal account muddles the audit trail. A dedicated profile, prepared and tested before the DR, solves the problem.
- Restricted rights to the applications to be corrected, not full access.
- Controlled overrides: knowing which ones the profile may accept, and which must remain blocking.
- Clear identification in the audit fields (INPUTTER, AUTHORISER): loaded and corrected records can be told apart at a glance.
- Four-eyes control on sensitive corrections, with authorisation by a second person.
- Planned deactivation after the hypercare period.
Multi-value fields and AA: correct without misaligning
On a simple record, correcting a field is enough. On an AA arrangement or a multi-value field, a misplaced correction shifts every associated value.
- Respect the position: within a group of associated fields (VM/SM), value n must stay aligned with value n of the other fields in the group. Inserting or deleting a value at the wrong position silently corrupts the record.
- Go through AA activities rather than amending condition records directly: the arrangement must stay consistent with its properties, effective dates and history.
- Mind the effective dates: a correction to an interest condition applies from a given date, not “in general”.
- Check afterwards: recalculate and reconcile the balances and accrued interest of the corrected arrangement.
Takeover accounts: take over the history, then correct it
Taking over an existing account or loan is not a creation: you take over a balance, accrued interest and schedules that are already live. That is where the most expensive discrepancies hide.
- Distinguish creation from takeover: a takeover account carries a history that Transact must accept as it is, without recalculating it.
- Reconcile balance by balance: principal, accrued interest, arrears, against the source system frozen at the migration date.
- Correct without reloading everything: know how to adjust a balance or an accrual on a takeover account, rather than deleting and recreating it, which would break its consistency.
- Test the first COB: the first close of business is what shows whether the takeover holds.
Train and rehearse: remediation is a skill
A tool nobody has practised with is useless at 3 am. Remediation is trained and rehearsed, exactly like the loads.
- Train several people in the correction procedures: the cutover must not depend on a single expert who may be tired or unreachable.
- Rehearse the corrections in every DR, even when the anomaly could have waited: it is the only way to time the procedure and make it reliable.
- Update the catalogue after each rehearsal: every new discrepancy becomes a documented correction.
- Involve the business: the teams who will sign off the balances on go-live night must have seen the corrections during the DRs.
In summary
Go-live is also prepared through remediation. Before cutover, every team should be able to tick these boxes:
- Catalogue of known anomalies and their corrections up to date
- Correction scripts tested, versioned and identical to the DR
- Remediation profile created and tested, with four-eyes control
- AA and multi-value correction rules known to the team
- Method for adjusting takeover accounts approved
- At least two people trained in each procedure
- Remediation window and go/no-go criteria in the cutover plan
Vous préparez une migration ou un upgrade Transact ?Preparing a Transact migration or upgrade?
Discutons-enLet's talk