Comment mettre en place un flux de migration Revit Cloud Worksharing avec APS et MCP ?

Ce que vous allez apprendre dans ce guide

Ce guide explique comment concevoir un flux de migration Revit Cloud Worksharing (RCW) dans un serveur Model Context Protocol (MCP) qui communique avec APS. L’exemple d’Autodesk montre comment un client MCP convertit une demande en langage naturel en appels d’outils, comment le serveur orchestre les opérations APS et comment l’automatisation Revit migre le modèle. Les étapes présentées servent à comprendre l’architecture de l’exemple ; elles ne constituent pas une recette de configuration prête pour la production et applicable directement à tous les projets.

La distinction essentielle est la suivante : le client d’IA coordonne la décision de migration et les appels d’outils, tandis que l’opération réelle sur le modèle est exécutée par Design Automation for Revit, qui utilise l’API Revit. Le serveur MCP gère les opérations et l’autorisation entre ces deux parties.

Prérequis et accès

L’exemple d’Autodesk étend un serveur MCP basé sur Node.js avec des fonctions APS. Le serveur MCP doit être connecté à un client compatible et pouvoir accéder aux données APS contenant le modèle source et le projet cible. Le moteur Revit approprié à la migration et les activités d’automatisation doivent également être configurés pour exécuter l’automatisation Revit. La source ne précisant ni version de Node.js ni tarif, il ne faut pas supposer de version ou de coût.

Le choix de l’authentification dépend de l’emplacement du serveur et des données sur lesquelles l’opération doit porter. Pour un serveur lancé par un client de bureau local via STDIO, une authentification distincte au niveau client-serveur peut ne pas être nécessaire. Côté APS, 3-legged OAuth (3LO) peut être utilisé pour agir au nom d’un utilisateur ; PKCE peut convenir lorsque la clé secrète ne peut pas être stockée, par exemple dans un processus local. Pour les opérations nécessitant une identité d’application partagée à l’échelle du serveur, 2-legged OAuth (2LO) ou un Secure Service Account (SSA) autorisé peuvent être envisagés. Gardez à l’esprit que toutes les API n’acceptent pas tous les types d’identifiants.

Planifier le flux de migration étape par étape

1. Définissez le scénario d’utilisation et le client. Déterminez d’abord si l’opération doit s’effectuer avec les droits d’accès propres à l’utilisateur ou au moyen d’une identité d’automatisation partagée. Choisissez ensuite si le serveur MCP fonctionnera comme processus local ou sera proposé à distance via HTTP. Le guide d’Autodesk aborde STDIO pour l’utilisation locale et Streamable HTTP pour les scénarios distants et multi-utilisateurs. Pour les serveurs accessibles via HTTP, l’authentification entre le client et le serveur doit être conçue séparément de l’authentification APS.

2. Choisissez la méthode d’authentification APS en fonction des droits nécessaires. Pour accéder aux données personnelles d’un utilisateur, envisagez 3LO ou PKCE, qui reposent sur sa connexion. 2LO peut être utilisé pour les ressources propres à l’application, mais cette méthode peut ne pas suffire pour les appels d’API exigeant un contexte utilisateur. Si l’automatisation doit accéder aux données du projet sans qu’un utilisateur ait à se connecter constamment, un SSA autorisé pour les hubs et projets concernés peut être envisagé. Ne confondez pas le jeton d’accès entre le serveur et le client avec le jeton APS : ces jetons remplissent des fonctions différentes.

3. Séparez les rôles des outils MCP. Dans l’exemple d’Autodesk, le serveur peut explorer les projets et dossiers à l’aide des outils de gestion de données existants ; le champ extensionType du contenu d’un dossier permet de repérer les modèles RCW. L’outil migrate-rcw-model ajouté pour la migration reçoit le modèle source, le projet et le dossier cibles, ainsi que la version de Revit cible. L’application prépare et soumet ensuite un travail APS Automation à partir de ces informations. Séparer la découverte de l’action de migration, qui modifie les données, rend plus claire la décision de l’opération à lancer pour le client.

