L’automatisation de la conception en AEC : le guide complet des workflows fondés sur les données

Dans la plupart des agences d’architecture et des bureaux d’études, une part considérable du temps facturé ne sert pas à concevoir. Elle sert à renommer des vues, à corriger des nomenclatures, à recompter des surfaces après une modification de trame, à réexporter des fichiers d’échange, à vérifier que les paramètres attendus par le client sont bien renseignés, à reprendre un métré parce qu’un mur a changé de type. Ces opérations ne sont ni intellectuellement stimulantes ni particulièrement risquées prises isolément. Leur accumulation, en revanche, absorbe une énergie qui manque ensuite aux arbitrages réellement décisifs.

Cette réalité explique l’intérêt croissant pour l’automatisation de la conception AEC. Le sujet est cependant régulièrement mal posé. Il est présenté comme une question d’outils, alors qu’il s’agit d’abord d’une question de données, de règles et de responsabilités. On imagine des systèmes capables de produire un projet à partir d’une phrase, alors que les gains les plus solides proviennent aujourd’hui de tâches déterministes correctement industrialisées. On installe des scripts sans propriétaire, sans documentation et sans test, puis on s’étonne qu’ils deviennent une source d’erreurs silencieuses.

Ce guide propose une lecture complète et exigeante du sujet. Il décrit ce qui peut être automatisé, avec quelles données, sous quelles conditions de contrôle, et selon quelle séquence de déploiement. Il examine les approches disponibles — automatisation déterministe, conception paramétrique, design génératif, optimisation multicritère, intelligence artificielle générative, agents supervisés — en distinguant clairement ce qui est prévisible de ce qui est probabiliste. Il aborde enfin les dimensions que l’on oublie souvent : la gouvernance, la sécurité des données, la traçabilité, la mesure du retour sur investissement et la maturité organisationnelle.

Ce que recouvre exactement l’automatisation de la conception AEC

Le sigle AEC désigne l’architecture, l’ingénierie et la construction — en anglais Architecture, Engineering and Construction. Il rassemble sous un même terme des métiers dont les logiques diffèrent profondément : la conception architecturale, l’ingénierie structurelle, les études de fluides et d’énergie, l’économie de la construction, la planification, l’exécution sur site et, de plus en plus, l’exploitation de l’ouvrage après livraison. Parler d’automatisation dans ce contexte impose donc de préciser à quel maillon de cette chaîne on s’adresse, car les données disponibles, les contraintes réglementaires et la tolérance à l’erreur ne sont pas les mêmes d’un maillon à l’autre.

Il faut ensuite distinguer plusieurs notions que le vocabulaire courant confond. La numérisation consiste à disposer d’une représentation informatique d’une information qui existait auparavant sous une autre forme : un plan scanné, un relevé par nuage de points, un tableau de surfaces saisi dans un tableur. L’information est là, mais elle n’est pas nécessairement structurée. La modélisation BIM — pour Building Information Modelling, modélisation des informations de la construction — va plus loin : elle produit des objets porteurs de sémantique. Un mur n’est plus un ensemble de segments, c’est un objet qui connaît son type, sa composition, sa hauteur, son étage de rattachement, sa fonction porteuse ou non. La standardisation ajoute une couche de convention partagée : les noms, les classifications, les unités, les jeux de propriétés et les règles de nommage sont définis à l’avance et respectés par tous.

Pourquoi une belle maquette peut être inexploitable

Un test simple permet d’évaluer en quelques minutes si un modèle est prêt pour l’automatisation. Choisissez une information que vous utilisez régulièrement — la résistance au feu d’une paroi, le type de finition d’un local, la référence d’un équipement — et demandez où elle se trouve. Si la réponse est un nom de propriété exact, dans un jeu identifié, avec un type de donnée constant et une liste de valeurs admissibles, le modèle est exploitable. Si la réponse commence par « ça dépend qui a modélisé », il ne l’est pas.

Ce test ne mesure ni la qualité architecturale, ni la finesse géométrique, ni la compétence des équipes. Il mesure une seule chose : la stabilité des conventions. C’est pourtant la variable qui détermine si un traitement automatisé produira un résultat exact ou un résultat vraisemblable.

L’automatisation proprement dite désigne l’exécution d’une tâche par une machine selon des instructions explicites, sans intervention manuelle à chaque itération. La conception computationnelle est un cas particulier plus ambitieux : la géométrie et les dispositions ne sont plus dessinées directement mais décrites par une logique — des variables, des relations, des contraintes — que la machine évalue pour produire une forme. L’intelligence artificielle, enfin, recouvre des méthodes statistiques qui apprennent des régularités à partir de données plutôt que de suivre des règles écrites à la main. Cette dernière catégorie introduit une différence de nature, et non de degré : son comportement est probabiliste, ses résultats varient, et sa justesse ne peut jamais être garantie par construction.

Cette distinction éclaire une confusion coûteuse. Beaucoup d’organisations pensent qu’avoir adopté le BIM signifie être prêtes à automatiser. Ce n’est pas le cas. Une maquette BIM peut être remarquablement modélisée sur le plan géométrique tout en étant inexploitable par un programme, parce que les types d’objets ne suivent aucune convention stable, parce que les propriétés utiles sont saisies dans des champs libres orthographiés différemment selon les collaborateurs, parce que les unités varient entre les fichiers, ou parce que les objets ne sont rattachés à aucune classification cohérente. Un script n’interprète pas l’intention, il lit des valeurs. Si les valeurs sont hétérogènes, il produira soit une erreur visible, ce qui est le cas favorable, soit un résultat plausible mais faux, ce qui est infiniment plus dangereux.

L’automatisation de la conception AEC commence donc rarement par du code. Elle commence par une décision organisationnelle : accepter que la manière de nommer, de classer et de renseigner les objets ne relève plus du confort individuel mais d’une infrastructure partagée.

Comment se construit un workflow automatisé réellement fiable

Un workflow automatisé n’est pas une commande unique qui transforme une entrée en sortie. C’est une chaîne d’étapes dont chacune remplit une fonction précise, et dont l’absence crée un risque identifiable. Comprendre cette architecture est la condition pour concevoir des automatisations qui survivent au-delà de leur auteur.

Tout commence par les données d’entrée. Il faut savoir exactement quels fichiers, quels modèles, quelles bases externes et quels référentiels alimentent le traitement. Cela suppose de répondre à des questions banales mais décisives : d’où vient ce fichier, qui en est responsable, à quelle fréquence est-il mis à jour, que se passe-t-il si une source est indisponible. Un traitement qui lit un fichier déposé « quelque part sur le serveur » sans convention de localisation est déjà fragile.

Vient immédiatement la question des versions. Une automatisation exécutée sur une révision périmée d’un modèle produit un résultat parfaitement cohérent et totalement inutile. Le workflow doit donc enregistrer l’identifiant de version de chaque source consommée, et idéalement refuser de s’exécuter si cet identifiant ne correspond pas à un état validé. C’est précisément la fonction d’un environnement commun de données organisé par états — travail en cours, partagé, publié, archivé — et non par simples dossiers.

Les règles constituent le cœur métier. Ce sont les exigences explicites que le traitement applique : un local de type bureau doit disposer d’une surface minimale, un mur coupe-feu doit porter une propriété de résistance renseignée, une nomenclature ne doit contenir aucun élément non classifié, un dégagement d’accès doit être maintenu autour d’un équipement technique. La formalisation de ces règles est le travail le plus difficile et le plus rentable de tout projet d’automatisation, parce qu’elle oblige à transformer des savoirs implicites en énoncés testables. Une règle qui ne peut pas être écrite sous forme vérifiable n’est pas une règle : c’est un jugement, et il doit rester humain.

L’exécution est l’étape la plus visible et la moins problématique. Elle peut prendre la forme d’un script exécuté à la demande, d’un traitement déclenché par le dépôt d’un fichier, ou d’un service planifié. Ce qui compte davantage, c’est qu’elle soit reproductible : la même entrée, avec la même version de code et le même paramétrage, doit produire la même sortie.

L’analyse interprète le résultat brut. Une extraction de quantités devient un métré structuré, une liste de non-conformités devient un rapport hiérarchisé par criticité, une série de variantes devient un ensemble d’indicateurs comparables. Sans cette étape, l’automatisation produit du volume et non de l’information.

Les tests techniques sont l’étape systématiquement sacrifiée, et systématiquement regrettée. Il s’agit de vérifier que le traitement fonctionne encore correctement : sur un jeu de données de référence dont on connaît le résultat attendu, sur des cas limites — un modèle vide, un objet sans propriété, une unité inhabituelle — et après chaque mise à jour du logiciel hôte. Sans jeu de test, une modification mineure d’une API peut altérer silencieusement les résultats pendant des semaines.

La validation humaine intervient ensuite. Elle ne consiste pas à relire chaque ligne produite, ce qui annulerait le bénéfice de l’automatisation. Elle consiste à examiner les exceptions, les écarts par rapport aux ordres de grandeur attendus, et les décisions à conséquence contractuelle ou réglementaire. Le validateur doit être nommément identifié et compétent sur le sujet traité.

La publication rend le résultat officiel : il devient une donnée sur laquelle d’autres s’appuient. Cette bascule doit être explicite et datée. Enfin, le journal d’audit conserve la trace de ce qui a été exécuté, par qui, sur quelles versions, avec quels paramètres et quel résultat. C’est ce journal qui permet, six mois plus tard, de comprendre l’origine d’un écart plutôt que de reconstruire péniblement une histoire perdue.

Chaque étape absente crée une vulnérabilité précise. Sans gestion de versions, on produit des résultats justes sur des données fausses. Sans règles écrites, chaque exécution encode les hypothèses non dites de son auteur. Sans tests, la dégradation est invisible. Sans validation, l’organisation transfère à un programme une responsabilité qu’aucun programme ne peut porter. Sans journal, l’erreur devient impossible à circonscrire et contamine la confiance dans l’ensemble du dispositif.

Automatisation, paramétrique, génératif, IA : quelles différences réelles

Les six approches présentées ici sont régulièrement employées comme synonymes dans la communication commerciale. Elles diffèrent pourtant sur trois axes déterminants : la prévisibilité du résultat, la nature des données d’entrée nécessaires et le niveau de contrôle exigé avant utilisation.

L’automatisation déterministe

C’est l’approche la plus modeste en apparence et la plus productive en pratique. Un traitement déterministe applique une suite d’instructions fixes : pour chaque objet répondant à un critère, effectuer telle action. Renommer des vues selon une convention, appliquer une classification à partir d’une table de correspondance, générer des feuilles à partir d’une liste, exporter des fichiers d’échange avec un paramétrage constant, vérifier la présence de propriétés obligatoires. Les entrées sont explicites, la sortie est reproductible à l’identique, et l’erreur, lorsqu’elle survient, provient soit d’une donnée non conforme, soit d’une règle mal écrite — dans les deux cas, d’une cause localisable. Son niveau de risque est faible tant que le périmètre reste borné et que les cas non prévus provoquent un arrêt explicite plutôt qu’un traitement approximatif.

La conception paramétrique

Ici, la géométrie n’est plus dessinée mais décrite. Un panneau de façade est défini par sa position sur une surface support, une trame, un angle d’inclinaison lié à une orientation solaire, et une épaisseur dépendant d’une portée. Modifier la surface support régénère l’ensemble. L’intérêt est double : la variation devient bon marché, et les intentions de conception sont encodées explicitement, donc discutables. La limite tient à la fragilité des modèles paramétriques mal structurés, où une modification amont provoque des ruptures en cascade difficiles à diagnostiquer. Le résultat reste entièrement déterministe — les mêmes paramètres produisent toujours la même forme — mais la complexité du graphe de dépendances peut rendre ce déterminisme peu lisible. Les environnements de programmation visuelle comme Grasshopper pour Rhino ou Dynamo pour Revit relèvent typiquement de cette catégorie.

