Moderniser un parc AS/400 vers des architectures cloud-natives.

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.