Interopérabilité

Revit et Archicad : ce qui traverse, ce qui se perd, et pourquoi

« Convertir un projet Revit en Archicad » n'existe pas. On n'échange pas un projet, on échange pour un usage, et selon l'usage la réponse va de « ça marche très bien » à « ce n'est pas la bonne question ». Voici les trois cas, et la méthode pour chacun.

Lecture : 7 minTrois intentions, trois réponsesLes deux voies concrètesRégler les deux boutsMàJ : juillet 2026
La question de départ

On n’échange pas un projet, on échange pour un usage

La demande arrive toujours formulée de la même façon : « comment passer ce projet de Revit à Archicad ». Elle n’a pas de réponse unique, parce qu’elle recouvre trois intentions très différentes.

Récupérer une maquette pour s’en servir de référence, la reprendre pour continuer à la modifier, ou en transférer définitivement la production à une autre équipe : ce sont trois situations distinctes. La première est un problème résolu, la deuxième repose sur un malentendu, et la troisième n’est pas un problème d’export mais un projet à part entière.

Tant que l’intention n’est pas nommée, la discussion tourne en rond et se conclut généralement par « l’IFC perd tout », ce qui est faux et empêche de traiter le vrai sujet.

La question à poser avant toute manipulation

Qu’est-ce que le destinataire doit pouvoir faire avec ce modèle ? Le regarder et s’y caler, le modifier, ou en devenir responsable ? Les réglages d’export ne se choisissent qu’après cette réponse, jamais avant.

Les trois cas

Trois intentions, trois réponses

Chacune a sa méthode, son coût et son verdict. Les confondre est la source de toutes les déceptions sur ce sujet.

1. Référencer

Coordination, fond de plan
L’intention : afficher le modèle de l’autre pour s’y caler, coordonner, vérifier des interfaces. On consulte, on ne modifie pas.
Le verdict
  • Cela fonctionne bien. C’est exactement ce pour quoi l’IFC est fait.
  • Le modèle arrive en référence non modifiable, et c’est la bonne façon de le recevoir.
  • Le coût est faible et l’opération se répète à chaque cycle sans douleur.

2. Reprendre pour éditer

Continuer le travail
L’intention : récupérer les objets pour les modifier ensuite comme s’ils avaient été créés dans le logiciel receveur.
Le verdict
  • Cela ne fonctionne pas comme espéré, et c’est normal. L’IFC transporte des objets, pas l’intelligence paramétrique qui les a produits.
  • Les éléments arrivent exploitables mais figés dans leur logique d’origine.
  • Vouloir forcer cette voie coûte plus cher que de remodéliser proprement.

3. Transférer la production

Changer de responsable
L’intention : une autre équipe reprend la production du modèle, dans son propre outil, et en devient responsable.
Le verdict
  • Ce n’est pas un problème d’export. C’est une reprise de modélisation, à chiffrer et à planifier.
  • L’IFC sert alors de référence géométrique et de source de données, pas de point de départ éditable.
  • Le vrai sujet est contractuel : qui devient responsable de quoi, et à partir de quand.

Le malentendu central

Le cas 2 est celui qui alimente toutes les rumeurs sur l’incompatibilité des deux logiciels. Or l’IFC n’a jamais eu pour but de permettre l’édition croisée : c’est un format de livraison, pas un format de travail. Lui reprocher de ne pas faire d’aller-retour revient à lui reprocher de faire exactement ce pour quoi il est conçu.

Concrètement

Les deux voies disponibles

Il n’existe pas de passerelle native entre les deux logiciels. L’échange passe par l’IFC, avec ou sans outil d’appoint.

La voie standard consiste à exporter en IFC depuis le producteur et à importer chez le destinataire, chacun réglant son côté. C’est la voie robuste et durable, celle qui fonctionne quel que soit l’interlocuteur, y compris avec un troisième logiciel demain. Elle demande de savoir régler ses exports, sujet traité dans le guide sur l’export IFC depuis Revit.

La voie outillée existe également : Graphisoft publie un add-in gratuit pour Revit, IFC Model Exchange with Archicad, mis à jour chaque année pour suivre les versions. Il ajoute trois fonctions : un import IFC dont l’interprétation des modèles architecturaux est améliorée, une fonction de liaison qui insère un modèle IFC dans le projet Revit en référence non modifiable, et un export IFC spécialement préparé pour Archicad.

Ce que cet outil illustre du paysage

Notez qui le publie : c’est l’éditeur d’Archicad qui fournit l’outil, et il tourne dans Revit. C’est un connecteur dédié au sens du guide sur les chaînes d’outils, avec le profil de risque correspondant : il dépend d’un tiers et d’un rythme de mise à jour. Ici le tiers l’entretient annuellement, ce qui est le cas favorable. Gardez malgré tout la voie standard comme solution de repli.

