Bonjour,
Je lis quid beaucoup... (désolé, je devais faire cette blague pourrie). Et désolé pour le retard de réponse, je ne vois ce post que maintenant. J'espère qu'elle sera toujours d'actualité pour vous.
Vous demandez à savoir précisément comment cela fonctionne sous Revit. Donc, plutôt que de répondre point par point "bêtement", je vais présenter le contexte et principe du travail collaboratif sous Revit en tâchant d'être le plus exhaustif possible, afin que vous puissiez vous faire une idée des conditions et limites d'utilisation.
En prologue, Précisons que Revit inclut les fonctions nécessaires au travail collaboratif, sans nécessiter de fonctions ou outils complémentaires. La collaboration requiert une connexion internet et la présence du logiciel sur la machine de chaque intervenant (sauf à installer Revit dans un environnement Citrix XenApp ou XenDesktop). Donc, de ce point de vue, les conditions matérielles et logicielles sont exactement les mêmes, qu'il s'agisse de travailler en autonomie ou en collaboration. Comme si vous utilisez Archicad "tout seul dans votre coin".
Lorsque la fonction de collaboration est activée sur un projet, Revit génère ce qui s'appelle un
fichier central. ce fichier doit être stocké sur un serveur local (installé dans l'agence, par exemple) ou sur un serveur distant, suivant la structure (organisation et/ou répartition géographique) du groupe de travail. Dans tous les cas, il doit être accessible à tous les intervenants sur la maquette. Il peut être nécessaire de requérir à l'installation d'un serveur
Revit Server dans ce cas, mais cela ne modifie cependant pas le flux de travail et les conditions matérielles/logicielles par poste de travail ; Je n'en parlerai donc pas plus longuement ici.
A partir de ce fichier central, chaque intervenant génère son propre fichier de travail, enregistré sur sa machine. Ces fichiers sont appelés
fichiers locaux, et sont l'exacte copie du fichier central à un instant t.
Dès lors, il n'est plus question de modifier le fichier central. Chaque intervenant accède aux informations de ce fichier partagé et envoie ces propres informations par le biais d'une fonction de synchronisation des données, depuis sa copie locale. Il est donc possible pour un intervenant de travailler sur son fichier local tout en étant déconnecté du réseau puis de se reconnecter ultérieurement pour synchroniser ses données avec le fichier central. Sans rentrer dans trop de détails, cela peut tout de même engendrer des problèmes, puisqu'il existe réellement plusieurs copies simultanées de la même maquette.
Afin de structurer le projet et d'attribuer des droits aux utilisateurs, un fichier partagé se décompose en
sous-projets. Il s'agit ici de créer des jeux de travail, où chacun d'eux héberge un ou plusieurs objets de la maquette. Si, en théorie, il n'existe pas de contrainte imposée par Revit quant à la création et au nommage des sous-projets, il s'agit d'un point de vue logique du projet de créer des sous-projets conformes à la structure du groupe de travail. Il peut donc exister un sous-projet
Architecture, un second
Structure, un troisième
VRD, etc. Tout autant qu'il peut exister un sous-projet
Poteaux, un second
Dalles, etc.
Ces sous-projets contiennent en eux-mêmes plusieurs intérêts. Le premier est donc de structurer les objets de la maquette de manière logique. Le second est d'administrer les droits de propriétés et d'emprunts durant une session de travail. L'intervenant qui crée un sous-projet devient de facto le propriétaire de ce sous-projet. Tant qu'il n'a pas libéré les droits d'utilisation (lors de sa synchronisation avec le central), personne d'autre ne peut modifier ce sous-projet. Tout objet appartient forcément à un et un seul sous-projet. Lorsqu'un intervenant souhaite modifier un objet dont il n'est pas propriétaire, et si les droits n'ont pas été libérés, il peut envoyer une requête à l'actuel propriétaire ou emprunteur pour obtenir l'autorisation de modification. S'il reçoit une réponse positive, il devient le nouvel emprunteur, jusqu'à la prochaine demande d'un nouvel intervenant ou jusqu'à ce qu'il libère les droits.
L'acceptation/refus de la requête n'est pas automatique. Elle est subordonnée à une action réalisée par le propriétaire/emprunteur de l'objet. Donc, si le propriétaire n'a pas libéré ses droits avant de partir en vacances, les autres utilisateurs ne pourront pas modifier ledit objet, et le projet prend du retard (oui, j'exagère
)
En ce sens, on ne peut pas parler d'environnement client/serveur. Donc, la collaboration à plusieurs est possible, mais requiert une rigueur de travail accrue, notamment en ce qui concerne les droits sur chaque sous-projet et objets afférents et les attributions des tâches de chacun. Je précise que toute modification d'un objet (par exemple, placer une fenêtre dans un mur consiste en partie à modifier le mur) requiert de prendre les droits sur cet objet (en l’occurrence, en plus de la propriété de la fenêtre, vous devez obtenir les droits de modification du mur).
J'espère que tout ceci vous parait assez clair et précis (et indigeste ?)
