Un assistant de code écrit à votre place le script qui renomme une série de plans, interroge un IFC ou mesure un nuage de points. L’architecte peut décrire la tâche en langage courant ; il doit ensuite comprendre ce qui sera exécuté, travailler sur une copie et vérifier le résultat. Pour une opération qu’il ne sait pas contrôler, un appui technique reste nécessaire.
Demander le programme, pas le résultat
Une réponse de modèle de langage ne vaut pas un calcul géométrique exécuté. Un agent peut, en revanche, appeler des outils de calcul ; il faut alors identifier les données, le traitement et les contrôles du résultat. Un banc d’essai l’a mesuré sur des maquettes au format IFC, le format d’échange ouvert entre logiciels : sur 65 questions, les deux modèles testés retrouvent une information écrite dans le fichier dans 78 à 93 % des cas, mais ne réussissent que 43,8 % des questions qui demandent de compter, de sommer ou de croiser (MCP4IFC, 29 octobre 2025). Ils reconnaissent bien, en revanche, qu’une information manque : 95 à 100 %. Ces résultats décrivent ce banc d’essai, ses modèles et ses questions. Ils ne donnent pas le taux de fiabilité de tout assistant sur toute maquette.
La parade tient en une règle : faire exécuter le calcul plutôt que le demander. Le code exécuté rend le traitement inspectable et reproductible. Il peut pourtant contenir une mauvaise formule, un filtre incomplet ou une erreur d’unité. Le résultat doit être comparé à un cas connu.
Ce que fait un assistant de code
Claude Code est un agent : il lit un dossier, écrit un script, l’exécute, lit le compte rendu, corrige et recommence. Il s’ouvre dans un terminal, mais aussi dans un onglet de l’application de bureau, sans ligne de commande. Les briques qu’il assemble sont libres : IfcOpenShell pour les IFC, ezdxf pour les DXF, d’autres bibliothèques Python pour les tableurs et les nuages de points.
La version du logiciel, la disponibilité de sa documentation et les fonctions exposées par son interface de programmation déterminent ce que l’on peut automatiser. Un exemple écrit pour une autre version peut employer une fonction absente ou différente. Le réflexe consiste à préciser l’environnement exact, fournir la documentation utile et commencer par un essai limité. Les appréciations du livre sur AutoLISP, Rhino, Revit ou Archicad sont des repères de travail, sans garantie de réussite au premier essai.
Les tâches qui s’y prêtent
Quatre critères, à réunir tous : la tâche est fastidieuse, répétitive, massive et vérifiable. Renommer des fichiers en série, contrôler des milliers d’objets contre une règle, migrer une bibliothèque, extraire des données pour les recouper : bons candidats. Concevoir, arbitrer, produire un métré qui servira tel quel au chiffrage, modifier la géométrie du projet : mauvais candidats. Le quatrième critère décide de tout : une tâche que vous ne savez pas vérifier ne devient pas sûre parce qu’un script la traite vite.
La méthode : une copie, un cas connu, un regard
Le script ne touche pas au fichier de production. Il travaille sur une copie datée, dans un dossier distinct, après une sauvegarde vérifiée et rangée hors de portée de l’IA ; les originaux restent en lecture seule.
Avant d’exécuter, l’assistant dit ce que le script va faire. Vous relisez l’intention, la liste des fichiers touchés et le journal. Cette lecture fonctionnelle ne remplace pas une revue du code quand l’enjeu ou la complexité la rendent nécessaire. Puis vous jugez sur un cas dont vous connaissez la réponse : une pièce mesurée au télémètre, un élément mesuré à la main. Une configuration non mesurée est une opinion.
Deux garde-fous encore. Ne rien conclure d’une extraction vide : un filtre faux ressemble à une absence. Et vérifier que les données et les outils utilisés respectent le contrat et les engagements de confidentialité. L’essai se prépare avec des fichiers autorisés et un périmètre maîtrisé.
Un exemple : un relevé laser devenu maquette
Le 19 octobre 2026, j’ai confié à l’assistant le relevé laser d’un élément sculpté : 289 740 points, dont la couverture laisse des faces non relevées. Le nom du fichier suggère une station unique, point à confirmer dans les données du relevé. Dans cet essai, l’assistant accède au fichier par des scripts spécialisés. Il a écrit des scripts qui le lisent, le mesurent et le découpent, puis il a lu leur compte rendu. La première chaîne, prévue pour des murs, s’est arrêtée d’elle-même : ni sol ni plafond. Une fois la nature de l’objet requalifiée, la seconde a produit quatre objets maillés, avec un écart médian au nuage de 0,5 à 0,6 mm et 97 à 99 % des points à moins de 5 mm, en 45 secondes pour ce traitement, hors préparation et validation humaine. Ces écarts mesurent la proximité du maillage avec les points disponibles ; ils ne démontrent pas la précision absolue du relevé ni la fidélité des faces absentes.
Le chiffre le plus instructif est ailleurs. La reconstruction automatique avait fermé les volumes : 69 à 91 % de la surface qu’elle proposait ne reposait sur aucun point relevé, dans les parties que le nuage ne documentait pas. Le script l’a retirée, et l’a comptée. Le lendemain, une passe d’allègement a ramené le fichier IFC de 6,1 à 1,5 Mo.
Je n’ai pas écrit ces scripts. Mes décisions ont porté sur ce qu’aucun script ne tranche : la nature de l’objet, la méthode de dessin validée avant toute transcription, les faces laissées ouvertes faute de relevé.
Ce qui reste à l’architecte
L’assistant de code ne déplace pas la responsabilité. Les quantités d’un métré se recoupent avec une nomenclature du logiciel. Le dimensionnement structurel, la vérification réglementaire opposable et l’arbitrage de conception ne se confient pas à l’IA.
La progression se fait par niveaux : lire, préparer, modifier de façon réversible sur une copie ; décider reste humain. On passe au niveau suivant sur des preuves, comptes, exports, fichier rouvert, pas sur une impression de réussite.
Coder sans être développeur, c’est donc savoir ce que l’on veut obtenir, disposer d’un cas dont on connaît la réponse, et regarder le résultat avant de s’y fier.
Ces méthodes sont développées dans mon livre IA19 consacré à l’IA et au dessin 3D. Pour connaître le contenu et les modalités de l’accompagnement correspondant, contactez-moi.
Sources – Nithyanantham, Sesterhenn, Nedungadi, Peral Garijo, Zenkner, Bartelt et Lüdtke, « MCP4IFC: IFC-Based Building Design Using Large Language Models », arXiv 2511.05533, version 1 du 29 octobre 2025 : banc d’essai de 65 questions sur des maquettes IFC (27 directes, 16 demandant une agrégation ou un calcul, 22 sans information suffisante) ; questions directes réussies à 77,8 % et 92,6 % selon le modèle ; agrégation et calcul à 43,8 % pour les deux modèles (7 sur 16) ; information absente reconnue à 95,5 % et 100 % — arxiv.org. Relu le 12/11/2026. – Anthropic, documentation de Claude Code, page « Overview » : agent qui lit un dossier, modifie des fichiers et exécute des commandes ; disponible dans le terminal, l’application de bureau (onglet « Code ») et le navigateur — code.claude.com. Relue le 12/11/2026. – ezdxf, documentation : paquet Python qui crée, lit, modifie et écrit des fichiers DXF, sous licence MIT — ezdxf.readthedocs.io. Relue le 12/11/2026. – Essais des 19 et 20 octobre 2026 de Conseils d’Architecture (documents internes) : relevé laser d’un élément sculpté, 289 740 points, une seule station ; quatre objets maillés, écart médian de 0,5 à 0,6 mm, 97 à 99 % des points à moins de 5 mm, 69 à 91 % de la surface reconstruite automatiquement retirée faute de point relevé, 45 secondes ; fichier IFC de 6,1 Mo ramené à 1,5 Mo le 20 octobre. – Laetitia Bataillie, livre « IA et dessin 3D » (module IA19), v0.16 du 29/10/2026 : « Les scripts : ce que l’IA sait vraiment écrire, par environnement », « La règle de tri, les six règles », « Le socle S », section F « Du nuage de points à la maquette » ; livre IA01 « IA pour concepteurs : comprendre, décider, cadrer », v6.12 du 29/10/2026, sections 1.1 et 7.6.