Beaucoup d'équipes marocaines possèdent aujourd'hui une maquette BIM et une carte urbaine en trois dimensions. Presque aucune ne peut répondre à cette question simple : quand un mur change dans le modèle, qui met à jour la ville, dans quel délai, et sous quelle responsabilité ? Tant que cette réponse n'est pas écrite, la chaîne bâtiment–ville reste une collection de fichiers.

Deux standards, deux échelles, aucun recouvrement automatique

IFC, la norme d'échange maintenue par buildingSMART, décrit les objets d'un bâtiment : murs, réseaux, équipements, systèmes. CityGML, porté par l'Open Geospatial Consortium, décrit les objets de la ville en trois dimensions : parcelles, bâti, végétation, relief, mobilier. Les deux modèles ne couvrent ni les mêmes entités ni les mêmes échelles, et ils n'ont jamais été conçus pour se substituer l'un à l'autre.

Les travaux de buildingSMART l'illustrent mieux qu'un discours. Le cas d'usage consacré au permis de construire numérique et la démarche openBIM appliquée au facility management décrivent tous deux une séquence, pas un format : exigences, modèles, vérification, transfert, exploitation, mise à jour. La valeur naît de la continuité de cette séquence. Constat arrêté par la veille NEXUS le 27 juillet 2026.

Il faut aussi dire ce que ces deux standards ne portent pas. Ils ne décrivent ni les coûts, ni les contrats, ni l'occupation réelle, ni les données de comptage. Un projet qui espère répondre à une question financière ou juridique en ouvrant une maquette se trompe d'outil : ces informations vivent dans des systèmes de gestion, et leur rapprochement avec le modèle passe par un identifiant, pas par un import.

Autrement dit, l'interopérabilité n'est pas un problème de convertisseur. C'est un problème de contrat entre étapes. Chaque passage de main doit préciser ce qui est transmis, avec quel niveau de complétude, pour quel usage aval, et qui répond en cas d'erreur.

Le permis numérique, premier cas d'usage qui force la discipline

Un permis est un excellent point de départ parce qu'il impose une décision. L'instructeur doit vérifier des règles sur un objet réel, à une date donnée, et sa réponse engage la collectivité. Cette contrainte élimine les modèles décoratifs.

Concrètement, un dossier de permis interopérable exige trois choses. La géométrie doit être exploitable par un contrôle automatisé, ce qui suppose un modèle propre et non un nuage de surfaces. Les attributs vérifiés doivent être nommés à l'identique côté déposant et côté instructeur. Enfin la version déposée doit être figée et horodatée, faute de quoi l'instruction porte sur un objet qui a déjà changé.

Une précaution s'impose toutefois avant d'automatiser quoi que ce soit. Une partie des règles d'urbanisme n'est pas formulée de manière calculable : elle renvoie à une appréciation, à un contexte, à un avis. Prétendre les vérifier automatiquement conduit à des refus injustifiés ou à des accords indus. La démarche solide consiste à isoler le sous-ensemble de règles réellement calculables, à le publier, et à laisser le reste à l'instruction humaine. Un instructeur qui sait exactement ce que la machine a vérifié travaille plus vite ; un instructeur qui doit deviner ce qu'elle a laissé passer travaille plus lentement qu'avant.

Le second cas d'usage, la maintenance, obéit à une logique inverse. Il ne demande pas la richesse du modèle de conception mais sa réduction : l'exploitant veut les équipements, leurs références, leurs emplacements et leurs échéances, pas la totalité des couches structurelles. Une chaîne qui ne sait pas appauvrir le modèle au bon moment produit des fichiers que personne n'ouvre.

Identifiants, niveaux d'information, versions : la couche que personne ne finance

Le point de rupture le plus fréquent n'est ni IFC ni CityGML. C'est l'absence de convention d'identifiants partagée entre l'objet de conception, l'objet livré, l'objet urbain et l'objet de gestion patrimoniale. Sans identifiant commun, chaque outil recrée sa propre clé, et la mise à jour devient un travail de rapprochement manuel qui coûte plus cher que la modélisation initiale.

Deux autres règles doivent être écrites avant le premier fichier. Le niveau d'information attendu, défini par usage et non par phase : ce qu'il faut savoir pour instruire un permis n'est pas ce qu'il faut savoir pour planifier un remplacement de centrale de traitement d'air. Et la politique de versions : qui a le droit de publier une version de référence, à quelle fréquence, et comment on retrouve l'état du modèle à une date passée.

Le règlement européen 2024/3110 sur les produits de construction ajoute une pression utile sur cette couche, en poussant vers des données produit structurées et disponibles. Une donnée produit fiable n'a de valeur que si elle s'accroche à un identifiant d'objet stable dans le temps.

Cette couche a un coût, et elle n'a presque jamais de ligne budgétaire. Elle ne produit ni image, ni plan, ni livrable visible en réunion : elle produit de la cohérence, c'est-à-dire quelque chose qui ne se remarque que lorsqu'elle manque. Les organisations qui progressent sont celles qui la financent comme une fonction permanente, avec une personne nommée, plutôt que comme une prestation ponctuelle rattachée à une opération. Un référentiel d'identifiants abandonné après la livraison redevient inutilisable en deux ou trois ans.

Pour la partie exploitation temps réel, un troisième langage entre en jeu. NGSI-LD, spécifié par l'ETSI, organise l'échange d'informations de contexte entre systèmes : capteurs, équipements, services urbains. Il ne remplace ni IFC ni CityGML, il connecte l'état courant à la description de l'actif.

Pourquoi la conversion automatique BIM vers SIG reste une promesse dangereuse