Le design génératif

Le design génératif ajoute à la conception paramétrique un mécanisme d’exploration. Au lieu d’évaluer une combinaison de paramètres choisie par le concepteur, le système parcourt automatiquement un espace de combinaisons, évalue chaque variante selon des critères mesurables, et restitue un ensemble de solutions. Les données d’entrée sont donc plus riches : il ne suffit pas de définir la géométrie, il faut définir les variables libres, leurs plages de valeurs, les contraintes à respecter et les objectifs à évaluer. Le résultat n’est pas une réponse mais une population de réponses. Le risque principal n’est pas technique : il est méthodologique. Un espace de solutions mal formulé produit avec une grande rigueur des variantes qui ne répondent pas à la vraie question.

L’optimisation multicritère

L’optimisation multicritère est le moteur mathématique qui rend le design génératif exploitable. Elle traite le cas, universel en AEC, où plusieurs objectifs s’opposent : maximiser l’apport de lumière naturelle tend à dégrader la performance thermique, réduire le coût tend à contraindre la qualité constructive, augmenter la surface utile tend à réduire les espaces communs. L’optimisation ne supprime pas ces oppositions, elle les rend explicites en identifiant les solutions pour lesquelles aucun critère ne peut être amélioré sans en dégrader un autre. Sa prévisibilité est bonne au sens où l’algorithme est reproductible, mais les méthodes évolutionnaires courantes comportent une part d’aléa : deux exécutions peuvent converger vers des ensembles légèrement différents. Ce point doit être documenté, notamment si les résultats servent d’appui à une décision contractuelle.

L’intelligence artificielle générative

Les modèles génératifs — de langage, d’image, ou multimodaux — fonctionnent par estimation statistique de ce qui est plausible compte tenu de ce qu’ils ont appris. Cette caractéristique définit à la fois leur puissance et leur périmètre légitime. Ils sont remarquables pour produire un premier jet de note technique, reformuler une exigence, rédiger la documentation d’un script, expliquer un message d’erreur, ou proposer des directions formelles en phase amont. Ils sont structurellement inadaptés à la production d’une valeur qui doit être exacte : une quantité, une descente de charge, une référence normative, une cote. Un modèle génératif ne calcule pas, il compose ce qui ressemble à un calcul. Cette nuance est la plus importante de tout l’article. Son niveau de risque est élevé dès que la sortie alimente directement un livrable, et il devient acceptable dès lors que la sortie est traitée comme une proposition soumise à vérification.

La question à poser avant d’employer un outil génératif

Une règle de discernement suffit à couvrir la majorité des situations : la sortie attendue doit-elle être exacte, ou doit-elle être pertinente ?

Une sortie qui doit être exacte a une valeur vraie, indépendante de l’appréciation du lecteur : une quantité, une cote, une référence normative, un résultat de calcul, un identifiant. Un modèle génératif n’est pas l’outil adapté, non parce qu’il se trompe souvent, mais parce qu’on ne peut pas distinguer ses réussites de ses erreurs sans refaire le travail.

Une sortie qui doit être pertinente s’évalue par un jugement professionnel : une reformulation, une synthèse, une hypothèse à explorer, une explication, une première rédaction. Le lecteur compétent voit immédiatement si la proposition tient. C’est le domaine légitime de ces outils, et il est plus vaste qu’on ne le croit.

Les agents logiciels supervisés

Un agent est un système qui enchaîne plusieurs actions pour atteindre un objectif, en choisissant lui-même la séquence : lire un modèle, appeler un outil de vérification, interpréter le rapport, préparer une correction, soumettre le résultat. Sa valeur tient à l’orchestration de tâches hétérogènes. Sa difficulté tient au cumul d’incertitudes : si chaque étape comporte une probabilité d’erreur, l’enchaînement d’une dizaine d’étapes sans point de contrôle rend l’échec probable. Une supervision sérieuse implique donc de borner strictement les actions autorisées, d’imposer des points de validation intermédiaires, de conserver un journal complet des actions et de garantir la réversibilité. Un agent qui peut écrire dans un modèle publié sans validation n’est pas une automatisation avancée : c’est un risque non maîtrisé.

Ces approches ne se remplacent pas, elles se superposent. Une organisation mûre utilise le déterministe pour la production courante, le paramétrique pour les systèmes répétitifs, le génératif pour l’exploration amont, l’optimisation pour arbitrer, et les modèles génératifs pour la médiation textuelle et documentaire — chacun à sa place, avec le contrôle correspondant.

Les fondations informationnelles : pourquoi tout dépend de la qualité des données

Aucune automatisation ne compense une donnée mauvaise. Elle l’amplifie, la propage plus vite, et la rend plus difficile à détecter parce que le résultat porte l’apparence d’un traitement rigoureux. Les fondations informationnelles ne sont donc pas un préalable administratif : elles constituent l’essentiel du travail.

La première exigence porte sur les identifiants. Chaque objet doit posséder un identifiant stable, qui ne change pas lorsque l’objet est déplacé, modifié ou exporté. Sans cette stabilité, il devient impossible de comparer deux versions d’un modèle, de rattacher un constat de chantier à l’élément concerné, ou de suivre un équipement de la conception jusqu’à l’exploitation. Le format IFC prévoit à cet effet un identifiant global unique attaché à chaque instance, mais sa préservation dépend des pratiques d’export et des outils employés : il s’agit d’une exigence à vérifier, pas d’un acquis.

Viennent ensuite les classifications. Un objet doit pouvoir être rangé dans une catégorie partagée, indépendante du logiciel de production. Les systèmes de classification nationaux et internationaux — chacun avec sa logique propre, par ouvrage, par élément fonctionnel ou par produit — remplissent ce rôle. Une automatisation de métré ou de bilan carbone est directement tributaire de la couverture de cette classification : tout objet non classé devient un angle mort.

Les propriétés posent un problème d’une autre nature. Il ne suffit pas qu’une information existe, il faut qu’elle réside dans un emplacement prévisible, avec un nom exact, un type de donnée cohérent et une unité déclarée. Une valeur de résistance au feu saisie tantôt comme REI 60, tantôt comme 60 min, tantôt comme le nombre 60 dans un champ texte libre est inexploitable automatiquement, alors même qu’elle est parfaitement compréhensible par un humain. La normalisation des jeux de propriétés est le travail préparatoire le plus rentable qui soit.

Les unités méritent une vigilance particulière dans les projets internationaux, où coexistent millimètres, mètres, pieds et pouces, et où les conversions implicites produisent des erreurs d’ordre de grandeur difficiles à repérer visuellement. Un traitement automatisé doit lire l’unité déclarée dans le fichier plutôt que la supposer.

L’ensemble de ce dispositif prend sens dans un environnement commun de données, souvent désigné par le sigle anglais CDE pour Common Data Environment. Il ne s’agit pas d’un espace de stockage mais d’un système qui organise l’information par états successifs, gère les révisions, trace les transmissions et définit qui peut faire quoi à quel moment. C’est la condition pour qu’une automatisation sache sur quelle version elle travaille.

La série ISO 19650 comme cadre de référence

La série ISO 19650 constitue le cadre international de gestion de l’information dans les projets de construction. Elle est publiée en plusieurs parties complémentaires : la partie 1 traite des concepts et principes et a été publiée en décembre 2018 ; la partie 2 couvre la phase de réalisation des actifs, également publiée en 2018 ; la partie 3 porte sur la phase d’exploitation et date de 2020 ; la partie 4 traite de l’échange d’informations et a été publiée en 2022 ; la partie 5 aborde la gestion de l’information adaptée aux enjeux de sécurité, publiée en 2020 ; enfin, la partie 6, consacrée aux informations de santé et de sécurité, a été publiée en 2025.

Un point d’actualité doit être signalé avec précaution. Les premières parties de la série font l’objet d’une révision : la fiche officielle de la partie 1 indique un statut de norme à réviser, et un projet de norme internationale est en cours d’élaboration, avec une évolution de titre écartant la mention explicite du BIM au profit de la seule gestion de l’information. Tant que ces travaux ne sont pas publiés, ils n’ont aucune valeur normative et ne doivent pas être présentés comme des exigences applicables. Les organisations avisées suivent ces évolutions sans anticiper leur contenu.

L’apport concret de la série pour l’automatisation tient à trois notions. Les exigences d’information doivent être exprimées explicitement par le demandeur, ce qui rend possible leur vérification automatique. Les livrables d’information sont associés à des états et à des jalons, ce qui donne à un programme un point d’ancrage temporel fiable. Enfin, les responsabilités sont attribuées nommément, ce qui évite qu’une automatisation devienne un acteur sans propriétaire.

Les standards ouverts : IFC, IDS, BCF et bSDD

L’IFC — Industry Foundation Classes — est le format d’échange ouvert du secteur. Il décrit les objets de construction, leurs relations et leurs propriétés indépendamment de tout logiciel. La version actuelle de référence est l’IFC 4.3, dont la documentation officielle est publiée sous la désignation IFC 4.3.2.0, correspondant à IFC4X3_ADD2. Cette version a été normalisée sous la référence ISO 16739-1:2024, publiée en mars 2024 en deuxième édition, et remplaçant l’édition de 2018. Son apport majeur est l’extension du schéma aux ouvrages d’infrastructure — routes, ouvrages d’art, voies ferrées, ports — auparavant mal couverts. La documentation de buildingSMART précise que le contenu publié correspond à celui transmis à l’ISO, des exemples et clarifications complémentaires étant diffusés séparément.

L’IDS — Information Delivery Specification — est le complément décisif pour l’automatisation. Il s’agit d’un format lisible par une machine permettant d’exprimer, de manière non ambiguë, ce qu’un modèle doit contenir : quels objets, avec quelles propriétés, dans quels jeux, avec quelles valeurs admissibles. La version 1.0.0 a été publiée comme standard final de buildingSMART le 3 juin 2024, après approbation du comité des standards. Son intérêt est de déplacer l’exigence d’un document textuel interprétable vers un fichier exécutable : la même spécification sert à la fois de contrat et de test.

L’exigence qui se teste elle-même

Le déplacement introduit par l’IDS mérite d’être mesuré. Dans la pratique traditionnelle, une exigence d’information est rédigée par le maître d’ouvrage dans un cahier des charges, interprétée différemment par chaque intervenant, vérifiée en réception par un contrôleur qui a reconstitué sa propre lecture du texte, puis contestée lorsque les interprétations divergent. Le débat porte alors moins sur le modèle que sur le sens des mots.

Lorsque la même exigence est écrite dans un format exécutable, ce débat disparaît en amont : le producteur teste son modèle avec exactement le fichier qui servira à le contrôler. Il ne peut plus y avoir d’écart d’interprétation, seulement un écart de conformité — qui est un fait, non une opinion. Ce que l’IDS automatise n’est donc pas seulement une vérification : c’est la fin d’une catégorie entière de litiges.

Le BCF — BIM Collaboration Format — normalise la communication autour des problèmes détectés dans un modèle. Il transporte la description d’un constat, le point de vue de caméra correspondant et les identifiants des éléments concernés, sous forme de fichier échangeable ou via une interface web de type REST. Pour l’automatisation, c’est le maillon qui permet à un contrôle automatique de produire non pas un rapport isolé, mais des constats directement ouvrables dans l’outil de chaque intervenant.

Le bSDD — buildingSMART Data Dictionary — est un service de dictionnaires de données en ligne. Il héberge des classifications, des propriétés et des définitions publiées par des organisations, accessibles par interface programmatique. Il répond à un problème pratique : plutôt que de maintenir localement des tables de correspondance qui divergent, une organisation peut s’appuyer sur des référentiels partagés et identifiés de manière stable.

