Un système basé sur LLM a réduit la préparation des cartes de contrôle qualité en usine sidérurgique de 2 heures à 5 minutes

Une étude de cas pratique d'une entreprise métallurgique montre que les grands modèles de langage sont déjà capables non seulement de répondre à des questions, mais aussi de soulager les ingénieurs de lourdes tâches routinières de conformité réglementaire. Le système a été entraîné à lire des numérisations de GOSTs soviéticos et à assembler automatiquement des cartes de contrôle en 3–5 minutes au lieu de plus de deux heures de travail manuel. En termes de coûts de main-d'œuvre, selon l'évaluation de l'auteur du projet, cela élimine un volume de tâches équivalent au travail de trois technologues de processus.

Le problème était très concret. Dans une entreprise de cycle complet, environ 3.200 personnes travaillent, et la nomenclature dépasse 4.

500 articles et ne cesse de croître. Pour chaque article, un technologue devait ouvrir un GOST, OST ou un autre document réglementaire, trouver les tableaux et notes nécessaires, substituer des paramètres tels que la nuance d'acier, le diamètre de la pièce et le groupe, puis remplir manuellement plus de 40 paramètres de contrôle. La difficulté était qu'il y avait plus de deux cents documents, et une part significative d'entre eux existait sous forme de numérisations PDF plutôt inconvenantes de l'époque soviétique.

La première idée était un analyseur conventionnel, mais elle s'est rapidement avérée infructueuse. Le format des documents réglementaires était trop hétérogène : dans un document, les valeurs nécessaires se trouvaient dans des lignes de tableaux, dans un autre elles étaient cachées dans des notes, dans un troisième elles étaient éparpillées dans le texte avec des références à d'autres sections. Un schéma simple d'extraction basé sur des modèles échoue ici car la tâche exige une compréhension du sens du document, et non seulement de sa structure visuelle.

L'auteur a donc eu recours aux LLM et a construit un système où le modèle recevait en entrée un PDF de la norme, les paramètres du produit et un ensemble de règles sur la façon de déterminer les paramètres de contrôle spécifiques. L'hypothèse suivante semblait logique : créer un seul prompt universel pour tous les documents réglementaires. Au premier test, cette approche a montré des résultats décents.

Selon l'auteur, Claude Sonnet 4.6 en mode thinking a correctement identifié 85% des paramètres pour un GOST, et GPT 5.4 — 72%.

Mais sur les documents suivants, l'universalité s'est effondrée. Les modèles se sont confondus avec les tableaux imbriqués, ont mal interprété les conditions aux limites comme « pas moins de » et « pas plus de », et ont parfois manqué des constantes ou des liens entre sections. Il s'est avéré que l'approche générale élégante était inférieure ici à une architecture plus étroite mais maîtrisable.

La solution fonctionnelle a émergé après avoir décomposé la nomenclature selon le principe de Pareto. Il s'est avéré que 80% des produits de l'usine sont décrits par environ 18% des GOSTs. Pour le pilote, ils ont sélectionné 20 des documents les plus fréquemment utilisés et ont créé un prompt séparé pour chacun avec des règles spécifiques : où trouver le paramètre, dans quel tableau ou section il est décrit et comment interpréter les cas litigieux.

Le système recevait un PDF et les caractéristiques du produit en entrée, et retournait un tableau avec le paramètre, la valeur et la référence à l'emplacement dans la norme en sortie. Lorsqu'une erreur se produisait, l'auteur envoyait une capture d'écran au dialogue, montrait la bonne réponse et demandait de mettre à jour la règle pour que l'échec ne se reproduise pas. Neuf itérations et 14 jours ouvrables ont été consacrés au raffinage, après quoi l'extraction de paramètres pour les GOSTs sélectionnés a commencé à fonctionner sans erreurs.

Actuellement, le projet est en train d'être transféré du mode expérimental à un format plus convivial pour la production. Les règles sont extraites des prompts dans une feuille de calcul Excel pour que les technologues puissent éditer la logique eux-mêmes sans se plonger dans l'ingénierie des prompts. Le modèle reçoit maintenant en entrée non seulement un PDF et des paramètres de produit, mais aussi ce tableau de règles, et retourne les données dans un format approprié au chargement dans le système d'information interne de l'entreprise.

Cette couche rend la solution évolutive : de nouvelles normes peuvent être progressivement ajoutées sans dépendre entièrement d'un seul développeur. La conclusion principale de cette étude de cas est simple : dans l'industrie, les LLMs fonctionnent mieux non pas comme « une intelligence universelle pour toutes les occasions », mais comme un outil soigneusement ajusté pour une classe spécifique de documents. Si vous commencez par les documents réglementaires les plus courants, faites en sorte que le modèle indique la source de chaque paramètre et maintenez les règles modifiables pour les experts du domaine, l'IA se transforme d'une démonstration en un mécanisme de production avec une économie claire.

Une telle approche pourrait bien être reproduite non seulement en sidérurgie, mais aussi en génie mécanique, construction, chimie, pharmacie et énergie—partout où les gens transfèrent encore manuellement les données des règlements vers les systèmes de travail.