Un système à base de LLM ramène la préparation des cartes de contrôle d'une usine de 2 heures à 5 minutes

Un cas pratique issu d'une entreprise métallurgique montre que les grands modèles de langage ne se contentent plus de répondre à des questions : ils peuvent aussi décharger les ingénieurs d'une lourde routine normative. Un système a appris à lire des scans de GOST de l'époque soviétique et à produire automatiquement des cartes de contrôle en 3–5 minutes, contre plus de deux heures de travail manuel. En charge de travail, selon l'auteur du projet, cela supprime un volume de tâches comparable à celui de trois technologues.

Le problème était très concret. L'entreprise à cycle complet emploie environ 3200 personnes, et sa nomenclature dépasse 4500 références et ne cesse de croître. Pour chaque référence, le technologue devait ouvrir un GOST, un OST ou un autre document normatif, trouver les tableaux et notes pertinents, renseigner des paramètres comme la nuance d'acier, le diamètre de la billette et le groupe, puis remplir à la main plus de 40 paramètres de contrôle.

La difficulté tient à ce qu'il existe plus de deux cents documents, dont une bonne part sont des scans PDF peu pratiques datant de l'ère soviétique. La première idée était un parseur classique, mais elle a vite été abandonnée. Le format des normes est trop hétérogène : dans un document, les valeurs utiles figurent dans les lignes de tableaux, dans un autre elles sont cachées dans les notes, dans un troisième elles sont dispersées dans le texte avec des renvois à d'autres sections.

Un schéma d'extraction simple par gabarit se brise ici, car la tâche exige de comprendre le sens du document, et pas seulement sa structure visuelle. L'auteur s'est donc tourné vers les LLM et a monté un dispositif où le modèle reçoit en entrée le PDF de la norme, les paramètres de la nomenclature et un ensemble de règles indiquant comment déterminer chaque paramètre de contrôle. L'hypothèse suivante paraissait logique : écrire un seul prompt universel pour tous les documents normatifs.

Au premier test, cette approche a donné un résultat correct. Selon l'auteur, Claude Sonnet 4.6 en mode thinking a correctement identifié 85 % des paramètres d'un GOST, et GPT 5.

4, 72 %. Mais sur les documents suivants, l'universalité s'est effondrée. Les modèles se perdaient dans les tableaux imbriqués, interprétaient mal des conditions limites comme « au moins » et « au plus », et omettaient parfois des constantes ou des liens entre sections.

Il s'est avéré qu'une belle approche générale était ici moins bonne qu'une architecture plus étroite mais maîtrisable. La solution est venue après une analyse de la nomenclature selon le principe de Pareto. Il est apparu que 80 % des références de l'usine sont décrites par environ 18 % des GOST.

Pour le pilote, les 20 documents les plus utilisés ont été retenus, avec pour chacun un prompt dédié et des règles précises : où chercher le paramètre, dans quel tableau ou quelle section il est décrit, et comment interpréter les cas litigieux. Le système recevait le PDF et les caractéristiques du produit, et renvoyait un tableau avec le paramètre, sa valeur et un renvoi à l'endroit concerné de la norme. Quand une erreur apparaissait, l'auteur envoyait une capture d'écran dans la conversation, montrait la bonne réponse et demandait de mettre à jour la règle pour que l'erreur ne se reproduise pas.

La mise au point a demandé neuf itérations et 14 jours ouvrés, après quoi l'extraction des paramètres pour les GOST retenus a fonctionné sans erreur. Le projet passe maintenant du mode expérimental à un mode mieux adapté à la production. Les règles sont sorties des prompts pour être placées dans un tableau Excel, afin que les technologues puissent modifier la logique eux-mêmes sans se plonger dans l'ingénierie de prompts.

Le modèle reçoit désormais non seulement le PDF et les paramètres du produit, mais aussi ce tableau de règles, et restitue les données sous une forme directement chargeable dans le système d'information interne de l'entreprise. Cette couche rend la solution évolutive : on peut ajouter progressivement de nouvelles normes sans faire reposer toute la maintenance sur un seul développeur. L'enseignement principal du cas est simple : dans l'industrie, les LLM fonctionnent mieux non pas comme une « intelligence universelle pour tous les cas », mais comme un outil soigneusement réglé pour une classe précise de documents.

Si l'on commence par les normes les plus fréquentes, si l'on oblige le modèle à indiquer la source de chaque paramètre et si l'on laisse les règles modifiables par les spécialistes métier, l'IA passe de la démonstration à un mécanisme de production à l'économie claire. Cette approche pourrait très bien se reproduire non seulement dans la métallurgie, mais aussi dans la construction mécanique, le bâtiment, la chimie, la pharmacie et l'énergie — partout où des personnes recopient encore à la main des données de règlements vers des systèmes de travail.