Migration SharePoint : comment éviter le chaos documentaire

Une migration SharePoint ratée se reconnaît immédiatement : liens brisés, versions disparues, permissions incohérentes et des équipes qui demandent où sont passés leurs fichiers. Le calendrier était serré, alors on a tout déplacé « tel quel ». Voici comment éviter ce scénario.

Pourquoi les migrations déraillent

La douleur commence bien avant le premier transfert. Elle commence le jour où quelqu’un décide de tout déplacer sans trier, pour aller plus vite.

Les écueils que nous rencontrons le plus souvent :

• Du contenu obsolète ou dupliqué migré sans révision, qui pollue immédiatement la recherche.
• Des arborescences de dossiers reproduites à l’identique, sans métadonnées ni types de contenu.
• Des flux de travail personnalisés oubliés, qui cessent de fonctionner après la bascule.
• Des permissions héritées d’un serveur de fichiers, reportées telles quelles et impossibles à auditer.
• Des chemins d’accès trop longs ou des caractères non pris en charge, qui font échouer des lots entiers.

Chacun de ces points est prévisible. Aucun ne se corrige facilement une fois la migration terminée.

Concevoir l’architecture cible d’abord

Une migration réussie est d’abord un exercice d’architecture d’information. C’est la carte de la façon dont le contenu vivra dans SharePoint : quels sites, comment ils se relient, ce que contient chaque bibliothèque et comment les gens retrouvent l’information.

Les questions à trancher avant de commencer

• Organise-t-on par département, par fonction, par projet, par région — ou par une combinaison ?
• Qu’est-ce qui devient un site à part entière et qu’est-ce qui reste une bibliothèque ?
• Quelles métadonnées remplacent les niveaux de dossiers actuels ?
• Où résident les documents officiels soumis à un calendrier de conservation ?
• Qui possède quoi, et qui approuve la création de nouveaux espaces ?

Cette étape est aussi le meilleur moment pour éliminer ce qui n’a plus lieu d’être. Une migration est l’unique occasion réaliste de faire le ménage.

Un plan d’exécution par étapes

Une fois la cible définie, la migration devient une séquence de vérifications plutôt qu’un grand saut.

1. Découverte et inventaire. Balayage des sources, volumétrie, dates de dernier accès, types de fichiers, chemins problématiques.
2. Évaluation et nettoyage. Identification des doublons, du contenu jamais consulté depuis trois ans, des fichiers à archiver plutôt qu’à migrer.
3. Migration pilote. Un département représentatif, avec validation complète avant d’aller plus loin.
4. Tests utilisateurs. Les équipes vérifient elles-mêmes que leurs documents, versions et accès sont intacts.
5. Bascule finale. Par vagues, avec gel des sources, fenêtre de retour arrière et communication claire.

Le pilote est l’étape la plus souvent sacrifiée, et c’est presque toujours une erreur. Il coûte quelques jours et évite des mois de correction.

Préparer les équipes au changement

La technologie seule ne fait pas le succès d’un projet documentaire. Les gens doivent comprendre ce qui change et en quoi cela les aide.

• Impliquer tôt les parties prenantes, incluant les responsables de la conformité et des archives.
• Privilégier de courtes démonstrations concrètes aux longues présentations.
• Constituer un réseau de champions pour absorber les questions de premier niveau.
• Publier un guide « où va quoi » d’une seule page, en français et en anglais si nécessaire.

Une migration techniquement parfaite dont personne ne comprend la logique produit le même résultat qu’une migration ratée : le retour aux anciennes habitudes.

Faire de la migration un point de départ

L’objectif n’est pas de déplacer le maximum de fichiers dans le minimum de temps. C’est d’arriver dans SharePoint avec une structure défendable, une gouvernance nommée et des équipes qui savent s’en servir.

Les organisations qui traitent la migration comme un projet d’architecture — et non comme une opération de copie — n’ont pas à recommencer trois ans plus tard.

