Le portail ne règle pas le dossier final-final

Mon irritant techno du mois tient dans trois noms de fichiers :

procedure_final.doc

procedure_final2.doc

procedure_final_vraiment.doc

Le mot portail revient beaucoup, et je comprends pourquoi. Une seule page interne pour les procédures, les annonces et les documents communs est nettement plus attirante qu’une chasse dans les lecteurs réseau et les pièces jointes. Mais une page d’accueil n’est que la façade. Pour remplacer le dossier partagé, le portail doit gérer l’identité d’un document, ses versions, ses métadonnées, ses permissions et sa recherche.

Dans un lecteur réseau, le nom et le chemin servent presque d’identité : P:\Procedures\facturation.doc. Dans une bibliothèque de portail, une rangée peut plutôt décrire le document :

DocumentId      4182
Titre           Procédure de facturation
Type            Procédure
Propriétaire    GroupeCompta
État            Publié
VersionCourante 3
RévisionPrévue  2003-08-01

Le fichier binaire est associé à cet identifiant. Quand quelqu’un le réserve (check-out), le portail marque qui prépare la prochaine version. Au check-in, il crée une version avec l’auteur, l’heure et un commentaire. Une étape d’approbation peut rendre la version 3 visible aux lecteurs pendant que la version 4 reste en travail. On ne dépend plus du mot final pour savoir ce qui est officiel.

Le trajet de publication devient explicite :

  1. l’auteur ouvre la version courante et la réserve;
  2. il dépose sa modification avec un commentaire;
  3. un responsable approuve ou refuse;
  4. le portail désigne la nouvelle version publiée;
  5. l’index de recherche extrait le texte et les métadonnées;
  6. les lecteurs trouvent la version publiée selon leurs permissions.

La recherche ne lit pas magiquement chaque document au moment où je tape un mot. Un service parcourt les bibliothèques à intervalles réguliers, extrait le contenu des formats qu’il comprend et construit un index inversé reliant les mots aux documents. Une publication peut donc être visible par son lien avant d’apparaître dans les résultats. Un fichier scanné comme image ou protégé par mot de passe peut ne produire aucun texte indexable.

Les permissions descendent souvent d’un site ou d’un dossier et peuvent être assignées à des groupes Windows. Casser l’héritage pour un seul document confidentiel semble pratique, mais mille exceptions deviennent impossibles à vérifier. Je préférerais quelques bibliothèques aux règles claires — procédures générales, ressources humaines, finances — et des groupes métier entretenus dans Active Directory.

Centraliser crée aussi un point de dépendance. Si le portail ou sa base tombe, toutes les procédures disparaissent en même temps. Il faut sauvegarder les fichiers et les métadonnées/versionnements; recopier seulement les documents bruts ne restaurera pas le workflow ni les permissions. Une restauration testée doit vérifier qu’un document, son historique et ses droits reviennent ensemble.

La facilité d’usage décidera si le système gagne contre les copies locales. Douze champs obligatoires, un vocabulaire mystérieux ou un check-out bloqué par une personne en vacances ramèneront vite les pièces jointes. Le propriétaire doit aussi recevoir une liste des documents dont la date de révision approche; sinon le portail centralise très efficacement de vieilles procédures.

Je commencerais avec une seule bibliothèque et un contrat simple : un responsable, trois métadonnées utiles, une approbation courte et une règle de version. Je migrerais un petit ensemble, testerais la recherche avec un compte ordinaire et restaurerais une version supprimée. Si les gens savent où publier et quelle copie fait autorité, le portail a réglé un vrai mécanisme. Sinon, procedure_final_vraiment2.doc aura seulement déménagé dans un navigateur.