BenchCAD : ce que démontre la reconstruction d’une pièce mécanique exécutable, et ce qu’elle ne prouve pas sur la conception industrielle

Quel problème BenchCAD isole-t-il ?

Un système d’IA appliqué à la conception physique peut produire l’image plausible d’une pièce sans pour autant livrer un artefact utile à l’ingénierie. Pour modifier un modèle, l’inspecter ou le réutiliser dans un flux paramétrique, il faut une représentation exécutable : des opérations, des dimensions, des relations et une logique produisant une géométrie. BenchCAD se concentre sur l’écart entre une apparence extérieure approximative et un programme de CAO paramétrique qui peut être exécuté.

BenchCAD 1.0 utilise CadQuery comme environnement de CAO programmatique. Selon la tâche, son unité pratique d’évaluation combine des rendus d’une pièce, un programme initial, une instruction de modification, un programme CadQuery de référence et un solide STEP de référence. Le modèle doit répondre par du code, une modification de code ou une réponse numérique. L’évaluateur exécute ensuite la sortie et compare la géométrie produite, ou la réponse, avec la référence.

Cette conception a une conséquence importante : le benchmark n’a pas besoin qu’un autre modèle de langage décide si la pièce « semble correcte ». Le signal géométrique provient d’une exécution et d’une comparaison calculable avec le solide de référence. Cela réduit la subjectivité inhérente à une évaluation fondée exclusivement sur des juges génératifs. Cela n’élimine toutefois pas les choix méthodologiques : quelles pièces sont incluses, comment la géométrie est discrétisée, quel environnement est figé et ce qui est considéré comme une sortie valide.

Le dépôt de BenchCAD déclare quatre tâches et une collection composée de 17 900 programmes, 106 familles, 748 modifications et 2 400 questions associées à 200 pièces. Ces chiffres décrivent la composition publiée de la ressource ; ils n’équivalent pas, à eux seuls, à une couverture représentative de tous les secteurs, normes ou types de produits de l’industrie mécanique.

L’unité d’évaluation : code, vues et référence géométrique

Dans Vision2Code, l’entrée est une représentation visuelle de la pièce et la sortie attendue est un programme CadQuery capable de la reconstruire. L’évaluation ne récompense pas uniquement une séquence de texte ressemblant au programme d’origine : elle exécute le programme candidat et compare le solide obtenu au STEP de référence. Des programmes différents peuvent donc obtenir un résultat semblable s’ils produisent une géométrie proche.

Dans CodeEdit, l’entrée ajoute un programme de base et une instruction de modification. L’objectif n’est pas de reconstruire une pièce depuis zéro, mais de modifier le code pour rapprocher sa géométrie d’une cible. Cette formulation ressemble davantage à l’usage d’un assistant technique, mais demeure une tâche contrôlée : l’instruction, le point de départ, le moteur et la référence sont définis par le jeu de données.

Vision-QA et Code-QA changent le type de sortie. Dans la première, le système déduit une réponse numérique à partir de vues ; dans la seconde, il l’obtient en raisonnant sur du code. Ces tâches servent à séparer partiellement la lecture de la géométrie de la génération de programmes. Néanmoins, une réponse numérique correcte ne démontre pas que le système peut modifier une conception sans casser ses dépendances ni gérer un projet de CAO complet.

Le jeu publié comprend des exemples de programmes CadQuery, de rendus et de questions numériques. Le fait qu’un artefact soit visible dans un jeu de données ou un dépôt public soulève une incertitude habituelle dans l’évaluation des modèles : le matériau a pu être accessible avant l’entraînement de certains systèmes. Les sources fournies ne permettent pas d’établir, pour chaque modèle du leaderboard, quels contrôles de contamination ont été appliqués ni de démontrer l’absence d’exposition préalable.

Comment les résultats sont notés : exécution, recouvrement volumétrique et amélioration par rapport à une référence

La métrique de Vision2Code combine deux conditions. Premièrement, le programme doit s’exécuter. Deuxièmement, le solide généré doit recouvrir le solide de référence lorsque les deux sont voxelisés sur une grille de résolution 64³. Le leaderboard décrit le score comme l’IoU volumétrique multiplié par le pourcentage de programmes qui s’exécutent. Cette multiplication empêche qu’une bonne géométrie sur quelques cas masque un taux élevé d’échecs d’exécution.