Le cœur du sujet

Ce qui traverse et ce qui ne traverse pas

Voici la répartition réelle, valable dans les deux sens. Elle tient à la nature du format d’échange, pas à une faiblesse de l’un ou l’autre logiciel.

✅ Ce qui traverse

Si l'export a été réglé pour
  • Les objets typés : un mur reste un mur, une porte une porte.
  • La hiérarchie spatiale : site, bâtiment, étages, locaux.
  • Les property sets, standards et personnalisés, s’ils ont été mappés.
  • La géométrie, avec ses relations et souvent ses quantités.
  • Le géoréférencement, à condition qu’il ait été convenu en amont.

❌ Ce qui reste derrière

Par nature, quels que soient les réglages
  • L’intelligence paramétrique : contraintes, règles de mise à jour.
  • Les familles et leur comportement, réduits à des objets figés.
  • Les vues, gabarits, feuilles et annotations propres au logiciel.
  • L’historique et la logique de conception qui a produit la forme.
  • La possibilité d’un aller-retour sans perte.

La colonne de gauche dépend de vous

Tout ce qui figure à gauche peut quand même manquer si l’export n’a pas été réglé pour l’emporter : propriétés non mappées, objets en catégorie générique, éléments non rattachés à un étage. La colonne de droite est une propriété du format ; la colonne de gauche est votre responsabilité.

La moitié oubliée

Régler l’import autant que l’export

Tout le monde travaille son export et presque personne son import. C’est pourtant une opération symétrique, et le destinataire a lui aussi des réglages qui décident de ce qu’il obtient.

Un fichier IFC arrive avec ses entités et ses property sets, et le logiciel receveur doit décider comment les interpréter : quel objet natif correspond à quelle entité, où ranger les propriétés reçues, comment traiter la hiérarchie spatiale. Ces correspondances sont paramétrables des deux côtés, et leurs valeurs par défaut ne conviennent pas toujours.

D’où une conséquence pratique : une jonction se règle à deux. Un producteur qui optimise son export sans jamais voir le résultat chez le destinataire travaille à l’aveugle, et un destinataire qui se plaint sans avoir touché ses réglages d’import se plaint à moitié pour rien.

Nommer l'intention

Référence, édition ou transfert : la réponse conditionne tout le reste. Ne réglez rien avant d’avoir tranché ce point.

Usage

Convenir du contenu attendu

Quelles propriétés doivent arriver, sur quels objets, dans quels jeux. Cet accord se prend entre les deux équipes, pas dans un logiciel.

Property sets

Régler l'export, puis l'import

Le producteur prépare son fichier, le destinataire ajuste ses correspondances d’import. Les deux réglages se conservent et se réutilisent.

Deux côtés

Tester sur un échantillon réel

Un fragment du projet en cours, jamais un fichier de démonstration. Vérifiez trois objets de trois lots, typage, rattachement et propriétés.

Preuve

Écrire la fiche de jonction

Ce qui passe, ce qui ne passe pas, quels réglages ont été retenus de chaque côté. C’est le document qui évite de refaire ce travail au prochain projet.

Documenté
Ce qui rate en général

Les cinq erreurs classiques

Elles ont un point commun : elles consistent à traiter un problème d’organisation avec des réglages de logiciel.

  1. Ne pas nommer l’intention. On lance un export sans savoir si le destinataire veut consulter ou modifier, et on juge le résultat décevant sans référence claire.
  2. Vouloir éditer un modèle importé. Cette attente produit systématiquement de la frustration, alors que la réponse honnête tient en une phrase : ce n’est pas ce que fait le format.
  3. Régler un seul côté. L’export est soigné, l’import reste par défaut, et le destinataire constate des pertes qui n’en sont pas.
  4. Tester sur un fichier de démonstration. Les cas propres passent toujours. Ce sont les objets bricolés du projet réel qui révèlent les problèmes.
  5. Ne rien documenter. Le réglage trouvé après trois jours d’essais vit dans la tête d’une personne, et le projet suivant recommence de zéro.

La suite logique

Le réglage détaillé du départ est traité dans exporter un IFC propre depuis Revit, et ce que le format transporte réellement dans le format IFC. Pour situer cette jonction dans l’ensemble de votre chaîne, voyez choisir sa chaîne d’outils. Et si la question sous-jacente est celle du choix d’un modeleur, allez voir Revit ou Archicad, ou décodez la logique interne de chacun avec Revit décodé et Archicad décodé.

Rebondir

À explorer ensuite

Les guides qui prolongent naturellement celui-ci, dans d'autres sections du site.