IFC Viewer Online · Retour au blog BIM & IFC
Livraison & ISO 19650 · 2026-11-13 · 7 min
Qui voit quelle maquette : séparer les données des fournisseurs dans un CDE de livraison
Un espace de livraison contient des maquettes de nombreuses entreprises qui ne doivent pas voir le travail des autres. Cinq questions à poser à tout CDE qui reçoit des maquettes, et les tests que nous avons menés sur le nôtre avant de le juger prêt.
Registre des livraisons d’un projet avec 16 entrées, le SHA-256 de chaque fichier et la chaîne recalculée dans le navigateur et trouvée intacte
L’espace de livraison d’une entreprise générale est un lieu particulier. Le bureau d’études structure, l’installateur des lots techniques et le façadier y livrent tous, et chacun est, sur un autre projet, le concurrent de l’autre. Ils doivent voir les exigences et leur propre travail. Ils ne doivent pas voir celui des autres.
L’ISO 19650-5 définit une approche de la gestion des informations sensibles sur les actifs bâtis axée sur la sécurité, que le projet utilise le BIM ou non. [iso-19650-5] Pas besoin d’appliquer toute la norme pour poser cinq questions simples à un CDE.
L’essentiel
- Qu’affiche un lien fournisseur, et que n’affiche-t-il pas ?
- Que peut faire chaque rôle de l’équipe destinataire, et qu’est-ce qui lui est refusé ?
- Une entreprise peut-elle jamais lire les données d’une autre ?
- Le fichier vérifié est-il bien le fichier livré ?
- Si quelqu’un modifie le registre après coup, cela se voit-il ?
1. Ce qu’affiche un lien fournisseur
Un lien fournisseur contient un jeton pour un seul fournisseur. Seul, il n’affiche rien. Avec le projet pour lequel il a été créé, il affiche les exigences de ce projet et les livraisons de ce fournisseur, jamais celles d’un autre.
Nous le disons franchement parce que nous nous sommes d’abord trompés : pendant la construction de la page de dépôt, nos tests ont montré que le jeton seul listait tous les projets de l’entreprise. Cela a été corrigé avant la fusion de la page, et un test le vérifie désormais à chaque exécution.
2. Ce que peut faire chaque rôle
Dans l’équipe de l’entreprise générale, il y a six rôles, du propriétaire à l’invité. Nos tests font tenter chaque écriture par chaque rôle et attendent exactement ce que le rôle permet. Quelques exemples de refus :
- Un réviseur peut voir les livraisons mais ne peut ni les accepter ni les renvoyer.
- Un invité ne voit pas du tout les livraisons.
- Un lecteur ne peut pas placer d’e-mail dans la file d’envoi.
- Seuls les propriétaires et les administrateurs peuvent modifier la bibliothèque de règles de l’entreprise.
Quand deux personnes modifient en même temps le même problème ou le même jeu de règles, la seconde reçoit la copie actuelle et un conflit, au lieu d’écraser en silence le travail de la première.
3. Une entreprise ne lit jamais une autre
Nos tests créent une seconde entreprise sur le même serveur et essaient, avec ses propres utilisateurs, de lire et d’écrire les livraisons, problèmes et règles de la première. Chaque tentative est refusée. Le test tourne avec les autres : un changement qui le casse ne passe pas inaperçu.
4. Le fichier vérifié est le fichier livré
Le navigateur du fournisseur calcule le SHA-256 du fichier et l’enregistre avant l’envoi. Le moteur de validation vérifie cette empreinte et l’en-tête IFC avant d’ouvrir quoi que ce soit : un fichier modifié en chemin, ou qui n’est pas un IFC, est renvoyé avant validation. La personne qui décide voit la même empreinte, et sa décision est scellée avec elle.
Test local de l’espace de travail sur notre propre serveur avec les maquettes de test Hotel Vela (vrais fichiers IFC), interface en espagnol. Pas encore ouvert.
5. Un registre qui montre toute modification
Chaque livraison et chaque décision est une ligne du registre, avec la date, l’auteur et l’empreinte, chaînée à la ligne précédente. « Vérifier la chaîne » recalcule chaque hash dans votre navigateur ; dans notre projet de test, les 16 entrées concordaient. Si quelqu’un modifie une ligne, la chaîne casse à cette ligne. Le UK BIM Framework décrit la revue et l’acceptation comme une étape de la partie qui reçoit l’information ; [uk-bim-part-c] ce registre est la preuve de chaque acceptation.
Test local de l’espace de travail sur notre propre serveur avec les maquettes de test Hotel Vela (vrais fichiers IFC), interface en espagnol. Pas encore ouvert.
Ce qui sort de l’espace de travail
- Les webhooks sont signés en HMAC-SHA256 : votre système peut vérifier qu’ils viennent de nous.
- Les e-mails vont dans une file et y attendent. Un contact qui n’a jamais donné son accord, ou qui s’est désinscrit, est refusé par la file elle-même.
- Les liens client ne stockent que le hash du jeton et du mot de passe, expirent, peuvent être révoqués et se bloquent après 10 tentatives échouées.
Ce qui n’est pas encore fait
- Elle tourne sur notre propre serveur en tests, pas encore comme service hébergé sous contrat.
- Il n’y a pas encore d’audit de sécurité externe.
Posez les mêmes questions à tout CDE
Ces cinq questions valent pour n’importe quel outil, le nôtre compris. Pour les questions que pose une DSI sur la visionneuse gratuite (où vont les fichiers, cookies, sous-traitants ultérieurs), voir la checklist de sécurité informatique des outils BIM. Pour tester Réception sur un vrai projet, parlons-en.
Qui voit quelle maquette : séparer les données des fournisseurs dans un CDE de livraison