Dans cet article
- Pourquoi le code converti par l'IA demande des tests différents
- Comparer les résultats sur les mêmes transactions réelles
- Les cas rares : demandez à ceux qui les connaissent
- Une validation humaine pour chaque module
- Le fonctionnement en parallèle et le plan de retour arrière
- Le regard d'Origami
- L'exercice de la semaine : une fiche de bascule par module
- La suite
Vous basculez sans arrêter l'activité si l'ancien système reste allumé jusqu'à ce que le nouveau ait fait ses preuves : faites tourner les deux sur les mêmes transactions et comparez les résultats, testez les cas rares cités par les responsables des processus, faites valider chaque module par un humain et gardez l'ancien système prêt pour un retour arrière. Dans son guide d'exécution de la migration, Microsoft recommande de surveiller le nouveau système 24 à 48 heures après la bascule et de garder l'environnement source comme repli.
Dans la cinquième partie, vous avez choisi une voie pour chaque système. Cette partie ne reprend pas la méthode générale de bascule présentée dans Moderniser un système hérité sans interruption de service. Elle se concentre sur ce qui est nouveau : que tester quand c'est l'IA qui a écrit ou converti le nouveau code.
Pourquoi le code converti par l'IA demande des tests différents
Le code produit par les outils de conversion paraît propre et fonctionne dès le premier essai, et c'est précisément ce qui rend ses erreurs difficiles à voir. L'erreur n'apparaît pas dans les cas courants ; elle apparaît dans le cas qui survient une fois par mois ou une fois par an. Amazon explique dans son guide de transformation des applications mainframe que la première conversion de COBOL vers Java conserve le même comportement, puis qu'une étape appelée Reforge utilise de grands modèles de langage pour restructurer le code dans un style Java moderne. COBOL est un ancien langage de programmation qui fait encore tourner de nombreux systèmes bancaires et mainframe ; le mainframe est le grand serveur central sur lequel tournent les systèmes clés des grandes organisations.
Chaque étape qui réécrit le code peut modifier un petit détail. Il ne suffit donc pas qu'un développeur relise le nouveau code et le juge correct. La direction n'a qu'une question : le nouveau système donne-t-il le même résultat que l'ancien sur les mêmes données ? La réponse vient de la comparaison des résultats, pas de la lecture du code.
Comparer les résultats sur les mêmes transactions réelles
Prenez une période close de votre activité, par exemple un mois dont les comptes sont arrêtés, passez ses transactions dans le nouveau système et comparez ce qui en sort avec ce que l'ancien avait produit. Ce qu'il faut comparer :
- Les chiffres finaux : totaux de facturation, soldes et stocks en fin de période.
- Les rapports : les rapports mensuels sur lesquels s'appuie la direction, ligne par ligne.
- Ce qui part vers les autres systèmes : les fichiers et messages envoyés à la banque, à la comptabilité ou aux portails administratifs.
- Les rejets et les erreurs : une transaction rejetée par l'ancien système doit être rejetée par le nouveau, pour la même raison.
Certains outils aident à préparer, pas à juger. AWS Transform pour mainframe, par exemple, construit un plan de test à partir des attributs du code, de la complexité des traitements et des chemins d'ordonnancement en 3 phases (configuration, cadrage et revue), puis génère des scripts de collecte des données de test sur le mainframe en 4 phases. Mais Amazon précise dans le même guide que ces scripts doivent être exécutés sur votre propre mainframe, avec les autorisations de votre équipe. L'outil prépare ; votre équipe exécute et tranche. Pour vérifier les données elles-mêmes, Microsoft propose de comparer le nombre de lignes pour un contrôle rapide, puis des sommes de contrôle pour un contrôle approfondi : une somme de contrôle est un nombre calculé à partir des données, qui change si un seul caractère change.
Les cas rares : demandez à ceux qui les connaissent
Un mois de transactions réelles ne contient pas tout. Les cas qui font tomber les systèmes, ce sont les responsables des processus qui les connaissent, pas les développeurs : la clôture de fin d'exercice, un retour partiel sur une ancienne facture, un client au tarif spécial, une facture annulée après comptabilisation, le salaire d'une personne arrivée en milieu de mois. Demandez à chaque responsable de processus la liste des cas qui l'inquiètent, puis transformez chacun en test dont le résultat attendu est écrit avant l'exécution.
C'est là que reviennent les règles confirmées dans la quatrième partie : chaque règle confirmée devient au moins un cas de test. Une règle sans test est une règle dont vous ne pouvez pas dire qu'elle a survécu à la conversion. Pour les types de tests eux-mêmes, voyez notre guide des tests logiciels et de l'assurance qualité.
Une validation humaine pour chaque module
L'exemple publié le plus clair de ce principe est la chaîne de migration bancaire annoncée par Thought Machine avec Amazon le 29 septembre 2026. Elle comporte 4 étapes : l'extraction de la logique métier des applications existantes avec AWS Transform, la consolidation des variantes redondantes en spécifications unifiées, la génération des nouveaux produits financiers et de leurs suites de tests par des agents d'IA, puis une étape de validation qui donne aux équipes d'ingénierie et de risques de la banque une autorité de validation explicite avant toute acceptation. Même après validation, le résultat part dans un environnement isolé pour une évaluation complémentaire, pas directement en production.
La leçon pour votre entreprise ne demande ni banque ni Amazon : chaque module du système, comme la facturation, la paie ou les stocks, reçoit deux signatures avant sa mise en service. Une technique, qui confirme que tous les tests ont été exécutés, et une du responsable du processus, qui confirme que les résultats sont justes en termes métier. Microsoft demande la même chose après la bascule : que les responsables applicatifs confirment le bon fonctionnement de toutes les fonctions majeures.
Le fonctionnement en parallèle et le plan de retour arrière
Le fonctionnement en parallèle signifie que les deux systèmes tournent côte à côte pendant une période définie, l'ancien restant la référence officielle. Décidez avant de commencer quand cette période se termine et quelle condition permet d'y mettre fin, par exemple des résultats identiques sur un cycle complet de votre activité. Organisez ensuite la bascule ainsi :
| Étape | Ce que vous faites | Source |
|---|---|---|
| Avant la bascule | Une réunion avec toutes les équipes de support pour revoir le plan de migration, les procédures de vérification et les critères de retour arrière, et un gel des modifications sur l'ancien système pendant la fenêtre de migration | Microsoft |
| Jour de la bascule | Suspendre la saisie dans l'ancien système pendant la synchronisation finale à un moment de faible activité, prévenir tout le monde de l'horaire, et valider les données avant de rediriger les utilisateurs | Microsoft |
| Après la bascule | Tester les processus clés de bout en bout, surveiller les performances et les erreurs pendant les 24 à 48 premières heures, et garder l'ancien système prêt pour un repli | Microsoft |
Un plan de retour arrière n'est pas un aveu d'échec ; c'est une assurance. Écrivez à l'avance ce qui vous ferait revenir en arrière, comme une erreur de facturation ou l'arrêt d'un processus clé, qui détient cette décision et comment les utilisateurs retournent à l'ancien système. N'éteignez pas définitivement l'ancien système avant la fin de la période de stabilisation. Ce qui casse généralement dans les premières semaines est détaillé dans Les trente premiers jours après la bascule.
Le regard d'Origami
Nous traitons la bascule comme une décision de direction, pas comme un événement technique. Nous construisons donc la comparaison entre les deux systèmes avant le nouveau système lui-même, et nous nous accordons tôt avec les responsables des processus sur les cas rares et leurs résultats attendus, pour que la définition du succès soit écrite avant que quiconque voie les résultats.
Nous utilisons l'IA pour accélérer la conversion et générer les tests, mais la validation de chaque module reste entre les mains de personnes nommées de votre équipe. Pour voir comment nous travaillons, consultez nos services.
L'exercice de la semaine : une fiche de bascule par module
Pour chaque système que vous avez choisi de convertir ou de reconstruire dans la cinquième partie, remplissez cette fiche avec les responsables des processus avant de fixer une date de bascule :
| Module | Période de comparaison | Cas rares | Qui valide | Déclencheur de retour arrière |
|---|---|---|---|---|
| Exemple : facturation | Un mois clôturé | Retour partiel, facture annulée | Directeur financier et responsable technique | Tout écart sur les totaux de facturation |
| Exemple : paie | Un cycle de paie complet | Arrivée en milieu de mois | Responsable RH et responsable technique | Tout écart sur un salaire net |
Ce sont des exemples illustratifs ; votre fiche sera différente. L'essentiel est qu'aucune date de bascule ne soit fixée tant que chaque module n'a pas deux signataires nommés et un déclencheur de retour arrière écrit.
La suite
Reste une question que tout dirigeant pose avant d'envoyer son code et ses données à un outil d'IA : où vont mes données pendant la modernisation ? La septième et dernière partie y répond et rassemble les exercices de toute la série dans un plan de 90 jours.
Sources
- Microsoft : exécuter la migration, Cloud Adoption Framework — réunion sur les critères de retour arrière, gel des modifications, validation des données, surveillance de 24 à 48 heures, conservation de l'environnement source comme repli.
- Amazon : transformation des applications mainframe dans AWS Transform — plans de test, scripts de collecte des données de test et étape Reforge.
- Amazon : annonce de Thought Machine et AWS sur les migrations bancaires — les quatre étapes et la validation par les équipes d'ingénierie et de risques.
- AWS Transform : page officielle.
Questions fréquentes
Comment passer à un nouveau système sans arrêter l'activité ?
Faites tourner les deux systèmes côte à côte pendant une période définie, l'ancien restant la référence, comparez leurs résultats sur les mêmes transactions, et n'éteignez l'ancien qu'après la validation des responsables des processus et la fin de la stabilisation, avec un plan de retour arrière écrit.
La relecture du code converti par l'IA par un développeur suffit-elle ?
Non. Les erreurs apparaissent dans les cas rares, pas à la lecture du code. Le critère est que le nouveau système donne les mêmes résultats que l'ancien sur les mêmes données, ce que confirme le responsable du processus.
Combien de temps surveiller le nouveau système après la bascule ?
Microsoft recommande de surveiller les performances, les erreurs et les accès pendant les 24 à 48 premières heures après la bascule, en gardant l'environnement source disponible comme repli pendant la stabilisation.
Qu'est-ce qu'un plan de retour arrière et pourquoi en ai-je besoin ?
C'est une décision écrite à l'avance qui fixe ce qui vous ferait revenir à l'ancien système, qui tranche et comment les utilisateurs y retournent. C'est une assurance pour la continuité de l'activité, pas un aveu d'échec.
Suivez Origami sur Google
Ajoutez Origami à vos sources préférées : nos articles apparaîtront en premier pour vous dans la recherche Google et les actualités à la une.
