Logiciels BIM : Revit, Archicad, Tekla, Navisworks, Solibri… qui fait quoi ?

Sur un projet BIM, il est rare qu’un seul logiciel couvre correctement tous les besoins. Un outil d’authoring est excellent pour produire et documenter une discipline, mais moins adapté à la revue multi-modèles. Un outil de coordination sait agréger de nombreux formats, mais n’est pas fait pour modifier la maquette source. Un contrôleur IFC peut analyser finement la structure et les propriétés d’un fichier, sans pour autant remplacer Revit, Archicad ou Tekla pour la production.

Le bon raisonnement consiste donc à construire une chaîne d’outils cohérente avec les usages du projet. Dans cet article, je compare cinq logiciels fréquemment rencontrés : Revit, Archicad, Tekla Structures, Navisworks Manage et Solibri. Ce n’est pas un classement. Chacun répond à une partie différente du problème.

Avant de comparer les logiciels : distinguer les rôles

Je sépare généralement les outils BIM en quatre grandes familles. Les logiciels d’authoring servent à produire les modèles métiers et les documents associés. Les outils de coordination agrègent plusieurs modèles pour les comparer et suivre les sujets. Les outils de contrôle vérifient des règles géométriques ou informationnelles. Enfin, les plateformes de gestion et de collaboration organisent les fichiers, issues, versions et échanges.

Un même produit peut bien sûr couvrir plusieurs fonctions. Revit sait coordonner des liens, Solibri permet aussi de visualiser et quantifier, Navisworks propose des fonctions de revue et de simulation. Mais leur logique principale reste différente, et c’est cette logique qui doit guider l’architecture du workflow.

Revit : produire et documenter dans un environnement paramétrique

Autodesk Revit est un logiciel d’authoring BIM multidisciplinaire. Autodesk le positionne pour la conception, la documentation, la visualisation et la livraison de projets AEC. Il couvre l’architecture, la structure et les systèmes MEP, avec des objets paramétriques, des nomenclatures, des feuilles, des systèmes et des outils de travail collaboratif.

Son principal avantage est la forte intégration entre la maquette et la documentation. Un élément modifié dans le modèle peut affecter vues, coupes, nomenclatures et feuilles. Pour des équipes qui veulent produire dans un environnement homogène, cette cohérence est très efficace.

Revit est également extensible. Dynamo, l’API .NET et l’écosystème de plugins permettent d’automatiser des tâches qui seraient trop longues manuellement : contrôle des paramètres, codification, renommage, extraction de données, création de vues ou préparation des livrables. C’est précisément sur cette couche que des outils comme le plugin Pimp My BIM peuvent intervenir sans remplacer l’outil d’authoring.

Sa limite apparaît lorsque l’on attend de Revit qu’il devienne à lui seul une plateforme universelle. Les catégories, familles, paramètres et relations sont propres au modèle de données Revit. Lors d’un export IFC, une partie de cette structure doit être mappée vers le schéma IFC. Autodesk fournit des réglages spécifiques pour les classes, types prédéfinis, Property Sets et paramètres utilisateurs, mais la qualité de l’échange dépend toujours de la configuration choisie.

Quand Revit est particulièrement pertinent

Je le considère très adapté aux projets où la production architecturale, structure et MEP doit rester fortement liée à la documentation et aux nomenclatures, surtout lorsque les équipes travaillent déjà dans l’écosystème Autodesk. Il est également puissant lorsqu’un projet dispose d’un gabarit bien gouverné et d’une stratégie d’automatisation.

Archicad : authoring architectural et workflow openBIM solide

Graphisoft Archicad est lui aussi un logiciel d’authoring BIM, historiquement très présent côté architecture. La comparaison « Revit contre Archicad » est souvent caricaturale : les deux peuvent produire des modèles d’architecture riches, de la documentation et des données. Le choix dépend davantage du contexte de l’agence, des disciplines, des bibliothèques, des méthodes de production et de l’écosystème projet.

Archicad accorde depuis longtemps une place importante à l’IFC. La documentation Graphisoft actuelle indique la prise en charge de l’import et de l’export IFC2x3, IFC4 et IFC4.3, avec des traducteurs IFC permettant de gérer les règles de conversion. À l’import, Archicad peut ouvrir, fusionner ou hotlinker un IFC selon le besoin.

