Un agent LLM a assemblé un réducteur dans KOMPAS-3D, mais n'obtient que 50 points sur 100 pour la nomenclature

L'auteur d'un article publié sur Habr a écrit un plugin, kompas-mcp, grâce auquel un agent LLM travaille à l'intérieur de KOMPAS-3D, une CAO russe pour la modélisation d'ingénierie : l'agent ouvre des modèles, construit et modifie des pièces et des assemblages, et met en forme les dessins. L'agent communique via MCP, un protocole ouvert par lequel le modèle appelle des outils externes. L'exemple principal est un réducteur cylindrique à un étage, issu d'un projet de cours classique sur les éléments de machines : du calcul jusqu'au dessin d'ensemble et à la nomenclature, c'est-à-dire le dossier complet de documentation de conception (КД).

Pour savoir où l'agent est réellement utile, l'auteur a monté un benchmark maison de 15 tâches, notées jusqu'à 100 points. Les pièces et les sous-ensembles ont obtenu 88–100 points, la nomenclature de l'assemblage seulement 50.

Ce que l'agent a produit pour le projet de réducteur

L'auteur ne se considère pas comme concepteur et a joué le rôle de client : il fixait le cahier des charges étape par étape, validait chacune d'elles et repérait les erreurs visibles à l'œil. Les données de départ sont classiques : moteur AIR112M4 (5,5 kW, 1440 tr/min), rapport de transmission de 4, durée de vie de 10 000 heures. L'agent a calculé la transmission selon la méthode de Chernavsky. Le calcul n'est pas stocké sous forme d'image : il est écrit en variables et en équations directement dans le document KOMPAS, et le tableau des résultats y fait référence.

L'agent a ensuite construit un assemblage à squelette : l'entraxe, le module, les nombres de dents, les diamètres et les largeurs sont stockés dans l'assemblage, et les pièces y puisent leurs dimensions. Il a vérifié lui-même le caractère paramétrique : il a temporairement fixé u = 5, constaté que le squelette se reconstruisait, puis annulé la modification. Le modèle comprend un arbre-pignon z = 26 et une roue z = 105 (m = 1,5), un arbre lent, des roulements 207 et 208, des clavettes selon GOST 23360, des bouts d'arbre selon GOST 12080, un carter moulé avec bossages et dépouilles, et des couvercles encastrés pour joints à lèvres 35×58 et 40×60.

Les dents sont générées par l'application standard « Валы и механические передачи 3D » (Arbres et transmissions mécaniques 3D), et non par des esquisses.

Le caractère paramétrique n'est apparu qu'après l'intervention de l'humain. L'auteur a demandé si les résultats du calcul avaient été transmis aux variables. Ce n'était pas le cas. L'agent a proposé plusieurs options, et l'auteur a retenu les équations dans le document de calcul et les variables de référence dans l'assemblage. Autre découverte : sur les dessins, les rainures de clavette avaient des extrémités concaves, et l'agent a corrigé le défaut à la fois dans les modèles et sur les dessins. L'auteur ne garantit pas la justesse du réducteur dans son ensemble, et il garde des questions sur le dossier de documentation de conception.

Du code plutôt qu'un jeu de boutons : comment fonctionne le plugin

Le plugin est un serveur MCP pour KOMPAS. N'importe quel client compatible MCP peut s'y connecter : Claude Code, Claude Desktop, Cursor, VS Code, Codex, Gemini CLI. L'article utilise Claude. À l'intérieur de KOMPAS tourne une bibliothèque avec un Python embarqué : le code de l'agent s'exécute directement dans le processus du programme, avec un accès complet à l'API. À l'extérieur, un petit pont relie MCP à cette bibliothèque. L'installation se fait en un seul script dans le profil utilisateur, sans droits administrateur.

