C’est devenu un rituel. Chaque année, j’assiste avec beaucoup d’intérêt à Autodesk University, un rendez-vous privilégié pour découvrir les innovations, échanger avec d’autres professionnels et prendre le pouls des tendances qui façonnent notre industrie. 

Cette année, j’étais à Las Vegas du 14 au 17 septembre. Quatre journées bien remplies, avec 17 sessions auxquelles j’ai assisté, soit environ 15 heures et demie de présentations et de discussions. 

Cette édition avait aussi une saveur particulière pour moi : j’ai été particulièrement choyé de partager la scène avec Mostafa El Ayoubi, Michael Kilkelly et John Pierson, lors d’un panel animé par Carl Storms. Une discussion stimulante, qui a nourri ma réflexion tout au long de la semaine et m’a amené à porter un regard différent sur plusieurs des innovations présentées. 

Sans surprise, l’intelligence artificielle (IA) occupait une place importante dans les discussions. Ce qui m’a surtout frappé, c’est l’évolution des questions soulevées depuis l’édition précédente. 

L’an dernier, nous nous demandions encore si l’IA pouvait réellement accomplir certaines tâches dans le secteur de l’architecture, de l’ingénierie, de la construction et de l’exploitation (AECO). Cette année, les discussions avaient déjà changé de perspective. Nous sommes passés de « Pouvons-nous le faire ? » à « Qui vérifie les résultats ? », « Qui en assume la responsabilité ? » et « À quelles données et à quels systèmes l’IA peut-elle accéder ? ». 

Cette évolution en dit long sur la vitesse à laquelle les technologies progressent, mais aussi sur les nouvelles responsabilités qui accompagnent leur adoption. 

En reprenant mes notes à mon retour, j’ai réalisé qu’une même question revenait sous différentes formes : avec toutes les possibilités qu’offre désormais l’IA, comment déterminer ce qui mérite réellement d’être développé, et comment s’assurer de le faire correctement ? 

Voici les principaux enseignements que j’ai retenus et ce qu’ils pourraient signifier pour BIM One et les entreprises avec lesquelles nous collaborons. 

L’innovation fait partie de l’ADN de BIM One depuis sa création en 2013. Dans mon rôle en recherche et développement, je suis naturellement amené à m’intéresser aux nouvelles technologies et à réfléchir à la façon dont elles peuvent améliorer nos pratiques. 

Avec l’arrivée d’outils d’IA de plus en plus performants et accessibles, cette réflexion prend une tout autre dimension. Faut-il développer nos propres solutions, adopter celles qui existent déjà ou adapter les outils à nos besoins ? 

C’est justement autour de ces questions que nous avons échangé lors du panel Fonctionnalité, complément (Add-In) ou IA ? Faut-il acheter, développer ou bricoler en 2026 ? 

Carl Storms a publié un excellent compte rendu de notre discussion, que je vous invite à consulter sur The BIM Sider si le sujet vous intéresse. 

Je ne reprendrai donc pas tous nos échanges ici. Mais cette discussion m’a laissé une réflexion qui m’a accompagné tout au long de la semaine : il n’a jamais été aussi facile de développer un outil. La véritable difficulté consiste désormais à déterminer ce qui mérite d’être développé, puis à en assurer la qualité, la sécurité et la pérennité. 

Cette idée a pris tout son sens au fil des autres sessions auxquelles j’ai assisté.

Lors du Platform Leadership Forum, le lundi, une diapositive a particulièrement retenu mon attention. Elle présentait un agent IA à travers trois composantes : 

• Entrées (Inputs) : les instructions, le modèle d’IA, le contexte, la mémoire et les compétences. 

• Portée (Reach) : les connexions avec d’autres systèmes, notamment au moyen de MCP, REST ou GraphQL. 

• Garde-fous (Guardrails) : les mécanismes d’approbation et de contrôle, avec la gestion des identités au cœur du dispositif. 

Sous les deux premières composantes, la diapositive indiquait que la plupart des équipes les développaient déjà. Sous la troisième, le constat était différent : « Plus rares sont celles qui développent ceci ». 

Cette observation m’a particulièrement interpellé. 

Lorsqu’un prototype fonctionne et que les premiers résultats sont encourageants, il est tentant de poursuivre rapidement le développement. Les garde-fous peuvent alors passer au second plan, alors qu’ils sont essentiels pour encadrer les actions de l’IA. 

Ce n’est pas nécessairement par manque de volonté. La pression pour obtenir rapidement des résultats, un cadrage insuffisant ou une sous-estimation des risques peuvent facilement conduire à négliger ces aspects. 

La même session proposait justement six questions fondamentales à se poser avant de concevoir un processus faisant appel à l’IA : 