Cette souplesse est intéressante dans les projets openBIM, mais elle ne supprime pas les problèmes d’interopérabilité. Comme avec Revit, la qualité d’un échange dépend des mappings, de la structure du fichier et des exigences du destinataire. Deux applications capables de lire IFC peuvent interpréter différemment certains objets ou propriétés sans que le standard lui-même soit en cause.

Archicad est donc particulièrement pertinent pour les équipes de conception architecturale recherchant un environnement BIM intégré et une stratégie d’échanges ouverts assumée. Il ne remplace toutefois pas un outil de contrôle externe lorsqu’il faut auditer des modèles provenant de plusieurs disciplines.

Tekla Structures : quand la structure doit devenir constructible

Tekla Structures occupe une place différente. Trimble le décrit comme un environnement capable de créer, combiner, gérer et partager des modèles 3D riches en information. Dans la pratique, sa force est surtout visible lorsque la structure doit être détaillée à un niveau proche de la fabrication.

Pour l’acier, Tekla gère les assemblages, boulons, soudures, perçages, coupes et données de fabrication. La documentation 2026 mentionne notamment les exports de fichiers CN et les connexions vers des processus de fabrication. Pour le béton, il dispose d’outils de détail, de ferraillage et de préfabrication.

C’est une différence importante avec un modèle structure plus conceptuel. Sur certains projets, une maquette Revit structure suffit pour les études et la coordination. Dès que l’on descend vers le détail d’exécution, les assemblages métalliques ou la préfabrication, Tekla peut devenir la source métier principale.

La limite n’est donc pas que Tekla serait « meilleur » que Revit pour toute structure ; ce sont deux niveaux de granularité et deux usages différents. Un bureau d’études peut concevoir dans Revit et une entreprise détailler dans Tekla. Le problème BIM devient alors la continuité des identifiants, des classes, des modifications et des échanges entre ces étapes.

Navisworks Manage : agréger et coordonner sans refaire les maquettes

Navisworks Manage est principalement un outil de coordination et de revue. Son intérêt est de pouvoir fédérer des modèles issus de plusieurs logiciels et formats dans un environnement commun. On ne l’utilise généralement pas pour corriger la gaine ou le poteau source : on l’utilise pour détecter, qualifier et suivre le problème avant de revenir vers l’auteur de la maquette.

La fonction la plus connue est Clash Detective. Autodesk continue à faire évoluer ce module dans Navisworks 2026. Mais la valeur d’un workflow de clash detection ne vient pas du bouton « Run Test ». Elle dépend surtout de la qualité des jeux de sélection, des tolérances, des règles d’exclusion et du processus de traitement des résultats.

Un test « CVC contre structure » exécuté sans préparation peut générer des milliers de collisions dont une grande partie n’a aucune valeur opérationnelle. À l’inverse, des tests structurés par systèmes, zones et priorités permettent de concentrer la réunion de coordination sur les conflits réellement actionnables.

Navisworks est également utile lorsqu’un projet travaille dans l’écosystème Autodesk et veut agréger rapidement des modèles natifs ou convertis. Sa faiblesse est moins technique que méthodologique : il est facile d’en faire une « poubelle de modèles » si les versions, origines, sélections et statuts de coordination ne sont pas gérés avec rigueur.

Solibri : contrôler la qualité et la structure des IFC

Solibri est orienté revue et contrôle de modèles, avec une forte logique IFC. Sa documentation 2026 indique la prise en charge d’IFC2x3, IFC4 et IFC4.3. Il propose des règles de contrôle sur la structure des modèles, les composants, les propriétés, les quantités ou les incohérences métier.

C’est là qu’il se différencie d’un outil de clash detection classique. Une collision est une relation géométrique entre objets. Un contrôle IFC peut au contraire détecter qu’une classe est incorrecte, qu’une propriété obligatoire manque, qu’un espace n’est pas renseigné ou qu’une valeur ne respecte pas une règle attendue.

