IA et non-régression : modernisez vos applications IBM i sans risque !

L’IA générative change la donne sur IBM i : analyser un programme RPG vieux de trente ans, en expliquer la logique, proposer un refactoring, tout cela se fait aujourd’hui en quelques minutes. Une opportunité historique pour un patrimoine qui porte souvent le cœur du business : facturation, paie, stocks…

Mais une question revient en comité de direction : « L’application modernisée fait-elle exactement la même chose qu’avant ? » Pas à peu près. Exactement. Car sur ces systèmes, une différence de comportement, c’est une facture fausse ou une paie erronée.

Notre conviction, la modernisation la plus sûre est hybride : l’IA pour comprendre, le déterminisme pour transformer, la non-régression pour prouver.

Mais un modèle de langage est probabiliste par construction : il produit la sortie la plus probable, pas une sortie garantie. Demandez-lui de convertir deux fois le même programme : rien ne garantit deux résultats identiques. Et à l’échelle d’un portefeuille applicatif, qu’il s’agisse de quelques centaines ou de plusieurs milliers de programmes, rien ne garantit que la même règle de conversion sera appliquée uniformément partout.

Ce n’est pas un défaut de l’IA. C’est sa nature. Et c’est précisément pourquoi elle ne peut pas, seule, porter la responsabilité d’une modernisation de système critique.

Dans ces systèmes, tout se joue dans les détails : un arrondi comptable, un ordre de tri, un contexte de troncature numérique, une date au format hérité. Invisible en revue de code. Très visible en production.

Face à ce constat, beaucoup d’organisations concluent : « alors il faut tout faire relire par des humains ». C’est oublier qu’il existe une troisième voie, éprouvée bien avant la vague IA : la transformation de code par des moteurs déterministes, basés sur l’analyse syntaxique et sémantique du langage, pas sur des probabilités.

Un processus déterministe offre trois propriétés qu’aucun modèle génératif ne peut garantir :

1. Reproductibilité : la même entrée produit toujours la même sortie ;
2. Uniformité : la même règle s’applique partout, sans exception ;
3. Auditabilité : chaque transformation est traçable et justifiable devant un auditeur.

Sur IBM i, deux chantiers de modernisation majeurs peuvent être menés ainsi :

Transformation déterministe ou pas, une règle de gouvernance demeure : toute modernisation doit être prouvée. Et cette preuve obéit à une logique bien précise, elle aussi déterministe :

C’est le rôle d’ARCAD Verifier. Et un point mérite l’attention particulière des responsables QA : grâce au lien entretenu entre le code applicatif et les cas de test, Verifier identifie les seuls tests impactés par une modification. Concrètement, après la conversion d’un lot de programmes, on ne rejoue pas aveuglément 3 000 scénarios : on rejoue ceux qui touchent le code transformé. La vérification devient ciblée, rapide et donc réellement praticable à chaque itération, pas seulement en fin de projet.

Même entrée + même scénario = même résultat. Sinon, régression. La confiance ne se décrète pas : elle se démontre, écran par écran, enregistrement par enregistrement, état par état.

Assemblons les trois pièces : la chaîne de modernisation sécurisée ressemble à ceci :

IA (comprendre) → Moteurs déterministes (transformer) → Non-régression (prouver) → Confiance (déployer)

Reste une question : comment l’agent IA et les moteurs déterministes communiquent-ils ?

C’est le rôle de l’ARCAD MCP Server. Il expose, via le protocole standard MCP, le référentiel ARCAD (34 ans d’analyse déterministe du patrimoine : composants, champs, procédures, dépendances) sous forme de plus de 70 outils (ressources, actions, prompts méthodologiques). L’agent IA (Copilot, Claude, LLM on-premise…), interroge ces outils en langage naturel, enchaîne les appels, et peut déclencher les processus outillés (lancer une conversion Free Form via Transformer RPG, par exemple) tout en s’appuyant sur un contexte certifié, issu d’algorithmes déterministes et non d’inférence.

Trois conséquences directes pour un DSI :

Autrement dit, l’approche hybride décrite dans cet article n’est pas un concept : c’est une architecture opérationnelle, où l’agent IA orchestre et où les moteurs déterministes exécutent.

Cette répartition a une conséquence économique que peu d’organisations ont encore mesurée : la consommation de tokens.

Faire convertir des millions de lignes de RPG par un LLM, c’est envoyer des millions de lignes en entrée et en recevoir autant en sortie, puis recommencer à chaque correction. Coût direct, latence, empreinte énergétique, et selon les architectures, exposition du code source à des services externes. À l’inverse, dans l’approche hybride, la transformation de masse ne consomme aucun token : elle est exécutée par des moteurs d’analyse syntaxique. L’IA est mobilisée de façon chirurgicale, sur les tâches à forte valeur : comprendre, expliquer, documenter, arbitrer les cas complexes.

Résultat : des coûts IA prévisibles et minimaux, une maîtrise de la confidentialité du code, et un budget qui finance la transformation elle-même plutôt que des allers-retours d’inférence. Le protocole MCP amplifie encore cet effet : la contextualisation compensant la puissance brute du modèle, même un SLM local, hébergé on-premise, produit des résultats pertinents : la souveraineté sans le surcoût.

Plutôt qu’un argumentaire, trois situations que les DSI et RSI reconnaîtront.

Chaque patrimoine IBM i a son histoire, ses zones sensibles, son niveau de dette et ses contraintes réglementaires. Il n’existe pas de trajectoire de modernisation universelle, mais une méthode pour construire la vôtre : évaluer l’existant, choisir les chantiers (Free Form, services web, base de données), et bâtir la boucle de preuve adaptée à vos cycles de livraison.

C’est une conversation que j’ai chaque semaine avec des DSI, RSI et responsables d’applications. Si vous vous reconnaissez dans l’une des situations, ou si votre comité de direction vous demande déjà des preuves, contactez-moi. Je serai ravi d’échanger sur votre contexte, de partager des retours d’expérience concrets et de vous montrer comment articuler IA, transformation déterministe et non-régression dans votre propre chaîne DevSecOps.