Scénarios de versions de branche

Le versionnement peut être appliqué dans le cadre de différents scénarii, en fonction des exigences professionnelles de chaque organisation. Les conditions générales pour la mise à jour des processus et des configuration de versionnement recommandées sont décrites avec les illustrations ci-dessous.

Les processus varient selon les organisations. Ils évoluent souvent selon des étapes discrètes, chaque étape nécessitant l'attribution d'un ensemble différent de ressources et de règles commerciales. Généralement, chaque étape du processus global représente une seule unité de travail telle qu’un bon de travail ou une tâche. Pour gérer ces derniers, vous pouvez créer une version distincte et isolée, et la modifier. Une fois ce travail effectué, vous pouvez intégrer les modifications à la version par défaut.

La connaissance des exigences organisationnelles et commerciales ainsi que les points clés concernant les scénarios de versions de branche vous aideront à déterminer ce qui est le mieux pour votre organisation.

Le concept de versionnement reste le même, que vous utilisiez un versionnement de branche ou un versionnement traditionnel. Le versionnement fournit des représentations multiples des données sans les copier, permet de les mettre à jour simultanément et donne la possibilité aux utilisateurs de disposer de versions pendant de longues périodes. Pour plus détails, reportez-vous à la rubrique Vue d’ensemble du versionnement.

Le versionnement de branche est un type de versionnement de géodatabase qui fonctionne avec le modèle SIG Web de ArcGIS Enterprise en utilisant une architecture basée sur les services pour permettre des processus de mise à jour multi-utilisateurs et des scénarios de transactions longues via des couches d’entités Web. Les couches d’entités Web (également connues sous le nom de services d’entités) sont des couches partagées pour afficher, interroger et mettre à jour des données sur le Web.

Voici un aperçu général du processus de versionnement de branche.

Le versionnement de branche prend en charge des classes et des tableaux d’entités simples ainsi que des jeux de données de géodatabase plus complexes tels que les réseaux de distribution et les ateliers parcellaires dans une géodatabase d’entreprise. Il est important de préparer correctement le jeu de données pour qu’il puisse s’adapter aux divers processus accessibles via les couches d’entités Web qui contiennent les données inscrites en tant que branche versionnée. et publiées à partir d’une géodatabase d’entreprise. Une fois que les couches d’entités Web ont été publiées, le versionnement de branche vous permet de suivre les opérations d’insertion, de mise à jour et de suppression sur les entités d’une version.

Pour obtenir la liste complète des types de données pris en charge par le versionnement de branche, reportez-vous à la rubrique Options de processus de mise à jour.

Si vos données sont inscrites en tant que branche versionnée et que la fonction Version Management (Gestion des versions) n’est pas activée, toutes les opérations comme l’interrogation et la mise à jour se font sur la version par défaut publiée. Vous ne pouvez utiliser aucune des opérations de Version Management (Gestion des versions) comme la création, la modification, la suppression de versions ou la réconciliation et réinjection de versions.

Pour en savoir plus sur les éléments à prendre en compte lors de la mise à jour des services d’entités.

Considérations générales

Gardez les points suivants à l’esprit lorsque vous envisagez de recourir au versionnement de branche :

• Pour mettre à jour les versions de branche, elles doivent être accessibles via une couche d’entité Web, et l’utilisateur du portail doit se voir attribuer un rôle qui inclut le privilège de mise à jour. La mise à jour n’est pas disponible si vous accédez directement aux jeux de données de branche versionnée à partir de la connexion à une base de données.
• Les versions de branche ne sont disponibles que dans la couche d’entités Web dans laquelle elles ont été créées.
• Lorsque vous définissez les autorisations d’accès aux versions, tenez compte de la stratégie de processus de la version ainsi que des besoins des différents utilisateurs de la structure.
• La propriété des versions est basée sur l’utilisateur actif du portail. Les privilèges de l’utilisateur du portail déterminent également les versions que l’utilisateur peut consulter, mettre à jour et gérer.
• La résolution des conflits pour les données de branche versionnée peut être gérée sur plusieurs sessions.
• Les processus d’administration des versions sont rationalisés grâce à un modèle de données simplifié. Alors que les opérations de réconciliation et de réinjection sont toujours effectuées pour mettre à jour les versions par défaut, l’opération de compression n’est plus nécessaire pour les jeux de données de branche versionnée. Les mises à jour sont suivies grâce à l’archivage, ce qui permet de stocker toutes les mises à jour dans la table de base du jeu de données.

