IBM i, .NET et IA : et si vous construisiez vos propres outils ?

Une liste d'objets. C'était tout ce que nous voulions ce matin-là, le contenu d'une bibliothèque avec le type, le propriétaire et la date de création de chaque entrée, disponible dans une application .NET.

Sur IBM i, la chose porte un nom, QUSLOBJ, et elle ne rend pas son résultat de bonne grâce. Il faut créer au préalable un espace utilisateur dans QTEMP, appeler l'API, puis relire cet espace octet par octet pour y retrouver, à des décalages que seule la documentation IBM détaille, le nombre d'entrées et leurs propriétés. Et comme la taille du résultat reste inconnue tant qu'on ne l'a pas obtenu, mieux vaut prévoir de tout recommencer avec un espace plus grand.

Nous avons publié le tutoriel complet de cet appel en mai 2025. Six étapes, trente-sept propriétés à mapper, une centaine de lignes de C# en conclusion. Les écrire a demandé de lire la documentation IBM à la ligne, de se tromper sur quelques décalages et de recommencer.

Nous avons reposé la même question à un assistant de code, la documentation IBM d'un côté et, depuis la V5, le fichier de contexte NTi de l'autre, celui que nous fournissons désormais avec le connecteur pour lui éviter d'inventer une chaîne de connexion ou de confondre CCSID et convention de nommage. Les cent cinquante lignes étaient là en quelques instants, vérification faite.

Le tutoriel n'a rien perdu de son utilité, il a changé d'office : il ne sert plus à écrire le code mais à vérifier celui qu'on vous rend. Retenez cette nuance, elle porte à peu près tout ce qui suit.

L'anecdote ne surprendra plus personne, tant ce genre de récit circule depuis deux ans. Elle dit pourtant assez peu de chose sur l'intelligence artificielle et beaucoup sur l'économie du logiciel IBM i. Car cet effort-là, répété fonction après fonction, est exactement ce que vend un éditeur. Énumérer les travaux actifs, lire les attributs d'un profil, parcourir une file d'attente de sortie… chaque geste réclamait le même travail de décryptage, et un outil digne de ce nom en additionne des dizaines. Personne n'avait sérieusement les moyens de payer cette addition en interne, alors on achetait. Un éditeur pour l'émulation, un autre pour le webfacing, un troisième pour la supervision, un quatrième pour le décisionnel. Chacun vendait moins des fonctionnalités que des mois de documentation IBM déjà lue à votre place.

Mais que reste-t-il de ce commerce le jour où ces mois deviennent des heures ?

Deux couches, deux prix

Pour répondre honnêtement, il faut accepter une distinction sommaire mais commode. Dans un logiciel cohabitent deux couches de nature très différente, et une seule vient de perdre de la valeur.

La première est la connaissance métier. Le calcul du besoin net, les conditions de remise selon le canal, le traitement du reliquat, les quarante-sept cas particuliers accumulés depuis 1994 parce qu'un client important l'avait demandé. Cette couche vit chez vous, dans vos programmes RPG et dans la mémoire de vos équipes. Mais aucune machine ne la devine, et son prix n'a pas bougé d'un centime.

La seconde, c'est tout le reste. Une interface web, une grille paginée, un formulaire, un export, une authentification, un point d'entrée REST, un conteneur, une chaîne d'intégration continue... Et, sur IBM i, l'interprétation des structures que nous venons de décrire. Cette part générique représente couramment quatre cinquièmes du code d'un outil et réclame du savoir-faire tout en prenant du temps. Elle a simplement ceci de particulier qu'elle a déjà été écrite des dizaines de milliers de fois, ce qui explique que les modèles de génération s'en tirent aujourd'hui remarquablement bien.

Or les logiciels que l'on achète autour d'un IBM i relèvent presque tous de cette seconde couche, posée sur un système qui existe déjà. Un outil de supervision, c'est une lecture de files de messages et une interface pour la présenter. Un webfacing, c'est une projection d'écrans DDS. Dans les deux cas la valeur métier ne bouge pas d'un pouce, elle reste dans votre partition.

D'où une réponse moins brutale qu'il n'y paraît. Un éditeur dont le produit puise dans la première couche ne risque rien, et l'ERP vertical de votre secteur dormira tranquille encore longtemps. Un éditeur dont le produit tient tout entier dans la seconde vend désormais quelque chose que son client peut fabriquer lui-même. L'arbitrage se déplace mécaniquement, sans qu'il soit besoin d'en vouloir à personne.

L'épreuve des faits

Nous n'aurions pas écrit ces lignes sans les avoir éprouvées. Plusieurs outils de démonstration ont vu le jour ces derniers mois, tous en .NET, tous avec le connecteur NTi et des assistants de code, et tous dans des catégories qui se vendent aujourd'hui sous licence. Aucun composant installé côté IBM i, dans aucun des cas. En voici deux, pris au hasard de la démonstration : une gestion des files de messages, et une cartographie de bibliothèque.

