Votre agent peut vous tendre un STEP : text-to-cad et le code comme géométrie

La partie qui n'a jamais été du texte

Les agents de codage écrivent du logiciel parce que le logiciel est du texte. Ce seul fait explique presque tout ce qu'ils savent bien faire. Il explique aussi pourquoi ils sont restés inutiles en mécanique : un support n'est pas du texte, une épaisseur de paroi n'est pas du texte, et un fichier STEP n'est absolument pas du texte, même si techniquement, si.

text-to-cad, un plugin sous licence MIT signé earthtojake, qui squatte le tableau des tendances de GitHub ce mois-ci avec environ 18,600 stars, résout cette contradiction avec une vieille ficelle : si la chose n'est pas du texte, fabriquez une représentation textuelle de la chose. Ici, un script Python paramétrique.

Le boulot de l'agent n'est pas d'imaginer un modèle 3D. C'est d'écrire du code qu'un noyau géométrique peut exécuter. Cette distinction, c'est tout le produit.

Comment la boucle tourne vraiment

Le moteur en dessous, c'est cadgen, un paquet Python sur PyPI construit sur build123d, qui pilote lui-même Open CASCADE, la même famille de noyaux géométriques que les vrais outils de CAD. Un modèle, c'est un simple script Python : une fonction décorée par une définition step qui renvoie une forme.

Disons que vous voulez une fixation caméra avec des parois de 3mm et deux trous M3. Vous la décrivez en mots. L'agent écrit le script avec des paramètres pour l'épaisseur de paroi, le diamètre des trous et leur entraxe. cadgen l'exécute et écrit un STEP, plus du STL, du 3MF ou du GLB si vous demandez. Vous voulez bouger un trou ? Un chiffre à changer, on relance. Le source du modèle reste dans le dépôt, à côté de votre autre code : il se diff, se relit et se revert comme le reste.

C'est la différence entre une géométrie exacte et un maillage plausible. Un générateur de maillage produit une surface qui ressemble à un support. Un modeleur volumique produit un support dont l'épaisseur de paroi est connue, et un atelier acceptera un fichier STEP alors qu'il refusera poliment votre STL de surface courbe à 4,000 triangles.

Le plugin gère aussi les parties ennuyeuses qui décident si un design existe pour de vrai. Il lance des contrôles de conception pour la fabrication et pour la fabrication additive, épaisseur de paroi, surplombs, dépouilles, contre-dépouilles, et il donne la règle derrière chaque constat au lieu d'un avertissement sec. Il génère des plans cotés en PDF avec vues, traits cachés, annotations de trous et cartouche. Il écrit des profils DXF pour la découpe laser, tranche du G-code via OrcaSlicer, envoie les impressions sur les machines Bambu Lab, fait les vérifications avant envoi pour SendCutSend, et écrit des fichiers URDF, SRDF et SDF pour les descriptions de robots et les mondes de simulateur.

Il y a aussi une visionneuse locale. Dans les apps qui le supportent, le modèle apparaît sous forme de carte dans le chat ; ailleurs, vous récupérez un lien localhost.

Pourquoi ça se généralise

Le cas d'usage CAD est précis, le motif ne l'est pas. Tout domaine qui a deux propriétés peut être confié à un agent de codage : une représentation de l'artefact en code, et un vérificateur qui dit si l'artefact est valide.

Les pièces mécaniques ont les deux. Le script est la représentation, le contrôle de fabricabilité est le validateur. Les pages web ont les deux, HTML et un navigateur. L'infra a les deux, de la configuration et un plan. La vidéo, jusqu'à récemment, n'avait ni l'un ni l'autre sous une forme qu'un agent puisse exécuter, et c'est exactement le trou que des projets comme HyperFrames comblent.

Là où un domaine manque de vérificateur, les agents produisent des âneries avec assurance. C'est pour ça que "l'IA pour la 3D" est bloquée au stade de la preview : il n'y avait aucun validateur entre "on dirait une chaise" et "c'est fabricable".