L’ensemble forme une chaîne cohérente. Le bSDD définit le vocabulaire, l’IDS exprime l’exigence, l’IFC porte la donnée, le BCF véhicule l’écart constaté. C’est cette cohérence, et non la performance d’un outil particulier, qui rend l’automatisation transposable d’un projet à l’autre.

Automatiser pendant les études de conception : usages, données et limites

En phase amont, l’automatisation ne remplace pas la décision architecturale. Elle élargit le champ des options examinées avant que la décision ne soit prise, et elle réduit le coût de la vérification.

La programmation architecturale se prête bien au traitement automatisé, car elle repose sur des données tabulaires structurées : une liste de fonctions, des surfaces cibles, des effectifs, des adjacences souhaitées, des contraintes d’accès et de sécurité. Un traitement peut vérifier en continu l’écart entre le programme demandé et le programme effectivement modélisé, signaler les fonctions manquantes, les surfaces hors tolérance et les ratios de circulation. Les données nécessaires sont le tableau de programme et une modélisation d’espaces correctement typés. La décision qui doit rester humaine est l’arbitrage sur les écarts : un dépassement de surface peut être une erreur ou un choix assumé, et seule l’équipe de conception peut trancher.

Les études de faisabilité et d’implantation mobilisent des données de site : emprise, servitudes, règles d’urbanisme, topographie, orientation, contraintes de voisinage. Un traitement peut générer des enveloppes constructibles, tester des positions de bâtiment et calculer des indicateurs comparables. La limite est directement liée à la fidélité de la modélisation réglementaire : une règle d’urbanisme mal transcrite produit des enveloppes convaincantes et fausses. La transcription doit donc être vérifiée par un professionnel compétent, et son millésime documenté.

Les surfaces et les circulations constituent le cas d’usage le plus rentable, parce qu’elles sont recalculées à chaque itération de projet et que leur reprise manuelle est fastidieuse. Une automatisation peut recalculer surfaces utiles, surfaces de plancher, ratios d’efficacité, longueurs de parcours d’évacuation et largeurs de dégagement à chaque révision. Le point de vigilance est la définition exacte des méthodes de mesure retenues, qui varient selon les référentiels nationaux et contractuels : la même géométrie peut légitimement produire plusieurs valeurs de surface.

Les études d’ensoleillement et de lumière naturelle demandent une géométrie simplifiée, des données climatiques localisées, des propriétés de transmission lumineuse et un calendrier d’analyse. Elles produisent des indicateurs comparables entre variantes. Leur usage automatisé est solide pour comparer des options entre elles ; il devient délicat lorsque les valeurs absolues sont utilisées pour démontrer une conformité réglementaire, car la méthode de calcul imposée diffère souvent de celle des outils d’étude rapide.

Les façades sont le domaine d’élection de la conception paramétrique. Un système de façade peut être décrit par une trame, des règles de modulation, des contraintes de fabrication — dimensions maximales de panneau, rayon de courbure admissible, tolérances de pose — et des objectifs de performance. Le traitement génère alors non seulement la géométrie mais aussi les listes de composants, ce qui prépare la fabrication. La condition de fiabilité est l’intégration précoce des contraintes industrielles : un modèle paramétrique séduisant mais irréalisable est un coût, pas un gain.

Les systèmes structurels peuvent être prédimensionnés automatiquement à partir de portées, de charges d’exploitation et d’hypothèses de matériaux, ce qui permet de comparer rapidement plusieurs trames. Il faut cependant énoncer clairement le statut du résultat : un prédimensionnement automatisé oriente la conception, il ne remplace ni la note de calcul ni l’engagement de l’ingénieur. La distinction doit apparaître dans les livrables eux-mêmes, faute de quoi un indicateur exploratoire finit par circuler comme une donnée validée.

Les études d’énergie et de confort suivent la même logique. Elles demandent une enveloppe cohérente, des zones thermiques, des scénarios d’occupation, des systèmes et des données climatiques. Automatisées, elles permettent de balayer des combinaisons d’isolation, de vitrage, de protection solaire et de systèmes. Leur limite tient aux hypothèses d’usage : un scénario d’occupation standardisé produit des résultats comparables entre variantes mais s’éloigne du comportement réel des occupants. Un bâtiment optimisé sur une hypothèse d’usage erronée est optimisé pour un bâtiment qui n’existera pas.

Dans tous ces cas, le partage des rôles est le même. L’automatisation produit des indicateurs, révèle des écarts et élargit le champ des options. L’équipe humaine choisit les critères, juge de leur pertinence dans le contexte du projet, et assume l’arbitrage entre valeurs qui ne sont pas commensurables : la qualité d’usage, l’expression architecturale, l’insertion urbaine et la valeur d’usage à long terme ne se réduisent pas à des scores.

Production BIM et documentation : l’automatisation la plus rentable

La production documentaire est, dans la plupart des structures, le premier gisement d’automatisation. Elle est répétitive, normée, volumineuse, et son exécution manuelle mobilise des professionnels qualifiés sur des tâches sans valeur de conception.

La génération de vues et de feuilles peut être pilotée par une table de définition : pour chaque niveau, chaque zone et chaque discipline, créer les vues nécessaires avec le gabarit approprié, la plage de vue correcte et la convention de nommage attendue, puis les placer sur des feuilles selon un plan de composition. Ce traitement supprime une source d’erreur classique — la vue oubliée ou dupliquée — et rend la structure documentaire prévisible.

Les nomenclatures obéissent à la même logique. Plutôt que de créer manuellement des tableaux dont la définition dérive au fil du projet, une automatisation les régénère à partir d’une spécification centrale. Le bénéfice est moins le temps gagné à la création que la garantie que tous les tableaux du projet appliquent les mêmes filtres et les mêmes champs.

Les repères et étiquettes relèvent d’un traitement de placement : identifier les éléments à repérer, appliquer une numérotation cohérente avec la convention du projet, positionner les annotations en évitant les recouvrements. La numérotation automatique doit être conçue avec prudence, car les repères d’un projet ont souvent une valeur contractuelle et ne doivent pas changer arbitrairement d’une révision à l’autre. Une règle de renumérotation non maîtrisée peut invalider des documents déjà diffusés.

L’attribution des paramètres et des classifications consiste à écrire dans le modèle des valeurs déduites de règles ou de tables externes. C’est une opération à haut rendement, mais aussi à haut risque, car elle modifie le modèle. Elle exige donc systématiquement une exécution sur copie, un rapport détaillé de ce qui a été modifié, et une possibilité de retour arrière.

Les exports et contrôles documentaires ferment la chaîne : produire les fichiers d’échange avec un paramétrage constant, vérifier la présence des propriétés attendues avant diffusion, générer les bordereaux de transmission, contrôler la cohérence entre le contenu réel et l’index annoncé.

Ce qui rend un script BIM maintenable

Un script utilisé par une seule personne pendant un mois n’a pas besoin d’ingénierie. Un script utilisé par trente personnes pendant cinq ans est un logiciel, et doit être traité comme tel. Cinq conditions distinguent les deux situations.

La première est l’existence d’un propriétaire nommé, responsable de l’évolution et de la correction. Un script orphelin devient un passif. La deuxième est la séparation entre logique et configuration : les conventions de nommage, les listes de valeurs, les correspondances doivent résider dans des fichiers de paramétrage éditables, non dans le code. Sans cela, chaque nouveau projet impose une modification du code, et les variantes se multiplient jusqu’à devenir ingérables. La troisième est le versionnement : le code doit être conservé dans un système de gestion de versions, avec un historique des modifications et une version identifiable inscrite dans chaque rapport produit. La quatrième est le jeu de test de référence : un modèle d’essai dont on connaît le résultat attendu, exécuté après chaque modification et après chaque mise à jour du logiciel hôte. La cinquième est la documentation d’usage, courte mais réelle : ce que fait le traitement, ce qu’il ne fait pas, ce qu’il exige en entrée, comment interpréter son rapport et qui contacter en cas d’anomalie.

Ces conditions paraissent lourdes rapportées à un script de quelques dizaines de lignes. Elles sont pourtant ce qui sépare une automatisation qui produit de la valeur pendant des années d’une automatisation abandonnée après le départ de son auteur.

Coordination et contrôle qualité openBIM : détecter n’est pas décider

Le contrôle qualité est le domaine où l’automatisation apporte le bénéfice le plus immédiat, parce que la vérification exhaustive d’un modèle fédéré dépasse largement les capacités d’une relecture humaine.

Le contrôle des propriétés vérifie que chaque objet porte les informations attendues, dans les jeux prévus, avec des valeurs appartenant à la liste des valeurs admissibles. C’est exactement l’objet de l’IDS : la spécification décrit les objets concernés par une exigence et les caractéristiques qu’ils doivent présenter, et un moteur de vérification produit un rapport de conformité. Des implémentations libres existent, notamment dans l’écosystème IfcOpenShell avec le module IfcTester, et de nombreux outils commerciaux ont adopté le format. buildingSMART propose par ailleurs un service de validation IFC permettant de contrôler la conformité d’un fichier au schéma.

Le contrôle des classifications vérifie que tout objet appartenant au périmètre est bien rattaché à une catégorie du référentiel retenu. Les objets non classés doivent être signalés explicitement, car ils échapperont ensuite à tous les traitements en aval — métrés, coûts, bilans environnementaux.

Le contrôle des unités compare les unités déclarées dans le fichier aux unités attendues par le projet, et le contrôle des doublons identifie les objets géométriquement superposés ou porteurs d’identifiants dupliqués, situation fréquente après des opérations de copie ou de fusion de modèles.

La détection de collisions et la vérification des dégagements relèvent d’une logique géométrique. La première identifie les intersections entre volumes de disciplines différentes. La seconde, souvent plus utile, vérifie qu’un espace libre est maintenu là où il est nécessaire : accès de maintenance devant un équipement technique, hauteur libre sous réseaux, rayon de débattement d’une porte, espace de manœuvre en zone technique.

C’est ici que se joue la distinction la plus importante de cette section. Un moteur de contrôle détecte un écart ; il ne décide pas de sa signification. Une intersection entre une gaine et une poutre peut être une erreur de coordination grave, une réservation légitime non encore modélisée, un défaut de modélisation sans conséquence, ou un cas parfaitement acceptable compte tenu de dispositions constructives connues de l’ingénieur. Un rapport brut de plusieurs milliers de collisions n’est pas un résultat : c’est une matière première. Le travail de valeur consiste à filtrer selon des règles de tolérance explicites, à regrouper les occurrences relevant d’une même cause, à hiérarchiser selon la criticité et le coût de correction, puis à attribuer chaque constat retenu à un responsable identifié. Le rattachement des constats aux objets concernés, via les identifiants transportés par le BCF, est ce qui rend ce travail traçable plutôt que déclaratif.

Design génératif et optimisation : construire un espace de compromis

Le design génératif est souvent présenté comme un système qui trouve la meilleure solution. Cette formulation est trompeuse et empêche de comprendre ce que l’approche apporte réellement.

Tout commence par la construction d’un espace de solutions. Cet espace est défini par des variables — les grandeurs que le système est autorisé à faire varier, avec leurs plages admissibles : hauteur d’étage, profondeur de plateau, pas de trame, taux de vitrage, profondeur de brise-soleil, orientation d’un volume. Le choix de ces variables est un acte de conception à part entière : ce qui n’est pas variable ne sera jamais exploré.

Viennent ensuite les contraintes. Une contrainte dure définit ce qu’une solution doit impérativement respecter pour être considérée comme valide : un recul minimal imposé par une règle d’urbanisme, une hauteur maximale, une largeur d’issue de secours, une portée structurelle admissible. Toute variante qui la viole est écartée, sans négociation. Une contrainte souple exprime une préférence dont l’écart est pénalisé mais toléré : un ratio de compacité souhaité, une proximité fonctionnelle recherchée, une régularité de trame préférable pour la préfabrication. La distinction est essentielle, car traiter une contrainte réglementaire comme souple produit des solutions séduisantes et inconstructibles, tandis que traiter une préférence comme dure appauvrit inutilement l’exploration.

