Il y a des langages qu’on apprend, et d’autres qu’on hérite. Le Report Program Generator, connu sous l’acronyme RPG, appartient résolument à la seconde catégorie. Né en 1959, il n’a jamais prétendu rivaliser avec les langages académiques ni conquérir les startups. Et pourtant, aujourd’hui, des milliers de systèmes critiques dans la finance, l’industrie et la logistique tournent grâce à lui, souvent à l’insu même de leurs utilisateurs. Comprendre le RPG, c’est comprendre une certaine philosophie du développement : pragmatique, durable, orientée métier. Un langage qui, contre toute attente, a traversé six décennies sans jamais rompre avec son héritage.
Qu’est-ce que le RPG, et pourquoi ce nom prête à confusion ?
Quand on entend « RPG », beaucoup pensent jeu de rôle. La réalité est bien différente. RPG signifie Report Program Generator, autrement dit générateur de programmes de rapports. Derrière ce nom fonctionnel se cache une ambition précise : automatiser la production de rapports à partir de fichiers de données, sans obliger les utilisateurs métier à descendre dans les entrailles de l’assembleur. En 1959, c’est un choix radical. Les comptables et gestionnaires qui interagissaient avec les machines IBM n’étaient pas des informaticiens au sens contemporain du terme. IBM voulait leur donner un outil à leur portée, structuré autour de trois blocs logiques : les spécifications d’entrée, de calcul et de sortie.
Ce positionnement « langage orienté métier » était rare, presque insolent pour l’époque. Là où COBOL ou l’Assembleur exigeaient une maîtrise technique poussée, le RPG proposait une grammaire alignée sur la réalité opérationnelle des entreprises. C’est ce qui explique, en partie, sa longévité : il a toujours parlé le langage de ceux qui gèrent, pas seulement de ceux qui codent.
De l’IBM 1401 aux cartes perforées : la naissance d’un langage pragmatique
En 1959, IBM fait face à un défi de transition. Ses clients utilisent des machines à cartes perforées, des tabulating machines, dont les techniciens sont habitués à câbler des panneaux de contrôle pour piloter les opérations. Passer aux ordinateurs électroniques, c’est bien. Mais perdre ces opérateurs en chemin, c’est catastrophique. IBM développe alors le RPG comme pont entre deux ères. Son prédécesseur direct, FARGO (Fourteen-O-One Automatic Report Generation Operation), existait sur l’IBM 1401, mais le RPG le surpasse rapidement et s’impose comme standard.
La syntaxe en colonnes du RPG n’est pas un caprice esthétique. Elle découle directement du format des cartes perforées, où chaque colonne possède une signification précise. Un programmeur expérimenté peut repérer une erreur d’un seul coup d’œil, simplement en regardant l’alignement du code. Ce choix de conception reflète une époque autant qu’une philosophie : la rigueur au service de la lisibilité, sans concession à la fantaisie.
Les grandes versions du RPG : une évolution sur six décennies
Ce qui distingue le RPG de beaucoup d’autres langages, c’est sa capacité à évoluer sans jamais trahir ses utilisateurs. Chaque nouvelle version a apporté des fonctionnalités modernes tout en conservant une compatibilité ascendante remarquable. Un programme écrit en RPG II dans les années 1970 peut, dans bien des cas, coexister avec du code RPG IV contemporain. C’est rare dans l’univers du développement logiciel, et ça mérite d’être dit clairement.
| Version | Période | Plateforme | Apport principal |
|---|---|---|---|
| RPG I | 1959 | IBM 1401, IBM 360 | Génération automatisée de rapports à partir de fichiers, syntaxe en colonnes héritée des cartes perforées |
| RPG II | Années 1970 | System/3, System/36 | Boucles implicites, traitement batch plus structuré, prise en charge d’applications plus complexes |
| RPG III | Années 1980 | System/38, AS/400 | Structures conditionnelles (IF-ENDIF), boucles DO, sous-programmes, accès libre aux fichiers base de données |
| RPG IV / ILE RPG | Années 1990 | IBM i (AS/400) | Architecture modulaire ILE, procédures, interopérabilité avec COBOL et C, intégration SQL embarqué |
| Full Free Format (RPG V) | 2015 à aujourd’hui | IBM i | Suppression totale du colonnage, syntaxe libre proche de Java ou Python, directive **FREE |
Le cycle de programme RPG : la mécanique qui a tout changé
Le program cycle, ou cycle de programme, est le concept le plus singulier du RPG, celui qui le distingue radicalement de ses contemporains. Dans les premières versions, le développeur n’avait pas à écrire de boucle explicite pour parcourir les enregistrements d’un fichier. Le cycle s’en chargeait automatiquement : lecture d’un enregistrement, application des règles métier définies dans le programme, génération de la sortie, puis passage à l’enregistrement suivant. Ce mécanisme, inspiré du fonctionnement des machines à cartes perforées, offrait une puissance d’automatisation inédite pour l’époque.
Le cycle comprenait plusieurs phases enchaînées automatiquement par le moteur RPG :
- Lecture : chargement automatique de chaque enregistrement depuis le fichier source
- Traitement : exécution des règles métier et calculs définis dans les spécifications de calcul
- Sortie : génération du rapport ou mise à jour des données selon les spécifications de sortie
Ce qui est moins souvent dit : depuis l’introduction du System/38 en 1979, la majorité des développeurs RPG ont progressivement abandonné ce mécanisme au profit de boucles structurées classiques, plus lisibles et plus faciles à maintenir. Le cycle existe toujours, IBM maintient la rétrocompatibilité, mais il appartient désormais à l’histoire technique du langage. Les nouvelles applications RPG s’écrivent sans lui.
ILE, free-format et SQL embarqué : quand le RPG s’est mis à ressembler à un langage moderne
Le virage le plus important dans l’histoire du RPG n’a pas fait la une des magazines informatiques. Il s’est opéré discrètement, version après version, à travers trois évolutions majeures. La première, c’est l’ILE (Integrated Language Environment), introduite avec RPG IV. Ce modèle architectural permet de décomposer un programme en modules compilés séparément, puis liés entre eux pour former un exécutable. Les procédures deviennent réutilisables, les programmes de service fonctionnent comme des bibliothèques partagées, et on peut désormais lier du code RPG avec du COBOL ou du C dans un même programme. Une transformation structurelle, pas une simple mise à jour syntaxique.
La deuxième rupture, c’est le free-format. En supprimant le colonnage strict hérité des cartes perforées, IBM a profondément modifié l’expérience quotidienne du développeur RPG. Depuis 2015 et la directive **FREE, on peut écrire du RPG sans se soucier de l’emplacement précis de chaque instruction dans la ligne. Le code ressemble alors à du Java ou du Python. L’indentation devient possible, la lisibilité s’améliore, et l’intégration dans des environnements DevOps modernes avec Git et CI/CD devient réaliste. Les outils ont suivi : RDi (Rational Developer for i), l’IDE officiel d’IBM basé sur Eclipse, et depuis 2020, des extensions performantes pour Visual Studio Code permettent de coder confortablement en RPG.
La troisième transformation, souvent sous-estimée, c’est l’intégration du SQL embarqué via SQLRPG. Un précompilateur transforme les instructions SQL directement en appels RPG vers le gestionnaire de base de données DB2. Résultat : les requêtes complexes, les tris, les agrégations s’écrivent en ligne, sans parseur externe, en tirant pleinement parti des index DB2. C’est cette combinaison ILE + free-format + SQLRPG qui permet aujourd’hui d’exposer des fonctions RPG comme des API REST ou SOAP, consommables par n’importe quel outil moderne de business intelligence.
Dans quels secteurs et sur quels systèmes le RPG tourne-t-il encore aujourd’hui ?
Le RPG n’est pas un artefact de musée. Entre 3 000 et 4 000 entreprises industrielles françaises maintiennent IBM i comme colonne vertébrale de leur système d’information, et une grande partie d’entre elles font tourner du code RPG en production chaque jour. La finance, l’assurance, la logistique, la distribution et les éditeurs d’ERP constituent les secteurs les plus exposés. Ce ne sont pas des systèmes secondaires : ce sont souvent les applications les plus critiques, celles qui gèrent les flux financiers, les stocks, les contrats clients.
Les cas d’usage courants sur ces environnements couvrent un spectre large :
- Traitements batch : calcul de paie, génération de factures, réconciliations comptables nocturnes
- ERP de négoce : gestion des achats, des ventes, de la logistique et des stocks pour les PME industrielles
- Gestion de contrats : applications back-office dans les mutuelles, assurances et organismes de protection sociale
- Reporting opérationnel : génération d’états financiers et d’indicateurs de performance directement depuis DB2
Ce qui est frappant, c’est la stabilité de ces environnements. Un système IBM i peut fonctionner des années sans interruption. C’est précisément cette fiabilité qui rend si difficile la décision de le remplacer : pourquoi changer ce qui ne tombe jamais en panne ?
RPG et modernisation : exposer du legacy sans tout réécrire
La question se pose tôt ou tard dans toutes les DSI qui opèrent sur IBM i : faut-il réécrire ou moderniser ? La réponse, souvent, n’est pas celle qu’on attend. Les projets de réécriture complète d’applications RPG échouent fréquemment, avec des taux d’échec estimés autour de 25 %. La logique métier enfouie dans des décennies de code représente une connaissance fonctionnelle considérable, et la réécrire de zéro revient souvent à perdre cette connaissance autant qu’à migrer la technique. Sans oublier les coûts : remplacer une application RPG critique peut coûter plusieurs fois plus cher que de la moderniser à la marge.
La voie pragmatique consiste à exposer les fonctions RPG existantes comme des services consommables par des systèmes modernes, sans toucher au code sous-jacent. Exposer un programme RPG en API REST permet à un dashboard Power BI ou à une application web de consommer ses données sans que personne n’ait réécrit une ligne de logique métier. Migrer les sources vers le free-format, convertir les accès fichier en SQLRPG, configurer des pipelines CI/CD avec Jenkins ou GitHub Actions : ce sont des chantiers progressifs, pilotables, réversibles. Moderniser RPG, c’est souvent plus intelligent que de le remplacer.
La pénurie de développeurs RPG : une bombe à retardement silencieuse
Le chiffre mérite qu’on s’y arrête : 69 % des organisations signalent la compétence IBM i comme préoccupation majeure en 2026. Ce n’est pas une tendance émergente, c’est une réalité structurelle. La démographie joue contre les entreprises : une large majorité des spécialistes RPG ont aujourd’hui plus de 50 ans, beaucoup sont proches de la retraite, et les universités françaises n’enseignent pas ce langage. Pas les lycées professionnels, pas les BUT, pas les écoles d’ingénieurs. L’écosystème académique a tourné le dos au RPG il y a longtemps, et les entreprises commencent à en payer le prix.
Un phénomène aggrave la situation : l’essor de l’IA réduit les postes juniors dans l’ensemble du secteur IT. Selon Gartner, les entreprises recourent de plus en plus à l’IA pour les tâches à faible valeur ajoutée, ce qui freine mécaniquement l’arrivée des jeunes diplômés dans les équipes. Pour IBM i, déjà en déficit de nouveaux talents, cet effet secondaire représente une pression supplémentaire. La France dispose pourtant d’un levier méconnu : les dispositifs POEI (Préparation Opérationnelle à l’Emploi Individuelle), qui permettent de financer une formation ciblée avant embauche pour répondre à un besoin métier précis. Un avantage concret, encore trop peu exploité par les organisations qui recrutent sur ces profils.
Apprendre le RPG en 2026 : est-ce encore une opportunité de carrière ?
La réponse est oui, mais pas pour les mêmes raisons qu’apprendre Python ou JavaScript. Les offres d’emploi RPG existent, en CDI, dans des secteurs stables : assurance, banque, industrie, distribution. Les profils les plus recherchés aujourd’hui ne sont plus de simples développeurs RPG III. Ce sont des profils hybrides, capables de maîtriser RPG IV en free-format, SQL/DB2, et la conception d’API. Les entreprises ne cherchent plus seulement quelqu’un qui maintient du code ancien, elles cherchent quelqu’un qui peut ouvrir ce code vers l’extérieur, le connecter à des outils modernes, lui donner une seconde vie.
L’image vieillissante du RPG est un frein réel, mais elle est trompeuse. Ce que le marché ne dit pas assez clairement, c’est que la rareté crée de la valeur. Un développeur RPG confirmé, capable de travailler aussi bien sur du code legacy que sur des architectures API modernes, se retrouve en position de force dans un marché où l’offre ne couvre pas la demande. Les salaires le reflètent. L’environnement IBM i reste l’un des systèmes d’exploitation les plus fiables au monde, utilisé par des entreprises qui ne se permettent aucune interruption de service.
Choisir d’apprendre le RPG en 2026, c’est choisir la rareté plutôt que la saturation. Dans un marché IT où tout le monde apprend les mêmes frameworks, maîtriser ce que peu de gens comprennent encore est peut-être la meilleure stratégie de carrière qu’on n’ose pas recommander.
