eCCC-Bât et CFC : rendre les classifications exploitables dans l'IFC

Le code ne doit pas rester un commentaire

Dans une maquette BIM, un code CFC ou eCCC-Bât peut être présent sans être réellement exploitable. Il arrive qu'il soit saisi dans un nom d'objet, dans une propriété libre ou dans une convention propre à un logiciel. Cette approche fonctionne pour une lecture humaine, mais elle limite les contrôles automatiques et les exports.

Un audit qualité cherche à savoir si la classification est structurée, stable et cohérente avec l'objet. La donnée doit pouvoir être filtrée, comparée et transmise sans dépendre d'une lecture manuelle.

Ce qu'il faut vérifier

• Le code est attaché à l'objet concerné, pas seulement à un groupe ou à un libellé.
• La source de classification est identifiable : CFC, eCCC-Bât ou autre référentiel.
• Le format est homogène dans tout le modèle.
• Les correspondances multi-positions sont documentées lorsqu'un objet touche plusieurs lots.
• Les valeurs sont cohérentes avec la nature de l'élément IFC.

Pourquoi cela compte pour le maître d'ouvrage

Une classification propre facilite les métrés, les analyses de coûts, la comparaison entre lots et la préparation de la donnée d'exploitation. Elle évite aussi de reconstruire des tableurs à la main à la fin du projet.

Pour un BIM manager, la classification structurée rend les contrôles plus simples : il devient possible d'isoler les objets sans code, les codes incohérents ou les éléments portés dans une mauvaise catégorie.

Une approche progressive

Tous les projets n'ont pas besoin du même niveau de détail. L'enjeu est d'aligner le niveau de classification avec les usages attendus : coordination, estimation, exploitation ou handover. Un audit peut commencer par les familles les plus critiques, puis étendre le contrôle aux autres lots lorsque le modèle gagne en maturité.

Pourquoi la classification doit être structurée

Un code CFC ou eCCC-Bât écrit dans un nom d'objet peut dépanner une lecture humaine, mais il reste fragile pour un audit. La donnée doit pouvoir être filtrée, vérifiée et exportée. Pour cela, la classification doit être portée de manière homogène par les objets concernés, avec une source claire et un format stable. Sinon, chaque extraction devient une opération manuelle.

La classification sert plusieurs usages : suivi des lots, estimation, contrôle des familles d'objets, préparation du handover et parfois rapprochement avec les outils du maître d'ouvrage. Une erreur de code peut donc avoir un impact au-delà du BIM. Elle peut modifier une lecture économique, masquer une responsabilité ou rendre une donnée difficile à reprendre en exploitation.

Méthode de contrôle

Le contrôle commence par une cartographie des codes réellement présents dans l'IFC. Il faut ensuite regarder où ces codes sont stockés : classification structurée, propriété dédiée, type, nom d'objet ou champ libre. Plus l'information est éloignée d'une structure stable, plus le risque d'erreur augmente. Le rapport doit distinguer l'absence de code, le mauvais code et le code placé au mauvais endroit.

Les objets similaires doivent aussi être comparés entre eux. Si des portes équivalentes portent trois conventions différentes, le problème n'est pas seulement local. Il indique une règle de modélisation à clarifier. Le bon livrable ne se limite donc pas à corriger un objet : il identifie la convention à appliquer pour éviter que l'écart revienne au prochain export.

Décisions à prendre

Tous les projets n'ont pas besoin du même niveau de classification. Pour une coordination simple, un niveau général peut suffire. Pour une remise orientée exploitation ou coût, la précision attendue sera plus élevée. La question à poser n'est pas "peut-on ajouter plus de codes ?" mais "quel niveau de code sera réellement utilisé et maintenu ?".

Une classification fiable donne au maître d'ouvrage une donnée plus stable et aux équipes projet un langage commun. Elle rend les métrés, les contrôles et les tableaux de remise moins dépendants d'une relecture manuelle. C'est un point discret dans la maquette, mais il conditionne fortement la valeur de la donnée.

Checklist rapide

