Avant l'outil de contrôle par règles, avant l'IDS, avant même l'audit contractuel, il y a un geste que n'importe qui peut faire avec une visionneuse gratuite : ouvrir le fichier reçu et l'inspecter méthodiquement. En une à deux heures, sans licence ni règles écrites, on répond à la seule question qui compte d'abord : ce fichier est-il seulement exploitable ?
On parle beaucoup des outils de contrôle sophistiqués. On oublie qu’avant eux, il existe une inspection manuelle, sans licence ni compétence particulière, qui reste le niveau minimal exigible avant d’utiliser un IFC reçu.
Cette inspection ne remplace ni l’audit contractuel ni les méthodes automatisées : elle les précède. Son but n’est pas de tout trouver, elle ne contrôle qu’un échantillon, mais de répondre vite à une question préalable que les outils lourds ne posent pas : le fichier est-il seulement sain et exploitable, ou faut-il le renvoyer avant d’y consacrer une seule minute d’analyse ? La mener demande une visionneuse gratuite et une à deux heures, pas davantage.
Elle se déroule en trois passes, dans un ordre qui n’est pas indifférent : d’abord le fichier lui-même, puis sa structure, enfin les données portées par les éléments. Chaque passe suppose la précédente satisfaite, exactement comme pour l’audit : inspecter les données d’un fichier qui s’ouvre mal ou qui est mal calé est du temps perdu.
C’est la version approfondie du contrôle express décrit dans le guide sur le format IFC : là où celui-ci prend cinq minutes pour un tri, celui-ci prend une à deux heures pour une inspection sérieuse. Ce n’est pas pour autant l’audit, qui mesure un écart par rapport à des exigences écrites, ni un contrôle automatisé exhaustif. C’est le tri humain de bon sens qui rend les deux autres rentables.
Avant d’ouvrir la moindre vue 3D, le fichier lui-même se renseigne, et ces métadonnées disent déjà beaucoup de ce qu’il faut en attendre.
On commence par le plus bête et le plus révélateur. S’ouvre-t-il sans message d’erreur ? Reste-t-il fluide à la navigation, ou rame-t-il au point d’être inutilisable ? Quelle est sa taille, et est-elle raisonnable au regard de ce qu’il contient ? Un fichier qui ne s’ouvre pas proprement n’a pas besoin d’être audité, il a besoin d’être réémis.
Vient ensuite la carte d’identité du fichier, que toute visionneuse affiche : la version d’IFC et le MVD, le logiciel d’origine et sa version, l’auteur et sa discipline, la langue, l’unité de mesure et la précision (le nombre de décimales), et l’ordre de grandeur du nombre de propriétés présentes.
Elles cadrent vos attentes. Un modèle d’architecte et un modèle de stabilité ne montrent pas les mêmes choses : constater qu’il manque le gros œuvre dans un fichier d’architecture n’est pas un défaut. La version vous dit ce qui peut être présent, et le MVD ce qui a été cadré à l’export. Un fichier exporté depuis une version ancienne d’un exporteur traîne des défauts déjà corrigés ailleurs. Lire cette carte d’identité, c’est savoir quoi chercher dans les deux passes suivantes.
La deuxième passe vérifie la géométrie et l’ossature spatiale, par une inspection visuelle dans la fenêtre 3D et dans l’arborescence. On ne cherche pas encore les données, on cherche la cohérence d’ensemble.
Cherchez la classe des éléments non définis (IfcBuildingElementProxy) et comptez ce qu’elle contient. Cette classe fourre-tout accueille les objets que le modeleur n’a pas typés correctement : un mur, une gaine ou un équipement qui y atterrit arrive chez vous comme une forme sans identité, invisible à toute requête et à tout contrôle. Un modèle qui en compte beaucoup n’est pas exploitable pour grand-chose, quelle que soit sa beauté à l’écran. C’est le meilleur indicateur, en un seul chiffre, du soin réel apporté à la maquette.
La dernière passe consiste à sélectionner quelques éléments représentatifs et à vérifier, un par un, qu’ils portent bien les informations attendues. C’est ici que se révèle la différence entre une maquette renseignée et une maquette qui n’est qu’un joli dessin en trois dimensions.
Pour chaque élément échantillonné, on déroule la même liste. Porte-t-il une classe IFC et un type prédéfini corrects ? Un nom ? Une classification ou une codification de cahier des charges ? Une description de ses matériaux, avec les couches et leurs épaisseurs pour un élément composite ? Ses propriétés attendues, comme la résistance au feu, le caractère porteur ou la position intérieure ou extérieure ? Ses quantités, rangées dans les ensembles standard ?
Une propriété attendue et absente n’est pas un détail : c’est une donnée manquante, et sur un objet, elle en annonce souvent des centaines d’autres. Sélectionnez le même type d’élément à plusieurs endroits : si l’information est là ici et absente là, l’encodage est irrégulier, ce qui est parfois pire qu’une absence franche. Cette passe ne porte que sur un échantillon : pour vérifier la présence d’une donnée sur tout le modèle d’un coup, il faut passer aux méthodes automatisées, l’IDS en tête.
Trouver un défaut ne sert à rien si l’on ne sait pas d’où il vient, car c’est l’origine qui décide de qui doit le corriger, et comment. Les problèmes relevés ont presque toujours l’une de ces cinq causes.
Éléments mal définis, géométries incorrectes, données omises, objets de bibliothèque mal utilisés. La cause la plus fréquente, et elle se corrige dans le logiciel d’origine.
Une configuration d’export mal réglée qui omet des données ou en laisse passer trop. Se corrige sans remodéliser, en revoyant la vue et la version d’export.
Un modèle fait pour un usage, réemployé pour un autre qu’il ne peut pas servir. Le défaut est réel, mais l’exigence était mal posée en amont.
Le logiciel d’origine traduit mal certaines informations vers l’IFC. La correction passe par un autre réglage, une autre version, ou un contournement.
Deux visionneuses affichent parfois différemment le même fichier. Le défaut apparent vient de l’outil de lecture, pas du fichier.
Devant un doute, ouvrez le même IFC dans une seconde visionneuse. Si le problème disparaît, il venait de l’outil de lecture, pas du modèle. Si les deux montrent la même chose, le défaut est bien dans le fichier. Et retenez le fait le plus important de tout ce guide : ces problèmes ne viennent presque jamais d’une limite du format IFC lui-même, mais du processus de modélisation et d’export. C’est très exactement la thèse du guide sur le format : quand quelqu’un dit « l’IFC perd tout », il parle en réalité de l’un de ces cinq points.
Un contrôle sans licence ni règles écrites, dont la valeur est d’être fait systématiquement, à la réception, avant tout le reste.
Trois idées à emporter. Ce contrôle précède tous les autres : il ne cherche pas l’exhaustivité mais l’exploitabilité, en une à deux heures, avec une visionneuse gratuite, et il rend les outils lourds rentables en écartant d’emblée les fichiers inutilisables. Il se mène en trois passes ordonnées : le fichier (s’ouvre-t-il, quelle version, quelle unité), la structure (le bâtiment est-il là, bien rangé, bien typé), les données (chaque objet est-il renseigné), la classe des éléments non définis étant l’indicateur le plus parlant. Enfin, un défaut se rattache toujours à une cause parmi cinq, et presque aucune n’est imputable au format : le problème est dans la modélisation ou l’export, jamais dans l’IFC.
Ce contrôle manuel prolonge le format IFC et son tri express en cinq minutes. Pour lui donner un référentiel opposable, il faut l’adosser aux exigences écrites : c’est l’objet d’auditer une maquette. Pour le rendre exhaustif et rejouable, on passe aux méthodes automatisées, l’IDS pour la présence des données et Solibri pour la géométrie. La démarche pas à pas détaillée ici s’appuie sur le guide IFC de Buildwise (IP 51, 2025).
Les guides qui prolongent naturellement celui-ci, dans d'autres sections du site.
Non, l'IFC n'est pas « le PDF de la maquette ». C'est une base de données structurée qui transporte vos objets et leurs propriétés d'un logiciel à l'autre. Comprendre ce qu'il contient vraiment, c'est arrêter de subir les exports ratés.
Sans exigences écrites à l'avance, un audit n'est qu'un avis, et le producteur a le droit de ne pas être d'accord. Voici les quatre familles de contrôle, dans l'ordre où elles se mènent, et ce qui sépare un audit qui améliore d'un audit qui indispose.
Un cahier des charges dit « les murs porteurs doivent indiquer leur résistance au feu ». Deux personnes le lisent et le vérifient différemment ; un ordinateur ne peut pas le vérifier du tout. L'IDS traduit cette même exigence dans une forme que la machine exécute, avec le même verdict partout. C'est le chaînon qui manquait entre écrire une exigence et la contrôler.