budget.doc

budget_final.doc

budget_final_corrige.doc

budget_final_corrige2.doc

Chaque pièce jointe crée une copie indépendante. SharePoint m’intéresse parce qu’une bibliothèque ne traite pas seulement le document comme un fichier dans un dossier : elle lui donne un identifiant, des métadonnées, des versions, des permissions et un état de publication.

Dans Windows SharePoint Services, la page Web présente une vue de la bibliothèque. Le serveur applicatif traite les demandes et garde le contenu ainsi que ses métadonnées dans SQL Server selon l’architecture du produit. Une rangée logique peut ressembler à ceci :

DocumentId   4182
Nom          budget.doc
Titre        Budget 2006
Service      Finances
État         À approuver
Version      7
ModifiéPar   DOMAINE\stetreault
ModifiéLe    2005-05-18 14:42

La personne ouvre la version courante, peut réserver le document, puis fait un check-in avec un commentaire. La bibliothèque conserve la version précédente et peut demander une approbation avant de rendre la nouvelle visible. Le nom ne change plus à chaque correction; c’est le numéro géré par le système qui identifie l’historique.

La réservation réduit les modifications concurrentes, mais crée son propre cas limite. Si quelqu’un part en vacances avec le document en check-out, l’équipe peut rester bloquée. Un administrateur doit pouvoir reprendre la réservation avec une trace claire. Sans check-out obligatoire, deux personnes peuvent télécharger la version 7, modifier chacune leur copie et publier tour à tour; la deuxième risque d’écraser la première si le contrôle de version ne refuse pas son point de départ ancien.

Les métadonnées rendent les vues utiles. Au lieu de reproduire tout l’organigramme en sous-dossiers, une vue peut filtrer Service = Finances AND État = À approuver. Je garderais seulement les colonnes qui conduisent à une recherche, une permission, une rétention ou un workflow. Vingt champs obligatoires font gagner le courriel par forfait.

La recherche fonctionne en différé. Un composant parcourt les sites, extrait le texte des formats compris et construit un index. Un document publié à 14 h peut être accessible par son lien avant d’être trouvé par un mot-clé. Un fichier scanné en image ou chiffré ne fournit pas nécessairement de texte. Le support doit connaître l’heure du dernier crawl avant de conclure que le document a disparu.

Les permissions peuvent venir de groupes Windows et descendre du site vers la bibliothèque. Je préfère une bibliothèque distincte pour un ensemble réellement confidentiel à des centaines d’exceptions par document. Il faut tester avec un compte ordinaire, parce qu’un administrateur voit facilement des résultats que le reste de l’équipe ne peut pas ouvrir.

Mon pilote suivrait ce workflow :

1. migrer vingt budgets avec leur propriétaire et leur état;
2. annoncer que la bibliothèque devient la seule copie officielle;
3. envoyer des liens, jamais de nouvelles pièces jointes;
4. faire modifier le même document par deux personnes;
5. restaurer une ancienne version;
6. chercher par titre, contenu et service;
7. supprimer un document puis tester la récupération;
8. mesurer le nombre de copies encore échangées après un mois.

La sauvegarde doit protéger ensemble SQL Server, les fichiers/configurations et l’index ou prévoir sa reconstruction. Restaurer seulement budget.doc perdrait versions, permissions et métadonnées. Il faut aussi une politique de quota et de rétention : conserver chaque version d’un gros fichier pour toujours finira par remplir la base.

SharePoint peut tuer vraiment_final_v4.doc seulement si l’équipe accepte un mécanisme différent : un identifiant stable, une version publiée et un lien commun. Je commencerais avec une bibliothèque et une règle compréhensible, puis j’ajouterais le workflow quand la copie officielle est déjà devenue une habitude.