Mise à jour de la version par défaut

La version par défaut est la version publiée à laquelle les utilisateurs accèdent lorsqu’ils travaillent avec des données de branche versionnée. C’est la version initiale à laquelle la plupart des utilisateurs sont exposés lorsqu’ils consomment des couches d’entités Web via des services.

Pour mettre à jour des données faisant partie d’une branche versionnée, vous devez y accéder via une couche d’entités Web. Lorsque vous mettez à jour des couches avec la fonction de Version Management (Gestion des versions), les mises à jour sont immédiatement enregistrées dans la source de données sous-jacente. La version par défaut peut toujours avoir plusieurs éditeurs (par exemple plusieurs administrateurs), bien que ce soit le paramétrage du niveau d’accès à la version qui détermine qui peut accéder et mettre à jour cette version. Lorsque l’accès à la version est défini sur public, tous les utilisateurs du portail peuvent directement modifier la version par défaut et les éditeurs peuvent y injecter des mises à jour. La mise à jour de la version par défaut de la branche est équivalente à des transactions courtes standard de la base de données. Lorsque vous mettez à jour la version par défaut de la branche, votre première mise à jour de la session initie la transaction et chaque opération de mise à jour que vous exécutez est automatiquement validée dans la base de données en tant que transaction unique, sans qu’il soit nécessaire de sauvegarder les mises à jour. Les modifications que vous apportez sont disponibles pour tous les autres utilisateurs et applications qui accèdent à la couche d’entités Web à partir de la version par défaut lorsque votre transaction est terminée.

Si l’accès à la version par défaut (orange) est défini sur public, les éditeurs peuvent directement mettre à jour la version par défaut, qui est la version publiée. Les Viewers qui accèdent à cette couche d’entités Web publiée (service d’entités) avec VMS activé voient également les mises à jour apportées à la version par défaut.

Lors de la publication de données de branche versionnée, l’éditeur peut activer la fonction Version Management (Gestion des versions). Le service de gestion des versions (VMS) présente les opérations de Version Management (Gestion des versions) nécessaires pour prendre en charge les couches d’entités Web qui fonctionnent avec les jeux de données de branches versionnées.

L’accès aux versions est basé sur une combinaison des privilèges de l’utilisateur actif du portail et de l’autorisation d’accès à la version. Les privilèges des utilisateurs du portail et le niveau d’autorisation d’accès à la version (public ou protected [protégé]) de la version par défaut déterminent les types de processus de mise à jour autorisés.

• public : tous les utilisateurs du portail peuvent directement mettre à jour la version par défaut et les éditeurs peuvent y injecter des mises à jour.
• protected (protégé) : seuls les utilisateurs qui sont administrateur de la version (les utilisateurs du portail ayant des privilèges plus élevés) peuvent mettre à jour ou réinjecter des mises à jour directement dans la version par défaut. Les éditeurs doivent d’abord créer une version nommée pour pouvoir mettre à jour.

Eléments à prendre en compte

Tenez compte des points suivants lorsque vous mettez à jour une version par défaut :

• Plusieurs utilisateurs peuvent mettre à jour la version par défaut simultanément.
• Lorsque vous mettez à jour la version par défaut avec la fonction Version Management (Gestion des versions) activée, vous ne pouvez pas annuler et refaire les mises à jour.
• Aucune détection de conflit n’est appliquée lors de la mise à jour de la version par défaut. Lorsqu’un utilisateur met à jour une entité et l’enregistre, et qu’un autre utilisateur met à jour la même entité et enregistre les mises à jour, la dernière mise à jour apportée remplace la première.

Mettre à jour une version nommée

Si vous gérez plusieurs projets, bons de travail ou tâches, vous devez adopter une approche structurée pour la gestion des workflows. Les unités de travail discrètes comprenant plusieurs sessions de mise à jour et s’étalant sur de nombreux jours, semaines ou mois peuvent être gérées sans modifier la version par défaut. Un programme de rénovation d’autoroute, l’installation d’un nouveau service téléphonique ou un projet de maintenance de gazoduc en cours sont des exemples d’unités de travail discrètes. Lorsqu’un bon de travail ou un projet est lancé, vous pouvez créer une version nommée à partir de la version par défaut, pour isoler les mises à jour.