Solibri est donc particulièrement adapté à la QA BIM et à la recette de livrables openBIM. Il peut aussi produire des extractions d’information, à condition évidemment que le modèle contienne des données suffisamment structurées. La documentation Solibri précise d’ailleurs que les besoins d’information diffèrent selon les disciplines et que la fiabilité de l’information takeoff dépend directement du contenu du fichier IFC.

Sa limite est claire : Solibri ne doit pas être confondu avec un logiciel d’authoring. Il identifie un problème ; la correction reste généralement à réaliser dans l’application qui produit la maquette.

Comparatif : quel outil pour quel usage ?

Ce tableau ne doit pas être lu comme une notation absolue. Un outil peut être excellent dans un contexte et peu pertinent dans un autre. La maturité du gabarit, les compétences des équipes, les formats contractuels et les systèmes déjà déployés comptent souvent autant que le produit lui-même.

Exemple de chaîne d’outils sur un projet réel

Prenons un projet bâtiment avec architecture, structure et lots techniques. L’architecte produit dans Archicad ou Revit. Le BET structure produit son modèle d’études dans Revit, puis l’entreprise de charpente peut détailler dans Tekla. Les lots MEP produisent leurs systèmes dans Revit.

À intervalles définis, les modèles sont publiés dans le CDE. Pour la coordination spatiale, les fichiers sont fédérés dans Navisworks afin d’exécuter les clashs et préparer les sujets. En parallèle, des exports IFC sont contrôlés dans Solibri ou dans une plateforme dédiée afin de vérifier classes, Property Sets, identifiants et règles de livraison.

Les anomalies reviennent ensuite vers les équipes de production via un processus d’issues, idéalement basé sur des identifiants stables et des vues contextualisées. Le logiciel de coordination ne devient donc jamais la source de production ; il reste un système de contrôle et de décision.

Comment choisir sans tomber dans le comparatif marketing ?

Je commence par les usages et les livrables. Si le besoin principal est la conception architecturale et la documentation, le choix se joue entre environnements d’authoring. Si le besoin est le détail d’exécution de structures métalliques ou préfabriquées, le raisonnement change. Si le problème est la coordination interdisciplinaire, il faut un outil capable d’agréger et filtrer efficacement les modèles. Et si le contrat impose une qualité IFC mesurable, un moteur de contrôle devient indispensable.

Il faut ensuite tester les échanges réels. Un proof of concept de quelques objets et propriétés vaut souvent mieux que cinquante slides commerciales. Exportez un modèle test, vérifiez les classes, les quantités, les Property Sets, les coordonnées et la lecture dans l’outil destinataire. C’est le même principe que celui détaillé dans l’article sur les pertes de données IFC.

Enfin, prenez en compte la capacité d’automatisation. Un outil très performant mais impossible à intégrer à votre chaîne de contrôle peut générer beaucoup de travail manuel. Revit dispose de Dynamo et d’une API riche ; les autres environnements offrent eux aussi des interfaces et extensions. Le choix d’un logiciel doit donc inclure la manière dont les données seront extraites et auditées.

Les limites d’une approche centrée sur les logiciels

Le logiciel ne corrige pas un besoin mal défini. Aucun moteur de clash ne peut savoir si une collision est réellement critique sans règles projet. Aucun viewer IFC ne peut deviner qu’une propriété « CodeLocal » aurait dû être obligatoire si l’exigence n’a jamais été formalisée. Aucun outil d’authoring ne garantit la qualité parce qu’il contient beaucoup de paramètres.

C’est pourquoi la chaîne d’outils doit rester subordonnée au management de l’information. Les logiciels sont des moyens de produire, échanger et contrôler l’information ; ils ne remplacent ni la gouvernance, ni les exigences, ni les critères d’acceptation.

Conclusion

Revit et Archicad sont avant tout des environnements d’authoring bâtiment. Tekla Structures devient particulièrement puissant lorsque la structure doit être détaillée vers l’exécution et la fabrication. Navisworks Manage est un outil de fédération et de coordination. Solibri est particulièrement adapté au contrôle et à la qualité des modèles IFC.

Sur un projet mature, ces outils ne se concurrencent pas forcément : ils peuvent être complémentaires. L’enjeu du BIM Manager est alors de définir les interfaces entre eux, de limiter les transformations inutiles et de contrôler que l’information reste exploitable à chaque passage.