Dans les deux premiers épisodes, nous avons connecté Claude à l’IBM i et lui avons permis d'interroger et modifier une base de données DB2 for i.
Cet article fait partie d’une série consacrée à l’utilisation d’un agent IA avec l'IBM i via le Model Context Protocol:
- Créer un serveur MCP en .NET pour connecter l’IBM i (AS400) à une IA
- Lecture et écriture SQL sur DB2 for i depuis .NET avec un serveur MCP
- Appeler un programme RPG IBM i depuis .NET avec un agent IA (cet article)
Cette fois, nous allons analyser le code source d’un programme RPG IBM i et l’appeler depuis .NET via Claude Desktop et grâce à NTi data provider.
Architecture du serveur MCP .NET connecté à IBM i
On repart du projet de l'épisode 2, inchangé.
On crée un nouveau dossier RPG et on y ajoute la classe RPGTools.cs.
Le program.cs devient donc:
// … code
.WithTools<TranslogTools>();
.WithTools<RPGTools>();Exemple de programme RPG IBM i : CALCPRIX
CALCPRIX est un programme RPG free-format compilé dans la bibliothèque TLOG. Il encapsule la logique tarifaire de la société Translog que l’on a vu dans l’épisode précédent.
Règles tarifaires actuelles:
- Tarif de base : 10 € + 2 €/kg
- Client PREMIUM : remise de 10 %
- Client PROSPECT : majoration de 5 %
- Client STANDARD : pas de remise ni de majoration
- Poids > 10 000 kg : refus
- Montant > limite de crédit client : refus
Paramètres du programme:
| Paramètre | Type IBM i | Direction | Description |
|---|---|---|---|
P_SHIPID |
CHAR(10) | Entrée | Identifiant de l’expédition |
P_PRIX |
PACKED(11:2) | Sortie | Tarif calculé |
P_MSG |
CHAR(50) | Sortie | Ok ou motif de refus |
Analyser un programme RPG IBM i avec un agent IA
Partie 1 - Thomas découvre CALCPRIX
Thomas est développeur .NET, il vient de rejoindre la société Translog.
On lui dit qu’il y a un programme RPG quelque part dans la bibliothèque TLOG qui calcule les tarifs. Il doit l’intégrer dans une nouvelle application .NET, c’est tout ce qu’on lui a dit.
Il n’a pas accès à la documentation, vu qu’il n’y en a pas. Et Thomas ne connaît pas vraiment le RPG, il ne sait pas quels paramètres le programme attend, ce qu’il retourne, ni quelle logique s’applique
Il ouvre Claude Desktop et tape:
💬 Prompt Thomas
“ Analyse le programme RPG CALCPRIX dans la bibliothèque TLOG et explique moi comment il fonctionne. ”