Le versionnement de branche comprend une hiérarchie de versions simplifiée qui permet de créer un seul niveau de versions nommées à partir de la version de branche par défaut. Par défaut, le niveau d’accès à la version de branche versionnée par défaut est défini sur public. Pour utiliser les jeux de données de branche versionnée dans une version nommée et les faire participer aux processus de versionnement, activez la fonction Version Management (Gestion des versions) lorsque vous publiez le service. Une fois activé, le service de gestion des versions (VMS) permet de créer, de modifier et de supprimer des versions, ainsi que de réconcilier et réinjecter les mises à jour des versions, ce qui est nécessaire pour prendre en charge les couches d’entités Web qui fonctionnent avec des jeux de données de branche versionnée. Vous pouvez créer une version nommée pour fournir aux éditeurs leur propre vue unique et isolée afin de travailler avec les mêmes données en même temps.

Si l’accès à la version par défaut (orange) est défini sur Public, les éditeurs peuvent mettre à jour la version par défaut directement ou créer et modifier une version nommée, telle que la version A (verte) ou la version B (violette). Les éditeurs peuvent ensuite réconcilier (R) et injecter (P) leurs mises à jour apportées à la version par défaut publiée. Les Viewers qui accèdent à cette couche d’entités Web publiée (service d’entités) avec VMS activé voient les mises à jour apportées à ou injectées dans la version par défaut.

Si vous avez choisi une stratégie dans laquelle personne ne met à jour directement la version par défaut, l’administrateur de la géodatabase peut modifier les propriétés de la version et définir le niveau d’accès à la version sur protected (protégé), ce qui permet aux utilisateurs de continuer à voir la version par défaut mais limite leur niveau d’accès à la lecture seule. L’éditeur qui souhaite modifier les données doit créer une version nommée.

Si l’accès à la version par défaut (orange) est défini sur protégé, les éditeurs peuvent uniquement mettre à jour une version nommée, comme la version A (vert) ou la version B (violet). Les éditeurs peuvent réconcilier (R) et réinjecter (P) leurs mises à jour dans la version par défaut protégée et les Viewers qui accèdent à cette couche d’entités Web publiée (service d’entités) avec VMS activé voient les mises à jour apportées à la version par défaut.

Lorsqu’une couche d’entités Web dont la fonction Version Management (Gestion des versions) est activée est initialement ajoutée à la carte à partir d’une connexion au portail, la version par défaut est utilisée. Cependant, vous pouvez utiliser la boîte de dialogue Change Version (Changer de version) pour basculer d’une version à l’autre. Lorsque vous mettez à jour une couche d’entités Web avec la fonction Version Management (Gestion des versions) activée, vous pouvez mettre à jour soit la version par défaut, soit une version nommée si elle existe. Pendant la mise à jour d’une version nommée, vous pouvez annuler et rétablir chaque mise à jour et enregistrer ou ignorer des groupes de mises à jour. Pour accéder à ces fonctions de mise à jour dans une version nommée, la version en cours de mise à jour doit être isolée des autres éditeurs et des utilisateurs dotés du rôle de consultation. Pour ce faire, ArcGIS Pro prévoit des mécanismes de verrouillage visant à limiter l’accès aux versions en mode d’affichage ou de mise à jour.

Le modèle de verrouillage autorise plusieurs Viewers mais un seul Editor sur le principe suivant :

• Lorsqu’un utilisateur doté du rôle éditeur commence à effectuer une mise à jour d’une version nommée, un verrouillage exclusif est mis en place et aucun autre utilisateur ne peut se connecter à cette version pendant la session de mise à jour.
• Au moment où un éditeur commence la mise à jour d’une version nommée, il doit être le seul utilisateur connecté à la version.

La définition de l’accès à la version sur le mode private (privé) lors de la création d’une version nommée permet d’éviter le blocage de la version pour la mise à jour. Une version nommée définie sur private (privé) empêche les autres utilisateurs de se connecter à cette version. Les utilisateurs ayant des privilèges élevés (par exemple l’administrateur du portail et l’administrateur de versions) ne sont pas affectés par cette restriction.

