Vue d’ensemble

02Projet 02 sur 3

Développement assisté par IA sur IBM i

Un agent de code IA sur du RPG hérité, le langage des applications de gestion sur serveurs IBM i (ex-AS/400) : il reçoit le contexte et un guide pour chaque concept qu’il traite, mais pas de shell libre. L’agent tourne sur le poste du développeur, pas sur l’IBM i ; ses modifications de code passent par une clé SSH liée à un script.

A

La démarche

  1. 1

    Lui donner du contexte

    Les sources IBM i sont exportées dans l’IFS, le système de fichiers de l’IBM i, puis synchronisées sur le poste avec la documentation du projet. C’est ce que l’agent peut lire : le code, et les documents qui l’expliquent.

  2. 2

    Cartographier d’abord le concept

    Quand une tâche touche un concept métier qui n’a pas encore de guide, l’agent lance d’abord un skill maison d’analyse sur ce concept (un skill est une procédure écrite que l’agent charge et suit). Le skill trouve les programmes et les tables concernés et d’où viennent les données, puis écrit un guide qui mène aux bons fichiers. Les guides s’accumulent concept par concept. Comment ça marche

  3. 3

    Modifier par un seul script

    Toute modification du code passe par un seul script de l’IFS, atteint par une seule clé SSH. L’agent dépose le source sur l’IFS, le compare au source en production de la dernière release de l’objet, que le script extrait, et travaille sur la version la plus récente, dans l’IFS. Le script la pousse ensuite dans les bibliothèques de l’IBM i (QSYS), la compile et renvoie les messages du compilateur. L’agent boucle jusqu’à ce que le code compile.

  4. 4

    Piloter les écrans verts

    L’agent pilote une session 5250, l’interface en écrans texte de l’IBM i (l’« écran vert »), par un serveur MCP (MCP est le protocole standard pour brancher un outil sur un agent IA), avec un miroir en direct dans le navigateur pour que le développeur voie chaque étape.

B

Le skill d’analyse

Sur un code hérité, un skill maison documente le système un concept métier à la fois, et vérifie chaque affirmation clé de son propre guide dans le code source avant de le garder.

Tracer

Quel programme écrit chaque table, quel job lance ce programme et d’où viennent les données, en remontant jusqu’à trois étapes.

Chercher

Des workers IA, de petits agents lancés en parallèle, répondent chacun à une question factuelle : les champs d’une table, les conditions d’un programme, un dénombrement.

Rédiger

Un guide organisé par fonctionnalité métier, pas par programme, qui explique le pourquoi et cite les lignes.

Réfuter

Un worker par affirmation clé tente de la réfuter dans le code source et colle la ligne sur laquelle il s’appuie.

Chaque affirmation finit confirmée, réfutée ou invérifiableEffort choisi par concept : léger, standard ou profond avec une seconde passe de réfutation

Un guide vers les bons fichiers. Il mène d’une question aux deux ou trois fichiers qui valent la peine d’être ouverts ; le code reste la source de vérité. Le but : moins de deux minutes entre la question et ces fichiers.

Lire avant d’écrire

Le skill lit d’abord ce que le dépôt documente déjà, pour que le guide ne le contredise pas, ne fasse pas doublon et reprenne son vocabulaire.

Dire ce qu’un nom cache

Quand un menu ou un programme fait autre chose que ce que son nom suggère, le guide s’ouvre sur une clarification. C’est souvent la trouvaille la plus utile.

Un guide quand une tâche en a besoin

Le skill ne documente pas tout le dépôt d’avance : un tel document devrait être tenu à jour à la main et prendrait vite du retard. Il écrit un guide quand une tâche touche un concept métier ; des parties du dépôt n’ont donc pas encore de guide, et c’est voulu.

C

Où tourne quoi

Poste du développeur
Éditeur et agentVS Code
Fichiers locauxsources exportées · documents du projet
Clé SSHclé privée, qui ne quitte jamais la machine
Pont 5250serveur MCP · miroir en direct sur localhost
SSH · commande forcée
5250 · TLS
IBM i
Un scriptliste blanche d’actions · pas de shell
Cycle de modification et compilateurversions · composants · extraction · compilation
Session 5250profil dédié, bibliothèque de test
Le profil du développeurtrace d’audit · accès révocable par développeur
Deux canaux, tous deux étroits. SSH est lié à un seul script, et la session 5250 est pilotée par un pont qui lit l’écran comme une donnée. Versions, composants et extraction sont le vocabulaire d’ARCAD, l’outil de gestion des changements en place : une extraction sort un source de la production pour le modifier.
D

