Il y a quelques jours encore, je demandais à Claude d’interroger mes maquettes Revit via le serveur MCP officiel d’Autodesk. Le 16 septembre 2026, j’ai pu lui demander de les modifier. Ces tests m’ont permis de préciser ce que ce passage à l’écriture permet réellement, et où il s’arrête.

Depuis plusieurs mois, j’explore l’écosystème MCP appliqué au BIM : le serveur officiel Autodesk, des projets open source et les outils disponibles sur le Marketplace. Je cherche à comprendre comment une demande formulée dans la conversation peut devenir une action sur la maquette.

Ce qui vient de changer

Le 10 septembre 2026, Autodesk a annoncé deux nouveaux serveurs MCP en Tech Preview pour Revit 2027, en complément des outils de lecture existants.

• Read-Tools permet d’interroger la maquette.
• Trusted-Write ajoute un ensemble limité d’outils de modification, avec une revue humaine des changements.
• Experimental ouvre davantage de possibilités de création et de modification, avec un niveau de risque plus élevé.

Ces niveaux s’emboîtent : Trusted-Write comprend les outils de lecture ; Experimental comprend les deux autres. Autodesk annonce une évolution progressive des capacités et insiste sur le contrôle humain. Il s’agit encore d’une préversion technique. Lire l’annonce Autodesk

Ce passage à l’écriture concerne ici l’offre officielle Autodesk. D’autres solutions MCP permettaient déjà de modifier des maquettes : l’annonce ne marque donc pas la naissance de tous ces usages.

Ce que mes tests du 16 septembre ont précisé

Dans les versions explorées lors de ces tests, j’ai relevé trois périmètres : 8 outils pour Read-Tools, 12 pour Trusted-Write et 40 pour Experimental. Ces nombres décrivent mon relevé du 16 septembre 2026 ; ils pourront évoluer avec la préversion. Les ensembles se recouvrent, ils ne s’additionnent pas.

Mon récapitulatif distingue des outils de lecture, comme récupérer des données ou ouvrir une vue ; des outils de modification, comme changer des paramètres ou déplacer des éléments ; et des fonctions plus avancées, comme créer une feuille, annoter des éléments ou exporter un IFC. Ce sont les capacités relevées dans ces serveurs, pas une validation exhaustive de chaque outil sur tous les cas de projet.

Écrire ne veut pas encore dire tout modéliser

C’est la limite importante que je retiens de ces essais : la création d’éléments de bâtiment, comme des murs ou des fenêtres, n’est pas encore possible dans le périmètre des serveurs MCP Autodesk que j’ai exploré. Créer une feuille et créer un mur sont deux opérations très différentes, même si les deux utilisent le mot « créer ».

Mon constat est qu’on retrouve, sur le périmètre observé, les capacités fonctionnelles de l’Autodesk Assistant natif de Revit, accessibles depuis un assistant externe comme Claude. Je ne présente pas cela comme une équivalence vérifiée fonction par fonction.

Pour aller vers la création de murs ou de fenêtres, les pistes à explorer restent d’autres serveurs MCP, notamment open source, ou des applications du Marketplace, selon leurs capacités propres. Le choix du serveur détermine donc ce que l’agent peut effectivement faire.

Passer d’une réponse à une action

Une réponse peut déjà orienter une décision. Une modification touche directement les objets de la maquette. La question devient alors : quels éléments ont changé, pourquoi ceux-là, et comment vérifier que le résultat correspond à la demande ?

Imaginons une demande visant à compléter des informations manquantes. Avant de parler de gain de temps, il faut préciser les éléments concernés, les valeurs attendues et les cas où l’outil doit s’abstenir. Cet exemple est une piste de test, pas une capacité que je présente comme validée.

La facilité avec laquelle on formule une demande ne doit pas masquer ce qu’elle engage. Une phrase courte peut concerner beaucoup d’éléments. Pour moi, la qualité de la revue devient aussi importante que celle de l’exécution.

Ce que j’en retiens pour la suite

Ces essais déplacent une partie du travail : je formule l’intention, l’agent propose ou exécute des actions, puis j’examine ce qui a changé. Plus la modification devient facile à demander, plus je dois pouvoir comprendre et contrôler ses effets.

Cela rejoint la question de ma première réflexion, à paraître le 1er janvier 2027 : le logiciel reste présent, mais notre manière d’y accéder commence à changer. Le travail de formulation et de vérification prend une nouvelle place.

L’IA ne se contente plus de comprendre la maquette. Elle commence à agir dessus.

Et vous, qu’auriez-vous besoin de voir pour valider une modification faite par un agent dans votre maquette ?