DUCTILE: Agentic LLM Orchestration of Engineering Analysis in Product Development Practice

Ce papier présente DUCTILE, une approche d'orchestration agentic par LLM qui sépare l'adaptation des processus de l'exécution déterministe des outils d'ingénierie, permettant ainsi d'automatiser avec succès des tâches d'analyse structurelle dans l'industrie aérospatiale malgré des variations de données, tout en soulevant des questions sur l'évolution du rôle de supervision des ingénieurs.

L'essentiel

Voici une explication simple de l'article scientifique, imagée comme si on racontait une histoire autour d'un atelier de mécanique.

🛠️ Le Problème : La "Brittleness" (La Fragilité) des Usines Actuelles

Imaginez une usine de moteurs d'avion (comme GKN Aerospace) où les ingénieurs construisent des pièces ultra-sûres. Pour le faire, ils utilisent une boîte à outils remplie de logiciels, de scripts informatiques et de règles strictes.

Le problème, c'est que cette chaîne de production est fragile comme du verre.

• Si le fournisseur envoie les données dans un fichier YAML au lieu du JSON habituel ? Cassé.
• Si les unités passent des livres aux kilogrammes ? Cassé.
• Si le nom d'une pièce change de "Port" à "Gauche" ? Cassé.

Dans l'usine actuelle, dès qu'un petit détail change (ce qui arrive tout le temps), toute l'automatisation s'arrête. Les ingénieurs doivent alors passer des heures à faire du "bricolage numérique" (réparer les fichiers, changer les codes) au lieu de se concentrer sur la conception de l'avion. C'est comme si un chef cuisinier devait passer 3 heures à changer la forme des assiettes à chaque fois qu'un nouveau fournisseur arrive, au lieu de cuisiner.

🤖 La Solution : DUCTILE (Le Chef d'Orchestre Intelligent)

Les auteurs proposent une nouvelle approche appelée DUCTILE. Le mot est un jeu de mot : cela signifie "ductile" (comme le métal qui se plie sans casser) et aussi un acronyme pour une méthode intelligente.

Imaginez que vous engagez un Chef d'Orchestre très intelligent (une Intelligence Artificielle basée sur un "Grand Modèle de Langage" ou LLM) pour gérer l'usine.

Voici comment cela fonctionne avec une analogie simple :

1. Le Chef d'Orchestre (L'IA) ne touche pas aux outils dangereux :
   L'IA ne remplace pas les logiciels de calcul complexes (les "marteaux" et "scies" de l'ingénieur). Elle ne fait pas les calculs elle-même. Elle est trop "floue" pour ça.

   • Analogie : C'est comme un chef de chantier qui ne pose pas lui-même les briques, mais qui dit aux maçons exactement quoi faire.

2. L'IA lit les instructions et s'adapte :
   Si le fournisseur envoie un fichier bizarre, l'IA lit le manuel d'utilisation, comprend que "Oh, c'est du YAML, pas du JSON !", et écrit instantanément un petit script pour traduire le tout.

   • Analogie : Si le fournisseur arrive avec des ingrédients en livres au lieu de kilos, le chef de chantier dit : "Pas de panique, je vais juste convertir les mesures avant de les donner au cuisinier."

