RPG – quo vadis ?

Aujourd'hui, le terme RPG évoque des images très différentes selon les générations.
Pour les uns, il s'agit de C-Specs, d'indicateurs et de programmes dont le sens ne devient parfois clair que lorsqu'on sait dans quelle colonne se trouve un caractère. Pour les autres, RPG est un langage de programmation entièrement libre de contraintes de colonnes, avec des procédures, des variables locales, des structures de données complexes, du SQL embarqué, des API et des outils de développement modernes.
Ces deux visions sont justes.
RPG compte parmi les plus anciens langages de programmation encore utilisés quotidiennement pour des applications critiques pour l'entreprise. IBM l'a développé à la fin des années 1950 sous le nom de « Report Program Generator », initialement destiné au traitement commercial des données. De RPG II à RPG IV, en passant par RPG III et RPG/400, un langage fortement orienté formulaires et enregistrements est progressivement devenu un langage moderne de programmation métier pour IBM i.1
La question la plus intéressante aujourd'hui n'est donc pas de savoir si RPG est ancien : cela ne fait aucun doute.
La véritable question est : où en est RPG aujourd'hui – et dans quelle direction évolue-t-il ?

De RPG/400 à ILE RPG

RPG IV, ou ILE RPG, a marqué un tournant majeur.
Avec l'Integrated Language Environment, RPG s'est affranchi de l'idée selon laquelle un programme devait nécessairement constituer un ensemble volumineux et autonome. Les programmes pouvaient être composés de modules, les procédures encapsulées et les fonctions communes déplacées dans des Service Programs.
Les Service Programs permettent de mettre des fonctions à la disposition de plusieurs programmes au moyen d'interfaces définies. IBM les présente explicitement comme un moyen de réutiliser des fonctions communes et de simplifier la maintenance.2
De nombreux concepts aujourd'hui associés au développement logiciel modulaire étaient ainsi disponibles :
  • Procedures
  • Modules
  • Service Programs
  • Prototypes
  • variables locales
  • interfaces clairement définies
  • séparation des fonctionnalités publiques et internes
Malgré cela, le code source RPG a longtemps conservé l'apparence du RPG classique. La transformation majeure suivante fut donc moins architecturale que visuelle et syntaxique.

La libération des colonnes

Quiconque connaît RPG/400 ou les premières versions de RPG IV sait à quel point le langage dépendait de positions fixes dans les Source Members.
En 2013, IBM a introduit les déclarations Free-Form, notamment pour les spécifications H, F, D et P. Fully Free RPG a suivi en 2015. Pour la première fois, il devenait possible d'écrire entièrement du code RPG sans la structure traditionnelle en colonnes.3
Un programme RPG moderne peut, par exemple, commencer ainsi :
RPGLE_FREE
**free

ctl-opt dftactgrp(*no);

dcl-s customerNo packed(9:0);

dcl-proc GetCustomerName;
dcl-pi *n varchar(100);
customerNo packed(9:0) const;
end-pi;

// Logique métier ...

end-proc;
Cette syntaxe n'a plus grand-chose en commun avec l'image classique de RPG II ou RPG/400.
Il ne s'agit pas seulement d'un changement esthétique. Lorsqu'un langage de programmation n'est plus défini par des colonnes fixes, il devient beaucoup plus facile d'utiliser des éditeurs modernes, des systèmes de gestion de versions du code source, le formatage automatique et l'analyse de code.

À quel point RPG est-il moderne aujourd'hui ?

RPG possède aujourd'hui de nombreuses fonctionnalités attendues d'un langage procédural moderne destiné aux applications métier.
Parmi elles figurent :
  • une syntaxe entièrement Free-Form
  • des procédures locales
  • des Prototypes et des Procedure Interfaces
  • des Data Structures qualifiées et imbriquées
  • des tableaux (Arrays)
  • des énumérations (Enumerations)
  • la gestion des exceptions (Exception Handling)
  • le traitement ON-EXIT
  • FOR-EACH
  • les structures SELECT
  • de nombreuses Built-in Functions
  • la prise en charge d'Unicode
  • le traitement des données avec DATA-INTO et DATA-GEN
  • le traitement XML
  • une intégration très étroite avec Db2 for i et Embedded SQL
