Cet article expose discrètement pourquoi la plupart des "agents IA pour l'ingénierie" échouent dès qu'ils quittent les démonstrations simplistes. Tout le monde suppose que la partie difficile est le langage. Ou le raisonnement. Ou des modèles plus grands. Ce travail montre que le véritable goulot d'étranglement est la structure. L'article présente SimuAgent, un assistant basé sur un LLM pour Simulink, l'environnement de modélisation graphique utilisé par des millions d'ingénieurs dans des industries critiques pour la sécurité. Voitures. Avions. Réseaux électriques. Des endroits où les hallucinations n'ont pas droit à l'erreur. Le problème central est laid. Simulink n'est pas du texte. Ce sont des graphes hiérarchiques avec des règles de topologie strictes, des contraintes spécifiques au domaine, et des milliers de combinaisons de blocs valides mais fragiles. Déverser du XML dans un LLM ne fonctionne pas. Les captures d'écran ne fonctionnent pas. Les longues invites s'effondrent sous les limites de contexte. Ainsi, les auteurs changent la représentation. Au lieu de XML ou d'images, SimuAgent convertit les modèles Simulink en un dictionnaire Python compact. Seules les informations essentielles survivent : blocs, paramètres, connexions. Pas de bruit de mise en page. Pas de désordre visuel. Le nombre de tokens passe d'environ 43k à environ 2,7k dans des exemples réels, et même moins après simplification. Ce n'est pas cosmétique. Cela change fondamentalement ce que le modèle peut raisonner. De plus, l'agent utilise une boucle planifier-exécuter efficace. Pas un cirque multi-agents tentaculaire. Planification quand nécessaire. Exécution quand c'est sûr. Replanification uniquement après des échecs de validation. Un banc d'essai Python local détecte les erreurs de câblage, les paramètres invalides et les incompatibilités de type avant que MATLAB ne s'exécute. Mais la contribution la plus intéressante n'est pas architecturale. C'est la façon dont ils entraînent le modèle. L'utilisation d'outils à long terme a un problème de récompense brutal. Vous ne savez que si le modèle a réussi qu'à la toute fin. Une récompense scalaire. Pas de guidance en cours de route. GRPO aide un peu, mais c'est encore rare. Leur solution est Reflection-GRPO. Lorsque le premier lot de déploiements échoue, le modèle génère de courtes traces de réflexion expliquant ce qui a mal tourné — outils mal utilisés, mauvaises hypothèses, étapes manquantes. Ces réflexions sont alimentées dans un second sous-groupe, guidant l'exploration sans divulguer les réponses. Au début, la réflexion est fréquente. À mesure que le modèle s'améliore, elle s'estompe naturellement. L'apprentissage s'accélère. L'instabilité diminue. Ils associent cela à une astuce d'auto-supervision astucieuse : Abstract–Reconstruct. L'agent résume un modèle Simulink, puis essaie de le reconstruire en utilisant uniquement ce résumé. Cela l'oblige à établir un lien entre l'intention de haut niveau et l'implémentation de bas niveau, exactement ce que font les vrais ingénieurs. Le benchmark est réel, pas synthétique. SimuBench comprend 5 300 tâches à travers des systèmes de contrôle, électriques, mécaniques, thermiques, fluides et électromagnétiques. Création. Modification. QA. Petits modèles et grands modèles. ...