Modernisation AS/400 / IBM i

Leur AS/400 tournait depuis 1995. Aujourd'hui, c'est une application Java cloud-native.

Access International modernise les patrimoines AS/400 et IBM i (7.3 à 7.6) vers des architectures cloud-natives. Programmes RPG, COBOL/400, CL, écrans 5250, bases DB2 for i — chaque composant est porté avec parité fonctionnelle prouvée. Méthodologie ATLAS, delivery nearshore Tunis, présence France (Vivantro), co-delivery avec nos partenaires au Canada.

Chiffres clés
< 100
nouveaux développeurs RPG formés par an dans le monde
IBM
8:1
ratio de réécriture RPG Free Form vers Java ou TypeScript
18-36 mois
durée typique d'un programme AS/400 de 50 à 300k lignes RPG
Méthodologie ATLAS appliquée

Du cadrage au déploiement, cinq phases structurées.

Chaque phase regroupe une ou plusieurs des dix étapes ATLAS. Aucune phase ne démarre tant que la précédente n'a pas livré son artefact validé.

  1. 01Phase 1

    Cadrage

    Étapes ATLAS
    E1 Intake · E2 Discovery · E2b Spécification fonctionnelle

    Comprendre le patrimoine RPG, COBOL/400, CL existant. Reconstituer une analyse fonctionnelle exploitable. Définir le périmètre, les contraintes, les critères de réussite.

    Livrable de phase
    Inventaire du patrimoine + spécification fonctionnelle + chiffrage
  2. 02Phase 2

    Capture & dépendances

    Étapes ATLAS
    E2e Capture · E3 Mapping des dépendances

    Figer la référence de vérité : écrans 5250, rapports, jeux de données, transactions enregistrées. Cartographier exhaustivement les sous-systèmes, files, bases DB2/400, intégrations.

    Livrable de phase
    Bench de transactions de référence + carto complète
  3. 03Phase 3

    Architecture cible

    Étapes ATLAS
    E4 Architecture cible · E4b Tests pré-migration

    Choisir la cible (Java + Spring Boot, .NET Core, TypeScript), concevoir les patterns de migration RPG, sous-fichiers SFL, data queues. Préparer la suite de tests de caractérisation avant tout portage.

    Livrable de phase
    Architecture cible signée + suite de tests de caractérisation
  4. 04Phase 4

    Migration & parité

    Étapes ATLAS
    E5 Migration · E6 Validation parité

    Traduire pattern par pattern avec traçabilité ligne à ligne. Migration incrémentale par sous-système (strangler fig). Audit de parité signé entre legacy et cible sur chaque lot livré.

    Livrable de phase
    Code cible + audit de parité par sous-système
  5. 05Phase 5

    Déploiement & transfert

    Étapes ATLAS
    E7 Livraison

    Mise en service progressive, coexistence IBM i ↔ cible pendant 6 à 24 mois, bascule transactionnelle par lot, registre interne de discordances classées, transfert d'exploitation à l'équipe cliente.

    Livrable de phase
    Application en production + équipe cliente autonome
Voir la méthodologie ATLAS complète →
Périmètre couvert

Tout l'écosystème IBM i, du RPG aux jobs batch.

RPG (RPG/400, RPG IV, ILE RPG, Free-Form RPG)

Le langage historique et moderne de l'AS/400. Nous traduisons les programmes RPG en Java 21 ou .NET Core 8 pattern par pattern, avec capture des règles métier et tests de caractérisation en amont.

COBOL/400 et OPM/ILE

Programmes COBOL hébergés sur IBM i, intégrations CL, modules ILE. Migration vers Java ou .NET avec préservation de la sémantique transactionnelle.

DDS, DB2 for i, SQL

Tables DDS et schémas SQL DB2 for i. Migration vers PostgreSQL, SQL Server ou Azure SQL avec audit de parité des données et des contraintes.

CL (Control Language)

Scripts CL d'orchestration jobs, gestion des files, planification. Conversion vers Bash, PowerShell, ou orchestrateurs cloud (Azure Logic Apps, AWS Step Functions).

Programmes 5250 et émulation

Écrans 5250 modernisés en interfaces web React ou Angular. Conservation de la logique d'écran, refonte ergonomique progressive.

Sous-systèmes, jobs batch, IFS

Inventaire complet du patrimoine IBM i : sous-systèmes, jobs batch nocturnes, IFS, stockage natif. Cartographie avant migration, plan de bascule par lot.

Cibles technologiques

Java, .NET, TypeScript, Azure : trois cibles éprouvées.

Le choix de la cible dépend de l'écosystème client : Java 21 (Spring Boot) pour les acteurs Java existants, .NET Core 8 pour les écosystèmes Microsoft, TypeScript + Node.js pour les architectures full-web. Hébergement Azure, AWS, GCP ou on-premise selon les contraintes de souveraineté.

Composition de la cellule

