Retrait de SharePoint Classic : ce qui change avec la décision de Microsoft

Microsoft a annoncé un changement concernant toutes les organisations qui utilisent encore SharePoint Online dans sa version Classic. L’objectif affiché est de réduire les risques de sécurité et de gouvernance liés aux modèles de personnalisation les plus anciens, en poussant les entreprises vers l’expérience moderne de SharePoint, conçue pour être plus sûre, plus simple à administrer et pensée pour les appareils mobiles.

Le processus de retrait se déroule en deux phases distinctes, avec des dates déjà fixées, et concerne les sites de publication Classic, les pages créées par les utilisateurs et les scripts personnalisés. Ce n’est pas un changement brutal, puisque Microsoft laisse une fenêtre de quelques années avant que les effets ne deviennent irréversibles, mais c’est justement pour cela qu’il vaut mieux commencer à y réfléchir dès maintenant, surtout si votre intranet porte encore l’héritage de plusieurs années de personnalisations accumulées.

Les échéances fixées par Microsoft pour dire adieu à SharePoint Classic

Phase 1, à partir du 1er mars 2027

À partir de cette date, il ne sera plus possible, sur l’ensemble des tenants, de créer de nouveaux sites de publication Classic, que ce soit comme collections de sites ou comme sous-sites. De la même façon, il ne sera plus possible d’activer la fonctionnalité de publication Classic là où elle n’est pas déjà activée. Le paramètre de tenant qui permet de créer ces sites sera bloqué de façon permanente.

Pour les tenants créés à partir du 1er mars 2027, la restriction est plus large : les utilisateurs ne pourront plus créer de nouvelles pages Classic du tout, et l’ajout ou la modification de scripts personnalisés sera désactivé par défaut.

Phase 2, à partir du 1er octobre 2028

À partir du 1er octobre 2028, les restrictions introduites lors de la première phase s’étendent à tous les tenants existants, y compris ceux actifs depuis des années. Les pages Classic créées par les utilisateurs deviennent en lecture seule : il ne sera donc plus possible d’en créer de nouvelles ni de modifier celles qui existent déjà. Là aussi, la possibilité d’ajouter ou de mettre à jour des scripts personnalisés sera désactivée.

Microsoft précise que les pages restent accessibles en consultation même après cette seconde échéance, un détail qui mérite d’être souligné car il écarte l’angoisse de la suppression, mais ne réduit en rien l’urgence de planifier : une page que l’on ne peut plus modifier cesse en pratique d’être utile comme outil de communication interne.

Quelles pages et quels environnements sont concernés

Le retrait concerne spécifiquement certains types de pages Classic créées par les utilisateurs : les pages wiki, les pages de web parts, les pages de blog, les pages de publication et les pages ASPX personnalisées, créées avec SharePoint Designer ou des solutions tierces. Quiconque travaille au quotidien avec SharePoint reconnaîtra dans cette liste la plupart des pages qui composent un intranet construit avec l’approche la plus ancienne, celle basée sur des mises en page fixes et l’insertion de code plutôt que sur des web parts configurables.

Restent en revanche hors de ce périmètre les vues de listes et de bibliothèques documentaires ainsi que les pages de formulaires associées, même si les scripts personnalisés éventuellement intégrés y restent soumis aux nouvelles restrictions sur la création et la modification de scripts. C’est une distinction technique qu’il vaut la peine de garder à l’esprit lors de l’inventaire : tout ce qui est « ancien » dans un tenant SharePoint ne relève pas forcément de ce retrait, et tout ce qui en est exclu n’est pas pour autant à l’abri des règles sur les scripts.

Le changement s’applique à tous les environnements Microsoft 365, y compris les environnements Government (GCC, GCC High et DoD), les environnements air-gapped d’Office 365 et Microsoft 365 exploité par 21Vianet. Il n’y a donc aucune exception liée au type de plan ou au secteur d’activité de l’organisation.

Pourquoi Microsoft a décidé d’agir maintenant

Les pages Classic et les anciens modèles de personnalisation reposent sur le rendu côté serveur et sur des scripts personnalisés, des technologies qui, selon Microsoft, augmentent le risque de sécurité, la complexité administrative et les coûts de maintenance à long terme. Un site construit avec des pages maîtres personnalisées ou des scripts ajoutés des années plus tôt par un prestataire qui ne travaille peut-être plus avec l’entreprise finit, avec le temps, par devenir quelque chose que plus personne ne veut toucher de peur de le casser, c’est exactement ce type de dette technique que Microsoft veut réduire.

Il y a aussi une question de vitesse d’innovation. Le modèle Classic limite la cohérence avec laquelle de nouvelles fonctionnalités peuvent être introduites, tandis que l’expérience moderne de SharePoint offre un environnement de collaboration plus sûr et mieux gouverné, une gestion des autorisations simplifiée via les groupes Microsoft 365, une interface pensée dès l’origine pour les appareils mobiles et, dans une perspective plus large, les fondations sur lesquelles reposent les fonctionnalités les plus récentes liées à l’intelligence artificielle. Rester ancré aux pages Classic revient donc non seulement à prendre un risque de sécurité, mais aussi à risquer d’être exclu de cette évolution.

Ceux qui ont déjà approfondi les différences entre les deux expériences le savent bien, car le passage de SharePoint Classic à SharePoint Modern ne concerne pas seulement l’esthétique des pages, mais touche aussi la gestion des autorisations, l’intégration native avec Teams et Outlook, et la possibilité d’automatiser des workflows avec Power Automate, autant de domaines où le modèle Classic montre désormais ses limites.