3. L'Ingénieur humain reste le Capitaine :
   C'est le point le plus important. L'IA propose un plan, mais l'ingénieur humain doit le valider. L'IA ne décide pas si le moteur est sûr. Elle dit : "Voici comment j'ai traité les données, voici le résultat." L'humain vérifie et donne le feu vert.

   • Analogie : Le chef de chantier propose le plan, mais c'est l'architecte (l'ingénieur) qui signe le permis de construire.

🧪 L'Expérience : Le Test de la Vérité

Les chercheurs ont testé cette idée dans une vraie usine aéronautique. Ils ont donné à l'IA un travail difficile : analyser la solidité d'une pièce de moteur.

Le piège : Ils ont modifié quatre choses qui auraient fait planter les vieux systèmes automatiques :

1. Le format du fichier (YAML au lieu de JSON).
2. Les unités de mesure (Impérial au lieu du Système International).
3. Les noms des pièces (Gauche/Droite au lieu de Tribord/Bâbord).
4. Une nouvelle règle de calcul (un facteur de correction).

Le résultat :

• L'IA a lu les documents, a vu les changements, a écrit le code pour s'adapter, et a exécuté les calculs avec les outils officiels.
• Ils ont fait le test 10 fois de suite, avec deux ingénieurs différents (l'un qui a tout délégué, l'autre qui a vérifié chaque étape).
• Résultat : 100% de réussite. L'IA a géré les imprévus sans casser le système.

💡 Pourquoi c'est important pour nous ?

Cet article nous dit deux choses essentielles :

1. L'IA n'est pas là pour remplacer l'ingénieur, mais pour le libérer.
   Aujourd'hui, les ingénieurs perdent du temps à faire du "nettoyage de données" (data wrangling). Avec DUCTILE, l'IA fait le sale boulot d'adaptation. L'ingénieur peut se concentrer sur ce qu'il fait de mieux : la prise de décision et la créativité.

2. Attention au piège de la surveillance.
   Les auteurs mettent en garde : si l'IA fait tout le travail technique, l'ingénieur risque de devenir un simple "surveillant" qui vérifie tout le temps si l'IA ne fait pas d'erreur. Cela peut être épuisant. Il faut que l'IA soit un "super-outil" qui aide, pas un robot qui nous oblige à le surveiller 24h/24.

En résumé

Imaginez que vous avez un assistant très intelligent qui lit les manuels, comprend les changements de règles, et prépare le terrain pour vous. Mais vous, l'expert, vous gardez le volant. Vous vérifiez la route, vous validez la destination, et vous décidez si c'est sûr.

C'est ça, DUCTILE : rendre l'automatisation flexible (comme le métal) pour qu'elle ne casse plus quand le monde change autour d'elle.

Résumé technique

Titre : DUCTILE : Orchestration par agents LLM de l'analyse d'ingénierie dans la pratique du développement de produits

1. Problématique : La fragilité de l'automatisation en ingénierie

Le développement de produits, en particulier dans l'aérospatiale, repose sur un écosystème complexe d'ingénieurs, de données, de méthodes et d'outils spécialisés. L'automatisation actuelle souffre d'une fragilité systémique (brittleness) :

• Interfaces rigides : Les scripts et les flux de travail automatisés reposent sur des interfaces déterministes strictes (formats de fichiers, unités, conventions de nommage).
• Rupture de l'automatisation : Dès qu'un élément de l'écosystème évolue (mise à jour d'un outil, changement de format de données par un fournisseur, modification des exigences), les pipelines automatisés échouent.
• Coûts cachés : Les ingénieurs passent un temps considérable à la « gestion des données » (data wrangling) et à la réadaptation des scripts plutôt qu'à la prise de décision technique.
• Limites des approches existantes :
  • L'ajout de règles (KBE, pipelines scriptés) augmente la complexité et crée de nouveaux modes de défaillance.
  • La dépendance à l'expertise humaine pour corriger les cas par cas est lente et crée une vulnérabilité organisationnelle.
  • Les modèles génératifs (DGM) sont conçus pour la synthèse de conception, pas pour l'orchestration de processus existants et certifiés.

2. Méthodologie : L'approche DUCTILE

L'article propose DUCTILE (Delegated, User-supervised Coordination of Tool- and document-Integrated LLM-Enabled), une approche d'orchestration agissante basée sur les Grands Modèles de Langage (LLM).

Principe Fondamental : Séparation des rôles

L'innovation centrale réside dans la séparation stricte entre :

1. Orchestration adaptative (LLM) : L'agent interprète les pratiques documentées, inspecte les données d'entrée, détecte les déviations et génère le code d'exécution. Il gère l'incertitude et la variabilité.
2. Exécution déterministe (Outils) : Les calculs d'ingénierie sont effectués par des outils vérifiés et certifiés (ex: solveurs FEM, scripts Python existants). L'agent ne modifie pas ces outils, il les appelle.

Fondements Techniques

