Le paramétrique et son mur d’entrée
L’architecture paramétrique promet une chose simple : générer un système architectural par la seule description des lois mathématiques qui le guident. Dans les faits, elle restait jusqu’à présent réservée à ceux qui savaient construire des scripts complexes — ce qui suppose des connaissances approfondies en mathématiques et en programmation visuelle. Entre l’intention architecturale et toute la structure de composants qui la produit, il y a un apprentissage long et fastidieux, qui rend l’usage de l’outil rédhibitoire.
Après avoir vu passer beaucoup d’expérimentations d’architectes avec Claude ces derniers temps, j’ai voulu tester l’outil moi-même — et surtout chercher des cas d’usage concrets : gagner du temps, et itérer plus facilement sur plusieurs options de design. Deux systèmes ont guidé mes premiers pas, un moucharabieh en brique et un claustra en bambou. Les deux ont dépassé mes attentes, mais pas pour les raisons que j’imaginais.
Le renversement : on ne demande pas de dessiner, on demande d’écrire la règle
C’est la seule idée qu’il faut retenir de ce billet, et elle a mis quelques jours à se formuler.
Toute la méthode découle d’une distinction en trois couches, que la conception paramétrique établit déjà d’elle-même. L’intention m’appartient, exclusivement : le parti, l’effet recherché, la topologie. La règle revient à l’agent : le code qui traduit cette intention en loi géométrique. L’instance est produite par Grasshopper : la géométrie elle-même, régénérable à volonté.
Chaque fois que j’ai demandé à Claude de produire directement de la géométrie, la production s’est avérée plutôt décevante. Chaque fois que je lui ai demandé d’écrire la loi qui la produit, il a été excellent. Claude n’est pas encore un modeleur expérimenté, mais c’est un rédacteur de règles mathématiques et géométriques hors pair.
Ce renversement en entraîne un second, plus technique mais tout aussi structurant : le code ne vit pas dans le fichier Grasshopper. Un fichier `.gh` est un binaire, illisible et non versionnable. Le code vit sur le disque, dans des fichiers Python référencés en externe par un composant script unique. Grasshopper redevient ce qu’il fait le mieux : une interface, qui permet à l’utilisateur de jouer avec les entrées du script et donne à voir le résultat dans le viewport Rhino. Ce sont donc bien les scripts Python qui portent toute la géométrie.
Quant au pont MCP, il ne sert qu’à deux choses très précises : lire le canvas et ses erreurs, et capturer le viewport. Le MCP est un organe de perception, pas d’écriture. C’est probablement la différence principale entre un usage démonstratif et un usage productif.
Premier cas : le moucharabieh en brique
Pour le premier test, j’ai choisi un terrain où je pouvais juger sans complaisance : reproduire le résultat d’un script que j’avais construit à la main quelques mois plus tôt. Un réseau de briques ajourées dont l’ouverture s’élargit à mesure qu’on s’éloigne d’un ou plusieurs points d’attraction. Un mur dynamique, irrégulier, dont le dessin naît du jeu progressif entre les modules.
J’ai pris le temps de monter l’infrastructure de travail avant le moindre prompt : arborescence de projet, règles permanentes, et surtout un contrat d’interface — la liste figée des entrées et sorties du composant, avec leurs types, leurs unités, leurs plages et leur mode d’accès. Ce document a l’air bureaucratique ; il règle en amont la première cause d’échec silencieux du paramétrique, les arbres de données. Une définition qui ne renvoie rien est presque toujours un problème d’accès item/list/tree.
J’ai aussi écrit les critères d’acceptation, chiffrés et vérifiables par script : jeu maximal entre modules, appui de chaque brique sur deux briques de l’assise inférieure, temps de résolution. Sans eux, un agent améliore indéfiniment. Avec eux, chaque itération se conclut par un verdict clair.
Une fois ce cadre posé, les résultats ne se sont pas fait attendre : en quelques dizaines de minutes, le workflow était opérationnel et la géométrie conforme à mes attentes. Le temps investi dans la mise en place s’est remboursé dès la première heure — le script initial m’avait demandé plusieurs heures de production.
Deuxième cas : le claustra en bambou, dessiné puis décrit
Le deuxième test posait une autre question. Non plus « l’agent sait-il traduire une règle écrite ? », mais « sait-il lire un croquis annoté et en tirer des intentions géométriques claires ? »
J’ai donc rejoué l’expérience sur un claustra de bambous orthogonaux à écartement linéaire, en partant d’un dessin annoté plutôt que d’un texte. Résultat, là encore, bluffant.
La répartition qui fonctionne : le texte spécifie, l’image qualifie, la géométrie contraint. Environ 80 % de texte en spécification — et le rapport s’inverse en validation, où l’œil de la machine est bien meilleur en critique qu’en génération : on génère, on capture le viewport, on pose la capture à côté de la référence, on demande l’analyse d’écart, et l’on corrige ensuite les scripts Python en conséquence.
La bibliothèque de scripts, ou pourquoi le deuxième projet démarre plus haut
C’est le point qui sépare une démonstration d’une méthode.
D’un projet paramétrique à l’autre, les mêmes opérations géométriques reviennent : champs d’attracteurs, courbes d’atténuation, remapping, pavage de surface, appareillages, contrôles de fabricabilité, nomenclatures. Sans bibliothèque, l’agent réinvente ces primitives à chaque projet.
En capitalisant les sous-scripts dégagés par le moucharabieh, le claustra n’est pas parti de zéro : il a composé à partir d’un socle déjà éprouvé. Le gain se cumule, et le dispositif se renforce de lui-même. C’est cette bibliothèque, et non les prompts éphémères, qui constitue la valeur réelle de l’appareillage.
Deuxième accélérateur, moins visible : les fonctions de calcul pur se testent hors de Rhino. Écrites séparément de la couche géométrique, elles se vérifient en Python standard, en une seconde, sans ouvrir le logiciel. Le débogage logique n’a plus besoin du moindre aller-retour. Sur une session entière, le gain de temps peut s’avérer considérable.
Ce qu’il faut en retenir
On ne demande pas à un agent de dessiner, on lui demande d’écrire la règle qui dessine. Le code vit sur le disque, jamais dans le fichier Grasshopper, qui redevient une interface. Le pont MCP perçoit — canvas, erreurs, viewport — il n’écrit pas. Le contrat d’interface et les critères d’acceptation chiffrés se rédigent avant le premier prompt : c’est la demi-heure la plus rentable du projet. Un croquis coté bat un rendu photoréaliste. Et la bibliothèque de primitives, qui grossit à chaque projet, est le seul actif qui ne s’érode pas.