On croit régler la sécurité avec un mot de passe et un pare-feu. C'est passer à côté du sujet. Une maquette concentre, en un seul endroit interrogeable, ce qu'il faut savoir pour nuire à un ouvrage : où passent les réseaux critiques, comment neutraliser une protection, où sont les zones sensibles. La partie 5 de la série, publiée en 2020, traite cette information-là, de façon proportionnée, sur tout le cycle de vie.
La sécurité, dans un projet BIM, est traitée de deux façons également insuffisantes : on la confie à l’informatique, ou on l’ignore. Les deux reposent sur la même erreur, croire que la sécurité est une affaire de technique.
Un serveur parfaitement protégé ne sert à rien si les droits d’accès laissent voir à tout le monde ce que seuls quelques-uns devraient voir. Le pare-feu le plus solide n’empêche pas un sous-traitant de repartir avec une copie de la maquette. La sécurité ne se joue pas seulement dans les tuyaux informatiques, elle se joue dans la gestion de l’information elle-même : qui la crée, qui y accède, ce qu’on en partage, ce qu’on en garde, tout au long de la vie de l’ouvrage.
La partie 5 de la série ISO 19650, publiée en 2020, pose cette approche dite security-minded. Elle part d’un constat que le BIM rend aigu : en concentrant toute l’information d’un ouvrage dans un modèle unique et interrogeable, on crée une cible qui n’existait pas quand cette information était éparpillée dans des centaines de documents. Le pendant du volet sécurité-santé de la partie 6, appliqué cette fois à la sécurité de l’information sensible.
L’agrégation. Des informations anodines prises séparément, un plan de réseau, l’emplacement d’un local technique, un horaire de maintenance, peuvent, une fois réunies dans un même modèle, dessiner exactement ce qu’il faut savoir pour porter atteinte à un ouvrage. La force du BIM, tout réunir en un endroit, est précisément ce qui fait le risque. Sécuriser chaque pièce ne suffit pas si leur assemblage, lui, n’est protégé par personne.
La partie 5 ne commence pas par des mesures, elle commence par une question. La plupart des projets n’ont pas besoin d’une approche de sécurité, et l’imposer partout serait aussi absurde que de l’ignorer là où elle est vitale.
Le premier geste est une évaluation de sensibilité : déterminer si l’ouvrage, ou l’information qui le concerne, justifie une approche sécurisée. Un immeuble de logements ordinaire n’en a probablement pas besoin. Un hôpital, un palais de justice, un centre de données, une installation d’énergie, un ouvrage militaire, oui, sans hésiter. Entre les deux, il faut trancher au cas par cas, plutôt que d’appliquer un réflexe uniforme.
Comme pour les exigences d’un marché, le principe qui gouverne tout est la proportionnalité : la protection doit répondre à un risque réel, ni plus, ni moins. Trop de sécurité étouffe un projet qui n’en avait pas besoin ; trop peu expose un ouvrage qui en exigeait. L’évaluation de sensibilité existe précisément pour placer le curseur au bon endroit, et pour le justifier. Ne pas la faire, c’est décider au hasard, dans un sens comme dans l’autre.
Lorsque l’évaluation conclut qu’une approche sécurisée est nécessaire, la partie 5 organise cette approche autour de quelques piliers, appliqués tout au long du processus et non ajoutés à la fin.
Décider quelle information est sensible, qui peut y accéder, et sous quelles conditions. C’est le cadre, écrit en amont, dont tout le reste découle. Il rejoint les exigences d’information du projet.
Traduire la stratégie en droits d’accès réels dans l’environnement commun, en règles de partage et de diffusion. C’est là que la sécurité vit ou meurt, dans les droits du CDE tenus à jour.
Prévoir ce qu’on fait quand une information fuit, plutôt que de l’improviser le jour venu. Une brèche anticipée se contient ; une brèche découverte sans plan se propage.
Étendre l’exigence à tous les intervenants, sous-traitants compris. Une chaîne n’est sécurisée qu’au niveau de son maillon le plus faible, et ce maillon est souvent le plus petit prestataire.
La sécurité suit l’information partout où elle va, y compris hors du projet. Le sous-traitant qui garde une copie de la maquette après sa mission, la donnée sensible versée dans le modèle d’exploitation et consultée par un mainteneur externe, l’archive conservée des années : chacun est un point de fuite. Une stratégie qui ne protège que le serveur central, en ignorant ce qui en sort, protège la porte d’entrée et laisse les fenêtres ouvertes.
Il faut le dire franchement : la sécurité de l’information contredit l’esprit même du BIM. Tout le reste de la série pousse à partager plus, plus tôt, plus largement. La partie 5 pousse, elle, à restreindre. Cette tension ne se résout pas, elle s’arbitre.
Le BIM tire sa valeur du partage : plus l’information circule, mieux les intervenants coordonnent, décident, exploitent. La sécurité fait exactement l’inverse : elle cloisonne, restreint les accès, ralentit la diffusion. Un projet trop sécurisé perd une partie de ce qui faisait l’intérêt du BIM, et retombe dans le travail en silos qu’il cherchait à quitter.
Il n’existe pas de solution qui donne les deux à fond. Il existe un arbitrage, projet par projet : partager par défaut, restreindre par exception, et seulement là où la sensibilité le justifie vraiment. C’est le même curseur que dans openBIM contre closed BIM, où la question du contrôle de l’information se pose déjà, mais tranché ici sous l’angle du risque plutôt que de la dépendance.
Deux excès se répondent. Le premier ouvre tout par confort et expose l’ouvrage sensible. Le second verrouille tout par précaution et tue la collaboration sur un projet qui ne le justifiait pas. La partie 5 n’appelle ni à l’un ni à l’autre : elle appelle à décider en connaissance de cause, sur la base d’une évaluation, plutôt qu’à céder à l’un des deux réflexes.
Une norme pour une minorité de projets, mais vitale pour ceux-là, et qui commence toujours par se demander si elle s’applique.
Trois idées à emporter. La sécurité de l’information n’est pas de l’informatique : elle se joue dans la gestion de l’information elle-même, les accès, le partage, l’agrégation, tout au long du cycle de vie, et un serveur protégé aux droits mal réglés ne protège rien. Elle commence par une évaluation de sensibilité : la plupart des projets n’en ont pas besoin, certains absolument, et le principe est la proportionnalité, ni trop ni trop peu. Enfin, elle contredit l’esprit de partage du BIM : cette tension ne se résout pas, elle s’arbitre, en partageant par défaut et en restreignant seulement là où le risque le justifie.
Cette partie complète la série ISO 19650, aux côtés du volet sécurité-santé de la partie 6. Elle se concrétise surtout dans les états et les droits du CDE, où les accès sont réellement tenus, et s’exprime en amont dans les exigences de l’EIR. Le même arbitrage entre ouverture et contrôle, sous un autre angle, est celui d’openBIM contre closed BIM. Pour le cas le plus quotidien de cette sécurité, savoir où part un modèle quand on l’ouvre dans une visionneuse, voyez six visionneuses IFC comparées.
Les guides qui prolongent naturellement celui-ci, dans d'autres sections du site.
La norme dont tout le monde parle, expliquée sans jargon : qui demande quoi, qui livre quoi, et comment l'information est validée avant d'être partagée. Après ce guide, l'ISO 19650 ne vous impressionnera plus.
Créer quatre répertoires et y ranger des fichiers ne fait pas un CDE. Un état ne dit pas où se trouve une information : il dit ce que vous avez le droit d'en faire, et qui répond si elle est fausse. Toute la valeur est dans les passages de l'un à l'autre.
On présente le débat comme un choix technique entre formats. C'est un écran de fumée. La question réelle est : qui contrôlera votre information dans vingt ans ? Et sa réponse honnête n'est presque jamais « tout l'un » ou « tout l'autre », mais « où placer la frontière entre les deux ».