1. Est-ce réellement un problème qui nécessite l’IA, ou une règle ou une automatisation classique ferait-elle tout aussi bien l’affaire ? 
2. Les données sont-elles accessibles, fiables et soumises aux autorisations appropriées avant d’être transmises au modèle d’IA ? 
3. Quelle approche de développement convient le mieux : un agent prêt à l’emploi, une solution low-code ou du code personnalisé ? 
4. Comment vérifier les résultats avant que l’outil puisse agir sur des données réelles ? 
5. Qui sera responsable de l’outil une fois en production, et comment s’assurer qu’il est répertorié pour éviter de développer plusieurs fois la même solution ? 
6. Sommes-nous prêts à faire évoluer et à améliorer la solution dans le temps ? 

Je trouve ces questions particulièrement pertinentes, car elles permettent de considérer l’ensemble des dimensions d’un projet d’IA, au-delà de sa seule faisabilité technique. 

La première question, à elle seule, pourrait éviter bien des efforts inutiles. L’IA doit répondre à un besoin réel. Si une automatisation classique permet d’obtenir le même résultat, de façon plus économique, plus prévisible et plus facile à maintenir, pourquoi choisir une solution plus complexe ? 

C’est une réflexion importante à garder en tête avant de se lancer dans le développement d’un nouvel outil. 

Les sessions que j’ai trouvées les plus utiles n’étaient pas celles qui promettaient que l’IA pourrait tout faire, mais plutôt celles qui définissaient clairement ce qu’elle pouvait faire et dans quelles conditions. 

Dans Agentic AI for AEC, Autodesk a présenté un processus de mise en place d’un projet structuré en deux couches distinctes : 

• Une couche de planification, qui interprète la demande, vérifie l’état du projet et établit un plan d’action. 

• Une couche d’exécution, qui réalise uniquement les actions autorisées et clairement définies, comme la création d’emplacements, d’actifs ou de problèmes. 

Chaque action prévue dans le plan correspond à une fonction connue. Il n’est donc pas question de laisser l’IA exécuter librement des commandes arbitraires.  

Les sessions Dynamo de John Pierson ont abordé cette même logique sous un angle plus technique. 

Dans Unleashing Dynamo with Autodesk Assistant and MCP, John a présenté Dynamo MCP, un serveur local qui permet à un client IA d’accéder à environ 47 opérations Dynamo, notamment la création de nœuds et l’exécution de graphes. 

Deux phrases de sa présentation m’ont marqué. 

La première : « Le modèle lit la même documentation que vous. Il ne réinvente pas Dynamo à partir de ses données d’entraînement. » 

La seconde concernait le fichier d’instructions du serveur, dont le comportement était encadré par des tests unitaires et « traité comme du code, pas comme des impressions ». 

Cette approche correspond exactement à ce que je souhaite privilégier dans les développements de BIM One faisant appel à l’IA : laisser l’IA contribuer à la planification, tout en s’assurant que les actions qui modifient réellement les modèles soient testables, reproductibles et explicables. 

Le titre d’une autre session résumait d’ailleurs très bien cette idée : Don’t AI Everything: Hybrid Automation with APS and Revit. 

Une autre session de John, Break the Desktop Barrier, portait sur l’exécution de Dynamo dans le nuage. 

Avec Dynamo Switchboard, il devient possible de confier l’exécution d’un graphe aux capacités de calcul d’Autodesk Platform Services (APS). On peut ainsi exécuter Dynamo sans Revit, ou faire fonctionner Revit sans interface utilisateur (headless) pour traiter plusieurs modèles en parallèle et récupérer les fichiers .rvt modifiés. 

Une phrase de sa présentation résumait bien le changement : « Le poste de travail ne doit plus être l’unité de calcul. » 

Pour une entreprise comme BIM One, les applications potentielles sont très concrètes. 

Nous réalisons régulièrement des vérifications de conformité aux exigences BIM et des contrôles qualité sur les maquettes de nos clients. Effectuer ces vérifications une maquette à la fois, sur le poste de travail d’un expert, prend du temps et mobilise des ressources. 

La possibilité d’effectuer ces traitements par lots dans le nuage améliore notre efficacité.

La session sur l’openBIM, le jeudi après-midi, m’a laissé l’une de mes citations préférées de la semaine. 

Pour expliquer les limites d’un export IFC contenant l’ensemble des données d’un modèle, le présentateur a utilisé une comparaison assez parlante : « Personne ne veut d’une liste de lecture contenant toutes les chansons du monde. » 

L’idée est simple : pourquoi transmettre toutes les données d’un modèle lorsque seule une partie est nécessaire ? 

Une approche plus efficace consiste à préparer des exports ciblés selon les besoins : estimation, simulation, livraison, mise en service ou opérations. Ces données peuvent ensuite être fédérées lorsque cela est nécessaire. 