Si l’accès à la version par défaut (orange) est défini sur protégé, les éditeurs peuvent uniquement mettre à jour une version nommée, comme la version A (vert) ou la version B (violet). Pour empêcher d’autres utilisateurs de se connecter à leur version nommée, les éditeurs peuvent régler l’accès à leur version nommée sur privé. Une fois que les éditeurs ont réconcilié (R) et réinjecté (P) leurs mises à jour dans la version par défaut protégée, les Viewers qui accèdent à cette couche d’entités Web publiée (service d’entités) avec VMS activé voient les mises à jour apportées à la version par défaut.

Lorsque toutes les modifications apportées au bon de travail, à la tâche ou au projet sont terminées, vous pouvez effectuer une réconciliation pour récupérer les mises à jour de la version par défaut et résoudre tout conflit découvert. Le versionnement de branche permet de gérer les conflits sur plusieurs sessions de mise à jour, d’examiner et de résoudre ces conflits, de vous interrompre et de continuer ultérieurement. Vous pouvez examiner les conflits un par un et, si nécessaire, apporter les modifications nécessaires. Dès que cette opération est terminée, l’administrateur des versions peut réinjecter les mises à jour dans la version par défaut protégée, en les intégrant dans la version par défaut. La version nommée peut alors être supprimée.

Eléments à prendre en compte

Tenez compte des points suivants lorsque vous mettez à jour une version nommée :

• Le versionnement de branche comprend une hiérarchie de versions simplifiée qui permet de créer un seul niveau de versions nommées à partir de la version par défaut.
• Un seul éditeur par version de branche et plusieurs lecteurs est autorisé. Lorsqu’un éditeur commence à effectuer une mise à jour dans une version de branche, un verrouillage exclusif est mis en place et aucun autre utilisateur ne peut se connecter à la version.
• Les fonctions d’annulation et de rétablissement sont disponibles lorsque vous travaillez dans une version nommée.
• Les opérations de réconciliation et de réinjection sont effectuées en utilisant la version par défaut comme version cible ; vous ne pouvez pas effectuer de réconciliation ou de réinjection en utilisant une autre version nommée.
• Comme le modèle de versionnement de branche est un modèle temporel dans lequel tous les enregistrements et les mises à jour sont suivis dans la même table de base, il n’est pas nécessaire de procéder à une compression.

Prise en charge des éditeurs et des Viewers

Si votre organisation doit prendre en charge plusieurs niveaux d’utilisateurs, chacun d’entre eux devant effectuer des opérations différentes, l’approche recommandée consiste à créer un service pour chaque niveau d’utilisateurs. Par exemple, vous pouvez avoir un groupe d’éditeurs et de Viewers qui ont besoin d’un accès en lecture seule au système. Dans ce scénario, vous pouvez prendre en charge ces éditeurs et Viewers en publiant deux couches d’entités Web (services d’entités) de la même classe d’entités sous-jacente inscrites en tant que branche versionnée.

Une fois que les éditeurs réinjectent les mises à jour de la version par défaut (orange) dans la couche d’entités Web modifiable (service d’entités), ces mises à jour sont reflétées dans la classe d’entités sous-jacente inscrite en tant que branche versionnée. Elles sont visibles pour les Viewers qui accèdent à la couche d’entités Web non éditable (vert), car cette couche d’entités Web est également publiée à partir de la même classe d’entités sous-jacente.

• La première couche d’entités Web est publiée en tant que couche d’entités Web modifiable avec la fonction Version Management (Gestion des versions) activée et est créée dans le but d’être partagée uniquement avec les éditeurs de l’organisation pour qu’ils puissent effectuer des mises à jour.
• Une deuxième couche d’entités Web est publiée avec la fonction de requête activée et les opérations de création, de mise à jour, de suppression, d’exportation et de synchronisation sont désactivées. Cette couche d’entités Web, pour laquelle la mise à jour n’est pas activée, est publiée dans le but de fournir un service non éditable à partager avec les Viewers qui souhaitent avoir une vue en lecture seule des données publiées.

  Remarque :

  Lors de la préparation des données pour la publication d’un service d’entités, l’utilisateur de géodatabase connecté doit être le propriétaire des données et la géodatabase doit être inscrite en tant que répertoire de données. Pour le versionnement de branches, la propriété de la version est basée sur l’utilisateur actif du portail. Si vous envisagez d’utiliser la couche d’entités Web uniquement pour la mise à jour ou la consultation, l’utilisateur de votre portail doit se voir attribuer un rôle avec le privilège de mise à jour ou de consultation.