QSYSOPR, cent soixante-quinze messages, les répétitions regroupées, l'activité des dernières vingt-quatre heures résumée en un graphique. La même file, en vert, tient sur vingt-quatre lignes.

Le champ ADHEDB, présent dans deux fichiers physiques, touche cinq programmes avant d'atteindre un seul écran. Quatre le modifient, un le consulte, aucun ne reste d'usage indéterminé.

Nous n'en dirons pas davantage : ce genre de chose se montre plutôt qu'il ne se raconte, et se montre mieux sur vos données que sur les nôtres. Nous proposons volontiers une démonstration à qui veut se faire une idée de ce qu'il est devenu possible de fabriquer, et à quelle vitesse.

Le système entier est une API

L'histoire de QUSLOBJ racontée en ouverture n'était pas un cas isolé. Elle vaut pour la totalité du système.

On oublie volontiers que l'IBM i est documenté de bout en bout. Derrière chaque écran, qu'il s'agisse d'une session 5250 ou d'un panneau Navigator, derrière chaque commande en WRK, il y a une API publiée par IBM, avec son nom, ses paramètres, ses formats de retour et son manuel. Énumérer les travaux actifs, lire les attributs d'un profil, interroger l'état du système, gérer les autorisations, tout s'obtient par appel de programme dans QSYS. La machine ne cache rien et n'a jamais rien caché.

Si presque personne ne s'en servait, la documentation n'y était pour rien : l'exercice était ingrat, et notre liste d'objets comptait parmi les plus faciles. Ce que la lecture automatique des manuels modifie, c'est le coefficient. Ces documentations sont publiques, structurées et exhaustives, soit très exactement la matière que les modèles de langage restituent mieux que nous. Côté .NET, l'appel garde ensuite la forme d'une signature ordinaire.

var parametres = new List
{
    new NTiProgramParameter("NTILOBJ", 10).Append("QTEMP", 10), // espace utilisateur
    new NTiProgramParameter("OBJL0400", 8),                     // format des données
    new NTiProgramParameter("*ALL", 10).Append("PAYLIB", 10),   // objet et bibliothèque
    new NTiProgramParameter("*ALL", 10),                        // type d'objet
    new NTiProgramParameter("", 16)                             // structure d'erreur
};

conn.CallProgram("QSYS", "QUSLOBJ", parametres);

La conclusion devient inconfortable pour le marché : toute fonction d'administration accessible en vert l'est aussi depuis .NET, sans exception et sans intermédiaire. Reconstruire une console d'exploitation, un gestionnaire de profils ou un portail d'administration multi-partitions, à l'apparence et aux règles que l'on choisit, relève désormais du calendrier plutôt que de la faisabilité. La question n'est plus de savoir si le système laissera faire, il laisse faire depuis 1988. Elle est d'avoir un accès assez direct pour s'y adresser, et quelqu'un pour écrire les appels. Les deux réponses viennent de tomber en même temps.

L'inventaire des possibles

Reste à choisir par quoi commencer, et l'inventaire donne un peu le vertige. Côté interfaces, les portails métier par service, les tableaux de bord temps réel, les écrans de saisie repensés pour le tactile, les kiosques d'atelier, les accès nomades. Côté exploitation, les files de messages, le suivi des travaux et des sous-systèmes, les spoules, la surveillance des sauvegardes, le journal d'audit QAUDJRN, les profils et les droits, les alertes poussées vers Teams ou le téléphone d'astreinte.

Côté données, les API REST ou GraphQL sur DB2 for i, les exports automatisés, l'alimentation d'un entrepôt, les flux EDI, l'intégration avec un CRM. Côté métier, le portail client ou fournisseur, l'application mobile des commerciaux, le scan de code-barres interrogeant DB2 for i en direct. Côté développement, l'analyse d'impact sur vos sources, la documentation automatique des programmes RPG, la génération de jeux d'essai. Côté IA enfin, le serveur MCP qui expose vos traitements, dont nous avons documenté la construction pour SQL comme pour l'appel de programmes RPG.

Pas une ligne de RPG dans tout cela, et pas une modification de l'existant. Ces outils se construisent à côté, en .NET, et consomment l'IBM i comme un service.

Par où l'on commence

Le point de départ tient en quelques lignes. Une chaîne de connexion, et la partition devient une ressource .NET ordinaire.

using Aumerial.Data.Nti;

var conn = new NTiConnection("server=IBM;user=USER;password=PWD");
conn.Open();

conn.ExecuteClCommand("ADDLIBLE PAYROLL2025");   // commande CL
conn.CallProgram("PAYLIB", "PAYLIST");           // programme RPG existant

Pour les données, DB2 for i se comporte comme n'importe quelle base relationnelle, et l'extension Entity Framework Core autorise à raisonner en LINQ plutôt qu'en SQL.

builder.Services.AddDbContextFactory(options =>
    options.UseNTi(builder.Configuration.GetConnectionString("IbmI")));

var enRetard = await db.Commandes
    .Where(c => c.Statut == "EN_COURS" && c.DateLivraison < DateTime.Today)
    .OrderBy(c => c.DateLivraison)
    .ToListAsync();