Par exemple, plutôt que de travailler directement avec un fichier IFC volumineux, il est possible de l’importer dans Autodesk Forma, de sélectionner les données pertinentes, de publier un Data Exchange, puis de les charger dans Revit. 

On limite ainsi le volume de données à traiter et on facilite leur exploitation. 

Cette approche rejoint d’autres sujets abordés durant la semaine, notamment la feuille de route de l’API AEC Data Model, les premiers travaux sur la prochaine version d’IFC et une présentation consacrée à la mise en place d’une structuration de données BIM adaptée à l’IA. 

Tous ces éléments pointent dans la même direction : il devient de plus en plus important de privilégier l’accès aux données pertinentes plutôt que l’échange systématique de fichiers complets. 

C’est également un enjeu pour l’IA. La pertinence des résultats d’un agent dépend largement de la qualité et de l’accessibilité des données qu’il utilise. Des données structurées, fiables et bien délimitées sont aussi beaucoup plus faciles à contrôler qu’un modèle volumineux dont personne ne maîtrise entièrement le contenu.

Lors de la dernière journée, la session Don’t Wait, Non-Revit Developers! a montré comment les spécialistes BIM peuvent désormais créer leurs propres compléments Revit avec l’aide de l’IA. 

Le principe présenté était relativement simple : comprendre les quatre composantes essentielles d’un complément Revit — le manifeste, la DLL compilée, le point d’entrée et l’API Revit — puis utiliser l’IA pour faciliter la rédaction du code répétitif. Les exemples présentés reposaient sur du code du domaine public. 

Je trouve cette évolution particulièrement intéressante. 

Les professionnels qui connaissent les besoins du terrain disposent aujourd’hui de moyens beaucoup plus accessibles pour développer leurs propres outils, sans nécessairement posséder une expertise approfondie en programmation. 

Mais cette accessibilité nous ramène directement aux discussions du panel et à la question des garde-fous. 

Lorsque davantage de personnes peuvent développer des outils, il devient essentiel de savoir ce qui existe déjà, de maintenir un niveau de qualité adéquat et de s’assurer que les solutions développées puissent profiter à l’ensemble de l’entreprise plutôt que de rester limitées au poste de travail de leur créateur. 

D’autres présentations ont également soulevé des points importants à cet égard : 

• MCP distant et authentification : une session a montré comment héberger un serveur MCP dans le nuage et permettre à des clients comme Claude ou ChatGPT de s’authentifier au moyen d’un proxy OAuth. Cette approche permet de mettre en place une authentification unique (SSO), tout en conservant la maîtrise des mécanismes d’accès. C’est le type de solution qu’il nous faudrait envisager avant de partager un serveur MCP de BIM One avec nos clients. 

• L’évolution du modèle de facturation d’APS : de nouveaux plafonds d’utilisation permettent de définir une limite par application et de recevoir des alertes. La facturation directe (pass-through billing) est prévue pour les partenaires en 2026, puis pour les clients en 2027. Pour les entreprises qui développent des applications sur APS, dont BIM One, il devient important de bien comprendre la répartition des coûts. 

• La vision d’Autodesk : dans Every Project Builds the Next, Autodesk a présenté une répartition intéressante des rôles. D’un côté, Autodesk apporte sa connaissance de l’industrie et ses modèles de données. De l’autre, les fournisseurs de modèles d’IA apportent les grands modèles de langage (LLM). C’est à la rencontre de ces deux univers, au niveau des outils, des moteurs et de l’expérience utilisateur, que se dessinent de nouvelles possibilités pour des entreprises comme la nôtre. 

Toutes ces présentations m’ont donné plusieurs idées pour notre prochain cycle de recherche et développement. 

Voici les pistes que je souhaite explorer en priorité : 

1. Mettre à l’essai Dynamo MCP avec Autodesk Assistant : utiliser un graphe associé à un projet réel et mesurer les gains de temps. 
2. Automatiser les contrôles qualité dans le nuage : évaluer Dynamo Switchboard pour effectuer simultanément des vérifications de conformité aux normes sur plusieurs maquettes de clients. 
3. Mieux cibler les livrables : explorer la possibilité de proposer des exports IFC et des Data Exchanges adaptés aux besoins, plutôt que de transmettre systématiquement un modèle complet. 
4. Intégrer les garde-fous dès le départ : prévoir, pour chaque agent développé, des mécanismes d’approbation, une gestion des identités et un responsable clairement désigné. 
5. Suivre l’évolution de la facturation APS : comprendre l’incidence des plafonds d’utilisation et de la facturation directe sur nos compléments et nos applications destinées aux clients. 

Bien entendu, nous n’entreprenons pas tout en même temps. L’idée sera de sélectionner une ou deux pistes, de les mettre à l’essai sur des projets réels, puis de partager les enseignements tirés de ces travaux.