Architecte AS/400 ↔ Cloud
Pont entre les deux mondes, conception cible, gouvernance technique
Loading...
Loading...
Migration d'applications AS/400 (IBM i, RPG, DB2/400) vers Java, .NET Core ou TypeScript. Méthodologie ATLAS.
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é. La méthodologie ATLAS rend la migration AS/400 prévisible et auditable.
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.
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.
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.
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é.
Mise en service progressive, coexistence IBM i ↔ cible dont la durée est définie au cadrage selon le profil de risque, bascule transactionnelle par lot, registre interne des discordances classées, transfert d'exploitation à l'équipe cliente.
Les outils de conversion automatique de code legacy produisent du code qui compile, mais qui reste illisible et non maintenable : les patterns d'origine sont recopiés tels quels, sans idiomatisation, avec des dépendances à une runtime propriétaire. Mis en production sans re-caractérisation complète, ce code n'est ni fiable ni évolutif. La traduction automatique de bout en bout n'est pas une méthode de modernisation — c'est un transfert de dette.
Notre méthode est inverse. ATLAS repose sur plusieurs lectures du code legacy, menées selon plusieurs angles : flux de données, règles métier, dépendances, cas limites. L'IA intervient ici comme accélérateur de compréhension — pour déchiffrer des décennies de logique métier accumulée, rétro-documenter des branches non commentées, expliciter l'intention derrière le code. Elle ne décide pas et ne traduit pas : elle éclaire le travail de l'architecte, qui conçoit ensuite l'architecture cible (cloud, base de données, services) et pilote la migration pattern par pattern, sous audit de parité.
Cette compréhension exige encore des humains qui connaissent les langages legacy. C'est notre avantage : là où l'Europe et l'Amérique du Nord font face à une vague de départs en retraite des développeurs mainframe et legacy, la Tunisie conserve un vivier de développeurs expérimentés (COBOL, Delphi, PowerBuilder, RPG…). Couplés à des architectes et développeurs modernes formés à la méthode ATLAS, ils assurent la continuité entre l'intention métier d'origine et le système cible.
L'AS/400 — renommé IBM i depuis 2008 — reste remarquablement présent dans les PME et ETI des secteurs distribution, industrie manufacturière, logistique, agroalimentaire, retail. Beaucoup de ces entreprises ont acquis leur AS/400 dans les années 1990 à 2005 et l'exploitent toujours. La plateforme se distingue par sa stabilité opérationnelle exceptionnelle (disponibilité supérieure à 99,99 pour cent sans intervention), son modèle intégré (OS, base de données DB2/400 intégrée, sécurité native) et sa longévité (code écrit en 1995 tourne encore aujourd'hui sans recompilation).
Trois forces poussent à la modernisation IBM i : pénurie croissante de développeurs RPG (IBM indique moins de 100 nouveaux développeurs formés par an dans le monde), coûts de licence IBM Power significatifs à renouvellement matériel, et limitations d'intégration avec les API modernes REST, GraphQL, événementielles. Les DSI hésitent car l'AS/400 fonctionne parfaitement, mais la falaise démographique des compétences RPG rend la décision inévitable à horizon 5-10 ans. Notre méthodologie ATLAS est adaptée à cette trajectoire longue.
Un parc AS/400 combine typiquement trois langages : RPG (le plus répandu, depuis RPG II jusqu'au RPG Free Form moderne), COBOL (parfois cohabitant avec RPG), CL (Control Language pour les scripts système). Chaque langage a ses propres patterns de migration. RPG II / III classique se migre plus difficilement que RPG Free Form qui se rapproche d'un langage moderne. Le COBOL sur AS/400 suit le parcours COBOL vers Java ou .NET Core. Le CL est généralement réécrit directement en shell script ou en orchestrateur moderne (Airflow, Kubernetes CronJobs).
Java, .NET Core, TypeScript, PostgreSQL, conteneurs
Parc AS/400 stratégique, besoin de robustesse transactionnelle, équipes Java en interne ou accessibles via intégrateurs. Choix par défaut pour les PME et ETI qui veulent un code maintenable à long terme.
Écosystème Microsoft dominant dans le SI, intégration avec Dynamics 365 ou Power Platform. Voir COBOL vers .NET Core pour les subtilités arithmétiques.
Workloads modérés, priorité à la vélocité et au coût cloud. Adapté aux applications de gestion et e-commerce. Voir COBOL vers TypeScript.
Urgence de sortir du hardware physique sans refonte immédiate. Approche lift-and-shift qui préserve le RPG sur cloud IBM. Utile comme palier temporaire, pas comme cible finale.
Une modernisation AS/400 se structure par lots fonctionnels successifs, dont la cadence est définie au cadrage selon le volume et la criticité. La cellule combine un architecte AS/400-cloud capable de ponter les deux mondes, un tech lead sur le langage cible (Java, .NET, TypeScript), des développeurs idéalement avec un passé RPG ou COBOL, un DBA DB2/400-PostgreSQL pour la migration des données, un ingénieur réseau cloud, un QA. La composition et l'effectif ne sont pas fixés à l'avance : ils sont déterminés à l'issue du POC et du cadrage, une fois le travail réel mesuré.
Sous-estimer la particularité des sous-fichiers RPG (SFL). Les sous-fichiers 5250 sont des patterns d'affichage tabulaire avec pagination native qui n'ont pas d'équivalent direct en web moderne.
Portage explicite des sous-fichiers vers des data tables web (AG Grid, Material UI Table) avec pagination cursor-based. Les fonctions natives AS/400 (READC, REFRESH, UPDATE) sont reproduites en endpoints REST avec gestion d'état côté client. Tests de parité UX sur les workflows de saisie/consultation massive.
Ignorer les data queues et les data areas AS/400, mécanismes de communication inter-programmes propres à l'IBM i.
Remplacement par des files de messages modernes (Azure Service Bus, RabbitMQ, Apache Kafka selon contexte). Les data areas globales deviennent des entrées dans Redis ou une base clé-valeur. Tests unitaires sur les patterns de communication producteur-consommateur pour valider l'isofonctionnalité.
Oublier les particularités de DB2/400. DB2 for i diffère de DB2 classique et de PostgreSQL par ses règles d'intégrité, ses triggers, ses contraintes de nommage (noms longs versus tables système 10 caractères).
Cartographie exhaustive des schémas DB2/400 dès la phase discovery. Migration vers PostgreSQL avec adaptation des noms de tables, triggers portés en fonctions PL/pgSQL, vues matérialisées reproduites. Tests de parité sur jeux de données représentatifs avec reconciliation automatique.
Négliger les mécanismes de sécurité IBM i (profils utilisateurs, autorités, groupes système). L'IBM i a une sécurité intégrée très fine que les systèmes cibles ne reproduisent pas nativement.
Modèle RBAC cible conçu dès l'architecture (Role-Based Access Control). Les profils utilisateurs AS/400 sont mappés vers un annuaire moderne (Active Directory, Keycloak, Auth0) avec rôles et permissions granulaires. Tests de non-régression sur chaque profil utilisateur avec scénarios d'accès représentatifs.
Vouloir tout migrer d'un coup. Un parc AS/400 accumulé sur 15 à 25 ans contient souvent des programmes oubliés, des dépendances cachées, des workflows non documentés.
Stratégie strangler fig obligatoire. On migre sous-système par sous-système, les transactions les moins critiques d'abord. Coexistence IBM i-cloud pendant 2 à 4 ans. Décommission progressive des programmes migrés. Voir la méthodologie ATLAS pour le protocole détaillé.
Plusieurs profils distincts, mobilisés sur la durée du programme. Reproduire cette cellule en interne est rarement réaliste — la pénurie des compétences legacy et la profondeur d'expertise ATLAS rendent l'externalisation structurellement plus rapide et moins risquée.
Pont entre les deux mondes, conception cible, gouvernance technique
Java 21 / .NET Core 8 / TypeScript selon le choix d'architecture
Idéalement avec passé RPG ou COBOL pour la traduction pattern par pattern
Migration des schémas, triggers, vues matérialisées, audit de parité données
Coexistence IBM i / cloud cible, sécurité, intégrations
Bench de tests, comparaison legacy/cible, validation des audits ATLAS
Patterns RPG AS/400 testés dans le cadre de nos 10 POC globaux. Le langage RPG Free Form moderne se migre avec un ratio proche du COBOL, autour de 8:1 vers Java ou TypeScript. Les particularités (sous-fichiers, data queues, DB2/400) sont documentées dans notre catalogue ATLAS.
Oui, IBM continue d'investir dans IBM i. La version actuelle IBM i 7.5 est sortie en 2022 et une version 7.6 était annoncée. IBM garantit le support jusqu'à 2030 au minimum pour les versions récentes. La décision de migrer ne vient donc pas d'une fin de support IBM imminente, mais de considérations stratégiques : pénurie de compétences RPG, coûts, intégration web moderne. C'est une décision à prendre à horizon 5-10 ans, pas dans l'urgence.
Oui, c'est le web-facing d'IBM i. Des outils comme Profound UI, looksoftware, Aura, ou les composants Rational Open Access for RPG permettent d'habiller une application RPG existante d'une interface web sans réécrire le back-end. Avantages : modernisation rapide, préservation du code métier, moindre investissement. Inconvénients : dépendance éditeur, limites d'évolution, coûts de licence. C'est une solution de transition, pas une stratégie long terme — à combiner avec un plan de migration progressive du back-end.
RPG Free Form moderne : ratio environ 8:1 (8 lignes RPG pour 1 ligne Java/TypeScript), comparable au COBOL. RPG II / III classique : ratio plus serré 5:1, car le RPG ancien est très verbeux avec ses spécifications figées. Le CL se traduit avec un ratio variable selon le shell cible (bash, PowerShell, orchestrateur). Les volumes cibles sont plus réduits que les sources grâce aux briques de framework modernes.
Les écrans 5250 sont remplacés par une interface web moderne (React, Angular, Vue). Les workflows 5250 orientés touche fonction (F3 = sortie, F12 = retour) sont traduits en workflows web avec boutons explicites et raccourcis clavier web configurables. Les sous-fichiers 5250 deviennent des tables web paginées. L'expérience utilisateur est repensée — les utilisateurs formés au 5250 ont besoin d'accompagnement pendant la transition mais trouvent généralement la version web plus productive après 4 à 6 semaines d'usage.
Pour un parc de cent mille lignes RPG avec une cinquantaine d'écrans 5250 en co-delivery nearshore, comptez un million à un million cinq cent mille euros incluant UX, développement, tests, formation utilisateurs. Pour trois cent mille lignes, budget deux à quatre millions d'euros. Coût typique inférieur à une migration mainframe grâce à la taille plus modeste des parcs. Voir les modèles de delivery pour les formats contractuels.
Oui, c'est même un bon fit. Le modèle BOT consiste à confier la cellule de modernisation à Access pendant 2-4 ans, puis transférer progressivement l'équipe à votre interne. Adapté aux ETI qui veulent internaliser leurs compétences cibles tout en évitant le risque de démarrage. Voir le centre de développement pour les modalités contractuelles du BOT.
Il n'y a pas de fin de vie imposée par IBM pour l'AS/400 — IBM l'a renommé iSeries puis IBM i et continue d'investir activement dans la plateforme. La version actuelle IBM i 7.5 est sortie en 2022 avec support garanti au moins jusqu'à 2030. La décision de moderniser ne vient donc pas d'une fin de support IBM imminente. Les vrais déclencheurs sont : pénurie de développeurs RPG, coût matériel (les systèmes Power ne sont pas bon marché), friction d'intégration moderne (cloud, mobile, IA imposent des contournements), et besoins d'agilité que l'écran 5250 ne peut pas suivre. La modernisation est une décision stratégique à 5-10 ans, pas une urgence. La méthodologie ATLAS encadre la modernisation AS/400 vers Java, .NET Core ou TypeScript avec parité prouvée. Voir le parcours AS/400.
Cela dépend de votre écosystème existant et de ce que vous attendez de la migration. Choisissez Java quand votre plateforme est déjà bâtie autour de Spring, Kafka, Kubernetes ou de bases open source (PostgreSQL, MariaDB) — la profondeur de bibliothèque de Java sur les transactions financières, le record I/O à la AS/400 et la stabilité long terme du langage en font le défaut le plus sûr pour les gros parcs RPG. Choisissez .NET Core 8 quand votre organisation tourne sur Microsoft (Azure, Dynamics 365, Power Platform) — l'interop avec le reste de la stack fait économiser de l'argent réel, et le C# moderne est désormais au niveau de Java sur toutes les dimensions qui comptent. Mais le choix Java vs .NET est la deuxième décision. La première : quelle expérience vous voulez derrière — quitter l'écran 5250, exposer le système en APIs, préparer le code à l'évolution assistée par IA. Un portage ligne-à-ligne a le pire ROI possible. La méthodologie ATLAS cadre cela avec un registre interne de discordances classées.
Trois manières concrètes de démarrer — du diagnostic gratuit à la cellule de modernisation. Notre approche AS/400 / IBM i 7.5/7.6 est documentée, chiffrée, et applicable dès la première rencontre.