Il est utile de distinguer ces signaux. Le taux d’exécution indique si les sorties sont acceptées par l’environnement figé et produisent une géométrie évaluable. L’IoU indique dans quelle mesure le volume discrétisé des sorties exécutables correspond à la référence. Un programme peut s’exécuter sans erreur tout en générant un solide incorrect ; il peut aussi exprimer une stratégie raisonnable mais échouer à cause d’une API, d’un import ou d’une exception, et ne fournit alors aucune géométrie notée.

Dans CodeEdit, le leaderboard n’utilise pas simplement l’IoU final. Il normalise l’amélioration par rapport à la géométrie initiale : il soustrait l’IoU de référence à l’IoU du modèle et divise par la marge restante jusqu’à un ; le résultat est ensuite borné dans l’intervalle entre zéro et un. Si une modification n’améliore pas le point de départ, y compris lorsqu’une sortie ne s’exécute pas, sa contribution est nulle. Ce choix récompense un progrès vérifiable et évite de considérer comme réussie une modification qui conserve une pièce déjà proche de la cible sans apporter l’amélioration demandée.

Pour Vision-QA et Code-QA, la documentation décrit une précision symétrique de rapport pour les questions numériques. En pratique, la note dépend de la proximité relative entre la réponse prédite et la réponse de référence, de manière symétrique face à une surestimation ou une sous-estimation. Pour interpréter de faibles écarts de dixièmes, il faudrait examiner l’implémentation concrète des tolérances, des arrondis, des zéros et des formats de réponse. Les notes fournies ne détaillent pas tous ces cas limites.

Quels résultats sont réellement comparables ?

Un chiffre BenchCAD ne prend un sens comparatif que si le protocole est conservé. Il faut au minimum identifier la version précise du benchmark, la partition de données, la tâche et le type de résultat. Comparer Vision2Code à CodeEdit, ou un sous-ensemble sélectionné à une évaluation complète, n’est pas équivalent. Il ne l’est pas non plus de ranger dans une même catégorie des chiffres obtenus avec des outils, des boucles de réparation ou des budgets d’inférence différents.

Le processus de contribution publié demande les prédictions brutes et la configuration d’exécution, et indique que les mainteneurs recalculent les scores avec l’évaluateur officiel avant d’intégrer les résultats opérationnels au leaderboard. Cette pratique est importante : elle permet d’appliquer une politique commune d’exécution et de notation, plutôt que d’accepter uniquement un chiffre déclaré par la personne ayant exécuté le modèle. La réévaluation du résultat ne rend toutefois pas automatiquement identiques les conditions de génération.

Lors de la lecture d’une ligne du leaderboard, un responsable technique devrait demander la configuration complète : version de CadQuery et dépendances, accès ou non à Python et à des outils externes, nombre maximal d’itérations, usage de rendus intermédiaires, limites de temps, contexte disponible, température ou politique d’échantillonnage et budget de calcul. Un agent capable d’exécuter, d’observer les erreurs et de réparer le code plusieurs fois résout un problème opérationnel différent d’un modèle qui fournit une réponse unique.

La politique relative aux sorties en échec compte également. Dans Vision2Code, les échecs d’exécution réduisent le résultat agrégé par le pourcentage d’exécution. Dans CodeEdit, une sortie qui ne s’exécute pas ou ne dépasse pas la référence n’obtient aucune amélioration. Ne publier que l’IoU des cas réussis masquerait précisément une difficulté centrale : produire des programmes reproductibles dans l’environnement spécifié.

Ce qu’une concordance géométrique ne mesure pas

BenchCAD fournit des éléments de preuve sur la reconstruction géométrique dans des conditions circonscrites, et non une certification de conception industrielle. La géométrie extérieure peut être compatible avec plusieurs intentions de conception. Une épaisseur, la position d’un trou ou un rayon peuvent répondre à une charge, une interface, une norme, un outil de fabrication, une séquence d’assemblage ou une décision de coût qui ne se déduit pas de façon sûre à partir de vues et d’un solide de référence.

Le benchmark ne valide pas non plus les tolérances dimensionnelles et géométriques, les ajustements, les finitions, les matériaux, les traitements, les propriétés thermiques, le comportement structurel ou la durée de vie en fatigue. Une pièce peut atteindre un IoU élevé et échouer à une condition essentielle : ne pas s’assembler avec sa contrepartie, ne pas permettre l’outil d’usinage prévu, ne pas résister à la charge ou ne pas satisfaire une exigence réglementaire. Ces propriétés exigent des exigences explicites, des analyses spécialisées, des données matériaux et, selon le cas, des prototypes ou des essais.