Vient ensuite une étape qu'on néglige facilement et qui décide pourtant de la qualité du résultat : donner du contexte à l'assistant. Livré à lui-même, il produit du code approximatif, renseigné sur le terrain il devient étonnamment juste. Le connecteur en fournit une partie : depuis la V5, NTi est livré avec un fichier de contexte qui couvre déjà les pièges classiques comme le CCSID ou la portée de QTEMP.

Reste à ajouter le vôtre : le schéma DB2 des bibliothèques concernées, facile à extraire par quelques requêtes système, vos conventions de nommage et la correspondance entre noms courts DDS et noms SQL longs, source d'erreurs inépuisable, deux ou trois exemples de code déjà validés chez vous. Procédez ensuite fonction par fonction, testée contre une partition de développement réelle avant de passer à la suivante.

Vérifiez enfin, sérieusement. Testez contre des données réelles plutôt que contre des simulacres écrits par le même assistant, qui valident surtout ses propres hypothèses. Contrôlez les autorisations du profil employé, qui doit porter les droits nécessaires et rien de plus. Et surveillez les arrondis : zonés, packés et décimaux DB2 ne se comportent pas comme un decimal .NET sur toutes les opérations, l'écart se découvre rarement au moment opportun.

Générer n'est pas valider

L'article serait malhonnête s'il s'arrêtait sur cette note.

L'assistant n'a pas votre connaissance métier et il ne l'aura jamais. Il écrira un écran de saisie de commande impeccable ; il ne devinera pas que la remise ne s'applique pas aux références commençant par 9, ni pourquoi cette règle existe. Il faut donc que quelqu'un la connaisse et sache l'énoncer, ce qui n'est pas toujours acquis.

Il ne convertira pas davantage votre RPG tout seul, et c'est le point sur lequel nous invitons à la prudence la plus ferme. Générer du C# à partir de RPG est la partie facile, valider le résultat est le mur. Un programme de 1993 encapsule des accès natifs à sémantique de curseur, du contrôle de validation, des indicateurs, des arrondis en décimal packé et des MONMSG qui, à force, ont fini par constituer la règle de gestion elle-même. Un programme de paie converti à 97 % est plus dangereux qu'un programme non converti, pour cette raison très simple que personne ne sait dire lequel des 3 % restants est faux. La bonne façon de procéder consiste à capturer les entrées et sorties réelles en production pour en dériver un harnais de tests, puis à convertir sous ce filet : une opération qui prend du temps, pas un simple clic.

Notre conviction, après plusieurs projets de cette nature, tient dans un constat sans grande poésie : l'IA fait gagner un facteur considérable sur la construction et à peu près rien sur la spécification et la validation. Le goulet d'étranglement ne disparaît pas mais se déplace : hier on manquait de temps pour écrire le code, demain on en manquera pour le vérifier. C'est déjà beaucoup.

La tentation de tout quitter

Il serait tentant de conclure que si l'on peut tout reconstruire, alors on peut tout quitter. Ce serait tirer la mauvaise leçon d'une bonne nouvelle.

Ce qu'on reproche le plus souvent à l'IBM i n'est presque jamais l'IBM i lui-même. C'est l'écran vert, l'absence de mobilité, la difficulté d'intégration, l'ergonomie d'un autre siècle. Bref, la surface. Le moteur, avec son intégrité transactionnelle, sa sécurité au niveau objet, son journal et trente ans de fonctionnement sans incident majeur, est exactement ce que personne n'a envie de réécrire et ce qu'aucune refonte ne restitue à l'identique. Ceux qui ont vu passer une migration d'ERP savent de quoi il retourne.

Construire ses outils en .NET autour de l'IBM i revient à traiter la surface sans toucher au moteur, et procure au passage la liberté de mouvement. Votre logique d'accès est en C#, vos requêtes en LINQ, vos applications dans des conteneurs. Le jour où une décision d'infrastructure s'impose, elle redevient un choix technique au lieu d'une prise d'otage. La plupart de nos clients n'exerceront jamais cette faculté et la paient volontiers, parce qu'elle change la nature de la conversation avec leur direction générale. C'est la logique de notre approche de la modernisation par itérations courtes, où l'IBM i demeure le système de référence pendant que les nouvelles fonctions se construisent en .NET et se déploient en conteneurs.

Tout finit par se ramener au connecteur, et nous assumons de le dire sans détour puisque c'est notre métier. Pendant vingt ans, accéder à un IBM i relevait de la contrainte : on prenait ce qui existait, avec son pilote à installer, ses prérequis sur la partition et son incompatibilité chronique avec les versions récentes de .NET. Le connecteur était un détail d'infrastructure que l'on subissait au démarrage et que l'on regrettait à l'usage. Il est devenu le point de passage : entièrement managé, installable en une commande, capable d'adresser DB2 for i, les programmes RPG, les commandes CL et les API système par la même porte.

Ce qui limite un projet IBM i aujourd'hui n'est plus la machine, ni la technologie, ni même les compétences disponibles. C'est le chemin que l'on emprunte pour échanger avec lui.