Une fois que la première couche d’entités Web est publiée, les éditeurs peuvent soit modifier la version par défaut de la branche, soit modifier une version nommée et la réinjecter dans cette couche d’entités Web modifiable en utilisant la version par défaut. Une fois les modifications effectuées ou réinjectées dans la version par défaut, elles sont immédiatement disponibles et peuvent être publiées dans une couche d’entités Web distincte, la fonction d’interrogation étant activée et les opérations de création, de mise à jour, de suppression, d’exportation et de synchronisation étant désactivées. Lorsque vous publiez cette couche d’entités Web pour laquelle la mise à jour n’est pas activée, vous pouvez laisser la fonction Version Management (Gestion des versions) désactivée.

Lorsque des mises à jour supplémentaires sont apportées à la version par défaut dans la couche d’entités Web modifiable, ces modifications sont immédiatement visibles dans la version par défaut de la couche d’entités Web en lecture seule qui est disponible pour le groupe d’utilisateurs ayant reçu le rôle de consultation.

Eléments à prendre en compte

Tenez compte des points suivants lors de la prise en charge des éditeurs et des Viewers :

• Couche d’entités Web modifiable
  • La couche d’entités Web modifiable aura la fonction Version Management (Gestion des versions) activée et ne sera partagée qu’avec les éditeurs de l’organisation. Ils peuvent créer, modifier et supprimer des versions, ainsi que faire des mises à jour et effectuer des opérations de réconciliation et de réinjection.
• Couche d’entités Web non modifiable avec seulement la fonction d’interrogation activée
  • La couche d’entités Web non modifiable, avec seulement la fonction Query (Requête) activée, ne peut être partagée qu’avec les utilisateurs qui ont un accès en lecture seule aux données. Les Viewers ne peuvent accéder qu’à la version par défaut de ce service en requête seule, car le serveur de gestion des versions n’est pas activé.
  • L’opération Query (Requête) est requise pour que les Viewers puissent afficher les données dans la couche d’entités Web. C’est pour cette raison que l’opération Query (Requête) est activée lorsque vous effectuez une publication depuis ArcGIS Pro et qu’elle ne peut pas être désactivée.

Étapes de projet

Dans une organisation, les systèmes de gestion des bons de travail et le processus d’attribution d’un bon de travail passent par plusieurs étapes. Beaucoup de projets se déroulent selon un certain nombre d'étapes prescrites et réglementées nécessitant une phase d'ingénierie, d'administration, ou d'approbation légale avant de passer à l'étape suivante. Ces étapes peuvent comprendre la conception initiale proposée, la construction, l’étude sur le terrain, la construction conforme à l’exécution et l’achèvement du projet. À chaque étape d’un projet, des mises à jour peuvent être effectuées plusieurs fois sur des sous-ensembles de données. Ce processus est essentiellement cyclique : un bon de travail est initialement attribué à un ingénieur, modifié dans le temps au fur et à mesure des étapes du projet, avant intégration complète à la base de données de production. Il se peut que la dernière tâche de chaque étape exige qu’un administrateur se charge de l’assurance qualité (QA) et du contrôle qualité (QC) ou d’une étape de validation avant la réinjection.

Dans le scénario suivant, une version unique nommée Proposed est créée à partir de la version par défaut et représente l’étape de proposition dans ce processus. Une fois les mises à jour effectuées dans cette étape de proposition, l’utilisateur change la propriété de la version et l’attribue à l’utilisateur ayant le rôle d’administrateur. L’utilisateur administrateur examine et complète le processus de validation QA/QC, puis réconcilie et réinjecte les mises à jour dans la version par défaut protégée. Une fois réinjectée, la version Proposed peut être supprimée.

Un éditeur peut créer une version nommée appelée Proposed (vert) et procéder à une réconciliation (R) de la version nommée Proposed à partir de la version par défaut protégée. Pendant que l’éditeur (vert) met à jour la version nommée Proposed, les Viewers voient ce qui est publié à partir de la version par défaut (orange). Une fois que l’éditeur a terminé la mise à jour et changé la propriété de la version sur l’utilisateur admin (bleu) pour compléter le processus QA/QC, l’utilisateur admin réconcilie (R) et réinjecte (P) les mises à jour en utilisant la version par défaut. Une fois que les mises à jour sont réinjectées dans la version par défaut, les Viewers voient les nouvelles mises à jour lorsqu’ils accèdent à cette couche d’entités Web publiée.