Une migration AS/400 mobilise une équipe spécialisée.

Six profils distincts, huit à douze personnes, sur dix-huit à trente-six mois. Reproduire cette équipe en interne est rarement réaliste — la pénurie de compétences RPG et la profondeur d'expertise ATLAS rendent l'externalisation structurellement plus rapide et moins risquée.

Durée
18 à 36 mois selon volume et criticité
Volume
8 à 12 personnes pour 50-150k lignes RPG
Profils

Architecte AS/400 ↔ Cloud

1

Pont entre les deux mondes, conception cible, gouvernance technique

Tech Lead langage cible

1

Java 21 / .NET Core 8 / TypeScript selon le choix d'architecture

Développeurs

3-6

Idéalement avec passé RPG ou COBOL pour la traduction pattern par pattern

DBA DB2/400 → PostgreSQL

1

Migration des schémas, triggers, vues matérialisées, audit de parité données

Ingénieur réseau cloud

1

Coexistence IBM i / cloud cible, sécurité, intégrations

QA & parité fonctionnelle

1-2

Bench de tests, comparaison legacy/cible, validation des audits ATLAS

Questions fréquentes

Modernisation AS/400 — ce que les DSI demandent.

Vous gérez quelles versions d'IBM i (AS/400) ?+

Toutes les versions modernes : IBM i 7.3, 7.4, 7.5 et 7.6 (sortie 2025). Pour les versions plus anciennes (V5R4, V6R1, V7R1) nous prévoyons une étape de mise à niveau intermédiaire ou un export de code source pour analyse hors plateforme.

Combien de temps prend une modernisation AS/400 typique ?+

Pour un patrimoine de 200 à 500 programmes RPG : 9 à 18 mois en mode coexistence (legacy + cible en parallèle, bascule progressive). Pour 1000+ programmes : 18 à 36 mois. La méthodologie ATLAS découpe la migration en lots transactionnels, chaque lot livré avec sa parité auditée.

Faut-il forcément réécrire ou peut-on émuler ?+

Trois approches selon le contexte : (1) Réécriture pattern par pattern vers Java/.NET — recommandée pour préparer la dette long terme. (2) Émulation cloud (LzLabs, Heirloom Computing) — bascule rapide mais conservation de la dette. (3) Refonte fonctionnelle — quand le métier veut profiter de la migration pour repenser les processus. ATLAS combine les trois selon les modules.

Comment garantir la parité fonctionnelle après migration ?+

Capture exhaustive de l'état avant migration : tests de caractérisation (E5 ATLAS), bench de transactions enregistrées en prod, snapshot des données. Après portage : runs parallèles (legacy + cible) sur même corpus de transactions, comparaison des résultats champ à champ. Audit de parité signé avant bascule.

L'équipe Access connaît-elle les spécificités IBM i ?+

Oui. Nos consultants couvrent l'écosystème IBM i depuis vingt ans : RPG ILE, free-form, embedded SQL, IFS, journalisation, sous-systèmes. La nouveauté Watson Code Assistant for i (IBM 2024) est intégrée à nos chaînes de production. Plusieurs profils certifiés IBM i Developer.

Comment se déroule la coexistence pendant la transition ?+

Pattern strangler fig : le système cible cohabite avec l'AS/400 pendant 6 à 24 mois. Les transactions sont routées vers l'un ou l'autre selon leur état de migration. Synchronisation bidirectionnelle des données critiques. Bascule transactionnelle par lot avec fallback automatique en cas d'écart.

Vos centres de delivery sont où ?+

Centre nearshore principal à Tunis (UTC+1, fuseau européen). Présence en France via notre filiale Vivantro pour la relation client et l'expertise locale. Co-delivery avec partenaires au Canada pour les programmes nord-américains. Cette structure couvre toutes les contraintes de localisation des données (Loi 25 Québec, RGPD UE).

Réalisations

Cas clients liés

Secteur public — Amérique du Nord
Modernisation TI et transformation numérique d'un organisme public nord-américain
Voir la réalisation →
Multi-sectoriel
POC de migration legacy (COBOL, Delphi, BizTalk, mainframe)
Voir la réalisation →
Capacité Access — POC interne
Capacité
Capacité Delphi → .NET Core 8 validée sur POC interne
Voir la réalisation →

Insights récents

POC & retour d'expérience
10 POCs migration legacy : nos learnings
Méthodologie propriétaire
ATLAS : la modernisation legacy prévisible
IA & productivité
Vibe coding : consultants augmentés par IA

Vous évaluez une migration AS/400 ?

Nous démarrons par un audit de patrimoine (4 à 6 semaines) : inventaire des programmes RPG, cartographie des dépendances, analyse de complexité, recommandation cible. Le rapport est exploitable directement par le client, qu'il choisisse ou non Access pour la suite.

Demander un audit AS/400 →Méthodologie ATLAS →