L'autre moitié du motif, c'est l'exécution locale. cadgen tourne sur votre machine, contre un vrai noyau géométrique. Rien n'est approximé par un réseau de neurones à l'étape géométrique. L'agent apporte l'intention paramétrique, le noyau apporte la vérité.

Les taxes d'adoption, qui sont réelles

Deux choses vont mordre, et les deux sont documentées dans le dépôt plutôt que découvertes dans la douleur, ce qui fait honneur aux auteurs.

Windows 11 a un piège bien à lui. Le binding Python du noyau CAD embarque un module natif non signé, et le Smart App Control de Windows 11, actif par défaut sur une installation neuve, le bloque. Toutes les commandes échouent alors sur une erreur de chargement de DLL. Il n'y a pas d'exception par application. Vos options : désactiver Smart App Control, ce qui sur certains systèmes ne se revient qu'en réinstallant Windows, ou faire tourner les skills CAD sous WSL. Une commande doctor détecte le cas, donc au moins vous le savez vite.

La télémétrie est active par défaut. Le README la documente avec un luxe de détails inhabituel, et c'est le bon réflexe. Ce qui part : versions, source d'installation, système d'exploitation, l'app d'agent que vous utilisez, et des compteurs comme le nombre d'appels par outil et le nombre de modèles construits, plus des motifs d'échec choisis dans une liste fixe plutôt que le texte de l'erreur. Les rapports de crash contiennent le type d'erreur et l'endroit du code où ça a cassé. Le tout est étiqueté avec un ID d'installation aléatoire et stocké chez PostHog ; le serveur déduit votre pays de l'IP et ne garde pas l'adresse. Ce qui ne part jamais : noms de fichiers, chemins, contenu des fichiers, prompts. Une seule commande suffit à la couper, et elle supprime aussi ce qui est déjà parti ; rien n'est envoyé en CI ni depuis une installation de développement.

Les deux sont normaux pour un projet jeune, et les deux coûtent en adoption. Un éditeur de CAD commercial ne livrerait ni l'un ni l'autre.

Ce pour quoi ce n'est pas fait

Les formes organiques. Personnages, figurines, formes sculptées, tout ce où la forme est le but et pas la fonction : c'est le territoire du maillage, et un modèle image-to-3D à base de maillage est le meilleur outil. Décrire un dragon en paramètres, c'est une mauvaise après-midi.

Ce n'est pas non plus un remplacement pour la validation d'ingénieur. Le skill DFM est une revue guidée, pas une certification. Si une pièce doit porter le poids de quelqu'un, un ingénieur humain signe encore le plan. La boucle se termine quand quelqu'un paie une facture, et c'est probablement la bonne place pour l'humain.

Le dépôt lui-même est jeune et va vite : créé en avril 2026, plus de 1,400 commits, un paquet PyPI avec des dizaines de releases, et trois versions livrées en deux jours début octobre. Ce rythme est un atout si vous aimez les skills neuves et un risque s'il vous faut de la stabilité.

La phrase du README qui compte

Enterrée dans la description, il y a une affirmation facile à sauter : le plugin donne à votre agent un vrai workflow de CAD. Pas une démo, pas un wrapper de prompt, un workflow avec une représentation, un exécutant, un validateur et une passation à un fabricant.

C'est la forme de chose qui rend les agents utiles hors du logiciel. Pas un modèle qui connaît les supports, mais une boucle où le modèle écrit quelque chose d'exécutable, où autre chose le vérifie, et où la sortie est un fichier qu'un autre système accepte. L'agent n'a pas besoin d'être bon en CAD. Il doit être bon en code, et le domaine doit avoir un compilateur.

La mécanique y est arrivée la première parce que le compilateur a cinquante ans et que le validateur est un ensemble de règles de fabrication. Tous les autres domaines qui récupèrent ces deux pièces auront cette tête d'ici un an.