Accompagnement SharePoint — architecture, gouvernance et audits

Pourquoi Teams ne fait pas une gestion documentaire

Ce constat revient chez la plupart des clients et justifie à lui seul la priorisation d'une migration vers des bibliothèques SharePoint structurées.

• Duplication. Un même document est déposé dans plusieurs canaux ou plusieurs équipes, sans version faisant autorité.
• Versions divergentes. Sans gestion de versions structurée, plusieurs états du même fichier coexistent, avec le risque de travailler sur une version périmée.
• Partage non maîtrisé. Le partage externe est souvent actif par défaut, et un membre standard peut inviter un tiers sans validation d'un propriétaire.
• Droits peu granulaires. Les permissions découlent de l'appartenance à l'équipe dans son ensemble : pas de granularité par dossier ni par processus métier.
• Perte à l'archivage. La suppression ou l'abandon d'une équipe entraîne la perte d'accès, voire la perte définitive, de documents qui devaient être conservés.
• Aucune gouvernance documentaire. Pas de métadonnées, pas de classification, pas de politique de rétention : retrouver un document repose sur la mémoire individuelle.
• Angle mort pour l'IT. Les canaux privés et partagés créent des sites SharePoint cachés, invisibles même du propriétaire de l'équipe — d'où des concentrations de contenu hors de tout contrôle.
• Désynchronisation avec la source. Une copie circule sur Teams pendant que l'original continue d'évoluer sur le serveur de fichiers : deux sources concurrentes.
• Prolifération. La création d'équipes reste libre, ce qui multiplie les espaces non coordonnés pour un même besoin.

L'architecture de migration retenue

Un POC a été construit sous SharePoint pour valider l'architecture cible avant industrialisation.

Un site hub fédérateur rassemble les sous-sites correspondant aux dossiers du partage réseau.

Un site par dossier, plutôt qu'une bibliothèque unique. Chaque dossier du partage porte aujourd'hui ses propres habilitations. Créer un site dédié par dossier permet de conserver cette granularité telle qu'elle existe, au lieu de la reconstruire par des permissions rompues dans une bibliothèque unique — un modèle qui devient vite ingérable.

Chaque site peut être associé à une équipe Teams, ce qui limite le dépaysement des utilisateurs habitués à leur espace actuel : la gouvernance change, pas leur point d'entrée.

La web part Sites, testée sur trois sites pilotes

Trois sites pilotes ont été créés sous le hub pour éprouver la web part Sites en mode « tous les sites du hub ». Elle s'adapte à l'utilisateur courant : chacun ne voit, sur la page d'accueil du hub, que les tuiles correspondant à ses habilitations réelles — sans configuration site par site. Les tests sont concluants.

Le prérequis bloquant de la migration

La migration du contenu s'appuie sur ShareGate, avec reprise des habilitations existantes au niveau des dossiers, groupées par groupe de sécurité.

Les groupes de sécurité Active Directory locaux portés par les dossiers du serveur de fichiers doivent être synchronisés vers Entra ID avant la migration.

La raison est mécanique : ShareGate résout les permissions via le sélecteur de personnes de SharePoint, qui interroge Entra ID et non l'annuaire local. Sans cette synchronisation préalable, le mapping automatique des groupes ne fonctionne pas — et la reprise des droits doit être refaite à la main.

La méthode

1. Pilote sur une structure de test au périmètre restreint mais représentatif de la diversité des dossiers.
2. Usage quotidien pendant une période définie, pour faire remonter les irritants réels : ergonomie, habitudes, cas de permissions complexes.
3. Consolidation des retours avant toute décision d'industrialisation.
4. Migration de l'ensemble des sous-dossiers, puis reprise des habilitations.

Point de vigilance

Le principe « un site par dossier » répond au besoin de granularité sur le périmètre pilote. À surveiller lors de l'extension à l'ensemble du serveur de fichiers : un nombre de dossiers plus important pourrait imposer de regrouper certains sites par processus métier plutôt que de conserver une correspondance stricte de un pour un — au risque, sinon, de reconstituer côté SharePoint la prolifération que l'on cherchait à corriger côté Teams.

Évolutions envisagées

• Étendre la migration au-delà du premier partage, une fois la méthode validée.
• Synchroniser automatiquement les fichiers applicatifs — ceux que des logiciels tiers lisent et écrivent — entre le serveur de fichiers et SharePoint pendant la transition, via Power Automate.
• Faire à terme de SharePoint le point d'entrée unique de la documentation d'entreprise, serveur de fichiers et Teams inclus.

Audit d'applications Power Platform

Une autre nature d'intervention : la revue d'applications Power Apps et Power Automate déjà en service, ou sur le point d'être déployées. Les axes qui remontent le plus souvent :

Fiabilité des connecteurs. Sur une application de terrain souffrant de coupures de connexion, l'analyse a porté sur la gestion d'erreur, l'unification de connecteurs redondants — treize d'entre eux ramenés à une définition commune, via un tableau de correspondance et un connecteur unifié livré au client —, le paramétrage des tablettes et l'optimisation du nombre d'appels.

Délégation. Le point le plus fréquemment négligé : une requête non délégable est évaluée côté client sur les premiers enregistrements seulement, et l'application donne des résultats faux dès que le volume dépasse le seuil, sans erreur visible.

Gestion des versions et des couches de solution. Cas typique : une couche non gérée qui réapparaît sur l'application après chaque déploiement, et qui surcharge silencieusement les propriétés de la version livrée. Les causes possibles sont la liaison des connexions à l'import, l'ouverture de l'application en édition directement en production, ou un partage effectué hors solution.

Autres axes récurrents. Délégation des droits, suivi d'usage via Power BI, synchronisation avec une base SQL, et fonctionnement en mode hors ligne pour les applications utilisées sur le terrain.