YADRO interdit au LLM de toucher aux chiffres et publie plus de 10 rapports par jour sans intervention humaine

Chez YADRO, l'équipe qui gère le parc d'équipements IT a construit en trois mois un service qui produit chaque jour plus d'une dizaine de rapports analytiques pour cinq départements. Aucun humain n'intervient dans le processus. La règle d'ingénierie centrale : tous les chiffres sont calculés par le code, tandis que le modèle de langage se contente de rédiger des commentaires et ne voit aucun indicateur sous sa forme brute. Le projet est l'œuvre d'Egor Shliupikov, analyste métier senior, et de son collègue Egor Kataev, alors que personne dans l'équipe GRID n'avait jusqu'ici mené de développement en production.

De l'expérience sur un export au service autonome

Tout est parti d'une tâche d'avril : évaluer les stocks d'un entrepôt et proposer comment écouler le matériel qui dormait. L'entreprise suivait alors la métrique aged, c'est-à-dire la part des actifs stockés depuis plus d'un à deux ans. Egor Shliupikov a pris un export de Naumen.ITAM, supprimé les données sensibles (entités juridiques, noms des entrepôts) et demandé à un réseau de neurones de générer un rapport HTML. Les angles d'analyse étaient nombreux : chacun avait peu de valeur isolément, mais ensemble ils répondaient à une foule de questions. Le responsable a validé le développement de l'idée au sein du périmètre de l'entreprise.

La première version tournait sur la plateforme low-code Dify. L'équipe y a branché le contexte métier comme base de connaissances et, à cause des limites de contexte, a commencé à transmettre non pas les données brutes, mais une synthèse préparée par un script Python. Même avec cette synthèse, le modèle se trompait. Il reportait les chiffres dans le texte selon les règles du prompt, et les mêmes valeurs ressurgissaient hors de propos dans les commentaires. Il s'est avéré qu'il s'agissait des valeurs de l'instantané des actifs au jour du branchement de la base de connaissances, et non des données actuelles.

Des balises à la place des chiffres

De là est née une séparation stricte. Le script prépare deux jeux de données : un jeu complet, qui sert à construire les graphiques et le gabarit, et un jeu compact contenant quelques dizaines de chiffres clés. Le modèle ne voit que le jeu compact. Il renvoie des observations, des interprétations et des signaux d'alerte, en plaçant des balises à la place des chiffres. Les valeurs sont insérées lors de l'assemblage du rapport, selon les mêmes règles que dans le gabarit. Il est physiquement impossible que le modèle déforme un indicateur.

Côté économie de tokens, c'est aussi un avantage : le contexte contient des dizaines de chiffres, et non des tableaux de lignes. L'appel au modèle est isolé dans un client dédié, ce qui permet de le remplacer sans toucher au pipeline. L'apparence des rapports est externalisée dans des gabarits. Si le modèle est indisponible ou répond de façon incorrecte, le rapport sort à l'heure, avec des chiffres exacts, simplement sans conclusions textuelles.

L'équipe a dû quitter Dify à cause de la gestion des droits d'accès, du stockage des paramètres de connexion à la base dans les réglages du pipeline, et de l'absence de planification, de statistiques et de notifications.

Trino pour fusionner les données dans le temps et entre systèmes

Quand les sources se sont multipliées, toute la couche de données a migré vers une machine virtuelle dédiée avec Trino. Les auteurs reconnaissent que c'était alors surdimensionné, mais ils ont voulu se ménager une marge de sécurité. Trino résout deux problèmes.

• Fusion dans le temps. Dans Naumen.ITAM, l'état courant se trouve dans la réplique de la base de production, tandis que l'historique arrive dans ClickHouse sous forme d'instantanés quotidiens. Une seule requête fédérée prend le point du jour dans la réplique, et la veille ainsi que tout l'historique dans ClickHouse. Limite : le pas de l'historique est de 24 heures, les statuts modifiés au cours d'une journée sont invisibles, et la vitesse des processus est donc calculée avec prudence.
• Fusion entre systèmes. Naumen.ITAM sait à quelle équipe est rattaché un serveur, NetBox connaît sa baie dans le centre de données. Une requête les joint et montre comment les coûts d'une baie se répartissent entre les équipes.

Les générateurs de rapports ignorent d'où viennent les données, si bien que brancher une nouvelle source n'oblige pas à réécrire les rapports. Les sources actuelles : Naumen.ITAM, ClickHouse DWH, 1C, la plateforme BI/CPM (nombre de nouveaux collaborateurs et budget), Jira (demandes d'équipements) et NetBox.

Le pipeline et la protection contre ses propres erreurs

La chaîne se déroule ainsi : Airflow (qui a remplacé cron) lance un DAG, les données sont lues via Trino, Python calcule les indicateurs, Dify renvoie les commentaires, le gabarit génère le HTML, le rapport est enregistré avec un horodatage et le lien vers la dernière version est mis à jour. L'accès passe par le Keycloak de l'entreprise et une vérification des droits dans un validator, avec des rôles de propriétaires, d'administrateurs, d'utilisateurs et de superutilisateurs. Via Mattermost, on peut demander un accès, actualiser les rapports et consulter les statistiques.

Le code est hébergé sur le GitLab de l'entreprise, et les modifications ne sont acceptées que via une merge request validée par quelqu'un d'autre que l'auteur. Chaque mise à jour tourne pendant 24 heures sur un environnement distinct ; si la recette échoue, le retour arrière est automatique.

Des données qui n'existaient pas

Le service a mis au jour des trous dans les données. Personne n'avait jusqu'ici calculé la valeur opérationnelle des stocks en entrepôt, et le prix n'est pas renseigné pour toutes les positions dans Naumen.ITAM. La solution retenue : une imputation par cohortes (type de matériel, modèle, fabricant, année de production). Le prix moyen des positions dont le prix est connu est étendu aux autres. Dans le rapport, le coût réel et l'estimation sont présentés séparément. Si une cohorte ne contient aucun prix, elle est élargie ou laissée sans estimation, avec une mention. Le rapprochement avec la comptabilité a donné des chiffres comparables.

Ce qu'on peut en retenir

Ce schéma s'applique à n'importe quel reporting : un code déterministe calcule, le modèle reçoit des agrégats et renvoie un texte avec des placeholders. C'est moins coûteux en tokens, plus simple à auditer, et le rapport ne casse pas en cas de panne du modèle. Prochaine étape pour l'équipe : un générateur de rapports où l'utilisateur décrit une coupe en langage naturel, le modèle formule la description des métriques, et la couche sémantique Cube génère le SQL à partir de mesures définies à l'avance. Là encore, le modèle ne touche ni aux requêtes ni aux chiffres.