La fonction objectif définit ce que le système cherche à améliorer. Elle traduit un critère en une valeur numérique comparable : une consommation estimée, un coût, une masse de carbone, une surface utile, un pourcentage d’espaces atteignant un seuil d’éclairement. La qualité de cette traduction détermine la qualité de tout l’exercice. Un critère mal formalisé conduit le système à optimiser fidèlement quelque chose qui n’intéresse personne.

Lorsque plusieurs objectifs coexistent et s’opposent, il n’existe pas de solution unique optimale. Il existe un ensemble de solutions dites non dominées : chacune est telle qu’aucun de ses critères ne peut être amélioré sans en dégrader un autre. Cet ensemble constitue le front de Pareto. Sa lecture change la nature de la discussion de projet. Au lieu de débattre d’intuitions, l’équipe examine des compromis chiffrés : cette variante réduit sensiblement les besoins énergétiques mais coûte davantage en façade ; celle-ci maximise la surface utile mais dégrade l’accès à la lumière naturelle dans les zones profondes.

Le système ne désigne donc pas une réponse, et c’est précisément sa valeur. Le choix final dépend de considérations que les fonctions objectif ne capturent pas : la stratégie du maître d’ouvrage, la qualité d’usage perçue, la cohérence urbaine, la faisabilité industrielle locale, la capacité des équipes à réaliser un système constructif, l’évolutivité de l’ouvrage sur trente ans. Une organisation qui laisse un algorithme trancher n’a pas automatisé sa conception : elle a délégué sa responsabilité à un modèle de critères qu’elle a elle-même écrit, souvent trop vite.

Quantités, coûts et carbone : la chaîne la plus exigeante

Relier une maquette à l’économie du projet et à son empreinte environnementale est l’usage le plus demandé de l’automatisation, et le plus difficile à réussir. La raison en est simple : la géométrie et la quantité contractuelle ne sont pas la même chose.

Une quantité géométrique est ce que le modèle contient : le volume d’un objet mur, la surface d’une face, la longueur d’un tracé. Une quantité contractuelle est ce que la règle de mesurage retenue prescrit de compter, et cette règle est une convention professionnelle, souvent nationale, parfois propre au marché. Selon la convention, on déduira ou non les ouvertures en dessous d’une certaine surface, on comptera les recouvrements d’isolant, on intégrera ou non les retours d’angle, on mesurera un mur de nu à nu ou d’axe en axe. Un traitement automatisé qui extrait la géométrie sans appliquer la règle de mesurage produit des valeurs cohérentes entre elles et inutilisables pour un marché.

Les pertes et les recouvrements doivent être traités explicitement. Une surface de revêtement posée n’est pas la surface commandée, un linéaire de câble tiré n’est pas le linéaire théorique, une quantité de béton coulé intègre des tolérances de coffrage. Ces coefficients sont des paramètres métier : ils doivent résider dans un fichier de configuration versionné, être associés à une source documentée, et non être dissimulés dans le code.

Les accessoires posent un problème d’une autre nature. Une maquette modélise rarement les fixations, les suspentes, les colliers, les manchons ou la visserie, alors que ces éléments représentent une part réelle du coût. Leur estimation passe par des ratios rattachés à un ouvrage principal — un nombre de suspentes par mètre linéaire de chemin de câbles, par exemple. Ce sont des hypothèses assumées, pas des mesures, et elles doivent être signalées comme telles dans le livrable.

Les terrassements sont un cas emblématique de l’écart entre modèle et réalité. Le calcul de déblais et remblais dépend d’un terrain naturel dont la modélisation est elle-même une interpolation à partir de points de relevé, ainsi que d’hypothèses de foisonnement, de talutage et de réemploi. Automatiser ce calcul est parfaitement possible ; le présenter comme exact ne l’est pas.

Les unités et les objets non classés ferment la liste des pièges. Une confusion d’unité produit un écart d’ordre de grandeur, généralement repéré. Un objet non classé produit un manque silencieux, rarement repéré. C’est pourquoi tout traitement de métré automatisé doit produire, avant même ses résultats, un rapport de couverture : combien d’objets ont été traités, combien ont été écartés, et pour quel motif. Un métré sans rapport de couverture ne doit pas être exploité.

Trois niveaux de quantité, trois usages distincts

La confusion entre quantité géométrique et quantité contractuelle se clarifie lorsqu’on distingue trois niveaux successifs plutôt que deux.

Le premier niveau est la quantité brute extraite du modèle. C’est ce que le logiciel calcule directement à partir de la géométrie : le volume net d’un objet mur après soustraction des ouvertures modélisées, la surface développée d’une face, le linéaire d’un tracé de réseau. Cette valeur est objective au sens où elle ne dépend d’aucune convention professionnelle, mais elle dépend entièrement de la manière dont le modèle a été construit. Deux modeleurs représentant le même ouvrage produiront des valeurs différentes selon qu’ils ont modélisé un mur monolithique ou une superposition de couches, selon qu’ils ont interrompu les dalles au nu des murs ou les ont poursuivies, selon qu’ils ont modélisé les retombées de poutre séparément ou intégrées. La quantité brute mesure donc autant la convention de modélisation que l’ouvrage lui-même. C’est la raison pour laquelle une convention de modélisation écrite est un préalable au métré automatisé, et non un raffinement optionnel.

Le deuxième niveau est la quantité conventionnelle, obtenue en appliquant à la quantité brute la règle de mesurage retenue pour le marché. Cette règle prescrit ce qui se déduit, ce qui se compte au-delà de la géométrie stricte, et selon quel principe on mesure. Un enduit peut se mesurer en surface développée réelle ou en surface projetée avec des règles forfaitaires de traitement des tableaux et des angles. Un doublage peut se compter du sol à la sous-face de dalle ou jusqu’au plafond fini. Une ouverture peut se déduire intégralement, partiellement au-delà d’un seuil, ou pas du tout. Chacune de ces conventions est légitime dans son contexte, et aucune n’est déductible du modèle. Elle doit être saisie comme un paramètre explicite du traitement, associé à une référence documentaire identifiable et à une date.

Le troisième niveau est la quantité d’approvisionnement, qui intègre les pertes de coupe, les recouvrements, les chutes, les tolérances de mise en œuvre et les casses. Elle intéresse l’entreprise et la logistique de chantier bien plus que le maître d’ouvrage. Elle s’obtient par application de coefficients dont l’origine est empirique et propre à chaque entreprise, à chaque produit et parfois à chaque configuration de chantier.

Confondre ces trois niveaux produit des écarts qui n’apparaissent pas à la lecture, parce que chacun est cohérent dans son registre. Un traitement automatisé sérieux les calcule séparément et les restitue distinctement, en indiquant pour chacun l’hypothèse appliquée. C’est cette séparation, davantage que la précision du calcul, qui rend un métré automatisé défendable en cas de contestation.

Le rapport de couverture : le document que personne ne demande et que tout le monde devrait exiger

Un métré automatisé produit deux livrables, et non un seul. Le premier est le tableau de quantités. Le second, systématiquement omis, est le rapport de couverture, qui décrit ce que le traitement a effectivement vu.

Ce rapport répond à quatre questions. Combien d’objets le modèle contient-il dans le périmètre déclaré, et combien ont été traités ? Quels objets ont été écartés, et pour quel motif : absence de classification, propriété obligatoire manquante, type non reconnu, géométrie invalide, unité non déclarée ? Quels objets ont été traités par une règle de repli plutôt que par la règle nominale, ce qui signale une hypothèse implicite ? Enfin, quels ouvrages attendus par la structure du bordereau n’ont trouvé aucune correspondance dans le modèle, ce qui révèle soit un oubli de modélisation, soit une modélisation par un autre type d’objet que celui prévu ?

L’intérêt de ce document tient à une asymétrie fondamentale. Une erreur de calcul se manifeste généralement par une valeur aberrante, repérable à la relecture par un économiste expérimenté qui connaît les ordres de grandeur. Un objet non traité ne produit aucune valeur aberrante : il produit une absence, et l’absence ne saute pas aux yeux. Une automatisation qui ne rend pas ses lacunes visibles est plus dangereuse qu’une absence d’automatisation, parce qu’elle inspire une confiance que rien ne justifie.

En pratique, un taux de couverture inférieur à un seuil défini à l’avance devrait interdire la publication du métré, et non simplement l’assortir d’une réserve. Le seuil relève d’une décision de l’organisation, mais son existence n’est pas négociable.

Du métré au bilan environnemental : le même chaînage, une incertitude supplémentaire

Le calcul du carbone incorporé réutilise intégralement la chaîne du métré, en substituant aux prix unitaires des facteurs environnementaux. Cette continuité est un avantage considérable : une organisation qui a fiabilisé son métré automatisé a déjà réalisé l’essentiel du travail nécessaire au bilan carbone. Elle est aussi un piège, car elle transfère au bilan environnemental toutes les faiblesses du métré, en y ajoutant une couche d’incertitude propre.

Il s’agit d’associer à chaque quantité un facteur environnemental issu d’une base de données reconnue, généralement construite à partir de déclarations environnementales de produits élaborées selon la norme EN 15804 dans sa version consolidée. La méthode d’évaluation de la performance environnementale des bâtiments a fait l’objet d’une nouvelle version d’EN 15978, publiée le 17 avril 2026 par le CEN, élaborée par le comité technique CEN/TC 350. Cette norme précise le mode de calcul, de restitution et de communication des résultats, pour les bâtiments neufs comme pour les opérations de rénovation.

Le cadre méthodologique européen structure l’évaluation en modules correspondant aux étapes du cycle de vie : la production des produits de construction, leur transport et leur mise en œuvre sur le chantier, la phase d’utilisation avec ses remplacements et sa consommation d’énergie et d’eau, la fin de vie avec la déconstruction et le traitement des déchets, et enfin un module distinct traitant des bénéfices et charges situés au-delà des limites du système, notamment le potentiel de réemploi et de recyclage. Les organisations doivent vérifier auprès du texte lui-même la structure exacte et les évolutions par rapport à l’édition précédente, plutôt que reconduire par habitude une découpe apprise il y a dix ans.

Trois sources d’incertitude s’ajoutent à celles du métré. La première tient au choix des données environnementales : un facteur issu d’une déclaration environnementale spécifique à un produit identifié n’a pas la même valeur qu’une donnée moyenne de filière ou qu’une valeur par défaut majorée. Le mélange de ces trois natures dans un même bilan, sans traçabilité, rend le résultat ininterprétable. La deuxième tient aux hypothèses de durée de vie : la période d’étude retenue et les durées de vie attribuées aux composants déterminent le nombre de remplacements comptabilisés, et donc une part substantielle du résultat. La troisième tient au périmètre déclaré : deux bilans couvrant des modules différents ne sont pas comparables, quelle que soit la rigueur de chacun.

Un bilan carbone automatisé doit donc restituer, avec le même statut que le résultat lui-même, le référentiel méthodologique appliqué, la base de facteurs et son millésime, la répartition des quantités selon la nature des données environnementales mobilisées, la période d’étude, les durées de vie retenues et les modules couverts. Un nombre isolé de kilogrammes équivalent CO2 par mètre carré, présenté sans ce cadre, n’est pas une information environnementale : c’est un argument.

Construction et suivi de chantier : là où l’automatisation rencontre le réel

La phase de réalisation impose une contrainte que les phases d’étude ne connaissent pas : le monde physique ne se conforme pas aux hypothèses du modèle.