Claude appelle le tool ReadRpgSource déjà défini et récupère les lignes du code source du programme RPG. Il les analyse et répond directement: explication métier, description des paramètres entrée/sortie avec leurs types IBM i etc.
Thomas n’a ouvert aucun écran 5250. Il n’a pas eu besoin de solliciter un expert RPG ni de consulter la moindre documentation.
1. ReadRpgSource()
Le tool utilisé par Thomas exécute une requête SQL sur le fichier source QRPGLESRC de l’IBM i afin de récupérer les lignes du code source du programme RPG. Claude reçoit ainsi le code exactement comme un développeur le lirait dans un éditeur.
[McpServerTool]
[Description()]
public string ReadRpgSource(
[Description("Nom de la bibliothèque")] string library,
[Description("Nom du programme RPG")] string program)
{
var sql = _conn.Query($@"
SELECT SRCDTA
FROM {library.ToUpper()}.QRPGLESRC
ORDER BY SRCSEQ");
if (!sql.Any())
return $"Programme {program} introuvable dans {library}";
return string.Join(Environment.NewLine, sql);
}
Le fichier source QRPGLESRC utilisé pour cet exemple ne contient ici qu’un seul membre.
Une simple requête SQL permet donc de récupérer les lignes du programme dans l’ordre et de reconstituer le code complet.
Dès lors qu’un programme RPG est lisible depuis SQL, Claude peut en faire beaucoup plus qu’expliquer sa signature.
Il peut par exemple identifier des mauvaises pratiques, repérer des variables non initialisées ou des blocs de code dupliqués dans un programme existant. Il peut aussi transformer un ancien RPG colonné en FREE RPG en expliquant les changements, ou générer la documentation technique d’un programme non documenté.

La plupart des équipes IBM i ont des centaines de programmes dans leurs bibliothèques. Ce tool donne à n’importe quel développeur, quel que soit son niveau de connaissance RPG, un accès immédiat à leur logique métier.
Cette approche est particulièrement utile dans des projets de migration ou de modernisation. Plutôt que de réécrire à l’aveugle, on peut d'abord analyser et comprendre les règles métier existantes, puis décider quoi conserver, quoi refactorer.
Appeler un programme RPG IBM i depuis .NET
Partie 2 - Sylvie et la révision tarifaire
La direction de Translog vient de décider une révision tarifaire. Le tarif kilométrique passe de 2 €/kg à 3 €/kg, applicable immédiatement. Un collègue de Thomas, a déjà mis à jour la règle dans le programme RPG CALCPRIX.
Il reste maintenant à recalculer les tarifs des expéditions déjà en cours.
Sylvie est responsable commerciale chez Translog, on a fait sa connaissance dans l’article précédent. Elle ne sait pas ce qu’est un programme RPG, n’a pas accès à ACS, et n’a aucune raison de s’y intéresser.
Elle ouvre Claude Desktop:
💬Prompt Sylvie
“ La grille tarifaire de TRANSLOG a changé. Recalcule le tarif de l'expédition SHP-100007 ”.
Claude procède en deux temps. Il appelle d’abord GetShipmentsByStatus pour lister l'expéditions concernée et présente un récapitulatif à Sylvie avec les tarifs actuels.
Après confirmation, il appelle le tool CalculateTranslogShipmentRate pour l’expédition souhaité. Chaque appelle déclenche CALCPRIX sur l’IBM i, qui applique le nouveau barème et met à jour AMOUNT directement en base.
Exemple 1 - SHP-100007, Batifroid SAS, PREMIUM, 1 900 kg
Claude affiche les informations de l'expédition, rappelle les règles tarifaires applicables au segment PREMIUM, et demande confirmation avant d'appeler le programme.

Sylvie confirme.
Le programme RPG CALCPRIX est alors appelé, la remise de 10 % est appliquée et le tarif passe de 2 800 € à 5 139 €.

La mise à jour est visible immédiatement dans ACS.

Exemple 2 - SHP-100008, Nordbat, STANDARD, 3 100 kg
Même déroulé.
Segment STANDARD, pas de remise ni de majoration. Le tarif passe de 4 400 € à 9 310 €.

Exemple 3 - SHP-100012, statut DELIVERED
Sylvie demande à recalculer SHP-100012. Claude consulte l'expédition, constate le statut DELIVERED, et refuse d'appeler le programme.

💡La règle est définie dans la description du tool: le tarif d'une livraison déjà effectuée est définitif et immuable.
Claude ne peut donc pas faire n'importe quoi, il respecte les contraintes métier qu'on lui a données.
1. CalculateTranslogShipmentRate()
Ce tool a été implémenté par Thomas, le développeur .NET.
En analysant CALCPRIX via ReadRpgSource, il a pu comprendre la logique du programme et identifier ses paramètres. Cela lui a permis de configurer le tool avec les règles métier nécessaires (confirmation préalable, statut DELIVERED non recalculable, etc.) afin de garantir un usage correct du programme depuis Claude.
La logique se déroule en trois étapes: construire la liste de paramètres en respectant exactement la signature du programme, appeler le programme, et lire les sorties:
[McpServerTool]
[Description(@"
Calcule le tarif d'une expédition en appelant le programme RPG CALCPRIX sur l'IBM i.
Ce programme lit le poids dans SHIPMENTS, le segment client dans CUSTOMERS,
applique les règles tarifaires Translog et met à jour le champ AMOUNT.
IMPORTANT : ce tool modifie des données sur l'IBM i.
Avant de l'appeler, tu DOIS :
1. Afficher à l'utilisateur le SHIPMENT_ID et le nom du client concerné.
2. Rappeler les règles : PREMIUM -10%, PROSPECT +5%, poids max 10000kg.
3. Demander une confirmation explicite avant d'appeler le programme.
RÈGLE MÉTIER :
Les expéditions avec le statut DELIVERED ne doivent jamais être recalculées.
Le tarif d’une livraison déjà effectuée est définitif et immuable.
N'appeler le programme qu'après avoir reçu un accord clair.")]
public string CalculateTranslogShipmentRate(
[Description("Identifiant de l'expédition (ex: SHP-100003)")] string shipmentId)
{
var parms = new List
{
new NTiProgramParameter(shipmentId, 10).AsInput(),
new NTiProgramParameter(0m, 11, 2).AsOutput(),
new NTiProgramParameter("", 50).AsOutput()
};
_conn.CallProgram("TLOG", "CALCPRIX", parms);
var prix = parms[1].GetPackedDecimal(11, 2);
var msg = parms[2].GetString().Trim();
if (msg == "OK")
return $"Tarif calculé avec succès : {prix:C} - AMOUNT mis à jour pour {shipmentId}";
else
return $"Erreur : {msg}";
}
On crée un NTiProgramParameter par paramètre attendu par le programme, dans le même ordre que la signature RPG.
Les types doivent correspondre exactement à ceux définis côté IBM i: CHAR(10) pour le SHIPMENT_ID en entrée, PACKED(11:2) pour le tarif en sortie, CHAR(50) pour le message de retour.
Une seule ligne suffit ensuite pour appeler le programme:
_conn.CallProgram("TLOG", "CALCPRIX", parms);
NTi ouvre une session sur l’IBM i et exécute CALCPRIX dans son environnement d’origine. Après l’appel, on lit les sorties directement sur les paramètres:
var prix = parms[1].GetPackedDecimal(11, 2);
var msg = parms[2].GetString().Trim();Conclusion
Appeler un programme RPG depuis .NET avec NTi se fait très facilement: on déclare les paramètres, on appelle le programme, et on lit les sorties.
Dans cet exemple, Claude a pu:
- lire le code source RPG directement dans l’IBM i
- comprendre la logique métier du programme
- appeler ce programme pour recalculer des tarifs
La plupart des systèmes IBM i possèdent déjà des centaines de programmes RPG qui implémentent des règles propres à l’activité de l’entreprise: processus métier, calculs spécifiques, savoir-faire accumulé au fil des années. Avec un serveur MCP, ces programmes peuvent être analysés, documentés et appelés directement sans avoir à les réécrire.
Cela ouvre aussi la possibilité pour des développeurs .NET de travailler avec un système IBM i sans en maîtriser immédiatement tous les détails techniques, à condition bien sûr de définir des tools et des règles de sécurité adaptées. Et dans bien des cas, c’est une manière beaucoup plus réaliste de moderniser un système que de repartir de zéro.
Quentin Destrade