Structurer un environnement SharePoint moderne : architecture, bibliothèques, autorisations et archivage

Structurer un environnement SharePoint moderne, ce n'est pas "ranger des fichiers dans le nuage". C'est définir une architecture documentaire qui reste compréhensible quand l'équipe grandit, quand les projets se multiplient et quand les exigences de sécurité deviennent plus strictes. En PME, les dérapages sont fréquents : arborescences profondes, bibliothèques fourre-tout, autorisations gérées au cas par cas, et documents introuvables malgré "un bon classement". L'objectif de cet article est d'expliquer comment bâtir une structure SharePoint durable. Vous repartirez avec un cadre clair, des erreurs terrain à éviter, et une liste de vérifications pour sécuriser et maintenir l'environnement dans le temps.

Les principes Microsoft à connaître avant de créer des sites

Les recommandations Microsoft sur l'expérience moderne reposent sur une idée simple : l'architecture doit rester lisible, évolutive et gouvernable. Trois principes reviennent souvent :

1. Une structure "plate" (flat) : éviter les sous-sites et préférer des sites au même niveau, regroupés par hubs.
2. Des bibliothèques et des métadonnées pour organiser et retrouver : limiter les dossiers imbriqués.
3. Des accès gérés par groupes, avec héritage : limiter les permissions uniques au strict nécessaire.

Hiérarchie de sites : passer d'un arbre de dossiers à une architecture "plate"

Dans SharePoint moderne, Microsoft recommande de ne pas construire un "arbre" de sous-sites. À la place, on crée des sites au même niveau (top-level) et on les organise via des hubs. Cette approche réduit la complexité, simplifie la navigation et rend la gouvernance plus stable.

Choisir le bon type de site : site d'équipe vs site de communication

Au quotidien, deux modèles dominent :

• Site d'équipe : conçu pour collaborer (documents de travail, coédition, échanges).
• Site de communication : conçu pour diffuser (procédures, nouvelles, pages de référence).

Un repère simple : si la majorité des utilisateurs doit contribuer et produire des documents, on est souvent dans un site d'équipe. Si la majorité doit consulter, on est plutôt dans un site de communication.

Hubs : regrouper sans enfermer

Les hubs servent à regrouper des sites liés (ex. Opérations, Finance, Projets) sans créer de sous-sites. Le hub apporte une navigation cohérente et un périmètre logique, tout en laissant chaque site évoluer indépendamment.

Règles de nommage et gouvernance minimale

Une architecture durable repose aussi sur des règles simples et écrites :

• Convention de nommage des sites et des bibliothèques (ex. "FIN - Contrats fournisseurs").
• Politique de création : qui a le droit de créer un site, dans quels cas, avec quel gabarit.
• Propriétaires de site : au moins un propriétaire métier (responsable) et un remplaçant.

Bibliothèques documentaires : clarté d'usage, métadonnées, et dossiers avec parcimonie

Microsoft met l'accent sur la recherche, le filtrage et l'indexation : la structure ne doit pas dépendre uniquement d'une arborescence de dossiers. Dans la plupart des cas, il vaut mieux plusieurs bibliothèques "spécialisées" qu'une bibliothèque géante.

Concevoir des bibliothèques par usage

Exemples de bibliothèques (à adapter) :

• Modèles et gabarits
• Procédures et politiques
• Contrats
• Projets (ou une bibliothèque par projet, si le volume le justifie)
• Documents clients (si la confidentialité impose un cloisonnement)

Métadonnées : les deux briques clés

Microsoft souligne l'importance des colonnes (métadonnées) et des types de contenu pour organiser l'information. Les métadonnées permettent de filtrer, trier et retrouver des documents sans dépendre d'un seul "chemin de dossiers".

Exemples de colonnes utiles : Type de document, Client, Projet, Statut, Date d'échéance, Version contractuelle, Confidentialité.

Dossiers : quand ils aident, quand ils nuisent

Les dossiers ne sont pas "interdits", mais ils deviennent problématiques quand :

• l'arborescence devient profonde (navigation lente, adoption difficile),
• les droits sont cassés dossier par dossier,
• la logique varie selon les équipes.

Un bon compromis : utiliser quelques dossiers de premier niveau pour une séparation simple (ex. "À traiter / Final"), et faire le reste avec des métadonnées.

Tableau de décision : site, bibliothèque, dossier ou métadonnée ?

Autorisations : gérer par groupes et limiter les exceptions

Sur le terrain, la cause numéro un d'environnements "ingérables" est la gestion des accès au cas par cas. On recommande d'utiliser des groupes (Microsoft 365, groupes de sécurité, groupes SharePoint) et de s'appuyer sur l'héritage des permissions plutôt que de multiplier les permissions uniques.

Modèle recommandé : trois groupes SharePoint + groupes d'annuaire

Dans beaucoup de cas, un modèle simple suffit :

• Propriétaires : gouvernance du site.
• Membres : contribution (création/modification).
• Visiteurs : lecture.

On ajoute ensuite des groupes Microsoft 365 ou des groupes de sécurité Entra ID dans ces groupes SharePoint, au lieu d'ajouter des utilisateurs individuellement.

Héritage, puis permissions uniques seulement si nécessaire