Le BIM 4D consiste à associer les objets du modèle aux tâches du planning, ce qui permet de simuler le déroulement de la construction et de détecter des incohérences de séquence : un élément installé avant son support, une zone rendue inaccessible par une opération antérieure, un conflit d’occupation de grue. L’automatisation intervient à deux niveaux : le rattachement des objets aux tâches, qui peut être déduit de règles fondées sur la zone, le niveau et le type d’ouvrage plutôt que réalisé manuellement ; et la détection d’incohérences dans la séquence obtenue. Le maintien du lien lorsque le modèle et le planning évoluent séparément reste le point sensible.

La préfabrication est le domaine où l’automatisation atteint sa plus grande maturité, parce que la chaîne y est fermée : un modèle précis alimente directement des données de fabrication, elles-mêmes exploitées par des machines à commande numérique. La condition est la maîtrise en amont des contraintes industrielles — dimensions maximales transportables, capacités machine, tolérances d’assemblage, ordonnancement de production. La contrepartie est une exigence de fiabilité bien supérieure : une erreur de modèle devient une erreur de production physique, coûteuse et irréversible.

La logistique et les approvisionnements peuvent être partiellement pilotés par le modèle : déduire les besoins matières par zone et par période, préparer les commandes, planifier les livraisons en fonction de l’avancement prévu et des capacités de stockage sur site. La valeur de cette automatisation dépend entièrement de la fraîcheur des données d’avancement.

Le contrôle d’avancement et la réalité capturée forment ensemble le mécanisme le plus prometteur de la phase chantier. Des relevés réguliers par scanner laser, par photogrammétrie ou par imagerie automatisée produisent une représentation de l’état réel. La comparaison entre cet état et le modèle permet d’estimer un avancement par ouvrage, de détecter des écarts géométriques et d’alimenter les situations de travaux. Les traitements automatisés y sont utiles pour aligner les relevés sur le modèle, segmenter les éléments et calculer des écarts.

Il faut cependant énoncer clairement les limites. Un chantier est un environnement partiellement observable : des éléments sont masqués par d’autres, les conditions de relevé varient, une partie des ouvrages est enfouie ou recouverte au moment de la mesure. Les méthodes de reconnaissance appliquées à ces données sont probabilistes et produisent des faux positifs comme des faux négatifs. Par ailleurs, la comparaison entre planifié et réalisé produit un écart, non une explication : un retard peut provenir d’une intempérie, d’une rupture d’approvisionnement, d’une modification de programme, d’un défaut d’exécution ou d’une erreur de planning initial. Toutes ces causes appellent des réponses différentes, et aucune ne se déduit du chiffre. L’automatisation en phase chantier remplit donc son rôle lorsqu’elle fournit une observation fiable et rapide ; elle sort de son domaine dès qu’elle prétend attribuer une responsabilité.

Du BIM au jumeau numérique : une différence de nature

L’expression jumeau numérique est employée pour désigner des réalités très différentes, ce qui nuit à la compréhension du sujet. Une clarification s’impose.

Une maquette BIM est une représentation de l’intention et de la conception d’un ouvrage. Elle est produite pendant un projet, elle décrit ce qui doit être ou ce qui a été construit, et son contenu est figé aux jalons de livraison. Elle constitue un excellent référentiel de conception et de patrimoine documentaire.

Un jumeau numérique opérationnel est autre chose : une représentation d’un actif en service, alimentée en continu par des données provenant de son exploitation réelle, et destinée à soutenir des décisions d’exploitation. La différence n’est pas le degré de détail géométrique mais la présence d’un flux de données vivant et d’un usage opérationnel identifié. Un modèle très détaillé sans flux de données ni usage n’est pas un jumeau numérique ; c’est une maquette d’ouvrage exécuté.

Le passage de l’un à l’autre repose sur plusieurs continuités. La première est la continuité des identifiants : les équipements décrits en conception doivent être reliés aux équipements effectivement installés, eux-mêmes reliés aux enregistrements du système de gestion de maintenance et, le cas échéant, aux points de mesure de la gestion technique du bâtiment. C’est un travail de mise en correspondance qui doit être organisé au moment de la mise en service, faute de quoi il devient extrêmement coûteux à reconstituer.

La deuxième est la transmission des données de mise en service : références réelles des équipements installés, numéros de série, résultats des essais, garanties, notices, paramètres de réglage. Ces informations conditionnent l’utilité du jumeau bien davantage que la finesse de la géométrie.

La troisième est l’intégration des capteurs et des flux de mesure, avec les questions techniques associées : fréquence d’acquisition, gestion des valeurs manquantes, détection de dérive de capteur, volume de stockage, latence acceptable pour l’usage visé.

La quatrième est la gestion des événements et des historiques d’intervention : alarmes, opérations de maintenance préventive et corrective, remplacements, modifications de configuration. C’est cet historique qui donne progressivement au jumeau une valeur analytique, en permettant de relier un comportement observé à une cause documentée.

L’automatisation intervient à chacun de ces niveaux : rapprochement des identifiants, contrôle de complétude des données de mise en service, surveillance de la qualité des flux, détection d’anomalies de fonctionnement, préparation de plans de maintenance. Elle rencontre cependant la même limite que partout ailleurs : une anomalie détectée est un signal, pas un diagnostic, et l’intervention reste une décision d’exploitant.

L’écosystème technologique : familles d’outils et seuils de bascule

Il serait vain d’établir un classement des solutions disponibles, tant les besoins varient selon la taille des structures, les disciplines et les marchés. Il est en revanche utile de comprendre à quelle famille chaque outil appartient et quel problème il résout.

La programmation visuelle permet de construire une logique en reliant des composants graphiques plutôt qu’en écrivant du code. Dynamo, intégré à l’environnement Revit, et Grasshopper, associé à Rhino, en sont les représentants les plus répandus. Leur force est l’accessibilité : un professionnel non développeur peut y encoder une logique métier qu’il maîtrise. Leur limite apparaît avec la complexité, lorsque le graphe devient difficile à lire, à tester et à faire évoluer collectivement.

Les langages de programmation prennent le relais. Python est largement utilisé pour le traitement de données, l’automatisation de tâches et l’exploitation de fichiers IFC. C# est le langage privilégié pour développer des extensions dans les environnements .NET, notamment via l’API Revit. JavaScript et TypeScript dominent les interfaces web et les applications de visualisation en navigateur. Le choix dépend moins d’une préférence que de l’environnement d’exécution visé.

Les interfaces de programmation applicative, ou API, permettent à des programmes de communiquer avec des logiciels et des plateformes sans passer par l’interface graphique. C’est ce qui rend possible l’enchaînement d’outils hétérogènes dans une chaîne continue.

Les plateformes cloud hébergent modèles, données et traitements, et fournissent la gestion des droits, des versions et des exécutions planifiées. Elles apportent aussi une puissance de calcul indispensable aux explorations génératives, qui peuvent exiger des milliers d’évaluations.

Les moteurs de règles exécutent des vérifications formalisées sur des données structurées. Dans le contexte openBIM, l’IDS joue ce rôle de manière normalisée, et des implémentations libres comme IfcOpenShell permettent de lire, écrire et vérifier des fichiers IFC par programme.

Les plateformes d’échange de données AEC ouvertes, dont Speckle est un exemple représentatif, adressent un problème différent : transporter des données entre logiciels au niveau de l’objet plutôt qu’au niveau du fichier, avec un historique de versions.

Les bases de données deviennent nécessaires dès que l’on veut interroger, croiser et historiser des informations issues de plusieurs modèles et de plusieurs projets — ce qu’un fichier ne permet pas efficacement.

Les plateformes de jumeaux numériques, comme la plateforme iTwin de Bentley Systems, et les environnements de description et de visualisation de scènes tridimensionnelles fondés sur OpenUSD répondent aux besoins d’agrégation et de restitution d’actifs complexes en exploitation.

Le seuil de bascule entre programmation visuelle et développement applicatif se reconnaît à quatre signaux convergents. Le traitement est utilisé par plusieurs personnes qui n’en sont pas les auteurs. Il doit s’exécuter automatiquement, sans qu’un opérateur ouvre un logiciel. Il doit être testé et versionné comme un composant fiable. Enfin, il manipule des données à conséquence contractuelle. Lorsque trois de ces quatre signaux sont présents, poursuivre en programmation visuelle revient à accumuler une dette technique dont le coût dépassera rapidement celui d’un développement structuré.

Gouvernance, sécurité et validation humaine

L’automatisation déplace le risque plutôt qu’elle ne le supprime. Une organisation qui automatise sans gouverner ne réduit pas son exposition : elle la concentre en des points moins visibles.

Le premier risque est celui des mauvaises données. Un traitement appliqué à un modèle incomplet produit un résultat structurellement faux, mais présenté avec l’autorité d’un rapport machine. La parade est le rapport de couverture systématique et le refus d’exécution en cas de non-conformité aux prérequis.

Le deuxième est celui des versions incorrectes. C’est probablement la cause d’erreur la plus fréquente et la plus banale. Elle se traite par l’enregistrement obligatoire des identifiants de version consommés dans chaque rapport produit.

Le troisième, le plus insidieux, est celui des erreurs silencieuses. Un traitement qui échoue bruyamment est un incident mineur, car il est traité. Un traitement qui produit une valeur plausible mais fausse contamine les décisions en aval pendant des mois. La conception d’un traitement doit donc privilégier l’échec explicite : mieux vaut un arrêt sur cas non prévu qu’une valeur par défaut appliquée silencieusement.

Le quatrième est celui des automatisations non documentées. Chaque script sans propriétaire, sans description et sans test constitue un passif. Un inventaire tenu à jour des automatisations en service, avec leur responsable, leur périmètre et leur date de dernière vérification, est une mesure de gouvernance élémentaire et rarement mise en œuvre.

Le cinquième est celui des dépendances logicielles. Une automatisation dépend d’un logiciel hôte, de bibliothèques et parfois de services externes, dont les mises à jour peuvent modifier des comportements. Un calendrier de vérification aligné sur les cycles de mise à jour des outils est nécessaire.

Le sixième concerne la confidentialité et les droits d’accès. Les modèles de projets contiennent des informations sensibles : dispositifs de sécurité, réseaux critiques, données commerciales, parfois données à caractère personnel. Toute automatisation qui transfère des données vers un service externe, y compris un service d’intelligence artificielle, doit faire l’objet d’une analyse explicite : quelles données sortent, vers quelle juridiction, avec quelle durée de conservation, avec quel usage possible pour l’entraînement de modèles, et avec quel accord contractuel du maître d’ouvrage.

Le septième est spécifique à l’intelligence artificielle générative. Ces systèmes produisent des sorties fluides et convaincantes indépendamment de leur exactitude. Ils peuvent citer une norme qui n’existe pas, attribuer une valeur à une référence qui n’en comporte pas, ou inventer une clause. Dans un secteur où une référence normative erronée engage une responsabilité, l’usage de ces outils sans vérification systématique des sources primaires est une négligence.

L’humain dans la boucle

Le principe de l’humain dans la boucle est souvent réduit à une formule rassurante. Il n’a de valeur que s’il est opérationnalisé. Cela suppose de définir, pour chaque automatisation, quatre éléments. Ce qui est soumis à validation, en ciblant les points de décision plutôt que la totalité des sorties. Qui valide, avec la compétence correspondante et une désignation nominative. Sur quelle base, c’est-à-dire quels éléments doivent être présentés au validateur pour rendre son examen possible — les hypothèses retenues, les exceptions rencontrées, les écarts par rapport aux ordres de grandeur attendus. Et enfin quelle trace est conservée de cette validation.

Une validation qui consiste à cliquer sur un bouton sans disposer des éléments de jugement n’est pas un contrôle : c’est un transfert de responsabilité déguisé.

Classer les automatisations par niveau de conséquence

