L’application que personne n’ose toucher, modernisée fonction après fonction.
Des décennies de règles métier dorment dans du COBOL, du PL/I, de l’Oracle Forms ou les premières versions de Java et .NET. Nous remettons ces règles au jour, posons un filet de tests, puis déplaçons une fonction après l’autre derrière une façade. Rien n’est arrêté avant une exécution en parallèle et un rapprochement des résultats.
Pour les organisations luxembourgeoises dont les systèmes critiques servent plusieurs pays, et qui ne peuvent se permettre ni interruption ni règle perdue.
Responsables informatiques et architectes d’entreprise
Responsables d’application
Experts métier
Équipes d’exploitation
Workflow illustratif
01Évaluer le parc applicatifPersonne
02Remettre au jour les règles métierAgent
03Poser le filet de sécuritéSystème
04Reconstruire une tranche derrière une façadeSystème
05Exécuter en parallèle et rapprocherSystème
06Analyser les écartsPersonne
07Basculer puis retirer l’ancienPersonne
Première étape : un état des lieux du parc et une cible convenue. L’IA aide à lire le code pour en tirer les règles métier, que des personnes confirment. Des tests de caractérisation protègent contre les régressions. Une fonction à la fois est refaite derrière une façade et tourne à côté de l’ancien système ; tout écart est examiné et corrigé. Le responsable métier donne ensuite son feu vert à la bascule, et l’ancienne partie est retirée.
Avant et après
Ce qui change dans votre manière de travailler
Aujourd’hui
Avec le système
Aujourd’hui
Aujourd’hui : Chaque évolution fait peur
Une petite adaptation réglementaire prend des mois, car personne ne sait prévoir ce qu’elle va casser ailleurs.
Avec le système
Avec le système : Des évolutions couvertes par des tests
Les tests de caractérisation figent le comportement actuel du système ; l’effet de chaque modification se voit avant sa mise en production.
Aujourd’hui
Aujourd’hui : Le savoir part à la retraite
Les quelques personnes qui comprennent encore le code s’approchent de la retraite, et la documentation a cessé de refléter le système depuis longtemps.
Avec le système
Avec le système : Des règles écrites et confirmées
Les règles tirées du code sont décrites en langage courant et validées par les experts du domaine.
Aujourd’hui
Aujourd’hui : Le grand soir qui recule
Un remplacement complet annonce une date de bascule unique ; elle recule sans cesse, tandis que les coûts augmentent.
Avec le système
Avec le système : Des gains livrés par tranches
Les fonctions passent une à une derrière une façade. Chaque tranche entre en service seule et peut être annulée.
Aujourd’hui
Aujourd’hui : Des données prisonnières
Les nouveaux services et les usages de l’IA n’atteignent les données qu’au moyen d’extractions fragiles et de traitements de nuit.
Avec le système
Avec le système : Des données exposées par API
Une fois migré, chaque domaine publie ses données par des API documentées, rapprochées de l’ancien système jusqu’à son arrêt.
Workflow
Le parcours, étape par étape
Nous suivons le schéma du figuier étrangleur : le nouveau système se développe autour de l’ancien, fonction par fonction. La boucle entre fonctionnement en double et refonte concentre la plus grande partie de l’effort.
Workflow illustratif
7 étapes · 3 contrôles humains
Légende
Système
Agent
Personne
Contrôle humain
Circuit d’exception
Modernisation : parcours illustratif et boucle de rapprochement
Lire le schéma sous forme de texte
Le chemin principal enchaîne l’état des lieux du parc, l’extraction des règles métier, la mise en place des tests de caractérisation et la refonte d’une fonction derrière une façade. Viennent ensuite le fonctionnement en double de l’ancien et du nouveau, puis la bascule et le retrait de l’ancienne partie.
Trois points de contrôle humains : l’approbation de l’architecture cible, la confirmation de chaque règle extraite et l’accord donné à chaque bascule.
Dès que le fonctionnement en double fait apparaître des résultats différents, la tranche sort du chemin principal. Ingénieurs et experts du domaine examinent les écarts, puis la tranche retourne à la refonte, jusqu’à ce que les deux systèmes concordent.
01
Étape 1 : Évaluer le parc applicatifPersonne
Nous recensons les applications, relevons leurs dépendances et leurs flux de données, puis décidons pour chacune : la retirer, la garder, la réhéberger, la porter sur une autre plateforme, la reconstruire ou la remplacer. Le découpage en domaines fait apparaître les endroits où l’on peut trancher.
Contrôle humain
L’architecture cible et la séquence des tranches sont approuvées par votre comité d’architecture.
02
Étape 2 : Remettre au jour les règles métierAgent
Une lecture du code assistée par IA parcourt le COBOL, le PL/I, le JCL, l’Oracle Forms et les anciennes applications Java ou .NET, et produit un premier jet de documentation, de graphes d’appels et de catalogue des règles.
Contrôle humain
Ingénieurs et experts métier contrôlent chaque règle extraite avant qu’elle serve de spécification. Une règle non confirmée reste signalée comme telle.
03
Étape 3 : Poser le filet de sécuritéSystème
À partir d’entrées et de sorties réelles, anonymisées, nous générons des tests de caractérisation. Ils enregistrent ce que fait le système aujourd’hui, y compris ses bizarreries, avant toute modification.
04
Étape 4 : Reconstruire une tranche derrière une façadeSystème
Une façade de routage ou une couche d’API se place devant l’ancien système. Une fonction renaît sous la forme d’un nouveau service, avec ses données migrées et tenues synchronisées.
05
Étape 5 : Exécuter en parallèle et rapprocherSystème
L’ancien et le nouveau traitent les mêmes opérations. Résultats et données sont comparés automatiquement ; chaque écart est rapporté par règle et par enregistrement.
06
Étape 6 : Analyser les écartsPersonne
Pour chaque écart, ingénieurs et experts métier tranchent : défaut du nouveau service, défaut de l’ancien ou changement voulu. La tranche repart alors en reprise.
Circuit d’exception : Résultats divergents· Retour à l’étape 4
07
Étape 7 : Basculer puis retirer l’ancienPersonne
Via la façade, les appels destinés à cette fonction partent désormais vers le nouveau service. Une fois la stabilité constatée, l’ancien code et ses données sont archivés, puis retirés.
Contrôle humain
Chaque bascule demande l’accord du responsable métier, sur la base des rapprochements. Tant que l’ancien n’est pas retiré, la façade permet de revenir en arrière.
Composants
Les briques que nous réaliserions
01
Cartographie du parc et des dépendances
Inventaire, relevé des interfaces et des flux, et modèle de domaines qui indique où le système peut être découpé.
Salesforce comme nouveau front officePlateformeSalesforce
Plateforme d’intégration et passerelle d’API
Cloud ou centre de données cible
Contrôles
Contrôles prévus dès la conception
Périmètres d’accès
Le code est analysé dans un environnement sous votre contrôle et ne part vers aucun service que vous n’auriez pas validé. Les données de production utilisées pour les tests sont anonymisées avant de sortir de la zone de production.
Revue humaine
Ingénieurs et experts métier confirment chaque règle extraite avant qu’elle devienne une spécification. Le responsable métier autorise chaque bascule à partir des rapprochements, avec un retour arrière disponible.
Traçabilité
Pour chaque règle du catalogue, on retrouve l’extrait de code d’origine et le nom de la personne qui l’a confirmée. Les rapports de rapprochement sont archivés comme justificatifs de chaque bascule.
Protection des données
La migration suit une correspondance documentée, avec comptages et sommes de contrôle ; les jeux de test ne contiennent que les données personnelles indispensables. Les règles de conservation accompagnent les données.
Transparence de l’IA
Toute documentation ou tout code rédigé avec l’aide de l’IA est signalé, relu et versionné comme n’importe quel autre livrable d’ingénierie.
Indicateurs
Ce que nous mesurerions
Ces indicateurs sont fixés avec vous lors de l’évaluation et suivis tranche par tranche, pas seulement à l’échelle du programme.
Ce que nous mesurerions
Indicateur
Pourquoi c’est important
Comment nous le mesurerions
01Délai de mise en production d’une évolution
Pourquoi c’est importantLe signe le plus net que le système devient plus simple à faire évoluer.
Comment nous le mesurerionsDurée entre l’approbation d’une demande d’évolution et sa mise en production, côté ancien et côté modernisé.
02État du rapprochement
Pourquoi c’est importantVérifie que le nouveau service reproduit le comportement de l’ancien partout où c’est attendu.
Comment nous le mesurerionsPart des opérations et des enregistrements concordants pendant l’exécution parallèle, avec les écarts ouverts classés par cause.
03Couverture des règles
Pourquoi c’est importantUne règle inconnue est le premier risque de tout remplacement.
Comment nous le mesurerionsPart des règles extraites qui sont confirmées par les experts métier et couvertes par des tests.
04Empreinte de l’existant
Pourquoi c’est importantLa modernisation ne rapporte que lorsque d’anciens composants sont réellement arrêtés.
Comment nous le mesurerionsFonctions, chemins de code, traitements par lots et licences retirés, suivis par tranche.
Aucun objectif n’est fixé avant une mesure de référence.
Déploiement
La mise en service, par étapes
Phase 01
Évaluation
Parc, dépendances, domaines, risques. La première tranche retenue doit compter pour le métier et rester réversible.
Critères de sortie
Architecture cible validée
Ordre des tranches arrêté
Accès aux tests et aux données organisé
Phase 02
Première tranche
Extraction des règles, filet de tests, façade et une fonction reconstruite, exécutée en parallèle avec l’ancien système.
Critères de sortie
Rapprochement dans la tolérance convenue
Bascule autorisée par le responsable métier
Retour arrière testé
Phase 03
Tranche après tranche
Chaque fonction suivante passe par les mêmes étapes, avec son propre fonctionnement en double et sa propre décision de bascule.
Critères de sortie
Chaque tranche rapprochée et basculée
Connaissances transmises à votre équipe
Phase 04
Retrait
Anciens chemins de code, traitements par lots et bases de données sont archivés puis mis hors service.
Application développée en interne par une administration, où des textes légaux et des règlements grand-ducaux sont codés depuis des décennies et continuent d’évoluer.
Système de gestion de portefeuilles d’une banque ou système de contrats d’un assureur, modernisé derrière des API pendant que les comptes restent rapprochés.
Développements spécifiques autour de l’ERP et applications d’atelier, repris en même temps qu’une migration vers SAP S/4HANA.
Exemple illustratif
Le système de gestion de portefeuilles d’une banque
Situation
Une banque de la place gère ses portefeuilles clients sur un système développé il y a plusieurs décennies. Des évolutions réglementaires attendent, et deux des développeurs qui connaissent le code partiront bientôt à la retraite.
Système
Les règles sont extraites et confirmées domaine par domaine. Une façade oriente d’abord le calcul des frais vers un nouveau service, exécuté en parallèle avec l’ancien jusqu’à concordance des résultats.
Contrôle humain
Les experts métier valident leurs règles. Le responsable métier autorise chaque bascule, et le retour arrière par la façade reste possible. Le registre d’informations et le plan de sortie DORA sont mis à jour à chaque tranche.
Ce que nous mesurerions
État du rapprochement par domaine, couverture des règles et délai de mise en production de la prochaine évolution réglementaire.
Luxembourg
Moderniser sous le regard des autorités
Sur la place financière, un même noyau historique sert souvent plusieurs entités et pays, chacun avec ses propres évolutions réglementaires en attente. Nous ordonnons la modernisation pour que chaque variante nationale passe une tranche à la fois, avec un rapprochement entre l’ancien et le nouveau par juridiction avant tout arrêt.
Pour une banque ou un assureur, DORA s’applique depuis le 17 janvier 2025 sous la surveillance de la CSSF et du Commissariat aux Assurances (CAA) : registre d’informations, plans de sortie et tests de résilience accompagnent donc chaque tranche. Pour une administration ou une entité d’un autre secteur, la loi du 5 mai 2026 transposant NIS2 confie la supervision à l’Institut Luxembourgeois de Régulation (ILR) dans la plupart des cas.
Les règles du règlement sur les données relatives au changement de fournisseur plaident pour des données portables dès la première tranche. Si les enregistrements comportent des données personnelles, correspondances de migration et jeux de test suivent le RGPD.
Parce qu’une bascule unique fait porter tout le risque sur un seul jour et que le métier patiente des années sans rien recevoir. Fonction par fonction, chaque tranche se vérifie en double, entre en service de façon autonome et reste réversible.
02L’IA peut-elle convertir notre COBOL en Java ?
Traduite ligne par ligne, une application reste en général aussi rigide qu’avant. L’IA nous sert à lire et documenter l’ancien code, et à préparer des règles et des tests ; les nouveaux services sont ensuite conçus correctement. Aucune règle n’est utilisée sans confirmation humaine.
03Nos experts partent à la retraite. Comment conserver ce qu’ils savent ?
En organisant des séances où ils relisent, avec nos ingénieurs, les règles tirées du code et les tests de caractérisation. Ce qu’ils savent est ainsi consigné dans une documentation et des tests qui vous appartiennent, plutôt que dans la mémoire de nos consultants.
04La démarche vaut-elle aussi pour SAP ECC ?
Oui. Remise en ordre du code spécifique ou passage à SAP S/4HANA, la logique est la même : repérer ce qui est encore utilisé, extraire et tester ce qui compte, avancer par étapes maîtrisées. La question se pose notamment dans les groupes qui comptent des sociétés holding luxembourgeoises.
05Combien de temps l’ancien et le nouveau tournent-ils en parallèle ?
Aussi longtemps que les écarts dépassent la tolérance fixée avec le responsable métier, et au minimum le temps de couvrir les traitements périodiques, par exemple une clôture de fin de mois ou de fin d’année.
Indiquez-nous l’application qui bloque vos projets et les traitements qui s’y appuient. Nous suggérerons une première tranche et une façon sûre de la valider, pour tous les pays qu’elle couvre.