Pourquoi votre SharePoint ressemble à votre ancien serveur de fichiers
Dans la plupart des cas, la migration s'est faite par copie. Le contenu du lecteur réseau a été déversé dans une ou deux bibliothèques, en conservant l'arborescence par direction, puis par année, puis par projet, puis par sous-projet.
Le résultat est prévisible. Des chemins de plus de 200 caractères qui posent problème à la synchronisation. Des dossiers dont plus personne ne connaît le propriétaire. Des droits attribués fichier par fichier au fil des demandes urgentes. Et une conviction partagée dans l'entreprise : « on ne trouve rien dans SharePoint ».
Le problème n'est pas SharePoint. C'est qu'on lui a demandé de se comporter comme un disque réseau, alors qu'il est conçu autour d'une unité différente : le site, qui porte un périmètre de droits, un cycle de vie et un usage.
À quels signes faut-il tout remettre à plat ?
- Des liens de partage « tout le monde dans l'organisation » distribués sans traçabilité.
- Des dossiers avec permissions uniques, dont l'héritage a été cassé pour une exception jamais annulée.
- Plusieurs versions du même document dans OneDrive, dans Teams et dans une bibliothèque, sans version de référence.
- Des salariés partis dont les fichiers restent dans un OneDrive personnel devenu inaccessible.
Un seul de ces symptômes se traite ponctuellement. Trois d'entre eux ensemble signifient que la structure elle-même doit être revue, sans quoi les corrections seront défaites en quelques mois.
À quoi ressemble une architecture cible
Le principe directeur tient en une phrase : un site par périmètre de droits homogène, pas un site par service. Si deux populations différentes doivent voir des choses différentes, ce sont deux sites. Si tout le monde voit la même chose, un seul site suffit, même s'il couvre plusieurs équipes.
Voici le modèle que nous posons par défaut dans une PME, à adapter à votre organisation.
| Site | Bibliothèque | Usage | Qui a accès |
|---|---|---|---|
| Intranet Communication | Documents publiés | Notes internes, procédures, modèles, annuaire | Tous les salariés, en lecture seule sauf communication interne |
| Direction | Comité de direction | Comptes rendus de CODIR, budgets, dossiers stratégiques | Membres du comité de direction uniquement |
| Ressources humaines | Dossiers du personnel | Contrats, entretiens, éléments variables de paie | Équipe RH, avec étiquette de confidentialité appliquée |
| Ressources humaines | Documents partagés RH | Modèles, procédures d'onboarding, notes de service | Tous les salariés en lecture, RH en écriture |
| Commerce | Clients | Un dossier par compte : offres, contrats signés, échanges | Équipe commerciale et direction |
| Projets | Un site par projet, créé avec une date de clôture | Livrables, spécifications, comptes rendus, plan de charge | Membres de l'équipe projet, plus invités externes nommés |
| Finance | Comptabilité et fiscal | Pièces comptables, liasses, échanges avec l'expert-comptable | Finance, direction, expert-comptable en invité externe |
| Archives | Archives par année | Documents clos à conserver pour raison légale | Lecture restreinte, écriture bloquée, rétention appliquée |
Trois règles accompagnent ce modèle. Les droits se gèrent au niveau du site, par groupe, jamais par personne. On accepte au maximum trois niveaux de dossiers dans une bibliothèque. Chaque site a un propriétaire métier nommé, qui valide les demandes d'accès.
Le lien avec Teams doit rester clair : chaque équipe Teams crée automatiquement un site SharePoint. Créer des équipes sans gouvernance produit donc des dizaines de sites orphelins. Ce point est traité dans notre page collaboratif Microsoft 365.
Comment reprendre la main sur les droits sans bloquer l'entreprise
La séquence compte autant que le contenu. Fermer brutalement des accès arrête le travail et détruit la confiance dans le projet.
Nous procédons dans cet ordre. D'abord la cartographie : extraction des sites, des bibliothèques, des permissions uniques et des liens de partage actifs. Ensuite le classement des écarts en trois niveaux — à corriger tout de suite, à corriger avec le métier, acceptable en l'état.
Puis la correction, site par site, en commençant par les périmètres les plus sensibles : RH, finance, direction, juridique. Chaque changement est annoncé au propriétaire métier avant application, avec une procédure de retour arrière.
Enfin la prévention : paramétrage par défaut des nouveaux liens de partage sur « personnes désignées », expiration automatique des liens invités, revue trimestrielle des accès externes, et processus de départ qui traite explicitement le OneDrive du salarié sortant.
Pourquoi c'est aussi un prérequis Copilot
Copilot for Microsoft 365 ne dispose d'aucun droit propre. Il voit exactement ce que voit l'utilisateur qui l'interroge. La conséquence est directe : si un salarié avait techniquement accès au fichier de la masse salariale sans le savoir, Copilot peut le lui restituer sous forme de réponse en langage naturel.
Autrement dit, Copilot ne crée pas de faille. Il supprime la protection par l'obscurité, celle qui reposait sur le fait que personne ne fouillait dans les bibliothèques. Un sur-partage qui dormait depuis cinq ans devient exploitable en une question.
À cela s'ajoute un effet sur la qualité des réponses. Un espace documentaire rempli de doublons, de versions de travail et de documents obsolètes produit des réponses contradictoires. Ranger améliore donc la sécurité et la pertinence en même temps. La démarche complète est décrite dans notre page déployer Copilot sans fuite de données.
Par où commencer
Une mission de remise en ordre se déroule en quatre étapes. Les durées ci-dessous sont des ordres de grandeur pour une PME de 50 à 150 salariés, à ajuster selon le volume.
- Cartographie (3 à 5 jours). Inventaire des sites, des bibliothèques, des permissions uniques, des liens de partage et des OneDrive orphelins. Livrable : une carte des accès et une liste d'écarts hiérarchisée.
- Architecture cible (2 ateliers). Découpage des sites par périmètre de droits, désignation des propriétaires métier, choix des métadonnées et des règles de nommage. Livrable : un plan d'architecture validé par la direction.
- Reprise (2 à 6 semaines). Création des sites cibles, déplacement des contenus, reprise des droits, traitement des doublons et des archives. Le déplacement de gros volumes se prépare comme une migration à part entière, sujet couvert par notre page migration Microsoft 365.
- Gouvernance (continu). Règles de création d'équipes et de sites, revue périodique des accès, rétention appliquée sur les archives.
Ce qui peut mal se passer : déplacer des contenus sans prévenir casse les liens enregistrés par les utilisateurs et les liens présents dans d'anciens mails. Nous conservons donc les redirections lorsque c'est possible et nous annonçons chaque bascule au moins une semaine à l'avance.
Le choix de l'outillage se fait à l'issue de la cartographie, une fois le volume réel connu. Les fonctions natives de Microsoft 365 — rapports de partage, gestionnaire de migration, PowerShell — couvrent une bonne part des besoins. Une reprise de droits fine ou des bibliothèques très volumineuses justifient en revanche un outil de migration dédié, dont le coût entre alors dans l'arbitrage.