Appliquer le même dispositif de contrôle à toutes les automatisations est le meilleur moyen de n’en contrôler correctement aucune. Un traitement qui renomme des vues et un traitement qui produit un métré contractuel n’exposent pas l’organisation au même risque, et les traiter identiquement conduit soit à surcharger le premier, soit à sous-protéger le second. Une classification par niveau de conséquence est donc le premier acte de gouvernance utile.

Le niveau le plus bas rassemble les traitements dont l’erreur est immédiatement visible et sans effet en aval. Un script qui renomme mal des vues produit une gêne repérée dans l’heure et corrigée en quelques minutes. Ces traitements peuvent être développés et déployés avec une documentation minimale et sans validation formelle, à condition qu’ils soient réversibles.

Le niveau intermédiaire rassemble les traitements dont l’erreur est différée mais rattrapable. Un contrôle de complétude mal paramétré laisse passer des défauts qui seront détectés lors d’une coordination ultérieure, avec un coût de reprise réel mais borné. Ces traitements exigent un jeu de test de référence, un rapport lisible et un propriétaire identifié, sans nécessiter une validation nominative à chaque exécution.

Le niveau le plus élevé rassemble les traitements dont la sortie alimente un document engageant : métré contractuel, bilan réglementaire, note de dimensionnement, dossier de consultation, données de fabrication. Ici, la validation nominative est obligatoire, le rapport doit exposer les hypothèses et les exceptions, la version du traitement et des données consommées doit être inscrite dans le livrable, et le journal d’audit doit être conservé pendant la durée de responsabilité applicable à l’ouvrage.

Un quatrième cas mérite un traitement à part : les automatisations qui écrivent dans un modèle partagé. Leur conséquence n’est pas seulement dans leur sortie mais dans leur effet de bord. Elles doivent systématiquement s’exécuter sur une copie, produire un journal exhaustif des modifications apportées, et disposer d’un mécanisme de retour arrière testé. Une automatisation d’écriture sans possibilité de retour arrière ne devrait jamais être déployée sur un projet en production, quel que soit son intérêt.

Cette classification a une vertu pratique inattendue : elle rend les arbitrages de moyens explicites. Lorsqu’une équipe demande à automatiser un processus de niveau élevé, la question n’est plus peut-on le faire, mais acceptons-nous d’en financer le dispositif de contrôle. C’est une question de direction, pas une question technique.

Le registre des automatisations : un document d’une page qui change tout

La plupart des organisations AEC ignorent combien d’automatisations tournent chez elles. Les scripts se transmettent de poste à poste, se dupliquent, se modifient localement, et survivent au départ de leurs auteurs sans que personne n’en assume la maintenance. Cette situation ne devient visible qu’au moment de l’incident, généralement après une mise à jour logicielle.

Un registre des automatisations corrige cette cécité à un coût dérisoire. Il recense, pour chaque traitement en service, une dizaine d’informations : un identifiant, une désignation compréhensible par un non-spécialiste, la description en une phrase de ce qu’il fait et de ce qu’il ne fait pas, son niveau de conséquence, son propriétaire métier et son mainteneur technique, ses données d’entrée et ses prérequis, la localisation de son code et de sa configuration, la date de sa dernière vérification, l’environnement logiciel dont il dépend avec les versions concernées, et enfin son statut — en service, en expérimentation, gelé ou retiré.

La tenue de ce registre produit trois effets. Elle révèle d’abord les redondances : il n’est pas rare de découvrir trois traitements différents qui résolvent le même problème dans trois équipes, chacun avec ses propres défauts. Elle rend ensuite possible une réaction organisée lors d’une mise à jour majeure d’un logiciel hôte : on sait exactement quoi tester, plutôt que d’attendre les remontées d’incidents. Elle permet enfin de retirer proprement les traitements devenus inutiles, ce qui n’arrive jamais spontanément — une automatisation abandonnée ne s’éteint pas, elle continue de tourner en silence et de produire des résultats que plus personne n’interprète.

Ce registre n’a pas besoin d’un outil dédié. Un tableau tenu à jour et consulté lors des revues techniques suffit largement, et vaut infiniment mieux qu’une plateforme sophistiquée que personne n’alimente.

Adapter le cadre NIST AI RMF au contexte AEC

Le cadre de gestion des risques liés à l’intelligence artificielle publié par le NIST, dans sa version 1.0 diffusée le 26 janvier 2023, offre une structure de référence volontaire organisée autour de quatre fonctions. Le NIST a complété ce cadre par un profil consacré à l’intelligence artificielle générative, publié le 26 juillet 2024 sous la référence NIST AI 600-1, et indique que le cadre fait l’objet de travaux de révision. Ces éléments doivent donc être considérés comme un cadre en évolution, non comme une exigence figée.

La fonction Govern concerne la culture et les responsabilités. Transposée à une structure AEC, elle implique de désigner un responsable de l’usage de l’intelligence artificielle, de définir une politique explicite indiquant quels usages sont autorisés, conditionnés ou interdits, et d’intégrer ces règles aux procédures qualité existantes plutôt que d’en faire un document séparé que personne ne consulte.

La fonction Map consiste à cartographier le contexte et les risques. Concrètement : recenser les traitements en service, identifier pour chacun les données consommées, les décisions influencées, les parties affectées et les conséquences possibles d’une erreur. Un traitement qui produit une proposition de nommage de vues et un traitement qui produit un métré contractuel n’appartiennent pas à la même catégorie de risque et ne méritent pas le même dispositif.

La fonction Measure porte sur l’évaluation. Elle suppose de définir ce qui est mesuré — taux d’erreur sur un jeu de référence, taux de faux positifs d’un contrôle, part des sorties nécessitant une correction — et de mesurer réellement, à intervalle défini, plutôt que de supposer que la performance initiale se maintient.

La fonction Manage organise la réponse. Elle définit les seuils au-delà desquels un traitement est suspendu, les procédures de correction, la communication auprès des utilisateurs affectés, et la conservation des enseignements tirés des incidents.

À ce cadre volontaire s’ajoute, pour les organisations opérant dans l’Union européenne, un cadre réglementaire contraignant. Le règlement européen sur l’intelligence artificielle est entré en vigueur le 1er août 2024 et s’applique de manière échelonnée : interdictions et dispositions générales depuis février 2025, obligations relatives aux modèles à usage général depuis août 2025, entrée en application de la majorité des règles en août 2026, tandis que le calendrier officiel situe l’application des règles relatives aux systèmes à haut risque de l’annexe III en décembre 2027 et celles concernant les systèmes intégrés à des produits réglementés en août 2028. Ce calendrier a fait l’objet d’ajustements législatifs récents et continue d’évoluer ; toute organisation concernée doit vérifier l’état applicable auprès des sources officielles plutôt que se fier à une synthèse, y compris celle-ci.

Mesurer le retour sur investissement de l’automatisation AEC

Sans mesure, un projet d’automatisation repose sur une conviction. Or les convictions résistent mal aux arbitrages budgétaires, et les gains réels finissent par être attribués à autre chose.

La première étape est l’établissement d’une situation de référence. Avant d’automatiser, il faut mesurer le processus existant : combien de temps une exécution manuelle demande-t-elle réellement, combien de fois cette exécution a-t-elle lieu sur une période donnée, quel est le taux d’erreur observé et quel temps de reprise ces erreurs génèrent. Cette mesure doit être faite sur des cas réels, pas estimée de mémoire. L’écart entre le temps perçu et le temps mesuré est presque toujours significatif, dans un sens comme dans l’autre.

Les grandeurs à suivre sont peu nombreuses. Le temps manuel unitaire correspond à la durée d’une exécution complète, reprises incluses. Le volume d’exécution compte le nombre de répétitions sur une période. Le taux d’erreur mesure la proportion d’exécutions produisant un défaut détecté en aval, et le coût de reprise évalue ce que coûte la correction, en incluant les effets induits lorsque le défaut est détecté tardivement. Du côté de l’investissement, le coût de développement couvre la conception, l’écriture, les tests et le déploiement, tandis que le coût de maintenance couvre les corrections, l’adaptation aux mises à jour et le support aux utilisateurs. Ce dernier poste est le plus systématiquement sous-estimé.

La formule de base est simple. Le gain net annuel s’écrit comme la différence entre les coûts évités et les coûts engendrés :

Gain net annuel = [ (Temps manuel unitaire − Temps automatisé unitaire) × Volume annuel × Coût horaire ] + [ Réduction du coût annuel de reprise ] − [ Coût de maintenance annuel ]

Le délai de retour s’obtient en divisant le coût de développement par le gain net annuel, sous réserve que ce gain soit positif.

Voici un exemple pédagogique entièrement fictif, construit pour illustrer la mécanique du calcul. Les valeurs sont arbitraires et ne représentent aucune moyenne sectorielle. Supposons un contrôle de complétude des propriétés d’un modèle avant diffusion, réalisé manuellement en trois heures par un coordinateur BIM, exécuté quarante fois par an, au coût horaire interne fictif de 60 unités monétaires. Le coût manuel annuel s’élève alors à 3 × 40 × 60, soit 7 200 unités. Supposons que ce contrôle laisse passer un défaut dans un cas sur cinq, chaque défaut entraînant une reprise fictive de 400 unités, soit 8 × 400 = 3 200 unités par an. Le coût total du processus existant serait donc de 10 400 unités.

Supposons maintenant un traitement automatisé ramenant le temps unitaire à quinze minutes de préparation et de lecture du rapport, soit 0,25 × 40 × 60 = 600 unités, et réduisant le taux de défauts résiduels à un cas sur vingt, soit 2 × 400 = 800 unités. Le coût du processus automatisé serait de 1 400 unités. Le gain brut atteindrait 9 000 unités. En retranchant un coût de maintenance annuel fictif de 2 000 unités, le gain net s’établirait à 7 000 unités. Pour un coût de développement fictif de 14 000 unités, le délai de retour serait de deux ans.

Cet exemple appelle plusieurs réserves méthodologiques. Il suppose que le temps libéré est effectivement réaffecté à une activité de valeur, ce qui n’est pas automatique. Il ignore le coût de formation et d’accompagnement au changement, souvent comparable au coût de développement lui-même. Il suppose une stabilité de l’environnement logiciel sur la période, alors qu’une évolution majeure peut imposer une reprise substantielle. Il ne valorise pas les bénéfices non monétaires — réduction du risque contractuel, amélioration de la qualité perçue, attractivité pour les collaborateurs — qui sont réels mais difficiles à chiffrer honnêtement. Un calcul de retour sur investissement en automatisation est un outil de décision, pas une prédiction.

Déployer sur quatre-vingt-dix jours : une feuille de route réaliste

Un horizon de trois mois est suffisant pour livrer une automatisation utile et gouvernée, à condition de ne pas chercher à tout traiter simultanément.

Phase un : cadrage et mesure de la situation de référence

Les trois premières semaines ne produisent aucun code. Elles servent à identifier les processus candidats et à choisir le premier périmètre. Un bon candidat de départ combine quatre caractéristiques : un volume d’exécution élevé, une logique stable et peu contestée, une conséquence limitée en cas d’erreur, et un utilisateur demandeur identifié. Il faut résister à la tentation de commencer par le processus le plus douloureux, qui est généralement le plus complexe et le plus politique.

Cette phase établit également la situation de référence chiffrée, cartographie les données disponibles et évalue leur qualité réelle. C’est fréquemment ici que le projet découvre que le préalable n’est pas le développement mais la remise en ordre des conventions. Ce constat, désagréable, est plus économique à faire en semaine deux qu’en semaine dix.

Phase deux : formalisation des règles

Les semaines quatre à six sont consacrées à transformer les savoirs implicites en règles explicites et testables. C’est un travail d’entretien avec les praticiens, de rédaction et de confrontation. Il révèle presque toujours que les collaborateurs n’appliquent pas exactement la même règle, ce qui explique rétrospectivement des incohérences observées depuis des années. Cette phase se termine par une spécification écrite, validée par les métiers concernés, précisant les cas nominaux, les cas particuliers et les cas explicitement exclus du périmètre. Lorsque le contexte s’y prête, cette spécification gagne à être exprimée directement au format IDS, ce qui la rend exécutable dès sa rédaction.