Les 4 étapes recommandées par Microsoft pour moderniser SharePoint Classic

La documentation officielle suggère une approche progressive, pensée pour réduire les risques liés à la migration et laisser aux propriétaires de sites le temps de valider les pages modernisées.

1. Identifier et évaluer l’environnement Classic existant

La première étape, et probablement la plus importante, consiste à comprendre combien de sites et de pages Classic sont encore actifs dans le tenant. Microsoft met à disposition les événements d’audit de Microsoft Purview dans la catégorie dédiée aux activités Classic, qui couvrent la création, la modification et la consultation des pages Classic, ainsi que le Microsoft 365 Assessment Tool, conçu spécifiquement pour identifier les pages, web parts et schémas de personnalisation encore présents dans l’environnement. Le résultat de cet outil comprend un inventaire détaillé pour chaque page trouvée, avec un indicateur de la complexité de sa transformation vers l’expérience moderne.

Si l’évaluation ne détecte aucun site de publication Classic, aucune page créée par les utilisateurs ni aucun script concerné par les nouvelles règles, aucune action supplémentaire n’est requise. Mais ce résultat est moins évident qu’il n’y paraît, car certaines organisations qui se croyaient déjà entièrement modernes ont découvert, après une vérification approfondie, qu’elles avaient encore des dizaines, voire des centaines de pages Classic oubliées dans des sites secondaires, souvent créées des années plus tôt par des équipes qui ont depuis changé.

2. Prioriser selon l’importance pour l’activité

Il est préférable de commencer par les pages les plus utilisées, les plus fréquemment modifiées ou les plus pertinentes pour l’activité de l’entreprise, en les regroupant par complexité et par type d’intervention nécessaire, afin de pouvoir réutiliser ce qui a été appris lors des phases suivantes. Une page d’actualités consultée chaque jour par des centaines de personnes mérite un traitement différent de celui d’une page statique que personne n’ouvre plus depuis des années.

3. Transformer les pages vers l’expérience moderne

Pour la transformation proprement dite, Microsoft indique le guide officiel de modernisation ainsi que PnP PowerShell comme outil de conversion déterministe des pages suivant un modèle récurrent. Pour les scénarios plus complexes, avec du HTML personnalisé ou du contenu d’éditeur de script nécessitant un jugement humain, Microsoft signale également le SharePoint Page Migration Agent, un projet open source actuellement en préversion. Il convient de rappeler que les outils open source et en préversion ne bénéficient pas de la couverture SLA du support Microsoft, et que les pages les plus personnalisées peuvent malgré tout nécessiter une révision ou une reconstruction manuelle.

4. Procéder par vagues

La recommandation finale consiste à combiner une planification centralisée avec une exécution par les propriétaires de sites eux-mêmes, en modernisant des groupes successifs de pages plutôt que tout en une seule fois. Cette approche par vagues permet de valider le contenu, les liens, les autorisations, les web parts et la mise en page sur un nombre limité de pages avant d’étendre l’intervention au reste du tenant, limitant ainsi le risque de devoir corriger la même erreur sur des centaines de pages différentes.

Un sujet qui concerne surtout les tenants les plus grands et les plus stratifiés

Les organisations qui, au fil des années, ont construit leur intranet sur SharePoint Server on-premises puis ont migré vers SharePoint Online ont tendance à avoir un nombre plus élevé de sites, pages et personnalisations Classic encore actifs, souvent sans que le service informatique en ait une cartographie complète et à jour. C’est un schéma récurrent, car chaque changement de responsabilité entre équipes, chaque prestataire externe ayant travaillé sur le tenant à un moment donné, et chaque réorganisation de l’entreprise laissent derrière eux un site que plus personne ne gère activement, mais qui continue d’exister et reste accessible.

Plus un tenant est grand et stratifié dans le temps, plus la phase de recensement demande de l’attention, car les pages et personnalisations peuvent être réparties sur différents sites, gérés par différentes équipes, avec des niveaux de documentation très inégaux. Les deux échéances fixées par Microsoft, mars 2027 et octobre 2028, offrent une fenêtre de temps utile pour traiter le sujet avec méthode, mais c’est précisément la phase d’analyse initiale (celle qui permet de comprendre réellement combien de pages Classic sont encore en usage et avec quel niveau de complexité) qui exige la planification la plus minutieuse, car c’est le moment où l’on découvre l’ampleur réelle du travail à accomplir, avant même de commencer à moderniser quoi que ce soit.

Par où commencer si vous n’avez pas encore une vision claire

Pour les entreprises de taille moyenne à grande, au-delà d’environ 300 utilisateurs, le premier obstacle consiste presque toujours à comprendre si le sujet les concerne vraiment, plus qu’une question technique. Un bon point de départ consiste à se poser, ou à faire répondre par son service informatique, trois questions simples.

1. L’entreprise a-t-elle utilisé par le passé SharePoint Server ou SharePoint on-premises ?
2. Une migration vers SharePoint Online a-t-elle été réalisée ?
3. Sait-on avec certitude s’il reste des pages, des sites ou des personnalisations Classic dans le tenant ?

Si la réponse à la troisième question est incertaine, il vaut mieux impliquer directement le référent informatique pour une vérification ciblée, plutôt que de s’arrêter à une impression préliminaire. Il arrive plus souvent qu’on ne le pense que des entreprises convaincues de n’avoir plus rien de Classic découvrent, après un contrôle plus approfondi, plus de 120 pages encore actives et oubliées dans des sites secondaires. Une vérification faite à temps, même uniquement qualitative, permet de planifier avec de la marge, au lieu de découvrir l’ampleur réelle du travail juste avant les échéances.