Intégrer l'IA à T-FLEX : fini les chatbots, place aux agents contrôlés

Les tentatives d'intégrer de grands modèles de langage dans des logiciels d'ingénierie comme T-FLEX CAD finissent généralement de la même façon : le processus plante, la licence se bloque, le projet fait marche arrière. Des ingénieurs sur Habr ont cherché à comprendre pourquoi et proposent une méthode pratique pour y remédier.

Pourquoi les LLM hallucinent en CAO

T-FLEX n'est pas une application web. C'est un système fermé, qui passe par des bibliothèques DLL et exige un contrôle strict de la session, des noms exacts de méthodes d'API et une concordance des types de données. Une seule erreur, et le système plante.

Par nature, les LLM fournissent des réponses probabilistes. Un modèle peut générer du code qui semble plausible : la syntaxe est correcte, la logique paraît raisonnable. Mais le détail compte : le type d'un paramètre peut être erroné, un nom de méthode peut contenir une faute de frappe, ou le code peut faire référence à un champ de structure qui n'existe pas. Dans une application web, cela affiche une erreur sur la page. Dans une CAO, cela fait tomber le processus.

Les ingénieurs appellent cela une « hallucination » : le modèle donne avec assurance une réponse fausse. Et quand des dizaines de tentatives consécutives échouent, l'approche habituelle perd son sens.

Comment fonctionne tflex_harness

Plutôt que de brancher directement le LLM, les ingénieurs ont créé le framework tflex_harness. Ce n'est pas un chatbot. C'est un système de contrôle multicouche :

• Couche 1 : modèle de langage — génère une description textuelle de la tâche à partir de la requête de l'utilisateur
• Couche 2 : boucle de contrôle — analyse la sortie du LLM et vérifie les commandes avant leur envoi à la CAO
• Couche 3 : recherche locale dans la documentation de l'API — le système suggère au modèle les bons noms de méthodes et les types de paramètres
• Couche 4 : génération et compilation de code C# — le LLM écrit le code, et le compilateur le vérifie avant toute tentative d'exécution
• Couche 5 : exécution isolée — le code s'exécute dans une session T-FLEX distincte, de sorte que les erreurs ne font pas tomber le processus principal

Résultat : si la compilation échoue, le modèle voit l'erreur précise et réessaie. L'agent apprend. Surtout, seul du code vérifié et compilé atteint la CAO.

Le refus des abstractions

C'est ici que se joue la différence majeure avec les solutions d'IA habituelles. tflex_harness renonce aux belles promesses. Le système travaille de façon plus concrète : le modèle ne peut pas inventer de méthodes et doit utiliser uniquement celles enregistrées dans l'API. Le code n'existe pas seulement dans la tête du réseau de neurones : il est réellement compilé. Les erreurs sont vérifiées mécaniquement, et non statistiquement.

Cela ressemble à une contrainte. En pratique, c'est la seule façon de pouvoir se fier au résultat.

Ce que cela signifie

Pour intégrer des LLM dans des logiciels spécialisés, il ne faut ni le plus gros modèle ni l'interface la plus élégante. Il faut de la prévisibilité et du contrôle à chaque étape. Pour la CAO, les systèmes de FAO et les logiciels d'ingénierie en général, cette approche ouvre un nouveau scénario : l'automatisation sûre de tâches d'ingénierie, sans risque de perte de données ni de plantage de licence.