Phase trois : développement et tests

Les semaines sept à dix couvrent l’écriture du traitement, la constitution d’un jeu de test de référence et l’exécution des tests sur des cas nominaux et limites. Le développement doit rester délibérément modeste : mieux vaut un traitement qui couvre correctement quatre-vingts pour cent des cas et signale explicitement les vingt pour cent restants, qu’un traitement ambitieux qui traite tout de manière approximative. Cette phase produit également le rapport type, dont la lisibilité conditionne l’adoption : un rapport que personne ne comprend rend l’automatisation inutilisable, quelle que soit la qualité du calcul.

Phase quatre : expérimentation puis gouvernance

Les semaines onze à treize déploient le traitement sur un projet réel, avec un accompagnement rapproché et un double contrôle temporaire — l’exécution manuelle est maintenue en parallèle sur quelques itérations pour comparer les résultats. Les écarts constatés alimentent les corrections. La phase se conclut par la mise en gouvernance : inscription à l’inventaire des automatisations, désignation formelle du propriétaire, documentation d’usage, calendrier de vérification et décision explicite sur l’extension à d’autres projets.

Les critères de sortie de phase, et les signaux qui doivent faire arrêter

Une feuille de route n’a de valeur que si l’on sait à quelle condition passer à l’étape suivante. Sans critère de sortie explicite, les phases se chevauchent, le cadrage se poursuit pendant le développement, et l’expérimentation commence sur un traitement non testé.

La phase de cadrage se termine lorsque trois éléments existent sous forme écrite : le processus retenu est décrit du début à la fin avec ses acteurs, sa situation de référence est chiffrée à partir de cas réels et non d’estimations mémorielles, et un utilisateur nommément désigné s’est engagé à employer le futur traitement dans son travail quotidien. Ce dernier point est le plus souvent négligé et le plus prédictif de l’échec : une automatisation développée sans destinataire identifié finit dans un dossier partagé que personne n’ouvre.

La phase de formalisation des règles se termine lorsque la spécification écrite a été relue et approuvée par au moins deux praticiens du métier concerné, et lorsque les cas explicitement exclus du périmètre ont été listés. Cette liste d’exclusions est un livrable à part entière : elle protège le développeur d’une dérive de périmètre et protège l’utilisateur d’une attente déçue.

La phase de développement se termine lorsque le traitement s’exécute correctement sur le jeu de test de référence, produit un résultat conforme à celui attendu, et échoue de manière explicite sur les cas limites prévus. Un traitement qui produit une valeur sur un cas qu’il ne sait pas traiter n’a pas passé le test, même si la valeur semble raisonnable.

La phase d’expérimentation se termine lorsque le double contrôle manuel et automatisé, mené en parallèle sur un nombre d’itérations défini à l’avance, a produit des écarts compris dans une tolérance également définie à l’avance, et lorsque les écarts constatés ont été expliqués — non pas seulement corrigés, mais compris.

Trois signaux, enfin, doivent conduire à suspendre le projet plutôt qu’à le poursuivre par inertie. Le premier est la découverte, en cours de formalisation, que le processus visé n’est pas stabilisé et fait l’objet de pratiques divergentes défendues par chacune des parties : il faut alors traiter le désaccord avant de l’encoder. Le deuxième est la constatation que les données d’entrée exigent un travail de reprise supérieur au bénéfice attendu du traitement : la priorité devient alors la standardisation, ce qui n’est pas un échec mais un changement de sujet. Le troisième est le retrait de l’utilisateur destinataire, quelle qu’en soit la raison : un traitement sans usager n’a pas de valeur, quelle que soit sa qualité technique.

Répartition des responsabilités

Le propriétaire du processus est un professionnel du métier concerné. Il définit ce que le traitement doit faire, arbitre les cas particuliers et valide que le résultat correspond au besoin. Sans lui, le développement encode les hypothèses du développeur.

Le développeur conçoit et écrit le traitement, met en place les tests et assure la maintenance technique. Il ne décide pas des règles métier.

Le BIM Manager garantit la cohérence avec les conventions du projet, les gabarits, les classifications et l’environnement commun de données. Il vérifie que l’automatisation ne crée pas une pratique parallèle divergente.

Les utilisateurs exécutent le traitement dans leur travail quotidien, remontent les anomalies et les cas non couverts. Leur retour est la principale source d’amélioration.

Le validateur technique engage sa responsabilité sur les résultats à conséquence contractuelle ou réglementaire. Il doit disposer de la compétence, du temps et des éléments nécessaires. Ce rôle ne peut jamais être tenu par le traitement lui-même.

Cinq niveaux de maturité en automatisation AEC

Situer son organisation permet d’éviter deux erreurs symétriques : viser un niveau hors d’atteinte, ou se satisfaire d’un niveau dépassé.

Au premier niveau, les opérations sont manuelles et les conventions individuelles. Chaque collaborateur nomme, classe et renseigne selon ses habitudes. Les données ne sont pas exploitables par un programme. Le risque dominant est l’incohérence entre livrables et la dépendance à des savoir-faire non transmis. La condition pour progresser n’est pas technologique : elle consiste à définir et à faire appliquer des conventions communes, ce qui relève de la décision managériale.

Au deuxième niveau, les conventions existent et sont documentées. Les modèles sont structurés, les classifications appliquées, les propriétés renseignées dans des emplacements prévisibles. Aucun traitement automatisé n’est encore en service, mais les données sont devenues exploitables. Le risque est la dérive : une convention non contrôlée s’érode en quelques mois. La condition pour progresser est la mise en place de contrôles automatiques de conformité, qui rendent la convention vérifiable plutôt que déclarative.

Au troisième niveau, des automatisations déterministes ponctuelles sont en service : contrôles de complétude, génération documentaire, extraction de quantités, exports normalisés. Les gains sont réels et mesurables. Le risque principal devient la prolifération non gouvernée de scripts sans propriétaire ni test. La condition pour progresser est l’industrialisation : inventaire, versionnement, tests de référence, responsabilités formalisées.

Le piège du troisième niveau

C’est au troisième niveau de maturité que se perdent la plupart des organisations, et le mécanisme est toujours le même. Les premiers scripts fonctionnent, les gains sont réels, l’enthousiasme se diffuse. Chacun se met à automatiser ce qui le gêne, sans convention commune, sans test et sans propriétaire. Deux ans plus tard, la structure dépend d’une soixantaine de traitements dont personne ne connaît l’inventaire, dont la moitié a été écrite par des collaborateurs partis, et dont aucun ne survivra proprement à la prochaine mise à jour logicielle majeure.

Le signal d’alerte est facile à reconnaître : le jour où quelqu’un demande combien de scripts nous avons en service et où la réponse est un silence, l’organisation n’a pas franchi le troisième niveau — elle y a construit sa dette.

Au quatrième niveau, les outils et les sources sont connectés. Les données circulent entre modèles, bases de données, plateformes et outils d’analyse sans réexportation manuelle. Les résultats sont mesurés et suivis dans le temps. L’optimisation multicritère est employée en phase d’étude pour éclairer les arbitrages. Le risque se déplace vers les dépendances techniques et la sécurité des flux : une chaîne connectée propage un défaut plus loin et plus vite. La condition pour progresser est la maîtrise complète de la traçabilité, sans laquelle l’introduction de composants probabilistes devient impossible à contrôler.

Au cinquième niveau, des agents supervisés orchestrent des séquences de tâches sur un périmètre borné, avec des points de validation explicites, un journal complet et une réversibilité garantie. Ce niveau ne se caractérise pas par une plus grande autonomie laissée à la machine, mais par une capacité de contrôle suffisamment forte pour que cette autonomie partielle reste sans danger. Le risque dominant est le relâchement de la vigilance à mesure que les résultats deviennent habituellement satisfaisants. La condition du maintien à ce niveau est la mesure continue et l’acceptation qu’un dispositif dont on ne mesure plus la performance a déjà commencé à se dégrader.

Perspectives : ce qui est disponible et ce qui reste expérimental

Plusieurs directions se dessinent, qu’il convient de distinguer selon leur degré de maturité réelle.

Les interfaces en langage naturel progressent rapidement. Interroger un ensemble de modèles par une question formulée en français, obtenir une liste d’objets répondant à un critère, générer la documentation d’un traitement : ces usages sont accessibles aujourd’hui et apportent une valeur immédiate en réduisant la barrière technique. Leur limite tient à la vérifiabilité : une réponse en langage naturel doit pouvoir être tracée jusqu’aux données qui la fondent, faute de quoi elle constitue une opinion bien formulée. Les architectures qui contraignent le modèle à produire une requête vérifiable plutôt qu’une réponse directe sont plus prometteuses que celles qui laissent le modèle répondre librement.

Les modèles spécialisés du domaine AEC, entraînés sur des données de construction plutôt que sur du texte généraliste, constituent une piste sérieuse. Elle se heurte à un obstacle structurel : la disponibilité de jeux de données ouverts, volumineux, annotés et représentatifs de la diversité des pratiques constructives régionales. Les données de projet sont confidentielles, hétérogènes et rarement annotées. Ce goulot d’étranglement est plus déterminant pour la vitesse des progrès que la puissance de calcul disponible.

Les contrôles continus représentent probablement l’évolution la plus immédiatement utile. Plutôt qu’un contrôle qualité réalisé à quelques jalons, une vérification exécutée à chaque dépôt de modèle transforme la coordination : les écarts sont détectés alors qu’ils coûtent peu à corriger. Cette évolution est technologiquement accessible aujourd’hui ; sa généralisation dépend surtout de l’organisation des équipes et de la capacité à traiter le flux de constats produits.

Les systèmes multi-agents et les workflows partiellement autonomes restent, pour l’essentiel, du domaine de l’expérimentation dans un contexte de production AEC. Les démonstrations existent et sont convaincantes sur des périmètres restreints. Le passage à l’échelle se heurte à la question de la responsabilité : dans un secteur où les décisions engagent la sécurité des personnes et des responsabilités décennales, l’absence d’un acteur identifié assumant une décision n’est pas un détail d’implémentation. Il est raisonnable d’anticiper une extension progressive de ces dispositifs sur des tâches à faible enjeu, avec un périmètre d’action strictement borné, plutôt qu’une bascule générale.

Conclusion : automatiser ce que l’on comprend

L’automatisation de la conception AEC n’est pas une course à l’outil. C’est un travail de clarification. Elle contraint une organisation à écrire ce qu’elle sait faire, à nommer ce qu’elle attend, à distinguer ce qui relève de la règle de ce qui relève du jugement, et à désigner qui répond de quoi. Ce travail est exigeant parce qu’il met au jour des ambiguïtés que les habitudes de métier permettaient de contourner. Il est aussi ce qui produit les bénéfices les plus durables, indépendamment des technologies qui se succéderont.

Ce constat conduit à une conséquence peu intuitive. Les organisations qui tireront le meilleur parti des avancées à venir en intelligence artificielle ne seront pas celles qui les auront adoptées en premier, mais celles qui auront mis leurs données en ordre, formalisé leurs règles et construit une culture de la vérification. Un outil probabiliste greffé sur une base incohérente produit du bruit convaincant. Le même outil, adossé à des données structurées, à des exigences exécutables et à un dispositif de contrôle réel, devient un instrument de travail.

Reste une dimension que ce guide n’a fait qu’effleurer et qui mérite d’être posée. À mesure que les tâches d’exécution se réduisent, la valeur du professionnel se déplace vers la formulation du problème, le choix des critères et l’arbitrage entre des valeurs qui ne se réduisent pas à des scores. La question posée aux métiers de la conception n’est donc pas de savoir quelles tâches la machine peut reprendre, mais de savoir sur quel jugement ils entendent fonder leur légitimité lorsque la production ne sera plus, à elle seule, une compétence distinctive.

