Sur un mandat ce mois-ci, on déploie SharePoint 2007 — MOSS, dans le jargon — pour une couple d’équipes qui veulent « enfin arrêter de s’envoyer des fichiers par courriel ». Comme architecte-développeur chez Fujitsu, c’est moi qui dois traduire ce souhait-là en quelque chose de solide. Pis c’est là que je vois revenir le même piège que je vois revenir à chaque plateforme collaborative : on installe vite, on structure jamais.

Le client est content le premier jour. Le site monte, t’as des bibliothèques de documents, t’as des listes, tu peux téléverser. Beau. Sauf que deux semaines plus tard, t’as déjà trois dossiers qui s’appellent « Final », un autre qui s’appelle « Final_v2 », pis personne sait c’est lequel le vrai. Le problème, c’est jamais la techno. C’est qu’on a copié le bordel du lecteur réseau dans un outil neuf, en espérant que l’outil règle le bordel tout seul. Il le fait pas.

Mon réflexe d’architecte, c’est de poser les règles avant d’ouvrir les portes. Qui a le droit de créer un site ? Qui est propriétaire d’une bibliothèque ? C’est quoi nos métadonnées obligatoires ? Comment on nomme les affaires ? Ça a l’air plate, mais c’est ça qui fait la différence entre un SharePoint qui aide pis un SharePoint qui devient un nouveau dépotoir.

Voici, en gros, la gouvernance légère que je propose au client.

flowchart TD
    A[Demande d'un nouvel espace] --> B{Type de besoin?}
    B -->|Projet temporaire| C[Site projet avec date de fin]
    B -->|Équipe permanente| D[Site d'équipe + propriétaire nommé]
    C --> E[Métadonnées obligatoires]
    D --> E
    E --> F[Permissions par groupe, jamais par personne]
    F --> G[Revue trimestrielle]

Le point qui me tient à cœur, c’est les métadonnées. Au lieu de classer les documents dans quinze sous-dossiers de profondeur, on met des colonnes : type de document, projet, statut. Après, les vues filtrent toutes seules. Un utilisateur arrive, il clique sur « mes documents en cours », pis il voit juste ça. Ça change la vie du monde, mais faut le penser d’avance, parce que rajouter des métadonnées sur 4 000 documents déjà téléversés, c’est un autre genre de party.

Côté technique, je garde les permissions propres. La règle que je martèle à l’équipe : on donne jamais un droit à une personne directement, toujours à un groupe. Sinon, dans six mois, personne se rappelle pourquoi un tel a accès à telle affaire. Quand on bâtit une fonctionnalité personnalisée, on reste dans le moule de l’objet SPWeb au lieu de bricoler à côté.

// On parcourt proprement les groupes, jamais les utilisateurs un par un
using (SPSite site = new SPSite("http://portail/projets"))
using (SPWeb web = site.OpenWeb())
{
    foreach (SPGroup group in web.SiteGroups)
    {
        // Chaque accès passe par un groupe identifiable
        Console.WriteLine(group.Name + " : " + group.Users.Count + " membre(s)");
    }
}

Là où ça brasse, c’est dans la conduite du changement. La techno se déploie en une journée; les habitudes, ça prend des mois. Le monde a passé dix ans à sauvegarder sur leur bureau pis à s’envoyer des pièces jointes. Leur dire « checkez-out le document avant de le modifier », faut le répéter, le montrer, l’accompagner. Pis faut accepter qu’au début, ça va être croche. Pas très glorieux, mais c’est la vraie vie d’un déploiement.

Le risque que je nomme tout de suite au client, c’est l’emballement. SharePoint 2007 fait beaucoup d’affaires : portail, recherche, workflow, formulaires. La tentation, c’est de tout ouvrir d’un coup. Mauvaise idée. On commence par le cas le plus simple — la bibliothèque de documents d’une équipe — on le fait bien, on le stabilise, pis on grandit. Un petit succès qui tient, ça convainc plus qu’un gros chantier qui plante.

Ce que je retiens de ce mandat-là, c’est qu’une plateforme collaborative, c’est moins un projet techno qu’un projet d’organisation. L’outil donne la structure, mais c’est le monde qui doit décider comment ils veulent travailler ensemble. Mon job d’architecte, c’est de leur donner un cadre assez clair pour les guider, mais assez léger pour pas les étouffer.

La suite, je la vois sobre : ajuster les métadonnées selon ce que le monde cherche vraiment, simplifier les vues, pis garder une revue régulière pour éviter que le beau site neuf redevienne un fouillis. Parce que SharePoint, livré tout seul, règle rien. Bien pensé, par exemple, ça peut vraiment remettre de l’ordre dans une équipe.