On va parler d'un sujet que je connais bien pour l'avoir vécu plusieurs fois chez des clients industriels : la migration d'un AS/400 (IBM i) vers une architecture web moderne. Si vous lisez cet article, c'est probablement que vous avez un système RPG/COBOL qui tourne depuis 15 ou 20 ans, que le dernier dev qui savait le maintenir est parti à la retraite, et que votre direction commence à paniquer.
Bonne nouvelle : c'est faisable. Mauvaise nouvelle : c'est un projet sérieux. Voici ce que j'ai appris sur le terrain.
Pourquoi migrer maintenant (et pas dans 5 ans)
Le problème numéro un, c'est la pénurie de compétences RPG/COBOL. En 2026, trouver un développeur RPG en France qui accepte un CDD, c'est comme chercher un plombier un dimanche : techniquement possible, financièrement douloureux. Les tarifs journaliers ont explosé — on parle de 800 à 1 200 € HT/jour pour un freelance RPG senior, contre 450-650 € pour un dev Python/Java de niveau équivalent.
Deuxième problème : l'intégration. Votre AS/400 est une île. Il ne parle pas REST, il ne comprend pas les webhooks, il ne sait pas envoyer un email sans passer par trois couches de middleware. Chaque nouveau besoin d'intégration (site e-commerce, CRM, appli mobile) nécessite un développement spécifique qui coûte une fortune.
Troisième raison, moins visible mais critique : la dette technique invisible. Les programmes RPG accumulés sur 20 ans forment un monolithe dont personne ne connaît vraiment les contours. J'ai vu des clients avec 3 000+ programmes RPG dont un tiers n'était plus utilisé — mais personne n'osait les supprimer.
Les 3 approches de migration
1. Le wrapping (encapsulation)
Principe : on garde l'AS/400, on colle une couche API par-dessus. Le système historique continue de tourner, mais on y accède via REST/JSON depuis les nouvelles applis.
Concrètement, IBM propose des outils comme IBM i Access Client Solutions ou des services web PCML. On peut aussi utiliser des connecteurs ODBC/JDBC pour taper directement dans DB2 for i :
import pyodbc
conn = pyodbc.connect(
driver='{iSeries Access ODBC Driver}',
system='192.168.1.50',
uid='QUSER',
pwd='motdepasse',
database='PRODLIB',
translate=1,
)
cursor = conn.cursor()
cursor.execute("SELECT CLNCOD, CLNNOM, CLNTEL FROM FICLIENT WHERE CLNACT = 'O'")
clients = cursor.fetchall()
# → [('C001', 'DUPONT SA', '0145678900'), ...]
Avantages : rapide à mettre en place (2-4 mois), risque faible, l'existant continue de tourner.
Inconvénients : on ne résout pas le problème de fond. Le jour où l'AS/400 tombe, tout tombe. Et on paie toujours la maintenance IBM.
Verdict : c'est une bonne solution transitoire, pas une solution définitive. Utile pour débloquer un besoin urgent d'intégration en attendant une vraie migration.
J'ai un client qui a fait du wrapping en 2021 pour connecter son AS/400 à un site e-commerce Prestashop. Les stocks et les prix remontaient en temps réel via une API Flask intermédiaire. Ça a fonctionné pendant 3 ans, le temps de préparer la vraie migration. Le wrapping leur a permis de ne pas rater le virage du e-commerce tout en gardant leur système de gestion historique. Coût total du wrapping : 18 000 € — largement rentabilisé par les ventes en ligne.
2. La réécriture complète
On repart de zéro. On analyse les processus métier, on les re-spécifie, et on développe une application web from scratch. C'est l'approche la plus propre, mais aussi la plus risquée et la plus longue.
Un exemple typique : réécrire un module de gestion des stocks AS/400 en Django :
# models.py — module stock réécrit
from django.db import models
class Article(models.Model):
code = models.CharField(max_length=20, unique=True, db_index=True)
designation = models.CharField(max_length=200)
famille = models.ForeignKey('FamilleArticle', on_delete=models.PROTECT)
stock_physique = models.DecimalField(max_digits=12, decimal_places=3, default=0)
stock_reserve = models.DecimalField(max_digits=12, decimal_places=3, default=0)
seuil_alerte = models.DecimalField(max_digits=12, decimal_places=3, default=0)
prix_achat_moyen = models.DecimalField(max_digits=10, decimal_places=4, default=0)
emplacement = models.CharField(max_length=20, blank=True)
actif = models.BooleanField(default=True)
@property
def stock_disponible(self):
return self.stock_physique - self.stock_reserve
def en_alerte(self):
return self.stock_disponible <= self.seuil_alerte
Avantages : architecture moderne, maintenable, performante. On peut recruter facilement. On profite de l'écosystème Python/Django (ORM, admin, REST framework, tests).
Inconvénients : coût élevé (voir section suivante), durée longue (12-24 mois), risque de périmètre qui explose.
3. L'approche hybride (recommandée)
C'est celle que je recommande dans 80% des cas. On migre par lots fonctionnels, en commençant par les modules les plus critiques ou les plus douloureux. L'AS/400 et la nouvelle appli coexistent pendant la transition, avec une synchronisation DB2 ↔ PostgreSQL.
# sync_clients.py — synchronisation incrémentale DB2 → PostgreSQL
import pyodbc
from datetime import datetime, timedelta
from clients.models import Client
def sync_depuis_as400(depuis=None):
if depuis is None:
depuis = datetime.now() - timedelta(hours=1)
conn = pyodbc.connect(DSN='AS400_PROD')
cursor = conn.cursor()
cursor.execute(
"SELECT CLNCOD, CLNNOM, CLNMAIL, CLNMAJ FROM FICLIENT WHERE CLNMAJ >= ?",
depuis.strftime('%Y-%m-%d-%H.%M.%S')
)
nb_sync = 0
for row in cursor:
Client.objects.update_or_create(
code_legacy=row.CLNCOD,
defaults={
'raison_sociale': row.CLNNOM.strip(),
'email': row.CLNMAIL.strip() if row.CLNMAIL else '',
'derniere_synchro': datetime.now(),
}
)
nb_sync += 1
conn.close()
return nb_sync
On migre d'abord la gestion commerciale, puis la facturation, puis les stocks, etc. Chaque lot est un projet autonome avec ses tests, sa mise en production, sa période de double run.
Le point clé de l'approche hybride, c'est la synchronisation bidirectionnelle. Pendant la période de coexistence, les données doivent être cohérentes entre les deux systèmes. C'est techniquement le morceau le plus délicat. Il faut gérer les conflits (quand le même enregistrement est modifié des deux côtés), la latence (la synchro n'est pas instantanée), et les différences de schéma (un champ "ville" sur l'AS/400 peut être un code commune à 5 chiffres ou un texte libre selon l'ancienneté de l'enregistrement).
En pratique, je mets en place une table de synchronisation intermédiaire avec des timestamps et un mécanisme de résolution de conflits simple : le dernier écrit gagne, avec un log de toutes les résolutions pour audit. C'est pas parfait, mais c'est pragmatique et ça marche dans 99% des cas.
Coûts réalistes
Voici les fourchettes que j'ai constatées sur des projets réels en PME/ETI :
| Approche | Durée | Budget estimé | Risque |
|---|---|---|---|
| Wrapping API | 2-4 mois | 15 000 — 40 000 € | Faible |
| Réécriture complète | 12-24 mois | 80 000 — 300 000 € | Élevé |
| Hybride par lots | 6-18 mois | 40 000 — 150 000 € | Modéré |
Ces chiffres incluent l'analyse, le développement, les tests, la reprise de données et la mise en production. Ils n'incluent pas l'hébergement, la maintenance corrective ni la formation utilisateurs.
Un point souvent sous-estimé : la reprise de données. Extraire 20 ans de données d'un AS/400, les nettoyer, les transformer et les injecter dans un nouveau schéma relationnel, c'est facilement 20-30% du budget total.
La méthodologie par lots
Voici comment je structure un projet hybride :
- Lot 0 — Audit (2-4 semaines) : inventaire des programmes RPG, cartographie des flux, identification des données critiques, interviews utilisateurs. Livrable : document de cadrage avec priorisation des modules.
- Lot 1 — Socle technique (4-6 semaines) : mise en place de l'infrastructure (serveur, CI/CD, base de données), connecteur DB2, mécanisme de synchronisation bidirectionnelle.
- Lot 2 à N — Modules métier (6-12 semaines chacun) : chaque module suit le cycle analyse → développement → tests → double run → bascule → décommissionnement AS/400.
Le double run est non-négociable. Pendant 2 à 4 semaines, les deux systèmes tournent en parallèle. Les écarts sont analysés quotidiennement. C'est pénible mais c'est ce qui garantit une migration sans perte de données.
Les pièges à éviter
En vrac, les erreurs que j'ai vues (ou commises) :
- Vouloir tout migrer d'un coup. C'est le meilleur moyen de ne jamais finir. Commencez par un module non-critique pour roder l'équipe et le processus.
- Ignorer les règles métier cachées. Sur un AS/400 de 20 ans, il y a des règles de gestion enfouies dans des programmes RPG que personne ne documente. Un SETON qui modifie un indicateur dans un sous-programme appelé par un CL qui lance un batch la nuit — bon courage pour retrouver ça.
- Sous-estimer l'encodage. DB2 for i utilise EBCDIC (CCSID 297 en France). Les accents, les caractères spéciaux, les champs packed decimal... ça demande un travail de conversion sérieux.
- Négliger la formation. Vos utilisateurs travaillent sur écran vert 5250 depuis 15 ans. Le passage à une interface web est un changement majeur. Prévoyez du temps et du budget pour l'accompagnement.
- Oublier les impressions. L'AS/400 gère les spools d'impression nativement. En web, il faut recréer tous les états avec ReportLab, WeasyPrint ou équivalent. C'est souvent 10-15% du développement.
Retour d'expérience : migration d'un ERP industriel
Dernier projet en date : une PME industrielle de 80 salariés dans l'usinage de précision. AS/400 en place depuis 1998, environ 1 200 programmes RPG, base DB2 de 45 Go.
On a procédé en 4 lots sur 14 mois :
- Lot 1 : Gestion commerciale (devis, commandes, clients) — Django + DRF + React
- Lot 2 : Facturation et comptabilité auxiliaire — Django + ReportLab pour les PDF
- Lot 3 : Gestion des stocks et nomenclatures — Django + Celery pour les calculs MRP
- Lot 4 : Planification atelier — module custom avec ordonnancement
Budget final : 127 000 € HT (contre 95 000 € estimé — le lot 3 a dérapé à cause de règles de calcul de prix de revient non documentées).
Résultat : l'AS/400 est éteint depuis 6 mois. Les utilisateurs sont autonomes. Le coût de maintenance annuel est passé de 35 000 €/an (licence IBM + prestations RPG) à environ 8 000 €/an (hébergement + maintenance évolutive ponctuelle). ROI atteint en moins de 3 ans.
Le moment le plus stressant ? La bascule du lot 2 (facturation). On avait 850 factures en cours au moment du switch. Le double run a révélé 3 écarts de montant sur les premières 24h — deux erreurs d'arrondi TVA (notre nouveau code arrondissait à 2 décimales au lieu de 4 en intermédiaire), et un cas tordu de facture d'avoir sur un avoir (le programme RPG faisait un truc très créatif avec les montants négatifs). Corrigé en 2 jours, mais ça illustre pourquoi le double run est absolument indispensable.
Un autre point souvent oublié : la reprise d'historique. Les utilisateurs veulent retrouver leurs 10 dernières années de factures dans le nouveau système. Ça veut dire extraire des données de fichiers DB2 avec des formats qui ont changé 3 fois au fil des années, les nettoyer (caractères EBCDIC mal convertis, dates au format AAAAMMJJ, montants en packed decimal), et les injecter dans le nouveau schéma. Sur ce projet, la reprise d'historique a représenté 18% du budget total.
Le test utilisateur final a été révélateur. On avait formé les 15 utilisateurs principaux sur 3 demi-journées. La plupart se sont adaptés en une semaine. Deux personnes ont eu plus de mal — des habitudes de 20 ans sur écran vert, ça ne se change pas du jour au lendemain. On leur a créé des raccourcis clavier personnalisés qui reproduisaient leurs workflows habituels. Au bout d'un mois, plus personne ne voulait revenir en arrière.
Les outils et technologies à connaître
Si vous vous lancez dans une migration AS/400, voici les outils que j'utilise et que je recommande :
Pour la connexion DB2 : pyodbc avec le driver IBM i Access ODBC. C'est le plus stable. Alternative : ibm_db (le driver officiel IBM pour Python), mais il est plus capricieux à installer sur Linux. JTOpen (JDBC via jaydebeapi) est une option si vous avez déjà un écosystème Java.
Pour le développement web : Django, sans hésiter. L'admin Django remplace avantageusement les écrans 5250 pour la saisie de données. DRF (Django REST Framework) si vous avez besoin d'API. Pour le front, ça dépend : du vanilla JS suffit pour des interfaces CRUD simples, React ou Vue.js si c'est plus complexe (grilles de données interactives, drag and drop).
Pour les états et rapports : ReportLab pour les PDF (factures, bons de livraison), openpyxl pour les exports Excel, WeasyPrint si vous préférez générer des PDF à partir de HTML/CSS (plus flexible pour le layout, mais plus lent).
Pour l'ETL et la migration de données : pandas pour le nettoyage et la transformation. Pour les gros volumes (>1M de lignes), passez à polars qui est significativement plus rapide. Un script de migration bien écrit en Python avec des vérifications d'intégrité à chaque étape vaut mieux que n'importe quel outil ETL graphique.
Pour le déploiement : Docker + Docker Compose. L'application tourne dans un conteneur, la base PostgreSQL dans un autre, un reverse proxy nginx devant. Déploiement reproductible et rollback facile. Pour la CI/CD, GitHub Actions ou GitLab CI font parfaitement le job.
Et maintenant ?
Si vous avez un AS/400 et que vous envisagez une migration, commencez par un audit. Pas un audit à 50 000 € fait par un gros cabinet, mais un état des lieux pragmatique : combien de programmes, lesquels sont encore utilisés, quels sont les flux de données critiques, quels modules sont les plus douloureux.
C'est exactement le type de mission que je fais régulièrement. Un audit de 2-3 semaines qui vous donne une vision claire du chemin à parcourir, avec un planning et un budget réalistes. Toutes les infos sur mon accompagnement migration AS/400 sont ici.