Un agent de parsing a corrompu notre table de production à 3 heures du matin. La mise à jour du prompt de l’agent n’avait pas été validée par un pipeline de régression automatique.

L’intégration de l’intelligence artificielle dans nos flux batch z/OS impose une rigueur de test identique à celle du COBOL. Nous manipulons des volumes de données critiques où une erreur de 0,1% est inacceptable. Le Framework pour agents est devenu notre seule barrière contre l’entropie des modèles de langage.

Après ce passage en revue, vous saurez implémenter un cycle de validation pour vos compétences d’agents. Vous apprendrez à mesurer précisément le taux de succès de chaque skill via la CLI sivchari.

Installation des outils nécessaires pour orchestrer le test des compétences.

• Python 3.12+ pour les scripts de validation de données.
• Go 1.22+ pour l’exécution de la CLI sivchari.
• GnuCOBOL 3.1.2 pour la génération des fichiers de test COBOL.
• Docker 24.0+ pour l’isolation des environnements de test.

Un skill dans un Framework pour agents n’est pas une simple fonction. C’est une unité de compétence testable comprenant un input, un output attendu et une métrique de succès. Contrairement à une procédure COBOL qui suit un chemin déterministe, un skill peut varier selon le modèle utilisé.

Le fonctionnement de sivchari repose sur trois piliers :

1. La Définition : On déclare le format de l’entrée (ex: structure Copybook).
2. Le Test : On exécute le skill sur un jeu de données d’entraînement.
3. La Mesure : On compare le résultat à la vérité terrain (Ground Truth).

Voici une représentation de la boucle de validation :

[ Input Data (EBCDIC/Flat) ]
|
v
[ Agent Skill (LLM/Logic) ] <--- [ sivchari CLI ] | | v v [ Output Parsed ] <---- (Compare) ----> [ Ground Truth ]
| |
+——> [ Metric: Accuracy/Precision/Recall ]

Si vous utilisez une approche classique sans ce Framework pour agents, vous ne faites que du monitoring, pas du testing.

Dans le premier snippet, la structure TXN-RECORD définit le contrat de données. C’est la base de notre ‘Ground Truth’. Si l’agent ne respecte pas cette structure, le test échoue. L’utilisation de PIC 9(07)V99 est cruciale. Elle impose une précision décimale fixe que l’agent doit respecter.

Le second snippet montre une logique de validation métier. Nous utilisons WS-VALID-FLAG pour signaler une erreur. Dans un contexte de Framework pour agents, ce code COBOL sert de test de validation post-extraction. Si l’agent extrait une donnée qui fait échouer 100-CHECK-AMOUNT, le score de qualité du skill chute immédiatement. Le piège classique est de tester uniquement le format, et non la cohérence métier.

L’incident s’est produit lors de l’intégration d’un nouvel agent capable d’extraire des données de fichiers plats convertis depuis l’EBCDIC. Nous avions mis à jour le prompt pour améliorer la détection des dates. Cependant, ce changement a introduit une régression sur le champ TXN-AMOUNT. L’agent commenç’t à ignorer la virgule décimale dans les montants élevés.

Le problème était invisible sur les petits jeux de tests manuels. Nous n’utilisions pas encore de Framework pour agents structuré. Le déploiement a eu lieu sur un environnement de pré-production. Le batch de fin de journée a échoué avec un écart de caisse de 12 000 euros. La cause : l’agent transformait « 000125050 » en « 125050 » sans la précision décimale.

Pour corriger cela, nous avons implémenté sivchari. Nous avons créé un dossier de ‘skills’ contenant des exemples de transactions critiques. Chaque modification de prompt est désormais soumise à la commande sivchari test --skill txn-parser. Cette commande compare le résultat de l’agent avec des fichiers de vérité terrain pré-générés en COBOL. Le pipeline CI/CD bloque désormais toute baisse de l’accuracy en dessous de 99.95%.

La résolution a nécessité la création d’un dataset de 5000 cas d’usage. Ce dataset inclut des cas limites comme les montants nuls ou les dates de fin de mois. Grâce au Framework pour agents, nous avons pu quantifier la perte de précision avant même le premier commit en production. Le taux d’erreur est passé de 15% lors de la régression à 0% après correction du prompt et validation par le nouveau framework.

Exécution d’un test de compétence sur le module de parsing de transactions.

# Initialisation du dossier de test
$ sivchari init --project mainframe-parser

# Création d'un nouveau skill pour les transactions
$ sivchari create skill txn-parser --type extraction

# Exécution du test de régression sur le dataset de production
$ sivchari test --skill txn-parser --dataset production-v1-golden

# Résultat attendu :
# [INFO] Running tests for skill: txn-parser
# [INFO] Found 500 test cases.
# [INFO] Accuracy: 99.98%
# [INFO] Precision: 100.00%
# [RECALL] Recall: 99.96%
# [SUCCESS] No regressions detected.

1. Validation de formatage EBCDIC vers ASCII : Utiliser sivchari pour vérifier que les caractères spéciaux ne sont pas corrompus lors du parsing par l’agent. sivchari run --skill ebcdic-fix --input sample.dat.
2. Détection d’anomalies transactionnelles : Créer un skill qui analyse les logs de batch pour identifier des patterns de fraude. L’agent doit être évalué sur sa capacité à ne pas générer de faux positifs.
3. Migration de code legacy : Utiliser l’agent pour traduire des routines COBOL en Python. Le Framework pour agents permet de comparer le résultat de la fonction Python avec l’output de l’original COBOL sur 1000 inputs différents.

Pour maintenir une qualité industrielle, suivez ces règles :

• Immuabilité des datasets : Ne modifiez jamais le dossier ‘golden-dataset’ sans une procédure de versioning stricte.
• Isolation des environnements : Utilisez Docker pour que vos tests de skill ne dépendent pas de la configuration locale de votre machine.
• Granularité des skills : Ne créez pas un seul skill géant. Divisez vos compétences en petites unités : parsing, validation, transformation.
• Automatisation du feedback loop : Intégrez la commande sivchari test directement dans votre pipeline GitLab CI ou Jenkins.
• Monitoring de la dérive : Re-testez vos skills chaque semaine avec de nouvelles données réelles pour détecter le ‘model drift’.

La maîtrise des agents nécessite la même rigueur que la gestion de programmes batch critiques. Le Framework pour agents n’est pas une option, c’est une nécessité pour tout projet industriel. Ne vous contentez pas de vérifier si l’agent « répond ». Vérifiez s’il respecte le contrat de données défini par votre architecture legacy. Pour approfondir les tests unitaires sur les structures de données, consultez la documentation COBOL officielle. Une donnée mal parsée est une dette technique qui se paie en heures de debugging à 3 heures du matin.