Sur les quatre-vingts pour cent d'usages courants, les deux font le travail. Demander lequel est le meilleur n'a donc pas de réponse. La bonne question est ailleurs : quelle contrainte de votre contexte n'est pas négociable ? Voici une méthode de décision, pas un verdict.
Le débat dure depuis vingt ans, il est devenu identitaire, et il repose sur une prémisse fausse : celle d’un vainqueur général.
Les deux logiciels ont convergé. Modélisation par objets paramétriques, génération automatique des vues et des coupes, nomenclatures liées au modèle, travail collaboratif, échange par IFC : sur le tronc commun d’un projet de bâtiment, les deux font le travail, et un professionnel compétent produit d’excellents livrables avec l’un comme avec l’autre.
Ce qui les distingue ne relève donc presque jamais des fonctionnalités, mais du contexte dans lequel on les emploie : avec qui vous échangez, quels lots vous traitez en interne, à combien vous travaillez sur un même modèle, et ce que votre marché attend de vous. Ces éléments-là ne se comparent pas dans un tableau de cases à cocher.
Ne demandez pas lequel est le meilleur. Demandez : « quelle contrainte de mon contexte n’est pas négociable ? » Cette contrainte élimine généralement l’une des deux options d’elle-même, et rend la décision évidente au lieu de la rendre passionnelle.
Voici ce que chacun est, tel qu’il se comporte en projet. Aucune de ces caractéristiques n’est un défaut ou une qualité en soi : tout dépend de ce que vous en faites.
La différence est réelle et structurante. Le modèle central de Revit encaisse bien des équipes nombreuses et pluridisciplinaires. Le verrouillage élément par élément d’Archicad se révèle très confortable pour des équipes d’architecture restreintes, et ses échanges allégés aident quand les connexions sont mauvaises. Ce n’est pas un classement : ce sont deux réponses à deux situations différentes.
Ces axes pèsent bien plus lourd que n’importe quelle comparaison de fonctionnalités, parce qu’ils portent sur des contraintes que vous ne pouvez pas contourner par de la compétence.
Traitez-les en séquence. La plupart des cabinets trouvent leur réponse avant la quatrième, et les suivantes ne servent qu’à confirmer.
Client, groupe, donneur d’ordre récurrent : si une exigence contractuelle nomme un format natif ou un outil, la question est déjà tranchée. Vérifiez-le avant tout le reste.
Si vous modélisez structure et fluides vous-même, la couverture multi-métiers d’un produit unique devient un argument lourd. Si vous ne faites que de l’architecture, il s’annule.
Comptez les personnes simultanées sur une même maquette, pas les effectifs du cabinet. Les deux modèles de collaboration ne se comportent pas pareil selon ce chiffre.
Bibliothèques, gabarits, formation, perte de productivité initiale. Ce chiffre dépasse presque toujours l’écart de licence, et il est souvent le vrai décideur.
Un outil dont personne ne maîtrise l’usage dans votre région vous rendra dépendant de quelques personnes. C’est un risque de continuité, pas un détail de confort.
Aucune démonstration commerciale ne vaut un projet pilote mené par votre équipe, avec vos contraintes et vos livrables réels. C’est le seul essai qui prédit quelque chose.
Un choix fondé sur l’enthousiasme d’une personne, sur une démonstration bien menée ou sur un tableau comparatif trouvé en ligne. Ces trois sources produisent des décisions qu’on regrette au bout de dix-huit mois, quand le coût de retour arrière est devenu prohibitif.
Ils reviennent dans toutes les discussions et n’ont pratiquement aucun pouvoir prédictif sur votre satisfaction à trois ans.
Dans la majorité des situations réelles, l’outil est déjà là, imposé par un client, un groupe ou dix ans d’historique. La question devient alors : comment ne pas le subir.
La réponse tient dans l’interopérabilité. Un flux IFC maîtrisé rend l’outil de vos partenaires beaucoup moins déterminant : vous recevez, vous contrôlez, vous produisez, et vous livrez dans un format que tout le monde lit. C’est précisément la promesse des standards ouverts, et elle tient à condition de savoir régler ses exports.
Cela ne supprime pas toutes les frictions. Les allers-retours restent coûteux, certaines informations ne survivent pas aux traductions, et cela demande des règles écrites. Mais un cabinet qui maîtrise ses échanges travaille avec n’importe qui, alors qu’un cabinet qui ne jure que par son format natif se coupe d’une partie du marché.
À budget de formation égal, former votre équipe aux échanges rapporte davantage que la former à un second logiciel de modélisation. La compétence d’interopérabilité sert sur tous les projets, quel que soit l’outil retenu, et elle ne devient jamais obsolète.
Ce guide ne conclut pas, et c’est délibéré : conclure à votre place supposerait de connaître votre contexte, qui est précisément ce qui décide.
Trois idées à emporter. Les deux outils font le travail sur le tronc commun : cherchez la différence dans votre contexte, pas dans les fonctionnalités. Les critères qui décident réellement sont l’écosystème, les lots traités en interne, la taille des équipes et le coût de migration, ce dernier étant systématiquement sous-estimé. Enfin, quand le choix vous échappe, la maîtrise des échanges ouverts vous rend l’autonomie que le choix d’outil ne vous donnait pas.
Pour comprendre la logique interne de l’un des deux, voyez Revit, une base de données déguisée en logiciel de dessin. Pour l’interopérabilité qui relativise le choix, commencez par le format IFC puis exporter un IFC propre. Et si la question n’est pas de choisir mais de faire travailler les deux ensemble, c’est l’objet de passer de Revit à Archicad, et retour. Pour la logique interne d’Archicad sur ses propres termes, voyez Archicad décodé.
Les guides qui prolongent naturellement celui-ci, dans d'autres sections du site.
« 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.
Assembler le meilleur outil de chaque catégorie produit rarement la meilleure chaîne. Ce qui coûte cher n'est pas le nombre de logiciels, c'est le nombre d'endroits où l'information doit changer de main. Voici comment concevoir une chaîne au lieu de la subir.
La plupart des blocages de débutant viennent d'un malentendu : on essaie de dessiner, et Revit résiste. Il ne dessine pas, il enregistre. Comprenez ce déplacement et l'interface devient lisible, y compris les parties que vous n'avez jamais ouvertes.