OpenSCAD vs CadQuery vs Build123d : quel moteur CAO l'IA sait-elle vraiment écrire ?

GrandpaCAD transforme un message de chat en modèle imprimable en 3D. L'IA écrit le code CAO, on le compile, tu obtiens un maillage. Le plus gros levier que j'ai, c'est donc de choisir le langage CAO dans lequel l'IA écrit. Choisis le mauvais, et le modèle passe son budget à se battre avec la syntaxe au lieu de construire ta pièce.

Chaque fois que je publie là-dessus, quelques personnes sur Hacker News me disent la même chose : OpenSCAD est un jouet, il ne sait pas faire de la vraie CAO, et je devrais plutôt utiliser un vrai noyau paramétrique comme CadQuery ou Build123d. Ils ont en partie raison, les noyaux sont vraiment plus capables. Alors au lieu de discuter, j'ai fait l'expérience. Si tu es arrivé ici parce que tu m'as dit de changer, voici ma réponse.

J'ai écrit plus tôt sur pourquoi on a choisi OpenSCAD après avoir commencé par un schéma JSON, puis JSCAD, puis Blender. Ceci est la suite. Je suis revenu tester les deux moteurs CAO paramétriques "sérieux" que j'avais sautés, CadQuery et Build123d, l'un après l'autre, sur la même suite d'evals. Voici ce que les chiffres ont dit.

Si tu veux la méthodologie derrière ces exécutions (comment je note, pondère et archive), c'est un billet à part : comment nous testons l'agent de modélisation.

Deux familles de code CAO

Il y a vraiment deux camps.

OpenSCAD est déclaratif et bâti sur la géométrie de solides constructive (CSG). Tu décris des formes et tu les combines avec union, différence et intersection. Le langage est petit, donc il n'y a pas beaucoup de surface pour qu'un modèle se trompe.

CadQuery et Build123d sont des bibliothèques Python qui enveloppent OpenCASCADE, le même noyau B-rep (représentation par les bords) qui se trouve sous FreeCAD et beaucoup de CAO commerciale. Le B-rep est l'approche "vraie" CAO : surfaces courbes exactes, et vrais congés et chanfreins qui cassent une arête au lieu de gonfler toute la pièce. Sur le papier, ils sont plus capables qu'OpenSCAD, et c'est du Python, que tout modèle écrit couramment.

Mon attente en entrant était donc que les moteurs B-rep Python gagneraient. Ce ne fut pas le cas.

Ce que j'ai mesuré

Chaque moteur a fait passer le même jeu de prompts par le même harnais, sur le même palier de modèle (gemini-3.5-flash, la bête de somme bon marché que je benchmarkais à l'époque), pour que la seule variable soit le langage CAO. Je me soucie de trois choses :

• Erreurs de code par génération : à quelle fréquence l'IA écrit du code qui ne compile pas ou plante à l'exécution.
• Modèles ratés : générations qui n'ont jamais produit un maillage utilisable.
• Coût et temps réel, comme départage.

Les erreurs de code sont le signal honnête. Mon harnais les répare automatiquement, donc un utilisateur voit rarement l'échec, mais chaque réparation est un appel de modèle de plus, ce qui veut dire plus de latence et plus de dépense. Un taux d'erreurs de code élevé, c'est l'IA qui te dit discrètement qu'elle ne connaît pas vraiment le langage.

Sur le même modèle et les mêmes scénarios, OpenSCAD s'est établi autour de 0,4 erreur de code par génération (10 sur une exécution de 23 modèles). Build123d, qui écrit du Python censé être plus facile pour le modèle, est arrivé à 40 erreurs de code sur la même exécution sans aide, et 33 avec, soit à peu près trois à quatre fois le taux d'OpenSCAD. Ça fait trois à quatre fois plus de boucles de réparation pour le même travail.

CadQuery était plus compliqué à ne serait-ce que mesurer. Mes premières exécutions ne tombaient pas sur la syntaxe, elles tombaient sur l'export. L'écrivain 3MF intégré de CadQuery ne gère que le maillage et perd les couleurs des pièces, alors j'ai dû écrire à la main un exporteur 3MF couleur avant que les modèles multi-pièces ne sortent intacts. Avant ce correctif, jusqu'à la moitié des scénarios d'une exécution échouaient carrément. Une fois la plomberie en place, les échecs ont baissé, mais le motif de fond rejoignait Build123d : le modèle continuait à chercher des méthodes qui n'existent pas.

Pourquoi l'IA est moins bonne sur les "meilleurs" moteurs

Ça m'a d'abord surpris, puis c'est devenu logique. Ce qui rend CadQuery et Build123d puissants est aussi ce qui fait trébucher le modèle : une API vaste, fluide et chaînable avec des centaines de méthodes et des attentes strictes sur ce qui renvoie une face plutôt qu'une arête plutôt qu'un fil. Les modèles actuels n'en ont pas assez vu. Ils appellent avec assurance une méthode au mauvais nom, dans le mauvais ordre d'arguments, ou sur le mauvais type d'objet. Ça se lit comme du Python plausible et ensuite ça ne tourne pas.

OpenSCAD a le profil inverse. Le langage est petit et stable, et les modèles en réussissent bien plus souvent la forme déclarative. Quand ça dérape, une seule passe de réparation de syntaxe suffit d'habitude à corriger.

J'ai bien essayé de combler l'écart. Pour Build123d, j'ai généré une référence d'API à signature exacte directement depuis la bibliothèque (introspectée, pas écrite à la main) et je l'ai donnée au modèle. Ça a aidé de façon mesurable : les erreurs de code sur une exécution complète sont passées de 40 à 33. Mais 33 reste bien au-dessus du niveau d'OpenSCAD. Une fiche de référence réduit l'écart, elle ne l'efface pas.

Le plan : OpenSCAD maintenant, B-rep plus tard

Rien de tout ça ne veut dire que CadQuery ou Build123d sont mauvais. Ce sont de meilleurs moteurs. Le noyau est plus capable et la géométrie plus exacte, et le jour où un modèle les écrira aussi fiablement qu'il écrit OpenSCAD, GrandpaCAD basculera. Les faire tourner comme des evals, c'est précisément ce qui me permet de changer de moteur au moment où le tableau de scores dit que c'est l'heure.

Pour l'instant, la réponse est ennuyeuse et correcte : OpenSCAD, c'est ce que les modèles actuels écrivent assez bien pour être livré. Je garde CadQuery et Build123d branchés et sélectionnables dans le harnais pour pouvoir relancer ce comparatif à chaque fois qu'un modèle plus fort débarque, et laisser les chiffres décider plutôt que le buzz.

Alors à tous ceux qui me disent d'utiliser un vrai noyau CAO : vous avez raison, il est plus capable, et je l'ai bien essayé. Le goulet d'étranglement aujourd'hui, ce n'est pas le noyau, c'est ce que le modèle peut écrire sans casser. Quand ça changera, le choix par défaut changera aussi.

Envie de voir ce que le moteur produit ? Essaie le moteur OpenSCAD.