IBM ne fait d'ailleurs pas évoluer RPG uniquement lors des nouvelles versions majeures. De nombreuses fonctionnalités du langage sont désormais livrées par PTF pour les versions existantes. RPG Cafe documente une série continue d'améliorations depuis de nombreuses années.4
Cette situation est très différente de celle d'un langage maintenu uniquement pour des raisons de compatibilité.

Quelles nouveautés avec IBM i 7.6 ?

IBM i 7.6 a apporté de nouvelles améliorations à ILE RPG. Il faut toutefois souligner qu'une partie de ces fonctionnalités a également été, ou sera, proposée sous forme de PTF pour les versions précédentes. Parmi les nouveautés figurent, par exemple, de nouvelles possibilités de conversion de dates, des Built-in Functions supplémentaires et des améliorations concernant les procédures et ON-EXIT.
IBM indique explicitement que de nombreuses améliorations incluses dans la version 7.6 sont également disponibles par PTF pour IBM i 7.4 et 7.5.5
Cela révèle aussi une évolution intéressante dans la maintenance du produit : autrefois, une nouvelle fonctionnalité du langage était étroitement liée à une nouvelle version du système d'exploitation. Aujourd'hui, IBM peut faire évoluer RPG beaucoup plus régulièrement, indépendamment de ce cycle. Les améliorations apparues après la sortie d'IBM i 7.6 sont donc encore plus intéressantes que celles présentes au lancement.

Juillet 2026 : IBM enrichit encore RPG

En juillet 2026, IBM a publié de nouvelles fonctionnalités ILE RPG pour IBM i 7.5 et 7.6.
Parmi elles6 :
  • ASSERT-T et ASSERT-F
  • des Message IDs génériques pour ON-EXCP
  • LIKE(*EXT)
  • %LOOKUPNE et %TLOOKUPNE
  • des informations supplémentaires sur le job dans la Program Status Data Structure
Aucune de ces améliorations ne révolutionne RPG.
Mais c'est précisément ce qui est intéressant : IBM ne cherche manifestement pas à transformer RPG en un langage totalement différent. L'entreprise corrige plutôt progressivement des faiblesses concrètes et ajoute des fonctionnalités utiles aux applications métier modernes et aux méthodes de développement actuelles.

Assertions – une petite nouveauté porteuse d'un message important

ASSERT-T et ASSERT-F méritent une attention particulière.
Une assertion décrit une condition dont le programmeur attend qu'elle soit vraie ou fausse à un endroit précis du programme.
Par exemple :
RPGLE
ASSERT-T customerNo > 0
%MSG('Customer number must be greater than zero');
Les assertions peuvent servir à vérifier les préconditions et les postconditions d'une procédure.
IBM mentionne également explicitement une deuxième utilisation : les tests unitaires (Unit Testing).
Différents Assertion Modes permettent de définir ce qui doit se passer lorsqu'une assertion échoue. En mode ASSERT(*CALL:...), par exemple, une procédure peut être appelée pour chaque assertion afin d'évaluer le résultat du test.7
Le fait qu'en 2026 IBM ajoute à RPG des fonctionnalités du langage qui prennent explicitement en charge les tests unitaires constitue un signal important.

Un langage maintenu en vie uniquement pour assurer la compatibilité ascendante ne bénéficierait guère de telles fonctionnalités de développement

RPG et SQL se rapprochent toujours davantage