• L'usage attendu de la donnée est identifié avant le contrôle.
• Les objets critiques sont typés correctement dans l'IFC.
• Les propriétés demandées sont présentes, remplies et placées dans des champs cohérents.
• Les classifications suisses sont lisibles et homogènes.
• Les écarts sont priorisés par impact projet, pas seulement listés.
• Le livrable permet une correction réelle par les équipes concernées.

Prochaine décision à prendre

Avant le prochain export IFC, il faut choisir le contrôle qui réduit vraiment le risque du projet : typage des objets, propriétés attendues, classification, localisation des actifs ou donnée de remise. Le résultat attendu n'est pas une remarque générale, mais une décision claire : corriger maintenant, suivre au prochain jalon ou accepter l'écart parce qu'il n'a pas d'impact sur l'usage prévu.

Cette logique transforme le contrôle en plan d'action. Le périmètre est vérifié, les écarts prioritaires sont isolés, les responsables de correction sont identifiés et la validation peut se faire sur un nouvel export.

Pourquoi la classification doit être structurée

Un code CFC ou eCCC-Bât écrit dans un nom d'objet peut dépanner une lecture humaine, mais il reste fragile pour un audit. La donnée doit pouvoir être filtrée, vérifiée et exportée. Pour cela, la classification doit être portée de manière homogène par les objets concernés, avec une source claire et un format stable. Sinon, chaque extraction devient une opération manuelle.

La classification sert plusieurs usages : suivi des lots, estimation, contrôle des familles d'objets, préparation du handover et parfois rapprochement avec les outils du maître d'ouvrage. Une erreur de code peut donc avoir un impact au-delà du BIM. Elle peut modifier une lecture économique, masquer une responsabilité ou rendre une donnée difficile à reprendre en exploitation.

Méthode de contrôle

Le contrôle commence par une cartographie des codes réellement présents dans l'IFC. Il faut ensuite regarder où ces codes sont stockés : classification structurée, propriété dédiée, type, nom d'objet ou champ libre. Plus l'information est éloignée d'une structure stable, plus le risque d'erreur augmente. Le rapport doit distinguer l'absence de code, le mauvais code et le code placé au mauvais endroit.

Les objets similaires doivent aussi être comparés entre eux. Si des portes équivalentes portent trois conventions différentes, le problème n'est pas seulement local. Il indique une règle de modélisation à clarifier. Le bon livrable ne se limite donc pas à corriger un objet : il identifie la convention à appliquer pour éviter que l'écart revienne au prochain export.

Décisions à prendre

Tous les projets n'ont pas besoin du même niveau de classification. Pour une coordination simple, un niveau général peut suffire. Pour une remise orientée exploitation ou coût, la précision attendue sera plus élevée. La question à poser n'est pas "peut-on ajouter plus de codes ?" mais "quel niveau de code sera réellement utilisé et maintenu ?".

Une classification fiable donne au maître d'ouvrage une donnée plus stable et aux équipes projet un langage commun. Elle rend les métrés, les contrôles et les tableaux de remise moins dépendants d'une relecture manuelle. C'est un point discret dans la maquette, mais il conditionne fortement la valeur de la donnée.

Checklist rapide

• L'usage attendu de la donnée est identifié avant le contrôle.
• Les objets critiques sont typés correctement dans l'IFC.
• Les propriétés demandées sont présentes, remplies et placées dans des champs cohérents.
• Les classifications suisses sont lisibles et homogènes.
• Les écarts sont priorisés par impact projet, pas seulement listés.
• Le livrable permet une correction réelle par les équipes concernées.

Prochaine décision à prendre

Avant le prochain export IFC, il faut choisir le contrôle qui réduit vraiment le risque du projet : typage des objets, propriétés attendues, classification, localisation des actifs ou donnée de remise. Le résultat attendu n'est pas une remarque générale, mais une décision claire : corriger maintenant, suivre au prochain jalon ou accepter l'écart parce qu'il n'a pas d'impact sur l'usage prévu.

Cette logique transforme le contrôle en plan d'action. Le périmètre est vérifié, les écarts prioritaires sont isolés, les responsables de correction sont identifiés et la validation peut se faire sur un nouvel export.