Comment migrer une application AS/400 (IBM i) vers une application web sur-mesure
Migrer une application AS/400 (IBM i) vers une application web sur-mesure prend 6 à 12 semaines et environ 6 000 – 19 000 € de reprise des données, en plus du nouvel outil (5 000 à 20 000 € par lot). Beaucoup d'industriels, de distributeurs et de transporteurs font encore tourner leur gestion sur une application AS/400, aujourd'hui IBM i, développée en RPG ou en COBOL il y a des décennies.
Par Baptiste Lamidey, fondateur de Trinity StudioMis à jour le
Migrer une application AS/400 (IBM i) : repères
- Durée de migration
- 6 à 12 semaines
- Reprise des données (en plus du nouvel outil)
- 6 000 – 19 000 €
- Situation de départ
- application vieillissante
- Solutions cibles
- ERP sur-mesure, outil de gestion et portail client B2B
Les signes qu’il est temps de quitter une application AS/400 (IBM i)
Beaucoup d'industriels, de distributeurs et de transporteurs font encore tourner leur gestion sur une application AS/400, aujourd'hui IBM i, développée en RPG ou en COBOL il y a des décennies. Le système est robuste, mais les écrans verts rebutent les nouveaux collaborateurs, les développeurs RPG partent à la retraite, chaque évolution prend des semaines et l'ouverture vers le web, le mobile ou les partenaires passe par des passerelles bricolées.
Les problèmes qui s’accumulent
- Les développeurs RPG et COBOL se raréfient, et chaque départ emporte une partie de la connaissance des programmes.
- Les écrans en mode texte allongent la formation des nouveaux arrivants et multiplient les erreurs de saisie.
- Ouvrir les données à un portail client, une application mobile ou un partenaire demande des développements lourds et lents.
- Le coût du matériel, des licences et de la maintenance reste élevé alors que l'usage réel se concentre sur quelques modules.
Un projet comme celui-ci ? Obtenez un ordre de grandeur sous 24 h
- Réponse du fondateur, pas d’un commercial
- Budget plafonné à 20 000 €, code source livré
- Cadrage gratuit, sans engagement
Migrer sans rupture d’activité : 5 étapes
Cartographier programmes et fichiers
Inventorier les bibliothèques, programmes, fichiers physiques et logiques, travaux planifiés et interfaces, puis identifier avec les utilisateurs les traitements réellement utilisés au quotidien et ceux devenus inutiles.
Ouvrir les données sans tout casser
Exposer les données utiles par une API au-dessus de la base DB2 for i, pour construire de nouveaux écrans sans toucher aux programmes historiques pendant la transition.
Moderniser par module
Reconstruire d'abord les écrans les plus utilisés et les besoins nouveaux, comme le portail client ou le mobile, en application web connectée à cette API.
Reprendre la logique métier
Relire les programmes RPG ou COBOL des modules à remplacer, réécrire les règles en langage moderne avec des tests, et comparer les résultats sur des jeux de données réels.
Arrêter le système progressivement
Basculer les modules un par un, réduire la charge de l'AS/400 à mesure, puis l'arrêter ou le limiter à l'archive quand plus aucun traitement critique n'en dépend.
Récupérer les données existantes
Les données d'un AS/400 vivent dans la base DB2 for i, lisible en SQL par ODBC ou JDBC. Les fichiers physiques sans description complète demandent une analyse des formats, notamment des champs numériques condensés et des dates stockées en nombres.
Risques à maîtriser
- Des travaux planifiés de nuit, invisibles pour les utilisateurs, alimentent d'autres systèmes et sont découverts après leur arrêt.
- Les champs numériques condensés et les dates codées en nombres faussent la reprise s'ils ne sont pas convertis avec soin.
- Vouloir tout réécrire d'un bloc retarde le projet de plusieurs années et fait perdre la confiance des équipes.
Questions fréquentes
Faut-il arrêter l'AS/400 tout de suite ?
Non. La méthode la plus sûre ouvre d'abord ses données par une API, construit les nouveaux écrans autour, puis remplace les modules un par un jusqu'à pouvoir l'arrêter.
Peut-on lire les données DB2 de l'AS/400 ?
Oui, en SQL par ODBC ou JDBC. Les formats particuliers, comme les numériques condensés et les dates stockées en nombres, sont convertis et contrôlés pendant la reprise.
Nos développeurs RPG ont-ils un rôle dans le projet ?
Un rôle central. Ils connaissent la logique des programmes et les traitements cachés, et leur participation réduit fortement le risque d'oubli pendant la modernisation, module après module.
Méthode et sources
Budget de migration = durée × 1 000 à 1 600 € par semaine : la reprise des données est menée à temps partiel pendant le lot de développement. Estimation indicative avant audit de l’existant.
Mise à jour : octobre 2026. Auteur : Baptiste Lamidey, fondateur de Trinity Studio. Ces valeurs sont des estimations indicatives destinées à cadrer un budget, pas un devis : un chiffrage ferme demande un cadrage du périmètre.
Recevez un chiffrage adapté à votre contexte
Cinq questions, une réponse sous 24h ouvrées, sans engagement.