L’évaluation se concentre en outre sur des pièces et des programmes individuels dans un environnement contrôlé. Elle ne démontre pas la gestion d’assemblages complexes, de références externes, de bibliothèques internes, du contrôle des modifications, de la traçabilité des décisions, de la revue par les pairs, du contrôle d’accès ou de l’interopérabilité avec les systèmes de CAO, PLM et de gestion documentaire d’une entreprise. Un copilote peut être utile à une étape sans être apte à fonctionner de manière autonome dans un processus de libération.

Pour ces raisons, une lecture responsable n’est pas de dire que BenchCAD est insuffisant, mais qu’il répond à une question délimitée. C’est un signal plus direct qu’une comparaison visuelle lorsqu’il faut savoir si le code de CAO généré s’exécute et s’approche d’une référence. L’adoption exige d’ajouter des essais représentant les risques réels du produit et de l’organisation.

BenchCAD 1.0 et BenchCAD 2.0 ne doivent pas être présentés comme équivalents

Les sources distinguent un benchmark publié avec des tâches, des métriques et un leaderboard d’une initiative ultérieure appelée BenchCAD 2.0. Le dépôt de BenchCAD 1.0 documente les quatre tâches, son environnement et le processus de soumission des résultats. Ses métadonnées de citation déclarent l’artefact comme un jeu de données, version 0.1.0, avec une date de publication indiquée au 24 juin 2026. Cette date doit être lue comme une métadonnée déclarée par le projet ; elle ne prouve pas à elle seule quand chaque résultat a été exécuté ni quelle révision exacte chaque participant a employée.

BenchCAD 2.0 est décrit comme un pipeline de données fondé sur des contributions communautaires, avec un objectif de 150 familles et des conceptions paramétriques auditables, y compris des composants et assemblages industriels. Le dépôt indique lui-même qu’il ne s’agit pas d’un pipeline d’évaluation ou de notation. L’étendue de données prévue ne doit donc pas être confondue avec un leaderboard disponible, un protocole validé ou un chiffre directement comparable à BenchCAD 1.0.

Cette séparation protège contre deux erreurs. La première consiste à présenter une promesse de couverture future comme s’il s’agissait déjà d’une mesure de performance. La seconde consiste à transposer des résultats d’une version à l’autre alors que les pièces, les familles, les sources, les annotations ou les règles d’évaluation peuvent changer. Jusqu’à ce qu’un protocole d’évaluation et de scoring soit publié pour BenchCAD 2.0, une affirmation prudente est qu’il décrit un processus de construction de données, et non un leaderboard équivalent.

Checklist pour les annonces de fournisseurs et les décisions d’achat

Face à une annonce citant BenchCAD, la première question doit être précise : quelle tâche le système a-t-il résolue ? Dire qu’un modèle « excelle en CAO » sans préciser s’il a généré du code à partir d’images, modifié un programme ou répondu à des questions numériques mélange des capacités différentes. La deuxième question est opérationnelle : le chiffre inclut-il l’exécution complète, comment les erreurs ont-elles été traitées et les prédictions brutes ont-elles été recalculées avec l’évaluateur officiel ?

La troisième question porte sur les conditions : quels outils, itérations et budgets ont été autorisés ? Dans les systèmes agentiques, ces variables modifient matériellement le résultat et son coût. La quatrième est statistique : le split complet a-t-il été évalué ou une sélection, et combien de cas sont concernés ? La cinquième ramène la discussion au produit : quelle validation indépendante a été effectuée sur les tolérances, le procédé de fabrication, l’assemblage et les exigences du client ?

Une réponse solide peut être modeste. Par exemple : « Dans Vision2Code de BenchCAD 1.0, avec l’environnement et le budget déclarés, le système a généré des programmes dont la géométrie exécutée a atteint une certaine concordance volumétrique, avec un certain taux d’exécution. » Cette formulation indique ce qui a été mesuré sans transformer une métrique de benchmark en garantie d’ingénierie. La décision de déployer le système doit en outre reposer sur un pilote avec des pièces, des règles et des outils représentatifs du contexte propre à l’organisation.

La valeur principale de BenchCAD réside précisément dans le fait qu’il rend visible une frontière vérifiable : passer d’une entrée visuelle, textuelle ou de code à un programme que l’environnement de CAO peut exécuter et dont la géométrie peut être comparée. Cette frontière est exigeante et pertinente. La conception industrielle et la libération de produit franchissent néanmoins d’autres frontières que le benchmark ne prétend pas résoudre.

Poursuivre l’exploration

Corrections et transparence

Si vous repérez une information incorrecte ou obsolète, envoyez-nous la page et la source à vérifier.