L'héritage réduit les surprises : si un site est privé, ses bibliothèques héritent. On casse l'héritage uniquement quand il existe une raison métier claire (ex. RH, dossiers légaux, informations très sensibles). Et dans ce cas, on documente l'exception (quoi, pourquoi, qui est responsable).

Partage externe : cadrer avant d'ouvrir

Le partage externe doit être une décision de gouvernance, pas une improvisation. Avant d'autoriser un partage, clarifiez : qui peut partager, quel type de contenu, avec quels contrôles, et avec quelle durée.

Archivage : gérer le cycle de vie avec rétention et archivage, pas avec des "dossiers Archives"

Archiver n'est pas seulement déplacer des fichiers. Microsoft propose des mécanismes de gestion du cycle de vie via Microsoft Purview (politiques et étiquettes de rétention) et, selon les besoins, l'archivage de sites (Microsoft 365 Archive) tout en conservant les capacités de conformité.

Définir des règles simples de rétention

Un point de départ pragmatique :

• Quels contenus doivent être conservés ? (obligations légales, contrats, RH)
• Combien de temps ?
• Qui valide la destruction ?

Les politiques de rétention permettent d'appliquer des règles au niveau site, et les étiquettes de rétention d'affiner au niveau document/dossier.

Réduire les risques liés aux versions et à la récupération

SharePoint offre l'historique des versions et la restauration, mais ces mécanismes ont des limites. Microsoft documente des limites de versions (par exemple via des paramètres de limites d'historique) et la conservation des éléments supprimés dans la corbeille.

Point critique : les mécanismes natifs (corbeille, versions, rétention) ne remplacent pas un backup externe

Pour éviter une fausse impression de sécurité, il faut distinguer :

• Récupération native : corbeille, versions, restauration, rétention.
• Sauvegarde (backup) : copie indépendante, restaurable, avec une stratégie de conservation et de récupération définie.

Microsoft décrit, par exemple, que les éléments supprimés dans SharePoint pour Microsoft 365 sont retenus 93 jours dans la corbeille et qu'au-delà ils sont supprimés définitivement. Cela aide, mais ce n'est pas une stratégie de sauvegarde complète.

Pourquoi une sauvegarde externe est un sujet de direction, pas seulement "informatique"

Les incidents typiques ne sont pas théoriques : suppression massive, erreur de permission, chiffrement malveillant, ou besoin de restaurer précisément un site, une bibliothèque ou une version antérieure. Le modèle de responsabilité partagée en nuage rappelle que le fournisseur sécurise l'infrastructure, mais que l'organisation reste responsable de sa configuration, de ses accès et de la protection de ses données.

Complément logique : un service de backup externe Microsoft 365

C'est dans ce cadre qu'un backup externe prend tout son sens : une copie indépendante de l'environnement, avec des sauvegardes régulières et une capacité de restauration granulaire. Finova propose un service de sauvegarde Microsoft 365 et Google Workspace (backup externe).

Erreurs terrain à éviter (et pourquoi elles coûtent cher)

1. Reproduire un serveur de fichiers : dossiers profonds et bibliothèques uniques.
2. Multiplier les sous-sites : navigation et gouvernance qui se compliquent avec le temps.
3. Ajouter des utilisateurs un par un dans les permissions : difficile à auditer et à maintenir.
4. Casser l'héritage partout : "patchs" de sécurité qui finissent en incohérences.
5. Confondre corbeille/versions avec sauvegarde : fenêtre de récupération limitée et non conçue comme un plan de reprise.
6. Mettre l'archivage à la fin : sans règles de cycle de vie, le désordre revient mécaniquement.

Checklist de mise en place

☐ Définir 5 à 10 périmètres de sites maximum au départ (équipe, service, projet structurant).

☐ Définir 1 à 3 hubs (ex. Opérations, Finance/Administration, Projets).

☐ Standardiser le nommage des sites et bibliothèques.

☐ Créer des bibliothèques par usage et configurer des vues (par statut, par client, par projet).

☐ Définir 5 à 12 colonnes de métadonnées "communes" et documenter leur usage.

☐ Appliquer un modèle d'accès par groupes (Propriétaires/Membres/Visiteurs + groupes Entra ID).

☐ Documenter chaque permission unique (si nécessaire) : raison, contenu, responsable.

☐ Définir règles de rétention/archivage (Purview) et responsabilités métier.

☐ Mettre en place un backup externe et tester une restauration (site + fichier + bibliothèque).

Conclusion

Une structure SharePoint moderne tient davantage d'une "architecture d'usages" que d'un rangement par dossiers. Le fil conducteur des recommandations Microsoft est cohérent : garder les sites au même niveau (structure plate), regrouper par hubs, utiliser des bibliothèques spécialisées et des métadonnées pour retrouver rapidement, et gérer la sécurité par groupes avec un maximum d'héritage. Ces choix diminuent le coût de gouvernance : moins d'exceptions, moins d'accès incohérents, et une adoption plus simple pour les équipes. Enfin, la gestion du cycle de vie (rétention, archivage) doit être pensée dès le départ, sinon l'environnement se dégrade inévitablement. Et surtout : corbeille, versions et rétention aident à récupérer, mais ne remplacent pas une sauvegarde indépendante. Un backup externe, testé en restauration, complète l'ensemble pour protéger durablement les données et éviter qu'un incident ponctuel devienne une crise opérationnelle.