Retour au blog BIM & IFC
Confidentialité & sécurité · 2026-06-28 · 19 min
Validation IFC dans le navigateur ou dans le cloud : la décision d'architecture où les équipes BIM se trompent le plus souvent
Validation IFC hors ligne grâce à WebAssembly : rien n'est envoyé, ça fonctionne sur le chantier. Navigateur ou cloud : confidentialité, RGPD, vitesse d'envoi, usage hors ligne, et quand chaque architecture l'emporte.
Validation IFC dans le navigateur ou dans le cloud : la décision d'architecture où les équipes BIM se trompent le plus souvent — IFC Viewer Online article cover
- 0 octets — envoyé lors d'une validation navigateur
- 40 s — pour envoyer 50 Mo à 10 Mbit/s
- 44 — règles vérifiées côté client
- 10× — chargements répétés plus rapides grâce au cache OPFS
Quand un coordinateur BIM demande « où puis-je valider mon fichier IFC ? », la réponse qu'on lui donne le plus souvent est une URL. Un service cloud. Envoyer la maquette, attendre, récupérer le rapport. C'est devenu le réflexe par défaut pour la validation IFC — et c'est le mauvais choix pour une part importante des projets où on l'applique.
Il existe deux architectures fondamentalement différentes pour la validation IFC. Comprendre cette différence — et savoir laquelle convient à quel projet — devient une compétence professionnelle à part entière pour les BIM managers et les équipes de construction numérique. L'architecture choisie détermine à elle seule la confidentialité, la vitesse, la conformité réglementaire et la disponibilité hors ligne.
Deux architectures complètement différentes
Cette distinction n'est pas un détail de produit. C'est une question de lieu où s'exécute le calcul — et cela détermine tout le reste.
ARCHITECTURE A — Cloud Validation
══════════════════════════════════
Your Machine Internet Cloud Server
──────────── ──────── ────────────
① Open IFC file
│
│ ② UPLOAD ──────────────────────────────► Server receives file
│ 50 MB → ~40 s at 10 Mbps │
│ 250 MB → ~3 min at 10 Mbps ③ Server parses IFC
│ 1 GB → ~13 min at 10 Mbps │
│ ④ Validation runs
│ │
│ ⑤ RESULTS ◄───────────────────────────────────────┘
│
⑥ View report
Data custody: Your machine → Transit (TLS) → Third-party server
ARCHITECTURE B — Browser-Based Validation
══════════════════════════════════════════
Your Machine Internet
──────────── ────────
① Open IFC file
│
② WASM binary loads (Nothing uploaded.
│ Nothing leaves the device.
③ Web Worker: IFC parsing Ever.)
│
④ 44 validation rules run
│
⑤ Health Score calculated
│
⑥ WebGL renders 3D model
│
⑦ Results: instant, local
OPFS cache: parsed geometry persists → repeat load ~10× faster
Data custody: Your machine only
Dans l'architecture A, le fichier IFC est traité par une infrastructure que vous ne contrôlez pas. Il traverse un réseau, réside sur un serveur tiers et passe entre les mains d'un logiciel que vous n'avez pas déployé. Dans l'architecture B, la même logique de validation s'exécute dans votre navigateur grâce à WebAssembly, compilé à partir du même code C++ qui fait tourner les outils BIM natifs de bureau — rien ne quitte l'appareil, et aucun tiers n'intervient dans le traitement.
Pourquoi les maquettes IFC contiennent des informations sensibles
Le réflexe de traiter les fichiers IFC comme des PDF — partageables, envoyables, archivables n'importe où — sous-estime ce qui est contenu dans une maquette de bâtiment complexe. Un fichier IFC est une base de données structurée d'informations sur les actifs. Pour de nombreux types de projets, ces informations sont réellement sensibles, restreintes ou classifiées.
Bâtiments publics et infrastructures civiques
Tribunaux, administrations, data centers, réseaux critiques. Données de vulnérabilité structurelle, plans des systèmes de secours et schémas des infrastructures de sécurité, intégrés dans la géométrie et les propriétés IFC.
Aéroports et pôles de transport
Géométrie des postes de contrôle de sécurité, tracés des limites côté piste, emplacement de la vidéosurveillance et des capteurs, cheminement des systèmes de secours. Soumis à la réglementation de sûreté aéroportuaire et à des classifications de sécurité nationale dans la plupart des juridictions.
Hôpitaux et établissements de santé
Infrastructure de circulation des patients, redondance de l'alimentation en gaz médicaux, plans des unités de soins critiques. Soumis aux exigences NHS IG (Royaume-Uni) et HIPAA (États-Unis). Données structurelles des systèmes de sécurité des personnes.
Rail et transports critiques
Géométrie des tunnels, infrastructure de signalisation, issues de secours, topologie de l'alimentation électrique. Souvent classées comme infrastructures nationales critiques, avec interdiction explicite d'envoi à des tiers.
Sites industriels et usines de process
Implantation des équipements de process, géométrie de confinement des matières dangereuses, emplacement des systèmes de sécurité. Soumis à la réglementation COMAH / Seveso III dans l'UE. Données de process commercialement sensibles.
Défense et militaire
Explicitement restreint dans la plupart des pays par la réglementation des marchés de défense. Les fichiers IFC d'infrastructures militaires ne peuvent légalement pas être envoyés vers des services cloud commerciaux sans habilitation de sécurité spécifique et accord contractuel.
Au-delà du type de projet, les fichiers IFC embarquent des métadonnées qui relèvent de plusieurs cadres légaux sur les données sensibles. Le champ FILE_NAME de l'en-tête STEP contient le nom de l'auteur et de l'organisation. Les propriétés d'IfcProject portent des identifiants de client et de projet. Les maquettes de planification d'espaces peuvent inclure des effectifs et des répartitions de personnel. Les jeux de propriétés peuvent révéler les capacités des systèmes, les spécifications structurelles et les caractéristiques opérationnelles d'un bâtiment — exactement le type d'information qui rend possible l'espionnage industriel.
L'angle RGPD et traitement des données
L'article 4 du RGPD définit les données personnelles de façon large : toute information se rapportant à une personne physique identifiée ou identifiable. En BIM, cela couvre : les noms d'occupants dans l'affectation des espaces, les coordonnées du propriétaire dans les métadonnées d'IfcProject, les effectifs dans les calculs d'évacuation incendie, et parfois des codes de référence d'actifs, s'ils permettent de remonter à des personnes identifiables via d'autres jeux de données.
En pratique, la plupart des grandes entreprises AEC et des organismes publics ont des politiques de traitement des données qui interdisent techniquement l'envoi de maquettes de projet vers des services tiers non approuvés. Ces politiques sont souvent ignorées au niveau des coordinateurs, parce qu'elles dorment dans un système de gestion documentaire pendant que l'URL du validateur circule sur un forum communautaire. La validation dans le navigateur fait de la conformité le chemin de moindre résistance : elle supprime purement et simplement la décision d'envoyer le fichier.
Comment WebAssembly a changé les outils BIM dans le navigateur
Comprendre pourquoi la validation dans le navigateur est aujourd'hui techniquement crédible suppose de comprendre ce qui a changé. Avant 2017, aucun éditeur de logiciel BIM n'envisageait sérieusement de faire tourner un véritable parseur IFC dans un navigateur. Celui-ci ne pouvait exécuter que du JavaScript, un langage mal adapté pour analyser le format STEP ISO 10303-21 à une vitesse de production.
Avant WebAssembly — la situation d'avant 2017
- L'analyse IFC exigeait un traitement côté serveur — les validateurs cloud existaient non pas par commodité, mais parce que c'était la seule architecture viable. Il n'existait aucune alternative compétitive en performance.
- Les visionneuses IFC dans le navigateur utilisaient des formats intermédiaires pré-traités (extraits de géométrie JSON, maillages simplifiés) plutôt qu'une analyse IFC en temps réel. Ce que vous voyiez n'était pas l'IFC — c'était une approximation générée côté serveur.
- Un fichier IFC de 50 Mo analysé en JavaScript pur prenait plusieurs minutes et faisait planter l'onglet sur les machines à mémoire limitée. Un fichier de 200 Mo était tout simplement impossible à traiter dans un navigateur.
- Le rendu 3D en était aux débuts de WebGL — accéléré par le GPU, mais limité à des scènes d'une complexité gérable en JavaScript. Les grandes maquettes structurelles de plusieurs centaines de milliers d'éléments étaient impraticables.
- Les Web Workers offraient une isolation en threads, mais aucun moyen d'exécuter du code natif compilé. La performance restait bridée par les pauses du ramasse-miettes de JavaScript et son modèle d'exécution mono-thread.
Après WebAssembly — ce qui est possible aujourd'hui
WebAssembly (WASM) est un format d'instructions binaire pour une machine virtuelle à pile, qui s'exécute dans le navigateur à une vitesse proche du natif. Un code écrit en C, C++ ou Rust, compilé en WASM, s'exécute à environ 60 à 90 % de la vitesse native dans n'importe quel navigateur moderne — sans plugin, sans installation, avec isolation mémoire complète et sandbox garantie. WASM est devenu un standard du W3C en 2019 et est disponible dans tous les navigateurs majeurs.
Pour l'IFC en particulier : web-ifc — le parseur utilisé par la bibliothèque @thatopen/components — est compilé de C++ vers WebAssembly. Il analyse le format STEP de l'IFC dans la même classe de performance que les bibliothèques natives de bureau. Un fichier IFC de 50 Mo s'analyse en moins de 10 secondes sur un ordinateur portable récent, dans un onglet de navigateur, sans aucun serveur impliqué. La même classe de performance que Solibri ou Navisworks ouvrant un fichier local — mais dans un navigateur.
WASM : la vitesse du C++ dans le navigateur
web-ifc est compilé de C++ vers WebAssembly. L'analyse du format STEP de l'IFC tourne à 60–90 % de la vitesse native — la même classe de performance que les outils BIM de bureau. Une maquette de 50 Mo s'analyse en moins de 10 secondes sur un ordinateur portable récent.
Web Workers : un vrai parallélisme
L'analyse WASM s'exécute dans un Web Worker dédié — un thread OS séparé. L'interface du navigateur reste réactive pendant le chargement d'une maquette lourde. La validation tourne dans un worker parallèle, et fournit des résultats pendant que la géométrie se charge.
OPFS : un cache local persistant
L'Origin Private File System est une API de stockage native du navigateur, sandboxée par origine et inaccessible aux serveurs. La géométrie analysée est écrite dans l'OPFS après le premier chargement. Les chargements suivants sont environ 10 fois plus rapides : pas de ré-analyse, pas de nouvel envoi.
WebGL / WebGPU : rendu GPU
Three.js encapsule WebGL pour un rendu 3D haute performance. Une gestion de scène par fragments permet de gérer des maquettes de plusieurs centaines de milliers d'éléments à des cadences interactives. Le support de WebGPU arrive pour le rendu de nouvelle génération.
Le cache OPFS : pourquoi les chargements répétés changent le workflow
L'Origin Private File System est une couche de stockage native du navigateur, sandboxée à l'origine web en cours. Les autres origines, les autres onglets et — surtout — les serveurs distants ne peuvent pas accéder à son contenu. Il persiste entre les sessions du navigateur. Pour les workflows IFC, l'OPFS règle la friction la plus pénible des outils travaillant sur de grosses maquettes : le coût de la ré-analyse répétée.
Un fichier IFC de 250 Mo analysé depuis zéro prend 20 à 40 secondes sur une machine récente. Le même fichier chargé depuis le cache OPFS se charge en 2 à 3 secondes. Pour un coordinateur BIM qui ouvre la même maquette de projet plusieurs fois par jour, c'est toute la différence entre un outil qui semble rapide et un outil où l'on attend. Et comme le stockage OPFS est sandboxé par origine et vit sur le système de fichiers local, les données de maquette mises en cache n'atteignent jamais un serveur — elles héritent de la même garantie de confidentialité que la validation navigateur elle-même.
Le goulot d'étranglement de l'envoi — des chiffres réels
Le coût le plus sous-estimé de la validation IFC dans le cloud, c'est le temps d'envoi. Il est invisible dans les comparatifs produits, mais dominant dans le workflow réel. Voici à quoi ressemble l'envoi de tailles de fichiers IFC courantes selon des types de connexion réalistes — et comment le traitement local dans le navigateur se compare :
| Taille du fichier IFC | Bureau (envoi 10 Mbit/s) | 4G mobile (3 Mbit/s) | Chantier (1 Mbit/s) |
|---|
| 50 Mo | ~40 secondes | ~2 min 15 s | ~7 minutes |
| 250 Mo | ~3 min 20 s | ~11 minutes | ~33 minutes |
| 1 Go | ~13 minutes | ~45 minutes | ~2 h 15 min |
| 2 Go | ~27 minutes | ~1 h 30 min | ~4 h 30 min |
Temps d'envoi seul — ajoutez le traitement serveur par-dessus : 50 Mo +5–15 s · 250 Mo +30–90 s · 1 Go +2–6 min · 2 Go +5–15 min. Validation navigateur : 0 s d'envoi dans tous les cas.Une maquette de 250 Mo : des minutes avant que le contrôle démarre
- Navigateur, analyse locale (sans envoi): 0.7 min — 20–40 s pour la première analyse sur un poste récent
- Envoi depuis le bureau (10 Mbit/s): 3.3 min
- Envoi en 4G (3 Mbit/s): 11 min
- Envoi depuis le chantier (1 Mbit/s): 33 min
Temps d'envoi seul pour les outils côté serveur ; leur traitement ajoute encore 30 à 90 s.
Un fichier IFC de 250 Mo — une maquette de coordination typique pour un projet commercial de taille moyenne — met plus de 3 minutes à s'envoyer sur une connexion de bureau rapide. En 4G, il en faut 11. Pour un coordinateur BIM qui lance des contrôles pré-livraison plusieurs fois par jour, le seul temps d'envoi ajoute des heures d'attente morte par semaine. La validation elle-même ne représente qu'une fraction du temps d'envoi.
Sur les chantiers, où la 4G est la norme et où la bande passante se partage entre les bureaux de chantier et les tablettes BIM, envoyer un fichier IFC de 1 Go représente un engagement de 45 minutes avant qu'une seule règle de validation ne s'exécute. La validation dans le navigateur traite le même fichier localement en 90 à 180 secondes, sans dépendance réseau — et en 2 à 5 secondes lors des sessions suivantes grâce au cache OPFS.
Le comparatif complet : validation IFC navigateur ou cloud
| Dimension | Validation navigateur | Validation cloud |
|---|
| Confidentialité | ✅ Le fichier ne quitte jamais l'appareil | ⚠️ Fichier envoyé vers un serveur |
| Souveraineté des données | ✅ Aucune garde par un tiers | ⚠️ Garde des données par un tiers |
| Conformité RGPD | ✅ Conforme par conception | ⚠️ Nécessite un DPA + une base légale |
| Projets sensibles | ✅ Souvent la seule option possible | ❌ Souvent interdit |
| Vitesse (petit fichier <50 Mo) | ✅ Quasi instantané | ⚠️ Délai d'envoi + de traitement |
| Vitesse (gros fichier >250 Mo) | ✅ Aucune pénalité d'envoi | ❌ Goulot d'étranglement à l'envoi |
| Chargements répétés | ✅ Cache OPFS (~10× plus rapide) | ❌ Ré-envoi complet à chaque fois |
| Temps d'envoi | ✅ Nul | ❌ Proportionnel à la taille du fichier |
| Disponibilité hors ligne | ✅ Support hors ligne complet | ❌ Nécessite internet |
| Usage sur le terrain | ✅ Fonctionne en 4G ou hors ligne | ❌ Lent / peu fiable sur chantier |
| Dépendance à internet | ✅ Aucune (après le premier chargement) | ❌ Requise à chaque exécution |
| Traitement par lot | ❌ Manuel, un fichier à la fois | ✅ Automatisation par API / lot |
| Intégration CI/CD | ❌ Pas adapté | ✅ Webhook/API natifs |
| Traçabilité d'équipe | ⚠️ Locale uniquement | ✅ Historique centralisé |
| Reporting à l'échelle de l'organisation | ⚠️ Non agrégé | ✅ Tableau de bord multi-projets |
| Sécurité (données) | ✅ Aucun risque de transit / serveur | ⚠️ Exposition transit + serveur |
| Sécurité (compromission) | ✅ Aucun serveur à compromettre | ⚠️ Dépend du fournisseur cloud |
| Fichiers très volumineux >2 Go | ⚠️ Limité par la RAM de l'appareil | ✅ Le serveur a plus de RAM |
| Coût | ✅ Gratuit à peu coûteux | ⚠️ À l'usage ou par abonnement |
| Charge d'infrastructure | ✅ Nulle — s'exécute dans le navigateur | ✅ Gérée par le fournisseur |
| Complexité de mise en place | ✅ Ouvrir l'URL, glisser le fichier | ⚠️ Compte / clé API requis |
Quand la validation cloud est réellement meilleure
Un comparatif qui ne met en avant qu'un seul camp relève du plaidoyer. La validation IFC cloud a de réels avantages dans des contextes précis — et y appliquer la validation navigateur serait le mauvais choix.
Pipelines CI/CD automatisés
Validation déclenchée automatiquement à chaque commit de maquette — l'équivalent des tests unitaires en développement logiciel. Les API cloud avec réponses par webhook sont la seule architecture possible pour une automatisation sans interface. Il n'existe pas de session navigateur pour exécuter du WASM dans un pipeline côté serveur.
Traitement par lot à l'échelle d'un portefeuille
Auditer des centaines de fichiers IFC existants sur un portefeuille de projets — une migration de données patrimoniales, un audit d'archives de CDE — est réalisable via des API cloud par lot, et impraticable manuellement dans un navigateur, fichier par fichier.
Reporting d'équipe centralisé
Un BIM manager a besoin d'une vue unique de l'historique de validation sur plusieurs projets et intervenants — évolution des scores, fréquence des problèmes, conformité dans le temps. Les services cloud agrègent ces données. Les outils navigateur ne produisent que des résultats locaux.
Intégration à la passerelle du CDE
Certains CDE valident automatiquement les fichiers IFC entrants avant de les accepter. C'est par nature une opération côté serveur — c'est le serveur du CDE qui traite le fichier, pas le navigateur d'un utilisateur. Les API de validation cloud constituent le point d'intégration.
Validation navigateur — le bon choix pour
- Projets publics et gouvernementaux
- BIM défense, infrastructures et aéroports
- Maquettes d'hôpitaux et d'établissements de santé
- Sites industriels et ingénierie de process
- Maquettes soumises au RGPD ou à des politiques de restriction de données
- Validation sur chantier et hors ligne
- Pré-contrôle avant soumission formelle au cloud
- Coordinateurs individuels et petites équipes
Validation cloud — le bon choix pour
- Pipelines de validation CI/CD automatisés
- Audits qualité par lot sur tout un portefeuille
- Tableaux de bord qualité BIM centralisés
- Passerelle CDE et portes de livraison automatisées
- Projets commerciaux non sensibles à grande échelle
- Automatisation de workflow multi-équipes en entreprise
- Intégration par API avec d'autres systèmes
- Fichiers très volumineux dépassant la RAM locale
Cinq idées reçues sur la validation IFC dans le navigateur
Idée reçue n° 1 : « Les applications navigateur sont plus lentes que le cloud »
C'était vrai en 2015. Ce ne l'est plus. Le code WebAssembly s'exécute à 60–90 % de la vitesse du C++ natif dans un navigateur moderne. Le moteur d'analyse IFC (web-ifc) est compilé à partir de C++ — la même catégorie de performance que les bibliothèques qui font tourner Solibri, les importeurs IFC d'Autodesk et IfcOpenShell. Associée à une latence d'envoi nulle, la validation navigateur est souvent plus rapide que le cloud pour des tailles de maquette courantes, en particulier sur des connexions dont le débit montant est inférieur à 50 Mbit/s.
Cette idée reçue persiste parce qu'on compare le JavaScript du navigateur (lent, avec ramasse-miettes) à des applications natives compilées (rapides). Les outils BIM modernes dans le navigateur ne font pas tourner le traitement lourd en JavaScript : ils exécutent du WASM compilé à une vitesse proche du natif, le JavaScript se contentant d'orchestrer le workflow. La distinction entre JS et WASM est aussi significative que celle entre Python et C++.
Idée reçue n° 2 : « Il faut envoyer un fichier IFC pour le valider »
C'est faux. Quand vous ouvrez un fichier IFC dans un validateur navigateur, le navigateur crée un objet File en mémoire locale — accessible au WASM et au JavaScript de ce contexte navigateur, mais jamais transmis vers un point réseau, sauf si le code appelle explicitement une API fetch ou XHR. Vous pouvez le vérifier vous-même : ouvrez l'inspecteur réseau du navigateur (F12 → onglet Réseau) et constatez qu'aucun envoi n'a lieu lorsqu'une maquette est ouverte et validée.
Idée reçue n° 3 : « Les gros fichiers IFC ne peuvent pas tourner dans un navigateur »
Les navigateurs modernes peuvent allouer plusieurs gigaoctets de RAM sur un poste de travail courant. Un fichier IFC de 250 Mo occupe 250 Mo en mémoire — largement dans les capacités qu'un processus navigateur peut allouer sur une machine à 16 Go. Les Web Workers étendent cela avec un accès mémoire hors du thread principal. Pour les fichiers de plus de 500 Mo, un chargement spatial par blocs rend le traitement navigateur viable même sous des contraintes mémoire plus strictes. L'OPFS garantit qu'une grosse maquette analysée une fois n'aura plus jamais besoin d'être ré-analysée lors des sessions suivantes.
Idée reçue n° 4 : « Le cloud est toujours plus sûr »
La sécurité est multidimensionnelle, ce n'est pas un attribut unique. Les services cloud chiffrent généralement les données en transit (TLS 1.3) et au repos (AES-256), ce qui traite l'interception passive. Mais ils introduisent des surfaces d'attaque que le traitement navigateur élimine complètement : compromission côté serveur, buckets de stockage mal configurés, accès interne par des employés du fournisseur cloud, attaques de la chaîne d'approvisionnement sur l'infrastructure du fournisseur, et violations de résidence des données si le serveur se trouve hors des juridictions exigées contractuellement.
Un fichier qui ne quitte jamais l'appareil n'a aucune exposition aux menaces réseau. La bonne question de sécurité n'est pas « quelle architecture est la plus sûre dans l'absolu ? », mais « quels modèles de menace sont pertinents pour ce projet ? ». Pour une maquette d'installation d'un ministère de la Défense, le traitement navigateur élimine totalement le vecteur de menace lié à l'envoi. Pour un projet commercial non sensible où le journal centralisé compte, les contrôles cloud peuvent être le bon compromis.
Idée reçue n° 5 : « La validation navigateur n'est pas de niveau entreprise »
Un logiciel de niveau entreprise se définit par sa fiabilité, la profondeur de ses fonctionnalités et son support institutionnel — pas par son architecture de déploiement. Figma, AutoCAD Web, Google Earth et Microsoft Office pour le Web sont des applications de niveau entreprise qui tournent dans le navigateur grâce à WebAssembly et aux API web modernes. Le même runtime WASM, les mêmes Web Workers et la même infrastructure WebGL qui font tourner ces applications font aussi tourner la validation IFC dans le navigateur. « Basé navigateur » est une décision d'architecture sur le lieu d'exécution du calcul — ce n'est pas un plafond de qualité.
Résoudre les problèmes de validation navigateur
La maquette se charge mais la validation semble lente
La validation s'exécute dans un Web Worker séparé et ne bloque pas l'interface — la maquette 3D doit rester interactive pendant que la validation tourne en arrière-plan. Si le chargement global semble lent, vérifiez si la maquette se charge depuis le cache OPFS (rapide) ou est analysée depuis zéro (plus lent pour les gros fichiers). Au premier chargement, un fichier de 200 Mo prendra 20 à 40 secondes à analyser, même en local. Les chargements suivants depuis le cache prennent 2 à 5 secondes.
Mémoire insuffisante sur des fichiers très volumineux
Les fichiers de plus de 400–500 Mo peuvent épuiser la mémoire du navigateur sur des machines à 8–16 Go de RAM. Symptômes : l'onglet du navigateur plante ou ne répond plus. Solutions : fermer les autres onglets pour libérer de la mémoire, utiliser une machine avec 16 Go de RAM ou plus, ou scinder une maquette fédérée en fichiers par discipline avant de la charger. Pour des fichiers dépassant régulièrement 500 Mo, la validation cloud peut être l'architecture la plus adaptée — le matériel serveur dispose généralement de plus de marge en RAM.
Le cache OPFS grossit avec le temps
L'OPFS stocke des fragments de géométrie analysée pour chaque maquette chargée. Pour une équipe de projet qui charge de nombreuses maquettes sur plusieurs semaines, le cache peut atteindre plusieurs gigaoctets. Le gestionnaire de cache du validateur affiche tous les fichiers en cache avec leur taille et permet une suppression sélective. Les paramètres de stockage du navigateur permettent aussi de vider tout le stockage de l'origine. Le cache est stocké sur l'appareil local et n'est accessible à aucun serveur distant.
Les résultats de validation diffèrent entre navigateur et cloud
Si les résultats diffèrent, la cause la plus courante est que des jeux de règles différents sont appliqués. La validation navigateur (44 règles qualité) et la validation de schéma cloud (conformité ISO 10303-21) ne vérifient pas la même chose — ce ne sont pas les mêmes règles à des endroits différents. Consultez le guide des niveaux de validation pour la distinction entre le contrôle de schéma de niveau 1, le contrôle qualité de niveau 2 et l'IDS de niveau 3. Un résultat IDS doit être identique entre deux moteurs conformes à la spécification, exécutant le même fichier .ids sur la même maquette.
Où se situe IFC Viewer Online dans cette architecture
IFC Viewer Online est une implémentation navigateur de l'architecture B. Le parseur IFC (web-ifc compilé en WASM), le moteur de validation à 44 règles, le calcul du Health Score, le moteur de vérification IDS 1.0, le panneau BCF et le moteur de rendu 3D (Three.js via WebGL) tournent tous dans le navigateur. Rien n'est envoyé. L'architecture impose cela au niveau même de l'implémentation — il n'existe aucun point de terminaison côté serveur vers lequel envoyer les données de la maquette.
Analyse WASM dans un Web Worker
web-ifc (C++ → WASM) s'exécute dans un thread worker dédié. L'interface reste réactive pendant le chargement de grosses maquettes. Un fichier de 50 Mo s'analyse en moins de 10 secondes. Un fichier de 200 Mo en 20 à 40 secondes. Premier résultat : local. Toujours.
Cache OPFS pour les chargements répétés
Les fragments de géométrie analysée persistent dans l'OPFS après la première session. Les chargements suivants sont environ 10 fois plus rapides — pas de ré-analyse, pas de dépendance réseau. Le cache est privé à l'origine du navigateur et inaccessible aux serveurs distants.
44 règles qualité + IDS 1.0
44 règles de qualité de maquette (intégrité structurelle, ISO 19650, Psets, classification, LOD, MEP) plus un moteur IDS 1.0 buildingSMART testé sur les 100 cas de test officiels bSI — le tout côté client.
Édition non destructive des propriétés
Les noms d'éléments, les valeurs des jeux de propriétés et les GlobalId peuvent être modifiés sur un fichier IFC reçu sans passer par un aller-retour dans le logiciel de modélisation — et sans envoi vers un quelconque serveur.
Recommandations d'expert : choisir la bonne architecture
Le choix entre validation navigateur et validation cloud est une décision de gouvernance au niveau du projet, pas une préférence d'outil. Voici la logique de décision pour les scénarios les plus courants :
- Projets publics, défense, aéroports, rail, hôpitaux et sites industriels : la validation navigateur doit être l'hypothèse par défaut. Vérifiez si la politique de traitement des données de votre organisation autorise l'envoi de la maquette avant d'envisager le cloud. Si la politique ne traite pas la question, partez du principe que l'envoi est interdit et demandez une clarification à votre délégué à la protection des données.
- Projets commerciaux sans classification de données : les deux architectures sont viables. Utilisez le cloud pour la traçabilité centralisée et l'intégration CI/CD. Utilisez le navigateur pour la vitesse, la préférence en matière de confidentialité et la capacité hors ligne.
- Contrôles qualité quotidiens pré-livraison par des coordinateurs individuels : la validation navigateur est plus rapide, plus simple, ne nécessite aucun compte et supprime l'attente d'envoi. Exécutez-la en local avant toute soumission formelle au CDE.
- Audits de portefeuille ou évaluations de conformité CDE sur de nombreuses maquettes : le traitement par lot dans le cloud est le bon outil. Faire passer 200 maquettes par une API cloud et obtenir un rapport qualité consolidé est impraticable dans un navigateur.
- Porte de livraison automatisée au sein d'un CDE : la validation cloud avec intégration API est la seule architecture praticable. Il n'existe aucun contexte navigateur disponible dans un workflow automatisé côté serveur.
- Workflow hybride : utilisez la validation navigateur comme porte qualité quotidienne (rapide, privée, sans compte requis), et réservez le cloud à la soumission formelle au CDE, là où la traçabilité, l'intégration API ou l'automatisation par lot apportent une réelle valeur ajoutée. Ces deux architectures sont complémentaires.
Questions fréquentes
La validation IFC dans le navigateur est-elle vraiment privée ?
Oui, à condition d'être bien implémentée. WebAssembly s'exécute dans un contexte sandboxé du navigateur. L'objet File contenant les données IFC est créé en mémoire locale du navigateur. Pour que ces données atteignent un serveur, le code doit appeler explicitement une API réseau. Un validateur bien conçu n'effectue aucun appel de ce type pour le fichier IFC. Vérifiez-le en ouvrant l'inspecteur réseau du navigateur (F12 → onglet Réseau) et en constatant qu'aucun envoi n'a lieu lorsque vous ouvrez et validez une maquette.
La validation navigateur fonctionne-t-elle hors ligne ?
Oui, avec une réserve. L'application elle-même doit être chargée au moins une fois en ligne, le temps que le binaire WASM et les paquets JavaScript se téléchargent lors de la première visite. Ensuite, une application web progressive peut fonctionner entièrement hors ligne. Les maquettes mises en cache dans l'OPFS se chargent sans aucun accès réseau. Pour une visite de chantier où la connexion est incertaine, charger l'application et pré-mettre en cache la maquette du projet la veille au soir garantit une disponibilité hors ligne le lendemain.
Quelle est la limite pratique de taille de fichier pour la validation navigateur ?
Sur une machine avec 16 Go de RAM (un poste de travail moderne courant ou un portable haut de gamme), les fichiers jusqu'à 400–500 Mo s'analysent de façon fiable. Sur des machines à 8 Go, la limite pratique tourne autour de 200–250 Mo, au-delà de quoi la pression mémoire entraîne des instabilités. Le cache OPFS supprime le coût de la répétition : seule la première analyse impose le traitement complet. Pour des fichiers dépassant régulièrement 500 Mo, la validation cloud peut offrir davantage de marge.
WebAssembly introduit-il des risques de sécurité ?
WASM s'exécute dans le même environnement sandboxé que JavaScript : il ne peut pas accéder au système de fichiers, au système d'exploitation ni au réseau sans passer par les API du navigateur, soumises aux mêmes politiques de sécurité que n'importe quel contenu web. La vraie question de sécurité ne porte pas sur le runtime WASM lui-même, mais sur les appels réseau que fait l'application — et un validateur bien conçu n'en fait aucun pour le fichier IFC.
Peut-on utiliser les deux architectures dans le même workflow de projet ?
Oui — c'est souvent l'organisation la plus pratique. Les coordinateurs font tourner la validation navigateur en local comme pré-contrôle avant toute soumission formelle. La passerelle du CDE utilise ensuite la validation cloud avec une API pour la traçabilité et l'acceptation automatisée. Le contrôle navigateur est rapide et privé ; le contrôle cloud fournit l'enregistrement officiel et le reporting à l'échelle de l'organisation. Les deux architectures répondent à des besoins différents et se complètent.
En résumé
L'endroit où va un fichier IFC pendant sa validation n'est pas un détail technique. C'est une décision de gouvernance des données qui conditionne la conformité réglementaire d'une grande partie des projets AEC.
IFC Viewer Blog
Projets sensibles : le navigateur d'abord
Les projets publics, de défense, de santé et d'infrastructure devraient par défaut privilégier la validation navigateur. C'est souvent la seule option conforme — pas seulement la plus pratique. Les données ne quittent jamais l'appareil.
Automatisation et traitement par lot : le cloud
Les pipelines CI/CD, les audits de portefeuille et le reporting centralisé exigent une architecture cloud. Une session navigateur ne peut pas participer à des workflows automatisés sans interface, ni agréger des résultats entre équipes.
Validation quotidienne : le navigateur gagne en vitesse
Aucun temps d'envoi, des chargements répétés accélérés par l'OPFS, et aucun compte requis. Pour les contrôles pré-livraison qui rythment le quotidien d'un coordinateur, le traitement navigateur est plus rapide que le cloud pour toutes les tailles de maquette courantes.
Pour comprendre ce que vérifient réellement les 44 règles qualité — et leur lien avec la validation de schéma et l'IDS —, consultez le guide complet du model checker IFC. Pour le Health Score qui résume la qualité en un seul chiffre, consultez le guide du Health Score IFC. Si vous devez corriger des valeurs de propriétés ou des GUID sur un fichier IFC reçu sans l'envoyer nulle part, l'éditeur IFC en ligne gratuit applique la même architecture navigateur d'abord à l'édition non destructive des propriétés.
Validation IFC dans le navigateur ou dans le cloud : la décision d'architecture où les équipes BIM se trompent le plus souvent