Questions fréquentes sur l’automatisation de la conception AEC

Faut-il savoir programmer pour automatiser des tâches en AEC ?

Non pour commencer, oui pour aller loin. Les environnements de programmation visuelle comme Dynamo ou Grasshopper permettent à un architecte ou à un ingénieur d’encoder une logique métier sans écrire de code, et c’est souvent par là que les organisations démarrent avec profit. La compétence déterminante à ce stade n’est pas technique : c’est la capacité à décomposer un processus en étapes explicites et à identifier ses cas particuliers.

La programmation devient nécessaire lorsque le traitement doit être utilisé par plusieurs personnes, testé, versionné, exécuté automatiquement ou intégré à d’autres systèmes. Une organisation mature combine généralement les deux niveaux : des praticiens qui prototypent en programmation visuelle et formalisent les règles, et des développeurs qui industrialisent ce qui a fait ses preuves.

Quelle est la différence entre automatisation BIM et design génératif ?

L’automatisation BIM exécute une tâche connue selon des règles fixes : elle produit un résultat déterminé à partir d’une entrée déterminée. Renommer des vues, contrôler des propriétés, générer des nomenclatures ou extraire des quantités relèvent de cette catégorie. On sait à l’avance ce que le traitement va produire, et la même entrée donnera toujours la même sortie.

Le design génératif explore un espace de possibilités que l’on n’a pas défini explicitement. On décrit des variables, des contraintes et des objectifs, et le système parcourt les combinaisons pour restituer un ensemble de variantes évaluées. Le résultat n’est pas une réponse mais une matière à décision. Les deux approches répondent à des besoins distincts et ne se substituent pas l’une à l’autre : la première fiabilise la production, la seconde élargit l’exploration.

Par où commencer concrètement dans une agence ou un bureau d’études ?

Par la mesure, pas par l’outil. Identifiez trois tâches répétitives réellement chronophages, mesurez le temps qu’elles consomment sur des cas réels et comptez leur fréquence annuelle. Choisissez ensuite celle qui combine un volume élevé, une logique stable, une conséquence limitée en cas d’erreur et un utilisateur demandeur.

Avant d’écrire quoi que ce soit, vérifiez que les données nécessaires existent et sont exploitables : conventions de nommage respectées, propriétés présentes, classifications appliquées, unités cohérentes. Si ce n’est pas le cas, le premier chantier n’est pas l’automatisation mais la remise en ordre des conventions. Ce constat est frustrant, mais l’ignorer conduit invariablement à développer un traitement qui échoue sur les données réelles.

Un modèle de langage peut-il produire un métré fiable ?

Non, et cette limite est structurelle plutôt que temporaire. Un modèle de langage estime ce qui est plausible compte tenu de ce qu’il a appris ; il ne mesure pas et ne calcule pas au sens strict. Confronté à une demande de quantité, il produira une valeur qui ressemble à une quantité, parfois juste par coïncidence, sans qu’il soit possible de distinguer les deux cas à la lecture.

Un métré fiable s’obtient par extraction déterministe depuis la géométrie du modèle, suivie de l’application de règles de mesurage explicites et d’un rapport de couverture indiquant ce qui a été traité et ce qui a été écarté. En revanche, un modèle de langage peut utilement intervenir autour de ce calcul : expliquer un écart entre deux versions, rédiger la note méthodologique, aider à formuler une règle de mesurage ou faciliter l’interrogation des résultats. La distinction à tenir est celle entre produire une valeur et commenter une valeur produite par un calcul vérifiable.

Qu’est-ce que l’IDS et pourquoi change-t-il la pratique du contrôle qualité ?

L’IDS, ou Information Delivery Specification, est un format ouvert publié par buildingSMART permettant de décrire de manière lisible par une machine les exigences d’information d’un projet : quels objets doivent exister, quelles propriétés ils doivent porter, dans quels jeux et avec quelles valeurs admissibles. Sa version 1.0 a été approuvée comme standard final en juin 2024.

Son apport tient au fait qu’il fusionne le contrat et le test. Auparavant, une exigence d’information était rédigée dans un document textuel, interprétée différemment selon les intervenants, puis vérifiée manuellement ou par des configurations propres à chaque outil. Avec l’IDS, la même spécification sert de référence contractuelle et de fichier exécutable par un moteur de vérification. Un producteur peut contrôler son propre modèle avant transmission avec exactement la spécification qui servira à le vérifier en réception, ce qui déplace la conformité de la sanction vers la prévention.

L’IFC 4.3 est-il obligatoire aujourd’hui ?

L’IFC 4.3, publié comme norme internationale sous la référence ISO 16739-1:2024, n’est pas obligatoire en soi. Une norme technique ne devient contraignante que si un texte réglementaire ou un document contractuel l’impose. Ce qui rend son usage nécessaire, en pratique, ce sont les exigences des maîtres d’ouvrage, particulièrement dans la commande publique et dans les projets d’infrastructure.

Son intérêt technique est en revanche substantiel : l’extension du schéma aux ouvrages linéaires et aux infrastructures comble une lacune majeure des versions antérieures. Il faut cependant vérifier concrètement le niveau de prise en charge par les logiciels employés, car l’adoption d’un schéma normalisé par les éditeurs prend du temps et reste inégale selon les domaines et les fonctionnalités.

Comment éviter que les scripts deviennent ingérables avec le temps ?

En traitant comme un logiciel tout traitement qui dépasse l’usage individuel. Cela suppose cinq dispositions concrètes : désigner un propriétaire nommé responsable de l’évolution et de la correction ; séparer la logique du paramétrage, en plaçant conventions et tables de correspondance dans des fichiers de configuration éditables ; conserver le code dans un système de gestion de versions avec une version identifiable inscrite dans chaque rapport produit ; maintenir un jeu de test de référence exécuté après chaque modification et après chaque mise à jour du logiciel hôte ; rédiger une documentation d’usage courte précisant le périmètre, les prérequis et le mode d’interprétation du rapport.

À cela s’ajoute une mesure de gouvernance simple et rarement appliquée : tenir un inventaire des automatisations en service, avec leur responsable et leur date de dernière vérification. Une automatisation dont personne ne connaît le propriétaire est déjà un passif.

Le design génératif remplace-t-il l’architecte ?

Non, et l’examen du fonctionnement de ces systèmes montre pourquoi. Le design génératif évalue des variantes selon des critères mesurables, dans un espace de possibilités défini par des variables et des contraintes. Or ce sont précisément ces choix — quelles variables laisser libres, quelles contraintes poser, quels objectifs formaliser et comment les traduire en valeurs numériques — qui constituent l’acte de conception. Le système explore un espace que quelqu’un a construit.

Par ailleurs, une part importante de ce qui fait la qualité d’un projet ne se laisse pas réduire à des critères commensurables : l’insertion dans un contexte, la qualité d’usage perçue, la valeur symbolique, l’évolutivité à long terme, la cohérence culturelle. Le design génératif déplace le travail de l’architecte : moins de production de variantes, davantage de formulation du problème et d’arbitrage éclairé. C’est un changement de nature du métier, pas une substitution.

Combien de temps faut-il pour obtenir des résultats mesurables ?

Un premier résultat mesurable sur un périmètre bien choisi est atteignable en trois mois, à condition d’accepter une ambition limitée et de consacrer les premières semaines au cadrage plutôt qu’au développement. La séquence réaliste comprend environ trois semaines de cadrage et de mesure de la situation de référence, trois semaines de formalisation des règles, quatre semaines de développement et de tests, et trois semaines d’expérimentation encadrée sur un projet réel.

Le délai s’allonge considérablement dans deux situations. La première est celle où les données ne sont pas exploitables et où un travail de standardisation doit précéder toute automatisation : compter alors plusieurs mois supplémentaires, mais avec un bénéfice qui dépasse largement le traitement visé. La seconde est celle où le processus visé n’est pas stabilisé et fait l’objet de pratiques divergentes : automatiser un désaccord ne fait que le figer.

Faut-il un cadre de gouvernance de l’intelligence artificielle dans une structure AEC de taille moyenne ?

Oui, mais proportionné. Une structure de taille moyenne n’a pas besoin d’un dispositif formel comparable à celui d’un grand groupe. Elle a besoin de quatre éléments : une politique écrite indiquant quels usages sont autorisés, conditionnés ou interdits, notamment concernant l’envoi de données de projet vers des services externes ; un inventaire des traitements en service avec leur responsable ; une règle claire de vérification des sorties selon leur niveau de conséquence ; et une trace des validations sur les livrables engageants.

Le cadre publié par le NIST, organisé autour des fonctions Govern, Map, Measure et Manage, fournit une structure utile pour organiser cette réflexion sans imposer de formalisme excessif. Il s’agit d’un cadre volontaire, actuellement en cours de révision. Les organisations opérant dans l’Union européenne doivent par ailleurs suivre le calendrier d’application du règlement européen sur l’intelligence artificielle, dont les échéances ont fait l’objet d’ajustements législatifs et doivent être vérifiées auprès des sources officielles.

Références techniques et sources officielles

Sources consultées et vérifiées le 18 août 2026.

Normalisation internationale

• ISO 16739-1:2024, Industry Foundation Classes (IFC) for data sharing in the construction and facility management industries — Part 1: Data schema, deuxième édition publiée en mars 2024 — iso.org/standard/84123.html
• ISO 19650-1:2018, Concepts et principes, publiée le 7 décembre 2018, actuellement au stade de révision — iso.org/standard/68078.html
• ISO 19650-6:2025, Health and safety information, publiée en 2025 — iso.org/standard/82705.html
• EN 15978:2026, Sustainability of construction works — Assessment of environmental performance of buildings, publiée le 17 avril 2026 par le CEN (CEN/TC 350) — cencenelec.eu

buildingSMART International et openBIM

• Documentation officielle IFC 4.3.2.0 (IFC4X3_ADD2) — ifc43-docs.standards.buildingsmart.org
• Publication de référence IFC 4.3 — standards.buildingsmart.org/IFC/RELEASE/IFC4_3
• Information Delivery Specification (IDS), version 1.0.0 approuvée comme standard final le 3 juin 2024 — github.com/buildingSMART/IDS/releases
• Présentation générale de l’IDS — buildingsmart.org
• BIM Collaboration Format (BCF), spécifications fichier et service web — technical.buildingsmart.org/standards/bcf
• buildingSMART Data Dictionary (bSDD) — buildingsmart.org
• Service de validation IFC — buildingsmart.org

Gouvernance de l’intelligence artificielle

• NIST, AI Risk Management Framework (AI RMF 1.0), publié le 26 janvier 2023, fonctions Govern, Map, Measure, Manage — nist.gov/itl/ai-risk-management-framework
• NIST AI 600-1, Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile, publié le 26 juillet 2024 — nvlpubs.nist.gov
• Commission européenne, calendrier d’application du règlement sur l’intelligence artificielle — ai-act-service-desk.ec.europa.eu

Outils et plateformes (exemples représentatifs, sans classement)

• Autodesk, documentation de l’API Revit — aps.autodesk.com/developer/overview/revit-api
• Dynamo, manuel de référence — primer.dynamobim.org
• McNeel, documentation développeur Rhino et Grasshopper — developer.rhino3d.com
• Bentley Systems, plateforme iTwin — developer.bentley.com/itwinplatform
• Speckle, documentation officielle — docs.speckle.systems
• IfcOpenShell, bibliothèque libre de traitement IFC, et module IfcTester pour la vérification IDS — docs.ifcopenshell.org et docs.ifcopenshell.org/ifctester.html
• NVIDIA, ressources développeur OpenUSD — developer.nvidia.com/openusd