Quand un projet parle de sécurité des données BIM, la discussion se résume encore trop souvent à trois sujets : mettre un mot de passe sur le CDE, activer l’authentification multifacteur et limiter les droits des utilisateurs. Ces mesures sont utiles, mais elles arrivent trop tard si personne n’a d’abord déterminé quelles informations sont sensibles, pourquoi elles le sont et qui a réellement besoin d’y accéder.
Le BIM augmente mécaniquement la capacité à agréger des informations. Un plan architectural seul peut être relativement banal. Le même plan combiné avec les réseaux électriques, les systèmes de sûreté, les accès contrôlés, les chemins de maintenance, les équipements techniques et des données d’exploitation peut devenir beaucoup plus sensible. La question n’est donc pas seulement de protéger des fichiers : il faut gérer le risque associé à l’information et à ses usages.
ISO 19650-5 : une approche de la sécurité centrée sur l’information
ISO 19650-5:2020 est la partie de la série ISO 19650 consacrée à une approche du management de l’information axée sur la sécurité. La norme est toujours en vigueur en septembre 2026 et a été confirmée à l’issue de sa revue systématique en 2025.
Son périmètre est plus large que la cybersécurité informatique. Elle vise la gestion des informations sensibles obtenues, créées, traitées ou stockées dans le cadre d’un projet, d’un actif, d’un produit ou d’un service. Elle insiste également sur la culture de sécurité, les responsabilités, la surveillance et l’audit de la conformité.
Cette approche est complémentaire de normes plus générales comme ISO/IEC 27001:2022, qui définit les exigences d’un système de management de la sécurité de l’information à l’échelle d’une organisation. ISO 19650-5 est particulièrement intéressante pour le BIM parce qu’elle replace la sécurité dans le cycle de vie de l’actif et dans les processus de partage de l’information.
Qu’est-ce qu’une information BIM sensible ?
La réponse dépend du contexte. Un fichier n’est pas sensible uniquement parce qu’il porte l’étiquette « BIM ». Il le devient lorsque sa divulgation, sa modification, sa perte ou son utilisation abusive peut créer un risque significatif pour des personnes, un actif, un service, une organisation ou sa propriété intellectuelle.
Sur un projet courant, certaines données peuvent relever surtout de la confidentialité commerciale : prix, méthodes constructives, études internes, propriété intellectuelle ou informations contractuelles. Sur d’autres actifs, les enjeux peuvent être beaucoup plus importants : localisation d’équipements critiques, architecture des systèmes de contrôle, dispositifs de sûreté, structure détaillée, réseaux enterrés, accès techniques, locaux sensibles ou informations permettant de comprendre le fonctionnement d’un site.
Les guides de la National Protective Security Authority britannique rappellent que des éléments apparemment ordinaires peuvent devenir sensibles lorsqu’ils sont combinés. Une structure, une porte, un système de contrôle d’accès ou un réseau technique n’ont pas la même criticité selon l’actif, son usage et la menace considérée.
Commencer par une évaluation de sensibilité
L’erreur classique consiste à définir les droits d’accès directement dans l’outil avant d’avoir évalué le besoin. Une démarche plus robuste commence par un tri : quelles informations manipulons-nous, quelles conséquences aurait leur divulgation ou leur altération, quelles parties prenantes ont besoin d’y accéder et pendant combien de temps ?
Cette évaluation doit rester proportionnée. Un immeuble tertiaire standard n’a pas nécessairement besoin du même dispositif qu’un site industriel critique, un ouvrage stratégique ou une infrastructure de transport sensible. À l’inverse, considérer qu’un projet « n’est pas secret » ne dispense pas de protéger les données personnelles, commerciales ou la propriété intellectuelle.
Le résultat attendu n’est pas un classement compliqué de toutes les familles Revit. Il s’agit d’obtenir une vision exploitable des informations qui nécessitent une protection particulière et des mesures associées.
Menace, vulnérabilité et risque : ne pas confondre les termes
La sécurité est plus facile à piloter lorsque l’on distingue trois notions. La menace représente ce qui pourrait provoquer un dommage : acteur malveillant, erreur humaine, compte compromis, perte d’un équipement ou partage involontaire. La vulnérabilité est une faiblesse exploitable : lien public sans expiration, compte d’un ancien prestataire toujours actif, droits trop larges ou absence de sauvegarde. Le risque combine la possibilité qu’un scénario se produise et l’impact qui en résulterait.
Cette lecture permet d’éviter les mesures génériques. Si le risque principal est la diffusion d’un plan sensible par un lien externe, acheter un outil supplémentaire de clash detection ne change rien. Si le risque est l’altération silencieuse d’un fichier critique, la priorité porte davantage sur les droits d’écriture, les versions, les validations, les journaux et les sauvegardes.
Le CDE est un point de contrôle majeur
Le CDE concentre une grande partie des échanges du projet. Il devient donc un élément central de la sécurité de l’information, mais seulement si sa configuration traduit réellement les responsabilités du projet.
Les droits devraient suivre le principe du besoin d’en connaître : un utilisateur accède aux informations nécessaires à son rôle, pas à l’intégralité du projet par défaut. Cette logique doit être appliquée aux dossiers, aux espaces de travail, aux workflows d’approbation, aux téléchargements, aux partages externes et aux API.
Sur un projet long, la difficulté n’est pas la configuration initiale. Elle est dans la maintenance des accès. Les équipes changent, les sous-traitants interviennent ponctuellement, des consultants quittent le projet et certains comptes de service restent actifs. Un processus d’arrivée, de modification de rôle et de sortie des utilisateurs est donc aussi important que l’authentification elle-même.
Dans la pratique, je recommande de contrôler au minimum les comptes nominatifs, l’authentification forte lorsque la plateforme le permet, les droits par rôle, les liens externes, les dates d’expiration, les journaux d’activité, les versions et la suppression des accès en fin de mission.
WIP, Shared et Published ne sont pas des niveaux de confidentialité
Les états du CDE issus de la logique ISO 19650 servent à gérer le statut d’une information dans son workflow : travail en cours, partage, publication et archivage. Ils ne doivent pas être confondus avec une classification de sécurité.
Une information en WIP peut être très sensible. Une information Published peut également rester réservée à un cercle défini. Le statut de maturité et le niveau de sensibilité répondent à deux questions différentes : cette information est-elle autorisée pour cet usage ? et qui est autorisé à la consulter ?
Les deux dimensions doivent donc être pensées ensemble dans l’architecture du CDE.
IFC et BCF : ouverts ne veut pas dire publics
L’openBIM améliore l’interopérabilité, mais le terme « open » ne signifie pas que les informations doivent être librement accessibles. Un fichier IFC peut contenir une géométrie détaillée, des propriétés techniques, une structure spatiale, des systèmes, des coordonnées, des classifications et des relations entre objets. Selon le projet, tout ou partie de ces données peut nécessiter une protection.
Le BCF peut lui aussi transporter des informations sensibles. Une issue peut inclure un titre explicite, une description, un point de vue, un snapshot, une position de caméra et des références à des composants IFC. Une simple capture de coordination peut donc révéler la localisation ou la configuration d’un élément que l’on ne souhaite pas diffuser largement.
La bonne pratique n’est pas d’abandonner IFC ou BCF, mais de gérer leur diffusion comme celle de n’importe quel autre conteneur d’information : destinataires, droits, version, durée d’accès, contexte et traçabilité.
Le risque d’agrégation est spécifique aux environnements BIM
Un des sujets les plus sous-estimés est l’agrégation. Plusieurs informations peu sensibles prises séparément peuvent créer un ensemble beaucoup plus exploitable lorsqu’elles sont fédérées.
Un exemple simple : une maquette architecture montre les locaux ; la maquette CVC montre les gaines ; le modèle électricité montre les alimentations ; un modèle sûreté montre les caméras et contrôles d’accès ; un fichier de maintenance indique la criticité des équipements. La fédération de ces informations offre une compréhension opérationnelle du site bien supérieure à chacune des sources prises individuellement.
C’est pour cette raison que la sécurité doit être évaluée au niveau du système d’information global, pas uniquement fichier par fichier.
Revit, copies locales et exports : les angles morts
Sur les projets Revit, une partie importante du risque se situe en dehors du CDE. Les utilisateurs travaillent avec des caches, copies locales, exports DWG, IFC, NWC, Excel, PDF et parfois des extractions automatisées. Il faut donc éviter de croire qu’une politique de droits dans la plateforme cloud suffit à contrôler toutes les copies existantes.
Les workflows d’extraction de données méritent la même attention. Un export Excel ou Power BI peut contenir des milliers de propriétés issues des modèles. Une automatisation Python ou Dynamo peut dupliquer ces données dans un dossier temporaire, une base ou un service tiers. Avant d’automatiser un flux, il faut savoir où les données transitent, où elles sont stockées et qui peut y accéder.
Les plugins constituent également une surface à prendre en compte. Installer un add-in non maîtrisé dans un environnement de production peut lui donner accès aux informations ouvertes dans Revit. La sécurité de la chaîne logicielle fait donc partie du sujet, même si elle dépasse le périmètre strict de la convention BIM.
Choisir une plateforme cloud : regarder au-delà de la fiche commerciale
Pour une plateforme CDE ou un viewer IFC en ligne, les fonctions visibles dans l’interface ne suffisent pas. Il faut aussi comprendre les conditions d’hébergement, les mécanismes d’authentification, la gestion des rôles, les journaux disponibles, les sauvegardes, la réversibilité, les API, la localisation éventuelle des données et les engagements contractuels du fournisseur.
La certification ISO/IEC 27001 d’un fournisseur peut être un signal utile, mais elle ne remplace pas l’analyse du périmètre réellement certifié ni la configuration du projet. Une plateforme solide peut être mal configurée ; inversement, une bonne procédure ne compense pas une infrastructure techniquement fragile.
Préparer l’incident avant qu’il n’arrive
Une politique de sécurité incomplète décrit uniquement comment éviter un incident. Une politique mature prévoit également comment réagir : qui alerter, comment isoler un compte, comment identifier les informations exposées, comment conserver les traces, comment restaurer une version saine et comment informer les parties concernées.
Dans un contexte BIM, les incidents ne sont pas uniquement des cyberattaques spectaculaires. Ils peuvent être beaucoup plus ordinaires : un lien partagé au mauvais destinataire, un modèle téléchargé sur un ordinateur personnel, une maquette supprimée, un compte d’ancien collaborateur encore actif ou un export transmis sans les restrictions prévues.
Un processus simple, connu de l’équipe et testé occasionnellement est souvent plus utile qu’une procédure de cinquante pages que personne ne consulte.
Ce que je contrôle sur un projet
Lors d’un audit BIM orienté sécurité, je commence par cartographier les conteneurs d’information et les flux : modèles natifs, IFC, BCF, documents, exports, bases, dashboards et plateformes. Je regarde ensuite les responsabilités, les accès et les destinations plutôt que de me concentrer uniquement sur le paramétrage d’un logiciel.
Les contrôles les plus utiles sont souvent très concrets : identifier les utilisateurs inactifs, vérifier les partages publics, rechercher les comptes génériques, contrôler la cohérence des droits entre dossiers, vérifier les sauvegardes et la récupération, documenter les outils tiers, tester l’offboarding d’un prestataire et examiner les exports contenant des informations sensibles.
Le niveau de détail dépend ensuite de la sensibilité de l’actif.
- Identifier les informations réellement sensibles et les risques associés.
- Définir un responsable et des règles de gouvernance.
- Limiter les accès selon les rôles et les besoins.
- Contrôler les partages externes, comptes temporaires et liens publics.
- Gérer les copies locales, exports et données extraites.
- Appliquer la même vigilance à IFC, BCF, Excel et aux API.
- Prévoir l’arrivée et le départ des intervenants.
- Conserver versions, journaux et mécanismes de restauration adaptés.
- Préparer une procédure d’incident.
- Réévaluer les risques lorsque le projet, l’actif ou les usages évoluent.
Sécuriser sans casser le BIM
Le risque inverse existe : transformer la sécurité en système tellement contraignant que les équipes recréent des circuits parallèles par email, messagerie instantanée ou stockage personnel. Le résultat est alors moins sûr qu’au départ.
ISO 19650-5 insiste sur une approche appropriée et proportionnée. La sécurité doit préserver les bénéfices de la collaboration numérique. Un bon dispositif donne aux équipes un chemin simple et officiel pour partager l’information autorisée, tout en renforçant les contrôles là où l’impact potentiel le justifie.
Pour moi, c’est le bon équilibre : ne jamais banaliser la sécurité d’une maquette numérique, mais ne jamais appliquer non plus des restrictions sans rapport avec le risque réel.
La sécurité BIM est un sujet de management de l’information
La sécurité des données BIM ne se résume ni à la cybersécurité ni au choix d’un CDE. Elle commence par la compréhension de l’information, de sa sensibilité, de ses usages et de ses flux. Elle continue avec les responsabilités, les droits, les contrôles et la capacité à réagir lorsqu’un incident survient.
Cette approche rejoint finalement le principe général du management de l’information BIM : une donnée utile doit avoir un usage, un propriétaire, un état maîtrisé et un niveau de confiance adapté. La sécurité ajoute une question indispensable : quelles seraient les conséquences si cette donnée était vue, modifiée ou perdue par la mauvaise personne ?
Contrôler la donnée sans multiplier les manipulations
Les outils PMB Revit et IFC sont conçus pour faciliter les contrôles et l’analyse des données BIM. Dans un workflow sécurisé, ces contrôles doivent rester intégrés à une gouvernance claire des accès, exports et livrables.