L'une des transformations les plus importantes des applications RPG modernes ne concerne RPG qu'en partie : il s'agit de SQL.
Les applications IBM i traditionnelles utilisent souvent le Record-Level Access : CHAIN, SETLL, READE, WRITE, UPDATE et DELETE sont profondément ancrés dans l'histoire de RPG. Ces opérations ne disparaîtront pas.
Pourtant, la relation entre RPG et la base de données a changé.
Les opérations complexes sur les données peuvent souvent être formulées plus clairement et plus efficacement en SQL. Parallèlement, sur IBM i, SQL est depuis longtemps bien plus qu'un simple langage de base de données. IBM enrichit continuellement les services QSYS2 et SYSTOOLS, qui donnent accès à de nombreuses informations sur le système d'exploitation et la plateforme.
Pour les applications modernes, une répartition pertinente des responsabilités se dessine donc de plus en plus :
RPG pour la logique métier
SQL pour la logique des données
Bien entendu, la frontière n'est pas stricte. Mais le lien étroit entre RPG et Db2 for i constitue justement l'une des grandes forces du langage. Les développeurs RPG de demain devront donc maîtriser SQL aussi naturellement que RPG.

RPG n'a pas besoin de tout faire

RPG n'est pas un langage de programmation universel. Et il ne devrait probablement pas le devenir.
Pour développer aujourd'hui une application mobile indépendante de la plateforme, un modèle de Machine Learning ou un service Internet généraliste, rares sont ceux qui choisiraient RPG. Pourquoi le feraient-ils ? Les atouts de RPG se trouvent ailleurs.
RPG fonctionne là où de nombreuses entreprises conservent une part considérable de leur logique métier critique et de leurs données les plus importantes : sur IBM i. RPG peut y accéder directement à Db2, utiliser les objets et les API IBM i, appeler des programmes et des Service Programs existants et fonctionner en profondeur au sein de la plateforme sans middleware supplémentaire.
L'avenir de RPG ne dépend donc pas de sa capacité à résoudre toutes les tâches imaginables, mais de son aptitude à bien accomplir celles pour lesquelles IBM i est utilisé.

De l'application autonome à l'API

Traditionnellement, le modèle applicatif se présentait souvent, de manière simplifiée, ainsi :
5250
 |
RPG
 |
Physical File
Aujourd'hui, il peut être complètement différent :
Application Web / Client mobile / Système tiers
 |
REST API
 |
Logique métier RPG
 |
SQL / Db2 for i
Un programme RPG n'a plus besoin de présenter lui-même son interface utilisateur. Il peut fournir une fonction métier que d'autres applications utilisent.
Ainsi, la logique métier développée depuis des décennies n'est pas nécessairement remplacée : elle est intégrée dans une architecture moderne. C'est une différence essentielle entre modernisation et nouveau développement.

Développer en RPG moderne, c'est bien plus qu'utiliser Free Format

On peut écrire entièrement en Free Format un programme monolithique de 15 000 lignes. Cela ne le rend pas moderne pour autant.

L'avenir de RPG dépend donc au moins autant des méthodes de développement que des nouvelles fonctionnalités du langage.
IBM investit massivement dans Code for IBM i pour Visual Studio Code. Cette extension permet notamment de modifier et de compiler du RPGLE, du CL, du COBOL et du C/C++ directement depuis Visual Studio Code. Avec IBM i 7.6 et les Technology Refreshes suivants, la prise en charge de Git, le débogage, la couverture de code (Code Coverage), la prise en charge de RPG et d'autres fonctionnalités de développement ont été renforcés.8
Les chiffres de l'IBM i Marketplace Survey 2026 sont également remarquables :
- 74 % des personnes interrogées utilisent encore les outils classiques de l'Application Development Tool Set, notamment SEU et PDM.
- Parallèlement, 58 % utilisent déjà Visual Studio Code et 57 % RDi. Dans cette enquête, VS Code devançait ainsi légèrement RDi pour la première fois.9
Il ne s'agit pas d'un simple changement cosmétique d'éditeur. Les méthodes de développement évoluent :
Les Source Members deviennent des dépôts Git.
Les modifications peuvent être gérées par branches et Pull Requests.
La compilation du code peut être automatisée.
Les tests peuvent être intégrés aux processus de build.
Les Code Reviews deviennent plus simples.
Le Deployment et le Change Management peuvent être automatisés.
RPG moderne ne signifie donc pas simplement : « Plus de C-Specs. »
RPG moderne signifie aujourd'hui et demain : Git → Développement → Review → Build → Test → Deployment.

