Sur IBM i, la dette technique ne se voit pas toujours… jusqu’au jour où il faut modifier un programme RPG de 3 000 lignes, sans commentaire, sans versioning, écrit il y a 20 ans par un développeur parti à la retraite.

Voici où elle se cache vraiment :

🔹 Code RPG ou RPGLE monolithique
Fonctions métiers imbriquées, pas de modularisation, aucune séparation des responsabilités. Résultat : chaque modification est risquée, difficile à tester, et difficilement industrialisable.

🔹 Absence de documentation et de cartographie
Quand le seul référentiel est dans la tête de l’expert historique, chaque départ fait perdre du capital technique. Pas de vision claire des appels de programmes, des dépendances entre fichiers, ou des flux inter-applicatifs.

🔹 Bases DB2 figées
Des structures de fichiers DDS non normalisées, un langage DDS « figé » par IBM depuis 1992, des champs surchargés, des données orphelines ou en doublon, une absence de métadonnées ou d’index modernes et une complexité pour les outils BI ou les API.

🔹 Pas de DevOps, pas de CI/CD
Pas de gestion de version (ou alors à la main), pas de pipeline d’intégration, pas de tests automatisés. Livrer en production, c’est prier que ça passe. Pas de rollback possible sans stress.

💡 Et pourtant, il existe des solutions :

✅ Cartographie automatique des programmes, fichiers et dépendances
✅ Modernisation des bases de DDS à SQL, documentation du modèle relationnel, anonymisation des données sensibles…
✅ Transformation du code RPG en RPG Free
✅ Mise en place d’une logique DevOps adaptée à l’IBM i

➡️ La dette technique sur IBM i est une réalité. Mais elle peut être traitée comme un projet structurant.

Chez Itheis, nous intervenons pour documenter, diagnostiquer et transformer votre SI IBM i de manière progressive et sécurisée.

📩 Un projet, un doute, un héritage à éclaircir ? Discutons-en.