« Est-ce vraiment la dernière version? » Cette question revient assez souvent pour devenir une alerte d’architecture. Le problème n’est pas d’abord le nom version finale 2.doc; c’est le fait que chaque pièce jointe possède son propre contenu, sa propre date et aucun lien technique avec les autres copies.

Un courriel transporte un instantané. Le serveur de messagerie ne sait pas qu’il s’agit de la révision 7 du document conservé sur un lecteur réseau. Quand le destinataire modifie sa pièce jointe, il crée une branche sans historique partagé. Ajouter un portail sans changer ce trajet ajoute seulement une quatrième copie.

Je préfère séparer l’objet de sa notification. Le document possède un identifiant stable dans une bibliothèque. Le courriel contient un lien vers cet identifiant et explique pourquoi la personne doit le regarder. La conversation peut rester dans la boîte; les octets qui font foi restent au même endroit.

auteur -> bibliothèque -> document 184, version 3
                    |                |
                    +-> lien --------+-> lecteur
                    `-> alerte ----------> courriel

Le lien ne devrait pas dépendre d’un nom de fichier qui change à chaque correction. Une adresse fondée sur l’identifiant ou une page de propriété stable permet de renommer le document sans briser toutes les notifications.

Gérer deux modifications concurrentes

Une copie centrale n’élimine pas les collisions. Deux personnes peuvent ouvrir la version 3 et tenter d’enregistrer des changements différents. Le système doit choisir une stratégie :

1. extraction exclusive : une personne réserve le document;
2. détection de conflit : le second enregistrement est refusé si la version de départ a changé;
3. fusion : l’outil combine les changements lorsque le format le permet.

L’extraction est simple à comprendre, mais un utilisateur parti en vacances peut garder le verrou. La détection évite l’écrasement silencieux, mais oblige à comparer deux versions. La fusion fonctionne bien pour certains contenus et très mal pour un fichier binaire opaque. Il faut donc un propriétaire capable de libérer une extraction et un historique permettant de revenir avant une mauvaise résolution.

Les métadonnées servent ensuite à reconnaître la copie officielle. Un état Brouillon, À réviser ou Publié vaut mieux qu’un mot ajouté au nom. Une version publiée peut rester stable pendant que la suivante est préparée. Les permissions empêchent un lecteur de publier par erreur, sans lui retirer l’accès au document approuvé.

Le principal mode de panne reste humain : quelqu’un joint encore le fichier par habitude, et cette copie revient plus tard avec des corrections. Je rendrais le nouveau trajet plus court : bouton pour copier le lien, notification directe et seulement deux propriétés obligatoires. Puis je chercherais les pièces jointes résiduelles pendant un projet pilote pour comprendre où le flux est encore trop lourd.

La collaboration n’a pas besoin d’un centre pour tout. Pour un type de document important, elle a besoin d’un identifiant, d’un historique, d’un état officiel et d’un mécanisme de conflit. Quand ces quatre éléments existent, « la dernière version » devient une requête au système plutôt qu’un souvenir collectif.