Le véritable problème n'est peut-être pas RPG

Dans l'IBM i Marketplace Survey 2026, le manque de spécialistes IBM i a été cité pour la première fois comme la principale préoccupation des personnes interrogées. 10 Cet argument est souvent utilisé contre RPG. Mais on confond peut-être ici la cause et la conséquence.
Une application vieille de plusieurs décennies, peu documentée, composée de grands programmes monolithiques, faiblement modularisée, sans environnement de tests automatisés et dont le Source Control repose exclusivement sur des Source Files traditionnels, est difficile à aborder pour un nouveau développeur.
Le problème n'est pas ici le langage de programmation. Un projet Fully Free RPG bien structuré, utilisant des procédures, des Service Programs, SQL, Git, un IDE moderne, de la documentation et des tests, est tout autre chose.
La question déterminante pour l'avenir n'est donc peut-être pas : « Combien de temps RPG existera-t-il encore ? »
Mais plutôt : « Comment allons-nous continuer à faire évoluer les applications RPG ? »

Écrirait-on aujourd'hui une nouvelle application en RPG ?

La réponse n'est ni un oui systématique ni un non catégorique.
Pour une application critique destinée à fonctionner durablement sur IBM i, qui travaille intensivement avec Db2 for i et réutilise la logique métier IBM i existante, RPG reste un choix particulièrement pertinent.
Pourquoi se priver des avantages d'un langage intégré nativement dans un tel environnement ?
La situation est différente pour une application dont les principales exigences se situent en dehors d'IBM i :
Une application mobile n'a pas besoin d'être écrite en RPG.
Un modèle d'IA n'a pas besoin d'être écrit en RPG.
Un service Web indépendant de la plateforme n'a pas besoin d'être écrit en RPG.
Ces composants peuvent néanmoins collaborer avec des applications RPG. C'est précisément là que se dessine l'architecture de demain :
Non plus un seul langage de programmation pour tout, mais plusieurs technologies, chacune utilisée là où elle possède ses atouts.

RPG – quo vadis ?

RPG ne deviendra probablement pas le prochain langage de programmation universel à la mode. Une armée de développeurs Python, JavaScript ou Java ne va pas soudainement se mettre à apprendre RPG.
Mais ce n'est pas le bon critère d'évaluation.
RPG dispose d'une base installée exceptionnellement importante de logiciels critiques sur IBM i. IBM continue à faire évoluer activement le langage. Parallèlement, IBM investit dans Visual Studio Code, le développement orienté Git et la modernisation assistée par l'IA.11
L'évolution ne semble donc pas conduire vers un langage entièrement nouveau. Elle mène vers un RPG qui ne renie pas ses origines, mais qui en subit de moins en moins les contraintes.
  • Moins de code monolithique
  • Davantage de procédures et de Service Programs
  • Davantage de SQL
  • Davantage d'API
  • Davantage de tests
  • Davantage de Git
  • Davantage d'automatisation
  • Davantage d'assistance par l'IA
  • Et probablement moins de discussions sur le fait que RPG soit « ancien »
Un langage de programmation n'est pas dépassé simplement parce qu'il est ancien. Ce qui compte, c'est qu'il continue d'évoluer, qu'il remplisse efficacement sa mission et qu'il permette de développer des logiciels conformes aux exigences de qualité actuelles et futures.
Selon ces critères, RPG est loin d'être arrivé au bout de son chemin en 2026. Sa phase la plus intéressante ne fait peut-être que commencer.

Cet article est une traduction de l'original allemand réalisée avec l'aide de l'intelligence artificielle

RPG – quo vadis ? (original allemand)