Un classement logique pour qui, exactement?

Client, projet, étape, type de document, année : le même fichier peut être classé de cinq façons logiques. SharePoint offre dossiers, colonnes, types de contenu et vues. Ces mécanismes ne sont pas interchangeables.

Un dossier place le document dans un seul chemin. Une colonne lui associe une propriété indépendante du chemin. Une vue exécute un filtre et un tri sur ces propriétés; elle ne déplace pas le fichier. Un type de contenu regroupe un ensemble de colonnes, un modèle et certains comportements pour une catégorie de documents.

Document ID 731
  Type de contenu = Contrat
  Client          = Boréal
  Projet          = Refonte
  Étape           = Approuvé
  Année           = 2009

Avec ces propriétés, la même copie apparaît dans une vue « Contrats approuvés » et une vue « Projet Refonte ». Une arborescence obligerait à choisir un seul endroit ou à dupliquer le fichier.

Transformer le vocabulaire en requêtes

Je demanderais à l’équipe de retrouver dix documents réels et noterais les premiers mots employés. Si elle demande toujours « le contrat du client Boréal », Type et Client méritent probablement des colonnes. Si personne ne cherche par année, rendre Année obligatoire ajoute peu.

Une vue peut alors filtrer :

Type = Contrat AND Client = Boréal AND Étape <> Archivé
tri par Date de modification décroissante

Sur une grande liste, les colonnes utilisées pour filtrer doivent être indexées selon les capacités de la plateforme. Sinon, chaque vue examine trop d’éléments et devient lente. Un index accélère une propriété bien choisie; en créer partout augmente aussi le coût des écritures et de l’administration.

Les valeurs doivent être contrôlées. Boreal, Boréal inc. et Client Boréal représentent peut-être la même organisation. Une liste de choix ou une source de référence réduit les variantes, avec un propriétaire capable de corriger et fusionner les termes. Sans gouvernance légère, la taxonomie dérive et les vues se vident progressivement.

Une vue n’est jamais une permission. Cacher les contrats d’un client avec un filtre n’empêche pas un utilisateur de changer de vue ou d’appeler une autre page. Les documents sensibles ont besoin de groupes et de droits réels, souvent à une bibliothèque ou un site dont la frontière est claire. Les permissions uniques sur chaque fichier deviennent vite impossibles à expliquer.

Le formulaire doit rester court. Je préremplirais Projet lorsque la bibliothèque le garantit, rendrais obligatoires seulement les champs qui alimentent une action et prévoirais une vue Métadonnées incomplètes pour corriger sans bloquer tout téléversement. Une valeur vide visible vaut mieux qu’une valeur fausse choisie pour fermer la boîte.

Lors d’une migration du lecteur réseau, un script peut lire le chemin, créer les propriétés et produire un rapport de rejets. Je migrerais d’abord cent fichiers, comparerais les vues avec les dossiers d’origine et corrigerais les règles avant le lot suivant. Un import massif qui classe mal dix mille documents ne fait qu’automatiser le fouillis.

Mon test final serait celui d’une nouvelle personne : déposer un contrat, le retrouver par client, puis comprendre pourquoi elle ne voit pas un document protégé. Si elle a besoin du concepteur pour chaque étape, je réduirais les catégories avant d’écrire un manuel. La structure devient utile lorsque les mots de l’équipe se traduisent directement en propriétés, vues et frontières d’accès.