La décision centrale est de renoncer à un outil distinct pour chaque action. KOMPAS offre des milliers d'opérations avec des dizaines de paramètres, et une tâche réelle en combine toujours plusieurs. L'agent écrit donc un script sur l'API et l'exécute. Le plugin lui fournit une documentation des interfaces et des méthodes, une vue d'ensemble du modèle (arbre, variables, contraintes d'assemblage, liens entre pièces et dessins), des vérifications (erreurs de reconstruction, interférences entre corps, masse comme valeur de contrôle) et des images avec coupes, pour que l'agent voie le modèle au lieu de deviner à partir de chiffres.

Toute modification se fait à l'intérieur d'une étape : on l'ouvre, on exécute le code, on la ferme. À la fermeture, le plugin contrôle le résultat, et si des erreurs de reconstruction ou des interférences apparaissent, l'étape n'est pas acceptée. L'agent doit alors corriger le problème ou annuler l'étape entière. Dans l'historique de KOMPAS, une étape correspond à une seule entrée, de sorte que l'humain l'annule lui aussi en une seule action. L'agent peut également lancer une instance distincte de KOMPAS pour ne pas gêner l'ingénieur dans sa fenêtre.

Le benchmark : où l'on atteint 100 points, et où l'on plafonne à 50

L'auteur prévient : le benchmark est bricolé maison. Les 15 tâches sont dérivées d'assemblages prêts à l'emploi livrés avec KOMPAS. Il prend un produit fini, retire ou casse un élément, et demande à l'agent de le reconstituer. L'assemblage d'origine sert de référence, et la vérification est automatique : géométrie, assemblage, masse, dessin. C'est un outil pour améliorer le plugin, pas une comparaison scientifique de modèles.

Une partie des résultats (points sur 100, durée) :

• arbre d'après le dessin de définition, Sonnet : 100, 8 minutes ;
• sous-ensemble d'arbre d'après le dessin d'ensemble, Sonnet : 88–94, 7 minutes ;
• nouvel arbre dans le contexte d'un assemblage, Sonnet : 91, 15 minutes ;
• achèvement d'une charpente métallique d'après un modèle, Opus : 100, 5 minutes ;
• dessin de définition d'une roue dentée, Sonnet : 82, 49 minutes ;
• КМД d'une charpente métallique (repères, dessins, acier), Opus : 88, 32 minutes ;
• nœuds de charpente métallique à partir de solutions types, Opus : 63, 44 minutes ;
• nomenclature de l'assemblage, Sonnet : 50, 7 minutes.

En 3D, l'agent s'en sort avec assurance : il demande presque aucune correction et consomme peu de tokens. Les dessins et la documentation de conception sortent avec des remarques, et coûtent nettement plus de temps et de tokens. L'agent choisit les vues, les repères, les cotes et les tolérances, mais s'emmêle dans l'API au moment de tout placer sur la feuille : l'information figure sur le dessin, mais il est difficile à lire. Les bibliothèques intégrées de KOMPAS s'intègrent mal, beaucoup n'ont même pas d'interfaces COM, et une action simple se transforme en une série de commandes.

La seconde cause des points faibles est le manque de données. Les exemples de code sur l'API de KOMPAS sont rares sur le web, les modèles se perdent dans certaines opérations et la consommation de tokens grimpe. Pour l'instant, seuls les modèles de niveau Opus viennent à bout des tâches lourdes, tandis que Sonnet suffit pour les tâches simples. L'auteur espère que les nouvelles générations de modèles, y compris ouverts, rendront ce type de modélisation plus accessible.

Conclusion pratique : l'agent absorbe déjà la routine en 3D — pièce d'après un dessin, sous-ensemble, modification sur tout un assemblage, achèvement d'après un modèle, estimation des tolérances. Les dessins et les nomenclatures doivent être vérifiés et retravaillés à la main. Le plugin est disponible sur GitHub (cad-lab-ai/kompas-mcp), et l'auteur invite à lui envoyer les cas où l'agent a aidé et ceux où il n'a pas aidé.