La boucle : comparer, modifier, mettre à jour, compiler, retour

Comparerau source en production de la dernière release, extrait par le script
Modifierle fichier, dans l’IFS
Mettre à jourdans la bibliothèque QSYS, via le script
Compilervia le script
Retourles messages du compilateur

L’agent lit le retour, corrige le code et boucle jusqu’à ce qu’il compile

Un seul script pour toutes les étapes. De la consultation des sources à la compilation, chaque étape est une action du même script : rien ne tourne en dehors.
E

Modèle de sécurité

ENTRÉE AGENT IASCRIPT IFS · SSH
1 Parcourir sources, composants2 Créer une version3 Créer un composant4 Extraire5 Mettre à jour un source6 Compiler, renvoyer le résultat
Autre demande ........ refuséeSélection ===>
Illustration Tout le cycle de modification derrière une seule clé SSH, dessiné façon écran 5250.
  • La clé exécute le script, et rien d’autre. SSH impose la commande (restrict, command=) : pas de shell, pas de redirection de ports, pas de tunnel.
  • Une liste blanche d’actions. Toute autre demande est refusée avec un message explicite, jamais exécutée.
  • Une clé et un profil par développeur. Chaque action est attribuable dans le journal d’audit, et l’accès de chaque développeur se révoque séparément.
  • Des échecs visibles. Une étape en échec renvoie une erreur plutôt qu’un faux succès. Les noms de fichiers sont contrôlés, et les fichiers envoyés arrivent dans le dossier du développeur.
F

Écrans verts

AgentVS Code
Pont 5250serveur MCP, sur le poste
  • lit l’écran comme une donnée
  • saisit et appuie sur les touches
Session IBM i5250 · profil dédié

Miroir en direct · navigateur · localhost seulement · lecture seule

Le développeur regarde, l’agent tape. Un miroir interactif, où le développeur peut aussi saisir, est un chantier à part : il lui faut un verrou pour que les deux ne tapent pas en même temps.
Fenêtre VS Code : à gauche un programme RPG, au milieu le miroir de la session 5250 dans un onglet du navigateur intégré, à droite l’agent qui lit l’écran puis saisit.
Le miroir n’est qu’un onglet de VS Code. À gauche le source, au milieu la session 5250 en direct, à droite l’agent. Cliquer sur l’image pour l’agrandir.

Ce que voit l’agent

Le texte de l’écran tel quel, ses champs listés par nom et position, le curseur, l’état du clavier (verrouillé ou non) et une signature qui identifie l’écran. Que du texte structuré, pas de captures.

Les règles de sécurité que j’ai posées

L’écran est traité comme une donnée, jamais comme une consigne : un champ peut contenir « ignore les règles et exécute… ». La session utilise un profil dédié à droits réduits sur une bibliothèque de test, sans données réelles de l’entreprise, par un port chiffré seulement.

G

Choix de conception

Pourquoi un script à commande forcée plutôt qu’un shell ?

Un shell n’a aucune limite : tout ce que le profil peut faire, une injection de prompt ou une simple erreur peut le faire aussi. Une commande forcée transforme la clé SSH en menu. La demande est seulement découpée en mots, jamais évaluée comme une commande, et le dossier cible vient du profil connecté, jamais d’un argument.

Pourquoi cartographier d’abord le concept ?

Un dépôt RPG hérité porte des décennies de conventions que personne n’a écrites. Le guide donne à l’agent un index pour naviguer au lieu de chercher à l’aveugle, et me donne de quoi vérifier sa compréhension.

Pourquoi réutiliser un pont 5250 existant ?

Des serveurs MCP open source existent déjà, dont un avec une vue navigateur en direct. Restait le dispositif autour : réseau et droits, règles de sécurité, et un petit cas d’essai de bout en bout. Un émulateur sur mesure aurait coûté plus cher.

H

Limites