Résumé exécutif
Jusqu'ici, une grande partie de l'IA appliquée à l'ingénierie consistait à poser des questions à des données.
Une étape supplémentaire commence à apparaître :
permettre à un agent IA de déclencher directement des opérations dans un logiciel métier.
Bentley publie désormais un serveur OpenSTAAD MCP pour STAAD.Pro.
Concrètement, un assistant compatible MCP peut utiliser les capacités de l'API OpenSTAAD pour interroger un modèle, extraire des données, définir des cas de charge ou automatiser des modifications répétitives.
L'architecture ressemble alors à ceci :
ingénieur → agent IA → serveur MCP → API OpenSTAAD → STAAD.Pro
Le point important est là :
le modèle de langage ne remplace pas le logiciel d'ingénierie. Il orchestre ses fonctions.
C'est une évolution techniquement substantielle.
Mais elle déplace également le problème de confiance.
Une mauvaise réponse textuelle est gênante.
Une mauvaise action sur un modèle technique peut modifier le travail de l'ingénieur.
Verdict IngéPilot : TESTER — Evidence Score 76/100.
Pourquoi cela compte
Les logiciels d'ingénierie contiennent encore de nombreuses opérations répétitives :
extraction de résultats ;
définition ou modification de propriétés ;
préparation de cas ;
génération de tableaux ;
navigation dans des modèles complexes ;
enchaînement d'actions via API ou scripts.
Ces tâches peuvent déjà être automatisées.
Le problème est qu'elles nécessitent souvent de connaître une API, d'écrire un script ou de construire une automatisation spécifique.
MCP ajoute une couche supplémentaire :
l'ingénieur exprime son intention en langage naturel, puis l'agent choisit et appelle les outils disponibles.
Ce n'est donc pas seulement une nouvelle interface de chat.
C'est potentiellement une nouvelle manière de piloter les fonctions existantes des logiciels techniques.
Ce que Bentley a réellement publié
Le serveur OpenSTAAD MCP est public.
Bentley indique qu'il permet à des agents comme Claude Desktop, Gemini ou GitHub Copilot d'interagir avec STAAD.Pro via l'API OpenSTAAD.
Les cas d'usage explicitement cités comprennent notamment :
définition de cas de charge ;
extraction de données ;
réglage répétitif de propriétés ;
interaction avec plusieurs instances de STAAD.Pro.
Le serveur expose également un outil execute_code capable d'exécuter du code Python validé contre le modèle STAAD.Pro.
Dans cette implémentation, une partie importante de ces actions passe donc par du code Python généré par l'agent puis validé par le serveur avant exécution contre l'API OpenSTAAD.
Autrement dit, nous ne sommes plus uniquement face à une démonstration conceptuelle.
Il existe une couche logicielle publique permettant à un agent de demander l'exécution d'actions sur un outil d'ingénierie réel.
Cela ne signifie pas pour autant que toutes les fonctions de STAAD.Pro deviennent fiables lorsqu'elles sont pilotées par un agent.
Le serveur fournit le mécanisme d'accès.
La qualité du raisonnement, du choix des actions et du contrôle reste un problème distinct.
Le vrai changement : passer de « lire » à « agir »
Dans notre première analyse sur les assistants IA et les données BIM, la question centrale était :
peut-on permettre à une IA d'interroger correctement les données d'un projet ?
Avec MCP, une nouvelle question apparaît :
peut-on lui permettre d'agir sur ces données et sur le logiciel qui les manipule ?
Cette distinction est fondamentale.
Un agent disposant uniquement d'un accès en lecture peut :
rechercher ;
résumer ;
extraire ;
comparer.
Selon les outils et les permissions exposés, un agent peut aussi :
modifier ;
créer ;
lancer ;
automatiser certaines opérations.
Le niveau de risque change donc avec la nature de l'outil exposé.
La question pertinente n'est pas :
« Peut-on connecter l'IA au logiciel ? »
Bentley démontre que oui.
La question pertinente devient :
« Quelles opérations sommes-nous prêts à autoriser, dans quelles conditions et avec quel contrôle ? »
Le serveur peut être local sans que tout le workflow IA le soit
Bentley présente OpenSTAAD MCP comme un serveur fonctionnant localement, sans télémétrie ni envoi cloud côté serveur MCP.
Le dépôt prévoit également plusieurs protections techniques :
authentification par bearer token en mode HTTP ;
protection contre le DNS rebinding ;
restriction des chemins de fichiers autorisés ;
validation du code Python avant son exécution ;
blocage de certains imports, accès fichiers et fonctions dangereuses dans le sandbox.
Ces mesures sont importantes.
Mais elles ne suffisent pas à conclure :
« Les données du projet ne quittent jamais l'ordinateur. »
Le serveur MCP et le modèle de langage sont deux composants différents.
Si l'agent repose sur un service IA distant, la confidentialité de bout en bout dépend aussi :
du client utilisé ;
des données qu'il reçoit ;
de sa configuration ;
du contrat et des politiques du fournisseur ;
des permissions données aux outils.
La bonne unité d'analyse n'est donc pas seulement le serveur MCP.
C'est toute la chaîne : utilisateur → client IA → MCP → logiciel → données.
La vraie baseline n'est pas le travail manuel
Il serait facile de comparer :
ingénieur manuel → agent IA
et de conclure que l'agent est plus rapide.
Ce serait une comparaison insuffisante.
OpenSTAAD existe déjà comme API.
Des scripts Python ou des automatisations déterministes peuvent donc réaliser une partie des mêmes opérations sans laisser un modèle de langage décider à chaque étape.
La comparaison utile devient :
manuel → script/API déterministe → agent MCP
C'est probablement le test le plus important pour juger la valeur industrielle de cette approche.
Un script est rigide, mais prévisible.
Un agent est flexible, mais davantage dépendant du contexte, du modèle, du prompt et de l'interprétation des outils disponibles.
Le bon choix dépend donc du type de tâche.
Pour une opération parfaitement répétitive et stable, le script traditionnel peut rester supérieur.
Pour une opération variable nécessitant davantage de raisonnement ou d'interaction, l'agent peut devenir intéressant.
Le coût caché : la supervision
L'argument commercial naturel des agents est le gain de temps.
Mais l'équation économique doit inclure une autre variable :
combien de temps faut-il consacrer à vérifier ce que l'agent vient de faire ?
Nous n'avons identifié à ce stade aucun benchmark indépendant permettant de mesurer sérieusement :
combien de temps est réellement économisé ;
quel est le taux d'erreur ;
combien d'actions doivent être corrigées ;
quelle est la reproductibilité d'une même demande ;
quelle supervision reste nécessaire ;
dans quels cas un script classique est plus efficace.
C'est pourquoi IngéPilot ne retient aucun pourcentage de productivité pour l'instant.
Le potentiel est réel.
Le ROI ne l'est pas encore.
Jusqu'où faut-il laisser agir l'agent ?
Une manière simple de raisonner consiste à classer les outils exposés selon leur risque.
Faible risque
Lecture + réversible
Exemples :
extraction de résultats ;
génération de tableaux ;
recherche d'informations dans un modèle.
Ce sont les meilleurs candidats pour démarrer.
Risque intermédiaire
Écriture + facilement vérifiable
Exemples :
changement répétitif de propriétés ;
préparation de données ;
création d'éléments clairement identifiables.
Ici, une confirmation humaine avant exécution devient pertinente.
Risque élevé
Écriture critique ou difficilement réversible
Exemples :
modification massive d'un modèle ;
lancement d'un workflow entraînant des conséquences en chaîne ;
écrasement de fichiers ;
opérations pouvant influencer directement une décision technique.
Ici, l'autonomie doit être fortement limitée.
La spécification MCP elle-même insiste sur le consentement utilisateur et le contrôle des appels d'outils.
Ce n'est donc pas une contrainte périphérique.
C'est une caractéristique centrale d'une architecture agentique sérieuse.
Verdict IngéPilot
TESTER — 76/100
Le serveur OpenSTAAD MCP constitue une innovation réelle et accessible.
Le dépôt est public, les capacités sont documentées et l'architecture peut être expérimentée sur un environnement STAAD.Pro existant.
Le passage d'un assistant qui consulte des informations à un agent qui appelle les fonctions d'un logiciel métier est suffisamment important pour être suivi de près.
Mais trois éléments empêchent aujourd'hui une recommandation d'adoption générale :
absence de benchmark indépendant de productivité ;
absence de mesure robuste du taux d'erreur et du besoin de supervision ;
gouvernance de sécurité à considérer sur toute la chaîne IA, et pas uniquement sur le serveur MCP.
Le bon usage actuel n'est donc pas :
« connectons l'agent à nos projets et automatisons tout ».
C'est :
« choisissons une tâche limitée, réversible et mesurable, puis comparons l'agent à nos méthodes actuelles ».
À faire lundi matin
Choisissez une tâche répétitive sur laquelle vous disposez déjà d'une méthode fiable.
Par exemple :
extraire une série de résultats ;
contrôler certaines propriétés ;
générer un tableau ;
modifier une donnée facilement vérifiable.
Travaillez sur une copie du modèle, jamais sur le projet de production.
Puis comparez trois approches :
manuel → script/API → agent MCP
Mesurez :
temps total ;
nombre d'erreurs ;
temps de vérification ;
corrections nécessaires ;
reproductibilité ;
niveau de compétence nécessaire.
Et surtout :
séparez les gains d'exécution du coût de supervision.
Si l'agent réalise la tâche en deux minutes mais qu'il faut quinze minutes pour contrôler son travail, le gain apparent n'est pas un gain industriel.
Ce qu'il faudra démontrer avant d'aller plus loin
Pour passer de TESTER à ADOPTER, il faudra au minimum démontrer sur des cas réels :
un gain de temps end-to-end ;
un taux d'erreur acceptable ;
une supervision maîtrisée ;
des mécanismes de permissions par niveau de risque ;
une journalisation des actions ;
une procédure de rollback ;
une politique claire sur les données envoyées au modèle ;
une comparaison avec l'automatisation conventionnelle.
C'est seulement après cette étape qu'un agent connecté au logiciel peut devenir autre chose qu'une démonstration convaincante.
Il peut devenir un outil de production contrôlé.
Sources
Bentley Systems — OpenSTAAD MCP Server, dépôt officiel GitHub. Le dépôt décrit les fonctions disponibles, les prérequis, l'architecture locale et les protections de sécurité.
Bentley Systems — organisation GitHub officielle, confirmant OpenSTAAD MCP comme projet Bentley.
Model Context Protocol — Specification, principes de consentement, protection des données et sécurité des appels d'outils.
La question IngéPilot :
Si un agent IA pouvait agir demain dans vos logiciels métier, quelle serait la première tâche que vous accepteriez réellement de lui déléguer ?
Vous pouvez répondre directement à cette newsletter.
La rédaction IngéPilot