Migrer depuis un ancien système documentaire

Toutes les migrations ne partent pas du même endroit. Le point de départ influence ce que l’on peut transporter fidèlement et ce qui devra être repensé.

Les lecteurs réseau

C’est le cas le plus fréquent. Les fichiers se déplacent bien, mais la logique repose entièrement sur les noms de dossiers et de fichiers. Une partie de cette information (client, année, type de document) peut devenir des métadonnées, c’est-à-dire des colonnes qui permettent de trier et de filtrer les documents dans SharePoint. Les permissions, souvent accordées dossier par dossier au fil des ans, sont rarement à reproduire telles quelles.

Les anciennes GED

Une GED (gestion électronique des documents) plus ancienne contient souvent des profils de documents, des numéros de référence et des champs propres à l’outil. Ces données ont de la valeur, mais leur exportation dépend de l’outil et de sa version : certaines s’exportent proprement, d’autres demandent un travail d’extraction. Il faut le vérifier dès l’inventaire, pas pendant la bascule.

SharePoint sur site vieillissant

Passer d’un SharePoint installé sur vos serveurs à SharePoint Online semble naturel, mais tout ne suit pas. Les anciens flux de travail SharePoint et les formulaires InfoPath doivent être reconstruits, généralement avec Power Automate et d’autres outils de Microsoft 365. Le code personnalisé installé sur les serveurs n’est pas pris en charge dans SharePoint Online et doit être remplacé ou abandonné.

Garder, archiver, associer : les décisions à prendre

Ce que l’on garde et ce que l’on archive

Le contenu actif va dans le nouvel environnement. Le contenu qu’il faut conserver pour des raisons légales ou administratives, mais que personne ne consulte, va dans une archive en lecture seule soumise au calendrier de conservation. Le reste se détruit, avec l’accord écrit des responsables concernés.

L’association des métadonnées

Avant le transfert, on dresse un tableau qui associe chaque champ de l’ancien système à une colonne SharePoint, avec ses valeurs permises. C’est le moment de corriger les incohérences : trois façons d’écrire le même nom de client deviennent une seule valeur. Pour regrouper plusieurs sources, consultez notre approche pour consolider vos systèmes de gestion documentaire.

Ce qui ne se transporte pas

Les journaux d’audit de l’ancien système, les flux de travail personnalisés et certaines règles propres à l’outil ne suivent pas les documents. S’ils ont une valeur de preuve, exportez-les et conservez-les séparément avant de mettre l’ancien système hors service. Selon l’outil de migration et la source, les dates et les auteurs d’origine peuvent être préservés, ou non : vérifiez-le pendant le pilote.

Questions fréquentes

Combien de temps dure une migration SharePoint ?

Pour une PME avec quelques téraoctets de contenu, comptez généralement de deux à quatre mois entre l’inventaire et la bascule finale. Le transfert technique lui-même occupe une fraction de ce temps; l’essentiel va à la conception de l’architecture cible et au nettoyage.

Faut-il migrer l’historique des versions ?

Rarement en totalité. Conserver les trois à cinq dernières versions couvre la quasi-totalité des besoins opérationnels. Les documents soumis à des obligations réglementaires font exception et doivent conserver leur historique complet.

Que faire des dossiers que plus personne n’ouvre ?

Ils ne devraient pas être migrés dans l’environnement actif. Un archivage distinct, en lecture seule et soumis au calendrier de conservation, réduit le volume à migrer et améliore immédiatement la pertinence de la recherche.

Peut-on conserver les métadonnées de notre ancienne GED lors d’une migration vers SharePoint ?

Généralement oui pour les champs utiles, à condition de les associer à des colonnes SharePoint avant le transfert et de nettoyer les valeurs incohérentes. La faisabilité dépend toutefois de ce que l’ancien outil permet d’exporter. Les journaux d’audit et les flux de travail personnalisés, eux, ne suivent pas et doivent être exportés ou reconstruits.