Vendre une transformation universelle et sans perte entre modèle de bâtiment et modèle urbain revient à vendre une erreur silencieuse. La géométrie se simplifie, la sémantique se réinterprète, les attributs se perdent, et le résultat conserve une apparence correcte. C'est le pire scénario : une donnée fausse mais présentable.

La méthode défendable consiste à définir des règles de transformation explicites, cas d'usage par cas d'usage, et à les tester sur un jeu d'échange documenté. On accepte alors une perte connue plutôt qu'une perte ignorée. Ce test d'échange doit être rejoué à chaque montée de version d'un logiciel de la chaîne, sinon la conformité constatée hier ne prouve rien aujourd'hui.

Le transfert vers l'exploitation, moment exact où la chaîne casse

Sur la plupart des opérations, le modèle meurt à la réception. L'entreprise remet un livrable, l'exploitant reçoit des fichiers qu'il ne peut pas mettre à jour, et six mois plus tard la réalité du bâtiment a divergé du modèle. Personne n'a menti, personne n'a été désigné.

Trois clauses évitent cette mort programmée. Nommer, avant le démarrage des travaux, la personne responsable de la mise à jour après livraison, dans l'organisation de l'exploitant. Prévoir un mode dégradé : que fait l'équipe si la plateforme est indisponible, si le prestataire disparaît, si le format n'est plus lu ? Garantir la réversibilité, c'est-à-dire la capacité d'extraire l'ensemble des données dans un format ouvert sans négociation commerciale.

Le troisième cas d'usage, la résilience, justifie à lui seul l'effort de raccordement entre les deux échelles. Évaluer l'exposition d'un actif à une inondation, à une surchauffe ou à une coupure suppose de croiser la description du bâtiment — altitude du premier niveau, position des locaux techniques, nature des façades — avec la description du territoire : relief, réseaux, voisinage, occupation du sol. Aucun des deux modèles ne suffit seul, et l'analyse perd toute valeur si les deux ne sont pas datés du même moment. C'est le cas d'usage qui intéresse le plus directement les assureurs et les prêteurs.

La propriété des données mérite le même soin. Un exploitant qui ne détient pas ses données de patrimoine ne peut ni remettre son marché en concurrence, ni valoriser son actif, ni répondre à une collectivité. Au Maroc, cette question se double d'une contrainte de conformité dès qu'apparaissent des données rattachables à des personnes, sous le régime contrôlé par la CNDP.

Ce que cela change pour un maître d'ouvrage, un exploitant ou une collectivité

Pour les promoteurs, maîtres d'ouvrage, architectes, ingénieurs, exploitants, banques et territoires, la bonne entrée n'est pas un plan de déploiement BIM à l'échelle de l'organisation. C'est un périmètre restreint et une décision à améliorer : réduire le délai d'instruction d'un permis, ou fiabiliser la programmation des remplacements d'équipements sur un actif existant.

Les arbitrages à poser sont matériels. Le coût de structuration se paie en phase amont, alors que le gain apparaît en exploitation, souvent dans un autre budget et parfois dans une autre entité. Les compétences manquent : un coordinateur de données capable de tenir une convention d'identifiants est plus rare qu'un modeleur. Le délai est contraint par les marchés en cours, car une convention imposée en cours d'exécution se négocie mal. Enfin la dépendance à un éditeur se décide au moment du choix de plateforme, pas au moment du renouvellement.

Le levier le plus rapide reste la commande publique et privée. Une clause de trois paragraphes suffit à changer la pratique : elle nomme les formats d'échange attendus, exige la remise d'un jeu de données dans un format ouvert à la réception, et conditionne le paiement du dernier acompte à la réussite d'un test d'échange conduit par l'exploitant. Une organisation qui écrit cette clause obtient, dès l'opération suivante, ce qu'une charte interne n'obtient jamais.

Cinq indicateurs suffisent à savoir si la chaîne produit un effet. Le coût complet de l'actif sur sa durée de vie, base de référence sans laquelle aucune économie n'est démontrable. La qualité de service perçue par les occupants, mesurée avant et après. L'accessibilité, y compris celle des données pour les agents qui en ont besoin. Les consommations réelles, relevées et non estimées. Enfin la résilience et la maintenance, c'est-à-dire le délai de remise en service après incident. Chacun de ces indicateurs doit avoir une ligne de base, une fréquence et un propriétaire nommé.

L'enchaînement raisonnable tient en quatre gestes : choisir le cas d'usage, écrire la convention d'identifiants et de niveaux d'information, exécuter un test d'échange documenté sur un actif réel, puis décider à date fixe si l'on généralise. Une organisation qui saute la troisième étape découvrira ses pertes de données en production.

Un atelier de travail, pas une plénière

Ce sujet ne se traite pas sur une scène. Il se traite avec un cas, des fichiers et des personnes qui ont le droit de signer une convention. C'est pourquoi le format retenu côté NEXUS Living est l'atelier fermé, adossé au programme de conférences de l'édition, qui comptera plus de 60 conférences à Tanger, du 11 au 15 novembre 2026.

Le prolongement naturel se trouve dans deux autres univers. Le Summit accueille la discussion sur les jumeaux numériques territoriaux, là où se décide le financement de la couche de données. NEXUS Tech traite la partie plateforme, gouvernance et exploitation des flux. Une chaîne bâtiment–ville qui n'a de correspondant dans aucun de ces deux endroits restera un projet de bureau d'études.

Sources

• CityGML, Open Geospatial Consortium
• Industry Foundation Classes (IFC), buildingSMART
• NGSI-LD, ETSI Context Information Management
• Cas d'usage buildingSMART — permis de construire numérique
• Facility management et openBIM, buildingSMART
• Règlement (UE) 2024/3110 sur les produits de construction

Participer au workshop BIM & Construction 4.0