4. Faites vérifier les prérequis et demandez l’accord de l’utilisateur. Dans le flux d’exemple, check-migrator-setup sert à vérifier les moteurs Revit et les activités d’automatisation configurés. Autodesk indique que les consignes du flux de travail peuvent inciter l’assistant à vérifier les prérequis et à demander l’accord de l’utilisateur avant la migration. Ne soumettez pas le travail de migration avant d’avoir défini le projet, le dossier et la version de Revit cibles ; confirmez ces choix avec l’utilisateur.

5. Assurez le suivi du travail asynchrone. La migration pouvant durer plusieurs minutes, le retour d’un identifiant de travail par l’outil ne signifie pas que l’opération est terminée. Dans l’exemple, get-migration-status récupère l’état du travail et les informations d’erreur ; cancel-migration demande l’annulation des travaux en attente. Dans les clients compatibles utilisant MCP Apps, un panneau d’état peut afficher les travaux en cours, les migrations terminées, les détails des erreurs et les commandes d’annulation. Cette couche doit être considérée séparément de l’outil qui lance la migration.

6. Testez le flux de manière sécurisée et limitée. Commencez par vérifier que les modèles accessibles sont bien répertoriés et que la configuration est correcte. Ensuite, avec l’accord de l’utilisateur, soumettez un seul modèle au projet cible et vérifiez que l’identifiant du travail, son état et les informations d’erreur sont renvoyés comme prévu. Transmettre des jetons APS au client ou envoyer directement à APS le jeton du client n’est pas une bonne approche. Pour un serveur MCP distant, définissez également qui peut y accéder ; cette couche est distincte de celle qui détermine l’identité utilisée par APS.

Enjeux pour les flux de travail d’architecture et de visualisation

Les agences d’architecture qui travaillent avec plusieurs projets Revit ou modèles RCW peuvent tirer parti de la possibilité de lancer une migration en langage naturel et d’en suivre l’avancement dans le même client. Pour les développeurs, les outils MCP offrent un exemple de connexion de l’automatisation APS existante à différents clients compatibles. Cela ne résout toutefois pas automatiquement la coordination BIM ni l’analyse des dépendances du modèle.

Les sources ne donnent aucune information sur le matériel ou le coût des licences. Avant de prendre une décision, il convient donc de vérifier séparément l’accès de l’organisation à APS, la configuration d’automatisation Revit choisie et la compatibilité de la méthode d’authentification avec les autorisations du projet. Les équipes qui travaillent avec des modèles liés ne doivent surtout pas supposer que les modèles associés sont également migrés avec le modèle principal.

Erreurs fréquentes et prochaines étapes

La principale limite est que l’exemple se concentre sur des modèles RCW pris individuellement : il ne migre pas automatiquement les relations entre les modèles liés et ne répare pas les liens dans le projet cible. Les projets comportant des modèles liés nécessitent une analyse des dépendances, une vérification préalable et une coordination supplémentaires ; la source les présente comme des fonctionnalités susceptibles d’être ajoutées à l’avenir.

Une autre erreur fréquente de conception consiste à confondre l’authentification entre le client MCP et le serveur avec l’accès à APS. Commencez par déterminer quelle partie doit s’authentifier auprès de l’autre à chaque niveau. Examinez ensuite les outils, les autorisations et le consentement de l’utilisateur en tenant compte de cette distinction. Pour passer à la mise en œuvre technique, considérez le dépôt d’exemple d’Autodesk et ses exemples d’authentification APS MCP comme points de départ ; répondez séparément aux exigences de sécurité et de gestion des modèles liés en environnement de production.

Sources et licence

Ce contenu est adapté des guides d’Autodesk Platform Services intitulés « Bringing Revit Cloud Worksharing Migration to AI Assistants with APS and MCP », « Building Custom MCP Servers with Autodesk Platform Services » et « Authentication Patterns for APS MCP Servers ». Dans les enregistrements des sources fournies, le statut de licence est indiqué comme serbest, mais aucun nom de licence libre précis n’est donné ; le contenu n’est donc pas présenté comme publié sous une licence telle que CC BY.