Moderniser le système auquel personne n’ose toucher, une fonction à la fois.
Des décennies de règles de gestion vivent dans du COBOL, du PL/I, des Oracle Forms et les premières versions de Java et de .NET. Nous retrouvons ces règles, construisons un filet de sécurité de tests et migrons fonction par fonction derrière une façade, avec fonctionnement en parallèle et rapprochement avant toute mise à l’arrêt.
Pour les DSI qui ont la charge d’applications critiques en COBOL, en L4G ou sur des frameworks qui ne sont plus maintenus, et qui ne peuvent se permettre ni interruption ni perte de règles métier.
Directions informatiques et architectes d’entreprise
Responsables d’applications
Experts métier
Équipes d’exploitation
Workflow illustratif
01Évaluer le portefeuillePersonne
02Retrouver les règles de gestionAgent
03Construire 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 et retirerPersonne
Le portefeuille applicatif est évalué et la cible convenue. Les règles de gestion sont retrouvées dans le code avec l’aide de l’IA et vérifiées par des personnes. Des tests de caractérisation forment un filet de sécurité. Chaque fonction est reconstruite derrière une façade et exécutée en parallèle de l’ancien système ; les écarts sont analysés et corrigés avant que le responsable métier n’approuve la bascule et que l’ancienne partie ne soit retirée.
Avant et après
Ce qui change dans votre façon de travailler
Aujourd’hui
Avec le système
Aujourd’hui
Aujourd’hui : Chaque évolution est un risque
De petites évolutions réglementaires prennent des mois, car personne ne peut prévoir ce qu’une modification affectera par ailleurs.
Avec le système
Avec le système : Des évolutions couvertes par des tests
Les tests de caractérisation décrivent ce que fait le système aujourd’hui : chaque modification montre son effet avant la mise en production.
Aujourd’hui
Aujourd’hui : Le savoir part à la retraite
Les personnes qui comprennent le code approchent de la retraite, et la documentation ne correspond plus au système depuis longtemps.
Avec le système
Avec le système : Des règles écrites et vérifiées
Les règles de gestion retrouvées dans le code sont documentées en langage clair et confirmées par les experts métier.
Aujourd’hui
Aujourd’hui : Les plans de bascule unique s’enlisent
Les programmes de remplacement complet promettent une date de bascule unique qui ne cesse de reculer, pendant que les coûts augmentent.
Avec le système
Avec le système : De la valeur livrée par tranches
Les fonctions migrent une à une derrière une façade. Chaque tranche est mise en service séparément et peut faire l’objet d’un retour arrière.
Aujourd’hui
Aujourd’hui : Des données enfermées dans d’anciennes structures
Les nouveaux services et les cas d’usage d’IA n’accèdent aux données que par des extractions fragiles et des traitements batch nocturnes.
Avec le système
Avec le système : Des données accessibles par API
Les domaines migrés exposent leurs données par des API documentées, rapprochées de l’ancien système jusqu’à son retrait.
Workflow
Le déroulement du processus
Une approche dite « strangler fig » : le nouveau système se développe autour de l’ancien, fonction par fonction. C’est dans la boucle entre fonctionnement en parallèle et reconstruction que se concentre l’essentiel du travail réel.
Workflow illustratif
7 étapes · 3 contrôles humains
Légende
Système
Agent
Personne
Contrôle humain
Circuit d’exception
Modernisation des systèmes hérités : processus illustratif avec boucle de rapprochement
Lire le schéma sous forme de texte
Le circuit principal enchaîne l’évaluation du portefeuille, la reconstitution des règles de gestion, la construction d’un filet de tests de caractérisation, la reconstruction d’une fonction derrière une façade et l’exécution en parallèle de l’ancien et du nouveau, jusqu’à la bascule et au retrait de l’ancienne partie.
Des personnes valident l’architecture cible, vérifient chaque règle retrouvée et approuvent chaque bascule : ce sont les points de contrôle humain.
Lorsque le fonctionnement en parallèle révèle des résultats divergents, la tranche quitte le circuit principal pour être analysée par les ingénieurs et les experts métier, puis revient à l’étape de reconstruction jusqu’à ce que l’ancien et le nouveau concordent.
01
Étape 1 : Évaluer le portefeuillePersonne
Inventaire des applications, cartographie des dépendances et des flux de données, et une décision par application : retirer, conserver, réhéberger, changer de plateforme, reconstruire ou remplacer. Les domaines sont cartographiés pour repérer les lignes de découpe possibles.
Contrôle humain
Votre comité d’architecture valide l’architecture cible et l’ordre des tranches.
02
Étape 2 : Retrouver les règles de gestionAgent
Une analyse du code assistée par l’IA lit le COBOL, le PL/I, le JCL, les Oracle Forms et les anciennes applications Java ou .NET, et produit des projets de documentation, des graphes d’appels et un catalogue des règles de gestion.
Contrôle humain
Ingénieurs et experts métier vérifient chaque règle extraite avant qu’elle ne serve de spécification. Les règles non vérifiées sont signalées comme telles.
03
Étape 3 : Construire le filet de sécuritéSystème
Des tests de caractérisation sont générés à partir d’entrées et de sorties de production anonymisées, pour figer le comportement actuel, particularités comprises, 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 est placée devant l’ancien système. Une fonction est reconstruite sous forme de nouveau service, ses données étant migrées et maintenues synchronisées.
05
Étape 5 : Exécuter en parallèle et rapprocherSystème
L’ancien et le nouveau système traitent les mêmes transactions. Résultats et données sont comparés automatiquement, et chaque écart est signalé par règle et par enregistrement.
06
Étape 6 : Analyser les écartsPersonne
Ingénieurs et experts métier déterminent si chaque écart est un défaut du nouveau service, un défaut de l’ancien ou une évolution voulue, et renvoient la tranche en reprise.
Circuit d’exception : Résultats divergents· Retour à l’étape 4
07
Étape 7 : Basculer et retirerPersonne
Le trafic de la fonction est redirigé vers le nouveau service par la façade. Après une période de stabilité, l’ancien chemin de code et ses données sont retirés et archivés.
Contrôle humain
Le responsable métier approuve chaque bascule sur la base des résultats du rapprochement. Le retour arrière par la façade reste possible jusqu’au retrait.
Composants
Ce que nous construirions
01
Cartographie du portefeuille et des dépendances
Inventaire, cartographie des interfaces et des flux de données, et un modèle de domaines qui montre où le système peut être découpé en tranches.
Salesforce comme nouveau front-officePlateformeSalesforce
Plateforme d’intégration et passerelle d’API
Cloud ou centre de données cible
Contrôles
Des contrôles intégrés dès la conception
Périmètres d’accès
L’analyse du code s’exécute dans un environnement que vous maîtrisez, sans qu’aucun code source ne soit envoyé à des services que vous n’avez pas approuvés. Les données de production utilisées pour les tests sont anonymisées avant de quitter la zone de production.
Revue humaine
Les règles retrouvées sont vérifiées par des ingénieurs et des experts métier avant de devenir des spécifications. Chaque bascule est approuvée par le responsable métier sur la base des résultats du rapprochement, avec possibilité de retour arrière.
Traçabilité
Chaque règle du catalogue renvoie au code dont elle provient et à la personne qui l’a vérifiée. Les rapports de rapprochement sont conservés comme preuves pour chaque bascule.
Protection des données
La migration des données suit une correspondance documentée, avec comptages d’enregistrements et sommes de contrôle, et les données personnelles sont minimisées dans les jeux de test. Les règles de conservation suivent les données.
Transparence de l’IA
Lorsque l’IA produit un projet de documentation ou de code, le résultat est signalé, relu et versionné comme tout autre livrable d’ingénierie.
Indicateurs
Ce que nous mesurerions
Nous convenons de ces indicateurs avec vous pendant l’évaluation et les suivons tranche par tranche, et pas seulement pour l’ensemble du programme.
Ce que nous mesurerions
Indicateur
Pourquoi c’est important
Comment nous le mesurerions
01Délai de mise en œuvre des évolutions
Pourquoi c’est importantLe signe le plus clair que le système devient plus facile à faire évoluer.
Comment nous le mesurerionsTemps entre une demande d’évolution approuvée et sa mise en production, pour les parties anciennes et modernisées.
02État du rapprochement
Pourquoi c’est importantMontre si le nouveau service se comporte réellement comme l’ancien là où il le doit.
Comment nous le mesurerionsPart des transactions et des enregistrements concordants pendant le fonctionnement en parallèle, avec les écarts ouverts par cause.
03Couverture des règles
Pourquoi c’est importantLes règles inconnues sont le principal risque de tout remplacement.
Comment nous le mesurerionsPart des règles de gestion retrouvées qui sont vérifiées par les experts métier et couvertes par des tests.
04Empreinte des systèmes hérités
Pourquoi c’est importantLa modernisation n’est rentable que lorsque les anciens composants sont effectivement arrêtés.
Comment nous le mesurerionsFonctions, chemins de code, traitements batch et licences retirés, suivis par tranche.
Aucun objectif n’est fixé avant une mesure de référence.
Déploiement
Notre démarche de déploiement
Phase 01
Évaluation
Portefeuille, dépendances, domaines et risques. Nous choisissons une première tranche qui compte pour le métier tout en permettant un retour arrière.
Critères de sortie
Architecture cible approuvée
Ordre des tranches convenu
Accès aux tests et aux données organisé
Phase 02
Première tranche
Reconstitution des règles, filet de sécurité, façade et une première fonction reconstruite, exécutée en parallèle de l’ancien système.
Critères de sortie
Rapprochement dans la tolérance convenue
Bascule approuvée par le responsable métier
Retour arrière testé
Phase 03
Tranche par tranche
Les fonctions suivantes empruntent le même chemin, chacune avec son propre fonctionnement en parallèle et sa propre décision de bascule.
Critères de sortie
Chaque tranche rapprochée et basculée
Connaissances transférées à votre équipe
Phase 04
Retrait
Les anciens chemins de code, traitements batch et bases de données sont archivés et arrêtés.
Systèmes de prestations, de fiscalité et d’enregistrement, où la législation est codée dans des programmes vieux de plusieurs décennies et où les modifications ne cessent d’arriver.
Extensions spécifiques de l’ERP et systèmes d’usine, modernisés parallèlement à une migration vers SAP S/4HANA.
Exemple illustratif
Un moteur de calcul de cotisations en COBOL
Situation
Une institution de prévoyance calcule ses cotisations dans une application COBOL que très peu de personnes maîtrisent encore, et chaque évolution réglementaire prend des mois.
Système
Un nouveau moteur de calcul introduit fonction par fonction derrière une façade d’API, exécuté en parallèle de l’ancien sur les mêmes données jusqu’à concordance.
Contrôle humain
Les actuaires et les gestionnaires valident chaque écart entre ancien et nouveau calcul ; aucune fonction n’est basculée sans leur accord écrit.
Ce que nous mesurerions
Part des calculs concordants en exécution parallèle, délai de mise en œuvre d’une évolution réglementaire, incidents après bascule.
France
Moderniser sous contrainte de sécurité et d’hébergement
Beaucoup de systèmes critiques en France reposent sur des technologies dont les compétences se raréfient. Leur modernisation doit composer avec NIS2 et les recommandations de l’ANSSI, avec le RGPD pour les données reprises, et souvent avec une cible d’hébergement fixée par la doctrine « cloud au centre » ou une exigence SecNumCloud.
Nous procédons par remplacement progressif : chaque fonction migrée tourne en parallèle de l’ancienne jusqu’à preuve d’équivalence, et les règles métier redécouvertes sont documentées en français pour vos équipes.
Questions sur la modernisation des systèmes hérités
01Pourquoi ne pas remplacer tout le système d’un coup ?
Parce qu’une bascule unique concentre tout le risque sur une seule date, et que le métier attend des années avant d’en tirer le moindre bénéfice. Migrer fonction par fonction permet à chaque tranche de faire ses preuves en fonctionnement parallèle, d’être mise en service séparément et de faire l’objet d’un retour arrière si nécessaire.
02L’IA peut-elle traduire notre COBOL en Java ?
Une traduction ligne à ligne produit généralement un code aussi difficile à faire évoluer que l’original. Nous utilisons l’IA pour lire et documenter l’ancien code et pour préparer des projets de règles et de tests, puis nous concevons correctement les nouveaux services. Chaque règle retrouvée est vérifiée par des personnes avant d’être utilisée.
03Nos experts partent à la retraite. Comment préservez-vous leur savoir ?
Par des séances structurées au cours desquelles les experts relisent les règles retrouvées et les tests de caractérisation. Leur savoir se retrouve dans une documentation et des tests qui restent dans votre équipe, et non dans nos têtes.
04Cette démarche s’applique-t-elle aussi à SAP ECC ?
Oui. Les mêmes principes valent pour la reprise du code spécifique et une migration vers SAP S/4HANA : évaluer ce qui est encore utilisé, retrouver et tester ce qui compte, et avancer par étapes maîtrisées.
05Combien de temps l’ancien et le nouveau fonctionnent-ils en parallèle ?
Jusqu’à ce que les résultats du rapprochement respectent la tolérance convenue avec le responsable métier, et assez longtemps pour couvrir les traitements périodiques comme les clôtures mensuelles ou annuelles.
Apportez l’application qui vous inquiète le plus et ce que vous savez de ses règles. Nous vous proposerons un premier découpage et une façon de prouver l’équivalence.