Je commence un nouveau rôle et mon premier réflexe demeure celui du développeur : ouvrir l’outil, créer quelque chose et vérifier si ça marche. SharePoint se prête dangereusement bien à ce réflexe. On choisit un modèle, un titre et une adresse; quelques secondes plus tard, un site d’équipe apparaît.

Ce bouton ne crée pourtant pas juste une page. Dans une installation SharePoint de cette génération, la requête arrive à IIS, passe dans ASP.NET et dans les composantes SharePoint, puis inscrit la nouvelle structure dans SQL Server. Le site reçoit des listes, des bibliothèques, des pages, des groupes et des règles d’accès héritées de son parent. Les documents ajoutés ensuite ne sont pas simplement copiés dans un répertoire Windows : leur contenu et leurs propriétés sont conservés dans une base de contenu.

Le trajet ressemble donc plutôt à ceci :

Navigateur -> IIS / SharePoint -> site et listes -> base de contenu SQL Server
                  |                    |
                  |                    +-> versions, métadonnées, permissions
                  +-> identité Windows et groupes

Le modèle de site explique comment construire le contenant. Il n’explique pas pourquoi il existe, qui en répond ni combien de temps ses données doivent rester. C’est là que mon regard d’architecte commence à dépasser le bouton.

Une frontière de sécurité qui peut devenir floue

Prenons un site de projet créé sous un portail de département. Au départ, il hérite des groupes du parent : lecteurs, membres et propriétaires. Quelqu’un brise ensuite l’héritage pour protéger un budget, puis accorde un accès direct à trois personnes. Une autre personne crée une sous-bibliothèque avec ses propres droits. Six mois plus tard, une permission refusée ou accordée par erreur demande de reconstruire toute cette chaîne.

Je préfère une règle plus facile à expliquer : les accès passent par des groupes associés à des rôles, et les exceptions individuelles ont une date de révision. Par exemple :

Projet Atlas - Lecteurs      -> consulter
Projet Atlas - Contributeurs -> ajouter et modifier
Projet Atlas - Propriétaires -> gérer le site et ses groupes

Le groupe peut être alimenté à partir de l’annuaire; le site n’a pas besoin de connaître chaque employé un par un. Lorsqu’une personne change d’équipe, on corrige son appartenance au groupe plutôt que de chercher son nom dans dix bibliothèques.

Créer le site avec sa sortie en tête

Un site de projet devrait aussi avoir un propriétaire fonctionnel, un propriétaire technique et une date de révision. À la fermeture du projet, on choisit quoi archiver, quoi rendre en lecture seule et quoi supprimer selon les règles de conservation. Sinon, le moteur de recherche continuera d’indexer de vieux documents et les utilisateurs ne sauront plus lequel fait foi.

La panne à prévoir n’est pas seulement « le serveur tombe ». Une base de contenu peut grossir, une sauvegarde peut être inutilisable, le compte du propriétaire peut disparaître ou une personnalisation peut empêcher une restauration sur une autre ferme. Un test sérieux consiste à restaurer un petit site dans un environnement isolé, puis à vérifier les documents, leurs versions et leurs permissions. Le message backup completed ne suffit pas.

Je ne veux pas transformer la création d’un espace en poste de péage. Pour un premier projet, je demanderais seulement le but, les groupes d’accès, deux propriétaires et une date de révision. C’est assez léger pour laisser l’équipe avancer, mais assez précis pour que le site ne devienne pas un sous-sol numérique dont personne n’a la clé.