Les répertoires réseau partagés - peu adaptés au travail de groupe
Les répertoires réseau partagés sont une solution inadaptée pour la documentation d'équipe. Pourquoi ils posent problème et quelles alternatives choisir pour collaborer.
Définition
Section intitulée « 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
Section intitulée « 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 manipulant des fichiers texte :
| Mode de défaillance | Répertoire réseau partagé | Système de Gestion de versionsEnregistrement de chaque modification d'un ensemble de fichiers, qui permet de restaurer n'importe quel état antérieur, de comparer les changements et de travailler à plusieurs en parallèle. Git est le logiciel de gestion de versions le plus répandu ; en docs-as-code, la documentation est placée sous gestion de versions à côté du code du produit.Voir dans le glossaire → |
|---|---|---|
| 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
Section intitulée « Pourquoi les sauvegardes ne suffisent pas »Même fréquemment sauvegardés, les répertoires ne sont pas un RéférentielL'endroit où une équipe documentaire conserve ses sources : répertoires partagés, base de données d'un CMS ou système de gestion de versions comme Git, qui conserve en outre l'historique complet de chaque fichier. Un référentiel Git est aussi appelé dépôt.Voir dans le glossaire → 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
Section intitulée « 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 ? 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.