• Architecture Agentique : Utilisation d'un cadre (framework) agissant qui boucle entre la réflexion (inference), la pensée (thinking mode) et l'appel d'outils (tool calling).
• Mode de Réflexion (Thinking Mode) : Permet au modèle de se critiquer lui-même, d'explorer des interprétations alternatives et de corriger ses erreurs avant de s'engager dans une action, réduisant ainsi les hallucinations.
• Appel d'Outils (Tool Calling) : L'agent ne se fie pas uniquement à ses connaissances internes (entraînement), mais interroge des bases de données externes, des API et des documents techniques pour obtenir des informations précises et vérifiées.
• Gouvernance et Traçabilité :
  • Inspectabilité : Les ingénieurs peuvent inspecter chaque étape (prompts, appels d'outils, fichiers générés).
  • Reproductibilité : Les versions des modèles, des prompts et des outils sont figées (pinning).
  • Surveillance humaine : L'ingénieur valide le plan et supervise l'exécution, conservant la responsabilité finale du jugement d'ingénierie.

3. Contributions Clés

1. Cadre DUCTILE : Une méthode structurée pour développer, exécuter et évaluer l'automatisation agissante dans des contextes d'ingénierie critiques, respectant les normes de certification (aérospatial/automobile).
2. Étude de Cas Industrielle : Application réelle chez un fabricant aéronautique (GKN Aerospace) sur une tâche de traitement de charges pour une structure de turbine arrière (TRS).
3. Preuve de Robustesse : Démonstration que l'agent peut gérer des déviations d'entrée qui briseraient les pipelines traditionnels, tout en produisant des résultats conformes aux critères d'acceptation experts.
4. Métrique d'Évaluation (Pass-k) : Introduction d'une approche statistique pour valider la fiabilité des agents (basée sur le concept de Basis en aéronautique : S, B, A-Basis), exigeant un nombre de runs réussis consécutifs ($k$) proportionnel au risque.

4. Résultats de l'Étude de Cas

L'agent a été testé sur un scénario de traitement de charges avec quatre déviations d'entrée par rapport aux processus habituels :

1. Format de fichier : Passage du JSON au YAML (nécessitant un nouveau parser).
2. Système d'unités : Passage du système impérial au SI (risque d'erreur silencieuse).
3. Conventions de nommage : Changement des noms des nœuds (ex: port/starboard vs left/right), ce qui aurait fait échouer le maillage FEM en aval.
4. Méthodologie : Application d'un facteur de correction (1,04) sur les forces Fx, spécifié dans la description de la tâche mais absent des données brutes.

Résultats obtenus :

• Gestion des déviations : L'agent a identifié et résolu les quatre déviations en générant un script de traitement adapté.
• Robustesse : Sur 10 exécutions indépendantes, l'agent a réussi à produire des résultats corrects et conformes à 100 %.
• Flexibilité humaine : Deux ingénieurs avec des styles de supervision différents (l'un déléguant la tâche complète, l'autre supervisant étape par étape) ont obtenu le même résultat correct.
• Validation : Les résultats ont été vérifiés par un expert du domaine et par un « juge LLM », avec un accord inter-évaluateurs de 100 %.

5. Signification et Implications

• Réduction de la fragilité : DUCTILE absorbe la variabilité des données et des interfaces au niveau de l'orchestration, protégeant les outils d'ingénierie certifiés des changements fréquents.
• Préservation du savoir-faire : L'approche ne remplace pas l'ingénieur mais déplace son rôle de la manipulation de données vers la supervision stratégique et le jugement technique.
• Documentation comme actif : L'étude souligne que l'efficacité des agents dépend de la qualité et de la structure des documents de pratique. Cela incite les organisations à formaliser leur savoir tacite.
• Risques et Avertissements :
  • Le risque principal n'est pas la perte de compétences, mais la création d'un rôle de supervision épuisant si l'agent n'est pas conçu pour être un « super-outil » amplifiant l'humain.
  • La nécessité de maintenir une boucle de vérification humaine rigoureuse pour éviter la confiance excessive (overreliance) dans des composants probabilistes.
• Avenir : L'article plaide pour la création de jeux de données ouverts et de benchmarks spécifiques à l'ingénierie pour évaluer les agents, ainsi que pour des études mesurant l'impact réel sur la productivité et la satisfaction des ingénieurs.

En conclusion, l'article démontre que l'orchestration agissante par LLM, couplée à une exécution déterministe par des outils vérifiés, offre une voie prometteuse pour rendre l'automatisation en ingénierie résiliente face à l'évolution constante des écosystèmes de développement de produits.