Comme dans tout logiciel, exporter depuis Archicad est une traduction, pas un enregistrement. Mais là où d'autres éparpillent leurs réglages, Archicad les réunit dans un seul objet qu'il faut apprendre à manier : le traducteur IFC. Comprenez le traducteur, et le typage par classification qui va avec, et vous tenez l'essentiel d'un export propre.
La logique de fond, exporter c’est traduire, est la même que pour Revit et se trouve dans le guide correspondant. Ce qui change avec Archicad, c’est la façon dont ces décisions sont rassemblées : non pas dans une liste d’options éparses, mais dans un objet unique et réutilisable.
Cet objet est le traducteur IFC. C’est un jeu de règles de conversion, enregistré et nommé, qui décide d’un coup de tout ce qui compte : quelle version et quelle vue du schéma, comment les éléments deviennent des entités IFC, quelles propriétés partent, comment la géométrie est convertie. Exporter, dans Archicad, ce n’est pas régler dix cases à chaque fois, c’est choisir le bon traducteur, puis le maintenir.
Cette centralisation est une force et un piège. Une force, parce qu’un traducteur bien réglé rend chaque export reproductible, indépendant de qui le lance. Un piège, parce qu’un traducteur mal compris applique silencieusement des choix qu’on croyait maîtriser. Comme pour l’export depuis Revit, la question n’est pas comment exporter, mais ce que le destinataire doit pouvoir faire du fichier, et le traducteur est la réponse à cette question, figée une fois.
N’ayez pas un traducteur, ayez-en un par usage : un pour la coordination, un pour transmettre un modèle à reprendre, un pour un partenaire aux exigences particulières. Chacun encode une intention. Utiliser un traducteur de coordination pour un transfert de modélisation, ou l’inverse, produit un fichier techniquement valide et pratiquement inadapté. Le choix du traducteur est le premier geste de l’export, pas un détail de configuration.
C’est la différence la plus importante avec un logiciel qui type par catégorie. Dans Archicad, ce qui décide de l’entité IFC d’un objet n’est pas l’outil qui l’a créé, mais la classification qu’on lui a attribuée.
Un mur créé avec l’outil Mur n’est pas automatiquement un mur IFC parce qu’il a été dessiné comme tel. Il le devient parce qu’il porte une classification qui, dans le traducteur, correspond à l’entité murale du schéma. Le mapping se fait donc en deux temps : vous classez vos éléments, et le traducteur traduit ces classifications en entités IFC. La discipline qui en découle est simple à énoncer et souvent négligée : classez correctement, et le bon typage suit.
Un élément non classé, ou mal classé, tombe dans l’entité fourre-tout des éléments non définis, ce IfcBuildingElementProxy qui arrive chez le destinataire comme une forme sans identité. Le symptôme est le même que le modèle générique d’un autre logiciel, mais la cause est différente : ici, ce n’est pas une mauvaise catégorie d’outil, c’est une classification absente ou fausse. La chasse à ces éléments, décrite dans le contrôle d’un IFC pas à pas, est le meilleur test de la qualité de votre classification.
Comme partout, les propriétés ne voyagent pas toutes seules. Dans Archicad, leur sort se règle encore dans le traducteur, à travers ses règles de correspondance.
Le traducteur peut produire les property sets normalisés (Pset_...) et les quantités (Qto_...), par une option. Sûrs et universellement lus, ils sont le socle à activer d’abord.
Les propriétés propres au modèle, y compris celles calculées par expression, se dirigent vers des jeux IFC via les règles de correspondance du traducteur. C’est là que passe la donnée métier.
Une propriété qu’aucune règle ne vise reste dans Archicad, sans avertissement. L’oubli le plus courant, et le plus silencieux.
Avant de plonger dans les règles de correspondance, posez la question de l’aval : quelle propriété, sur quel objet, le destinataire doit-il pouvoir filtrer ? Ce que le traducteur doit produire découle de l’EIR, pas des propriétés que vous avez sous la main. Régler le traducteur sans cette réponse, c’est exporter beaucoup pour livrer mal.
Le traducteur ne règle pas que le typage et les propriétés, il décide aussi comment la forme est convertie. Un choix mérite une attention particulière, car il touche à ce qui fait la richesse d’un modèle Archicad.
Un mur ou une dalle composite peut sortir de deux façons, et c’est le traducteur qui tranche : soit comme un seul objet portant ses couches en information, soit décomposé en sous-parties, chaque couche devenant un élément à part. Ce choix n’est pas neutre : il décide si le destinataire pourra quantifier ou visualiser chaque couche séparément, au prix d’un fichier plus lourd. C’est exactement la distinction développée dans les matériaux multicouches, et le traducteur est l’endroit où elle se règle en pratique.
Le même principe gouverne tout le traducteur : on ne cherche pas le réglage « le meilleur », on cherche celui qui sert l’usage du destinataire. Décomposer les composites pour un partenaire qui n’en a pas besoin alourdit inutilement ; les garder groupés prive celui qui devait quantifier les couches. Là encore, l’export se règle en partant de l’aval, jamais du confort de production.
Restent deux réglages que le traducteur ne porte pas seul, et qui décident pourtant qu’un fichier complet et bien calé, ou amputé et décalé, sorte du même modèle.
Que le périmètre d’export dépende des combinaisons de calques n’est pas un hasard : c’est la signature d’Archicad, décrite dans Archicad décodé. Le même mécanisme qui gouverne l’affichage gouverne l’export. Un plan de calques bien pensé sert donc deux fois, à l’écran et à la livraison ; un plan bricolé se paie aussi deux fois.
Un export Archicad se maîtrise par un objet et une discipline : le traducteur, et la classification.
Trois idées à emporter. Tout passe par le traducteur IFC : version, vue, typage, propriétés, géométrie sont réunis dans un objet unique et réutilisable, et l’on en garde un par usage plutôt que d’ajuster des cases à chaque export. Le typage vient de la classification, non de l’outil : on classe les éléments, le traducteur les traduit en entités IFC, et un élément mal classé tombe dans l’entité fourre-tout. Enfin, le traducteur décide aussi de la géométrie, notamment de sortir les composites en un objet ou décomposés, un choix qui se prend en fonction de l’usage du destinataire, comme tout le reste.
La logique interne dont cet export découle est dans Archicad décodé, et l’équivalent côté Revit dans exporter un IFC propre depuis Revit. Le choix de la version et de la vue est détaillé dans versions d’IFC et MVD, le calage dans le géoréférencement, et le contrôle du résultat dans contrôler un IFC pas à pas. Le socle reste le format IFC.
Les guides qui prolongent naturellement celui-ci, dans d'autres sections du site.
Archicad ne s'apprend pas comme une liste d'outils, mais comme une idée : celle du bâtiment virtuel, un modèle intégré dont plans, coupes et planches ne sont que des vues. Comprenez cette idée fondatrice, et l'organisation du logiciel, ses calques, ses objets, son navigateur, cesse d'être un labyrinthe pour devenir une conséquence logique.
Un export IFC n'est pas un enregistrement, c'est une traduction. Tant que vous ne décidez pas comment Revit traduit, il décide à votre place. Voici les trois réglages qui font 90 % du résultat, et la logique derrière, valable quelle que soit votre version.
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.