Par la suite, une version unique appelée Constructed est créée à partir de la version par défaut pour représenter l’étape de construction de ce processus. Une fois les mises à jour effectuées dans cette étape de construction, l’utilisateur change la propriété de la version et l’attribue à l’utilisateur ayant le rôle d’administrateur. L’utilisateur administrateur examine et complète le processus de QA/QC, puis réconcilie et réinjecte les mises à jour dans la version par défaut protégée. Une fois réinjectée, la version Constructed peut être supprimée.

Un éditeur peut créer une version nommée appelée Constructed (violet) et procéder à une réconciliation (R) de la version nommée Constructed à partir de la version par défaut protégée. Pendant que l’éditeur (violet) met à jour la version nommée Constructed, les Viewers voient ce qui est publié à partir de la version par défaut (orange). Une fois que l’éditeur a terminé la mise à jour et changé la propriété de la version sur l’utilisateur admin (bleu) pour compléter le processus QA/QC, l’utilisateur admin réconcilie (R) et réinjecte (P) les mises à jour en utilisant la version par défaut. Une fois que les mises à jour sont réinjectées dans la version par défaut, les Viewers voient les nouvelles mises à jour lorsqu’ils accèdent à cette couche d’entités Web publiée.

Ce processus de cycle de vie consiste à générer des versions nommées, à effectuer les mises à jour, à changer la propriété de la version sur l’utilisateur administrateur qui complète alors le processus QA/QC et effectue la réconciliation et les réinjections en utilisant les versions par défaut successives jusqu’à l’étape finale.

Eléments à prendre en compte

Tenez compte des points suivants lorsque vous suivez les étapes de projet :

• Ce processus de QA/QC peut comprendre les éléments suivants :
  • Règles attributaires : les règles attributaires améliorent l’expérience de mise à jour et l’intégrité des données des jeux de données des géodatabases. Il s’agit de règles définies par l’utilisateur qui peuvent être utilisées pour renseigner automatiquement des attributs, restreindre des mises à jour non valides lors d’opérations de mise à jour et effectuer des contrôles QA sur des entités existantes.
  • ArcGIS Data Reviewer : Data Reviewer vous permet de gérer les données pour la production et l’analyse des données en fournissant un système d’automatisation et de simplification du contrôle de la qualité des données qui peut améliorer l’intégrité des données. Data Reviewer comprend un ensemble d’outils de contrôle qualité qui permettent un processus efficace et cohérent d’examen des données, comme l’analyse des valeurs d’attribut des tables et des relations spatiales entre les entités.
  • Workflow Manager : Workflow Manager vous permet de rationaliser et de normaliser vos processus commerciaux, qui peuvent être représentés sous la forme d’un flux de travail utilisant une série d’étapes reliées par des chemins dans Workflow Manager. En organisant et clarifiant les tâches, les processus garantissent qu’aucune étape n’est oubliée. Les informations sont automatiquement enregistrées pour chaque activité et des outils sont fournis pour générer des rapports d’information sur chaque tâche. Workflow Manager comprend des outils permettant d’allouer des ressources et de suivre le statut et l’avancement des tâches. Diverses notifications par courrier électronique sont fournies pour informer les utilisateurs, entre autres activités, des tâches qui leur sont assignées, des tâches réalisées et des données spatiales mises à jour.

Gestion répartie des données

Vous pouvez prendre en charge les processus d’édition mobile en utilisant ArcGIS Collector ou, dans ArcGIS Pro, en utilisant le bouton Download Map (Télécharger la carte).

Lorsque vous travaillez avec des données de branche versionnée et des éditeurs mobiles, apprenez à utiliser et manipuler des données de branche versionnée dans des services d’entités que vous mettez hors connexion.

La collaboration distribuée prend également en charge les couches d’entités Web, y compris celles qui s’exécutent sur des données de branche versionnée. Elle permet aux couches d’entités Web activées pour la synchronisation d’être partagées sous forme de copie lorsque les couches d’entités Web partagées dans le cadre de la collaboration fonctionnent sur des copies séparées des données. Pour en savoir plus sur le processus de collaboration et les concepts de la collaboration, reportez-vous à la rubrique Comment fonctionne la collaboration.