Un agent IA en production qui n'a pas le droit d'inventer

Sur la plupart des projets que VOID héberge et maintient, chaque cycle de maintenance se termine par un rapport envoyé au client : composants mis à jour, failles de sécurité corrigées, performance du site, parcours critiques re-testés. C'est la preuve visible du travail réalisé — et la base de la confiance du client.

Le problème : ce rapport était écrit à la main. Un ingénieur collectait les changements de version, allait chercher chaque advisory de sécurité, lançait les contrôles SSL et performance, copiait les résultats, puis réécrivait l'ensemble en français lisible. Deux à quatre heures par projet et par période, pour un résultat dont la qualité variait d'un auteur à l'autre.

Pendant mon PFE chez VOID, j'ai conçu un agent IA de reporting de TMA pour absorber cette corvée : un système qui collecte seul les informations, les agrège, les fait raisonner par un modèle de langage, puis produit un document propre en quelques minutes.

Mais le vrai sujet de ce retour d'expérience n'est pas l'outil. C'est la question que pose toute mise en production d'un LLM dès qu'on sort de la démo : comment faire écrire un modèle de langage quand on ne peut pas se permettre qu'il invente ?

Depuis GPT-3, l'intuition dominante est simple : on rassemble les données, on les colle dans un prompt, et on demande au modèle de rédiger le rapport complet. Avec un bon modèle frontier, la démo est bluffante — quelques secondes, et un texte fluide, structuré, convaincant.

C'est exactement ce qu'il ne faut pas faire ici.

Un rapport de maintenance est un document factuel : numéros de version (Drupal 10.4.6 → 10.5.6), identifiants de CVE, scores de performance, dates de certificat. Or un LLM en génération libre produit un texte qui sonne juste mais qui est parfois faux — c'est l'hallucination, le risque le mieux documenté de ces modèles. Et plus le modèle est capable, plus il est convaincant quand il se trompe : une hallucination à haute confiance.

Dans un rapport client orienté sécurité, une version erronée ou une CVE inventée n'est pas une coquille — c'est une perte de confiance, voire un risque contractuel. Le modèle écrira « cette mise à jour corrige une vulnérabilité critique d'injection SQL » avec le même aplomb, que la faille existe ou non. Pour un livrable que personne ne recoupe ligne par ligne, c'est rédhibitoire.

La partie difficile d'un rapport n'a jamais été la rédaction. C'est d'obtenir des données correctes. L'architecture en découle directement : on sépare les faits de la formulation.

Chaque chiffre est collecté de manière déterministe, depuis des sources officielles. Le modèle n'intervient qu'à la fin, et uniquement pour transformer cette matière vérifiée en français lisible. Le LLM n'est jamais une source de faits : c'est une couche de reformulation contrôlée posée au-dessus de données déjà collectées et validées.

C'est, mot pour mot, le principe du grounding popularisé par le RAG (retrieval-augmented generation) : on n'interroge pas la mémoire du modèle, on lui fournit le contexte vérifié et on lui demande seulement de le mettre en forme. La recherche appelle aussi cela la génération « data-to-text » : un texte dont chaque phrase est traçable jusqu'à une donnée structurée.

Aucune ne lui demande de produire un chiffre. On lui demande des phrases, à partir de valeurs qu'il n'a pas le droit de modifier.

L'agent fonctionne comme un pipeline orchestré. La validation de l'entrée arrive d'abord (schéma strict via Zod) : une entrée malformée échoue avant le moindre appel réseau. Suivent deux phases.

La plupart des étapes attendent un service distant : le contrôle SSL pilote un navigateur headless, l'audit performance est délégué à l'infrastructure de Google, le scan appelle notre web-scanner, l'agrégation interroge le NVD et les advisories GitHub et Drupal. Ces appels sont indépendants et dominés par la latence réseau ; lancés ensemble plutôt qu'en série, le temps mort de l'un recouvre le travail de l'autre, et la phase ne dure que le temps de sa sonde la plus lente.

La Phase 2 ne démarre qu'une fois toutes les tâches de la Phase 1 terminées. Les narratifs raisonnent sur les faits collectés (sauts de version, CVE filtrées, scores, findings) et ne doivent jamais s'exécuter en avance sur eux. Cette barrière est précisément ce qui empêche le modèle de décrire des valeurs encore en cours de récupération — un garde-fou d'orchestration autant que de correction.

Les narratifs sont générés en concurrence, mais avec un nombre borné d'appels simultanés : inutile de saturer un serveur d'inférence, et la concurrence se paie en tokens. L'assemblage HTML puis le rendu PDF (headless Chrome) sont, eux, strictement séquentiels.

Donner la parole à un LLM en production, c'est accepter qu'il puisse mal répondre. La réponse n'est pas de mieux « prompter » — c'est d'entourer le modèle de garde-fous, exactement comme les modèles frontier grand public sont aujourd'hui livrés avec leurs safety classifiers.

Dès qu'un agent repose sur une dizaine de services externes, la vraie question n'est plus « est-ce que ça marche ? » mais « que se passe-t-il quand l'un d'eux tombe ? ». Et il y en a toujours un qui tombe : une API rate-limitée, un checker SSL qui met quatre minutes à répondre, un quota dépassé.

Le premier justifie le pipeline parallèle ; le second, une couche de résilience uniforme : une primitive de retry (trois tentatives, backoff aléatoire, erreurs transitoires seulement), des wrappers best-effort (un échec renvoie des données vides plutôt que d'arrêter le pipeline) et des chaînes de fallback (SSL ×3, PageSpeed ↔ GTmetrix, scan repris du cache).

Un agent qui appelle un LLM sur chaque rapport, plusieurs fois, peut voir sa facture s'envoler. Trois leviers le contiennent : la concurrence bornée en Phase 2, le caractère strictement optionnel de l'enrichissement (sans endpoint configuré, l'agent saute la rédaction et garde le texte manuel — le rapport sort quand même), et un découpage des tâches qui n'envoie au modèle que le strict nécessaire.

Enfin, la portabilité. L'agent vise un endpoint compatible OpenAI, défini par configuration. On peut donc router vers un modèle auto-hébergé open-weight — un Qwen sur notre propre infrastructure, pour les données sensibles — ou vers une API commerciale comme Claude quand sa puissance fait la différence, et basculer de l'un à l'autre sans toucher au code. C'est la même logique d'architecture multi-modèles et de souveraineté des données que VOID applique à ses projets IA : le bon modèle pour le bon usage, selon le rapport coût / capacité / sensibilité.