# Les répertoires réseau partagés - peu adaptés au travail de groupe

## Définition

Les fichiers partagés par une équipe de rédaction technique sont souvent stockés dans un répertoire partagé sur le réseau.

## Compromis

Les rédacteurs techniques travaillent directement sur les fichiers partagés, ce qui pose les problèmes suivants. Chacun a son pendant dans un [système de gestion de versions](https://docs.redaction-technique.org/fr/tech-writing-process/version-control-systems/) manipulant des fichiers texte :

| Mode de défaillance | Répertoire réseau partagé | Système de gestion de versions |
|---|---|---|
| **Défaillance du réseau** | Risque de pertes de données | Pas de risque de pertes de données |
| **Travail off-line (déconnecté)** | Possibilités limitées | Possibilités poussées |
| **Accès concurrent** | Verrouillage des fichiers par les membres de l'équipe qui les ont ouverts | Non-verrouillage des fichiers par les membres de l'équipe qui les ont ouverts |
| **Restauration** | Répertoire par répertoire, à partir de sauvegardes souvent seulement quotidiennes | Très fine, dans le temps et en termes de quantité de travail |

## Pourquoi les sauvegardes ne suffisent pas

Même fréquemment sauvegardés, les répertoires ne sont pas un référentiel sûr pour les données :

- **Une granularité grossière.** La granulométrie de la sauvegarde est le répertoire, sa fréquence n'est souvent que quotidienne.
- **Une restauration qui échappe au rédacteur.** En cas de perte de données, la restauration se fait répertoire par répertoire, et non fichier par fichier et porte sur des versions dont l'ancienneté dépend de l'administrateur système, et non du rédacteur technique.
- **Des recherches sources d'erreurs.** Fouiller dans les archives est une opération fastidieuse qui peut elle-même être source d'erreurs : en l'absence d'une comparaison fiable et aisée entre plusieurs versions des fichiers, le rédacteur technique peut facilement supprimer des modifications qu'il aurait souhaité conserver en voulant en restaurer d'autres.

## Travailler sur une copie locale ne règle rien

Copier un fichier du réseau pour le modifier sur son disque dur personnel, puis écraser la version du réseau par la version locale est une opération des plus périlleuses :

- **Aucune notification.** Les membres de l'équipe ne sont pas informés du fait qu'un autre membre modifie ou non le même fichier en même temps qu'eux ; l'un des rédacteurs techniques devra alors renoncer à toutes ses modifications. [Quel référentiel pour le travail de groupe ?](https://docs.redaction-technique.org/fr/tech-writing-process/which-repository-for-group-work/) décrit un scénario similaire.
- **Des versions anciennes qui écrasent les récentes.** Lors d'une copie manuelle des fichiers, que ce soit *via* un gestionnaire de fichiers graphique ou en ligne de commande, le rédacteur technique peut facilement écraser la version la plus récente par la plus ancienne.

On préférera alors avoir recours à un logiciel de synchronisation de fichiers tels que rsync ou Unison (ce dernier étant plus adapté à la synchronisation bidirectionnelle) en ligne de commande sous GNU/Linux ou Windows, ou à un équivalent graphique, tel FreeFileSync. Cependant, ce type de logiciels se base sur la date de dernière modification des fichiers.

> **Note: Exemple : les livres FrameMaker**
>
> Lorsque l'on met à jour ou publie un livre FrameMaker, notamment, se fonder sur la date de modification peut créer des conflits entre fichiers, FrameMaker enregistrant dans ces cas tous les fichiers du livre, même si leur contenu n'a pas été modifié.

## Articles connexes

- [Quel référentiel pour le travail de groupe ?](https://docs.redaction-technique.org/fr/tech-writing-process/which-repository-for-group-work/)
- [Référentiel](https://docs.redaction-technique.org/fr/tech-writing-process/repository/)
- [Un référentiel unique ?](https://docs.redaction-technique.org/fr/tech-writing-process/single-repository/)

---

Source: https://docs.redaction-technique.org/fr/tech-writing-process/shared-network-directories/