Pages classiques SharePoint : retrait programmé en 2027 et 2028

Microsoft vient de fixer un calendrier précis pour la mise en lecture seule des pages classiques et la désactivation des scripts personnalisés dans SharePoint Online. Deux échéances structurent ce changement, entre mars 2027 et octobre 2028, avec des conséquences directes sur la gouvernance, la sécurité et même la qualité des réponses de Microsoft 365 Copilot. Voici ce qu'il faut comprendre, évaluer et planifier dès maintenant si vous administrez un tenant SharePoint.

Pourquoi Microsoft retire les expériences classiques

En 2016, Microsoft introduisait le SharePoint moderne et le SharePoint Framework (SPFx) comme socle cloud-native pour la publication de contenu et l'extensibilité développeur. Les fonctionnalités antérieures, rebaptisées « classiques » à l'époque, avaient pour but de faciliter la transition des environnements on-premises vers le cloud.

Dix ans plus tard, Microsoft indique que ces expériences classiques sont utilisées par moins de 5 % de la base mensuelle active des tenants. Le problème dépasse la simple obsolescence : le contenu des pages classiques ne s'intègre pas aux mécanismes modernes de sécurisation, de gestion et de partage, et il est mal représenté dans les formats de contenu exploités par Copilot — ce qui peut réduire la couverture et la précision des réponses générées à partir de ce contenu.

C'est ce constat qui justifie un retrait progressif, sur deux ans, des pages classiques et de la capacité à ajouter ou modifier des scripts personnalisés dans SharePoint Online.

Calendrier officiel : deux phases jusqu'en 2028

Phase 1 — à partir du 1er mars 2027

Pour tous les tenants, la création de nouvelles collections de sites ou sous-sites de publication classique sera désactivée, et l'activation de la fonctionnalité de publication classique ne sera plus possible. Le paramètre tenant AllowClassicPublishingSiteCreation sera forcé à False et ne pourra plus être modifié.

Pour les nouveaux tenants créés à compter du 1er mars 2027, deux restrictions supplémentaires s'appliquent :

• impossibilité de créer de nouvelles pages classiques (wiki, web part, blog, publication, ASPX personnalisées) ;
• désactivation par défaut de l'ajout et de la modification de scripts personnalisés, avec le paramètre de site DenyAddAndCustomizePages forcé à True et non modifiable.

Cette restriction ne concerne que les pages classiques : les pages SharePoint modernes ne sont pas affectées, et les solutions personnalisées construites sur SPFx continuent de fonctionner selon votre gouvernance actuelle.

Phase 2 — à partir du 1er octobre 2028

Les changements s'étendent alors à l'ensemble des tenants, existants comme nouveaux :

• toutes les pages classiques créées par les utilisateurs (wiki, web part, blog, publication, ASPX) passent en lecture seule : plus aucune création ni modification n'est possible ;
• l'ajout et la modification de scripts personnalisés sont désactivés partout, et le paramètre DenyAddAndCustomizePages est forcé à True sans possibilité de retour en arrière.

Ce qui n'est pas concerné par ce changement

Il est utile de clarifier le périmètre exact, car les termes « classique » et « script personnalisé » prêtent parfois à confusion :

• les pages SharePoint modernes ne sont pas affectées, quel que soit le paramétrage de DenyAddAndCustomizePages ;
• les solutions SPFx continuent de fonctionner sous votre gouvernance existante ;
• aucune donnée ni page n'est supprimée — les fonctionnalités de gouvernance des données déjà en place (rétention, conformité) continuent de s'appliquer normalement.

Comment évaluer votre exposition aux pages classiques

Avant toute action de modernisation, il faut mesurer l'ampleur réelle de l'usage classique sur votre tenant. Microsoft recommande deux leviers complémentaires.

Le premier est la catégorie « SharePoint Classic Activities » du journal d'audit Microsoft Purview, incluse dans l'offre Audit (Standard) et disponible pour toutes les organisations. Trois événements y sont particulièrement utiles : ClassicPageCreated, ClassicPageEdited et ClassicPageViewed, qui permettent d'identifier un usage encore actif plutôt qu'un simple historique de pages orphelines.

Le second est le Microsoft 365 Assessment Tool (aka.ms/microsoft365assessmenttool), qui donne une vue d'ensemble du périmètre classique et une estimation de faisabilité de modernisation.

Mise en œuvre : scripts d'audit du parc classique

Les deux scripts ci-dessous permettent de dresser un état des lieux concret avant de prioriser vos actions. Le premier interroge les paramètres tenant et sites via le module SharePoint Online Management Shell ; le second interroge le journal d'audit unifié via le module ExchangeOnlineManagement.

1# Prérequis : module Microsoft.Online.SharePoint.PowerShell (SharePoint Online Management Shell)
2# Installation : Install-Module -Name Microsoft.Online.SharePoint.PowerShell -Scope CurrentUser
3# Permission minimale requise : rôle SharePoint Administrator (lecture seule suffisante pour cet audit)
4 
5# Connexion au locataire SharePoint Online
6Connect-SPOService -Url "https://contoso-admin.sharepoint.com"
7 
8# 1. Vérifier l'état actuel du paramètre tenant de publication classique
9$tenantSettings = Get-SPOTenant | Select-Object AllowClassicPublishingSiteCreation
10Write-Host "AllowClassicPublishingSiteCreation actuel : $($tenantSettings.AllowClassicPublishingSiteCreation)"
11 
12# 2. Parcourir toutes les collections de sites pour repérer celles qui autorisent
13#    encore l'ajout/modification de scripts personnalisés
14$sites = Get-SPOSite -Limit All -IncludePersonalSite $false
15$sitesAvecScriptsAutorises = foreach ($site in $sites) {
16    if ($site.DenyAddAndCustomizePages -eq "Disabled") {
17        [PSCustomObject]@{
18            Url                      = $site.Url
19            Template                 = $site.Template
20            DenyAddAndCustomizePages = $site.DenyAddAndCustomizePages
21            StorageUsageCurrent      = $site.StorageUsageCurrent
22        }
23    }
24}
25 
26# Export pour analyse et priorisation par les équipes SharePoint
27$sitesAvecScriptsAutorises | Export-Csv -Path ".\Sites_ScriptsPersonnalises_Autorises.csv" -NoTypeInformation -Encoding UTF8
28 
29Write-Host "Nombre de sites avec scripts personnalisés encore autorisés : $($sitesAvecScriptsAutorises.Count)"

1# Prérequis : module ExchangeOnlineManagement (v3.4.0 ou supérieur recommandé)
2# Installation : Install-Module -Name ExchangeOnlineManagement -Scope CurrentUser
3# Permission minimale requise : rôle View-Only Audit Logs (ou Compliance Administrator)
4 
5# Connexion au service d'audit unifié Microsoft Purview
6Connect-ExchangeOnline -UserPrincipalName admin@contoso.com
7 
8# Recherche des événements liés aux pages classiques sur les 90 derniers jours
9# Ajustez -StartDate selon la période de rétention de votre plan Purview Audit (Standard ou Premium)
10$resultats = Search-UnifiedAuditLog -StartDate (Get-Date).AddDays(-90) `
11    -EndDate (Get-Date) `
12    -RecordType SharePoint `
13    -Operations ClassicPageCreated, ClassicPageEdited, ClassicPageViewed `
14    -ResultSize 5000
15 
16# Regroupement par type d'opération pour prioriser les sites à traiter en premier
17$resultats |
18    ForEach-Object { $_.AuditData | ConvertFrom-Json } |
19    Group-Object Operation |
20    Select-Object Name, Count |
21    Sort-Object Count -Descending
22 
23Disconnect-ExchangeOnline -Confirm:$false

Ce premier passage vous donne deux informations concrètes : la liste exacte des sites qui autorisent encore les scripts personnalisés, et le volume réel d'usage actif (création, édition, consultation) des pages classiques. Croisez les deux pour bâtir une liste de priorité par criticité métier plutôt que par ordre alphabétique de sites.

Stratégie de modernisation recommandée

Une fois le périmètre identifié, la démarche recommandée par Microsoft suit quatre étapes :

• Découvrir et évaluer : combiner les résultats des scripts ci-dessus avec le Microsoft 365 Assessment Tool pour obtenir une vue de faisabilité globale.
• Prioriser par criticité métier : si l'évaluation ne révèle aucun contenu classique, aucune action n'est requise. Sinon, concentrez l'effort sur les sites à forte valeur ou à mise à jour fréquente.
• Transformer avant les échéances d'enforcement : utilisez les outils SharePoint PnP Modernization et le SharePoint Page Modernization Agent pour convertir les pages classiques en expériences modernes. Microsoft continue d'améliorer cet outillage, mais il ne couvre pas automatiquement tous les scénarios complexes — les pages fortement personnalisées demandent souvent une refonte manuelle.
• Adopter une migration par vagues : combinez une planification centralisée par l'IT avec une exécution distribuée confiée aux propriétaires de site dans le temps. La plupart des organisations réussissent mieux en modernisant par vagues successives plutôt qu'en tentant une migration massive unique.

Côté propriétaires de site et auteurs de contenu, le rôle consiste à travailler avec l'équipe SharePoint pour identifier les pages classiques encore actives, et décider lesquelles doivent être modernisées, retirées, ou remplacées.

Erreurs courantes à éviter

• Confondre pages classiques et pages modernes dans l'audit : le filtre Get-SPOSite renvoie tous les templates de site ; croisez toujours avec le template et l'usage réel avant de lancer une modernisation inutile.
• Sous-estimer la rétention de l'audit Purview : si votre organisation dispose du plan Audit (Standard), la période d'historique disponible peut être plus courte qu'avec Audit (Premium) — vérifiez cette limite avant de conclure à une absence d'usage classique.
• Lancer la modernisation PnP sans validation fonctionnelle : les outils de conversion visent une fidélité « best-effort », pas une garantie de rendu identique. Prévoyez systématiquement une phase de recette avec les propriétaires de site avant bascule en production.
• Attendre l'échéance de phase 2 pour agir : le paramètre DenyAddAndCustomizePages devient non modifiable une fois enforced — planifier après l'échéance revient à subir la contrainte plutôt qu'à la piloter.

En résumé : ce qu'il faut faire dès maintenant

Ce changement ne supprime aucune donnée, mais il verrouille progressivement l'écriture sur les expériences classiques de SharePoint Online, avec deux échéances fermes : 1er mars 2027 et 1er octobre 2028. Concrètement :

• lancez dès maintenant l'audit de votre parc classique via la catégorie Purview « SharePoint Classic Activities » et le Microsoft 365 Assessment Tool ;
• identifiez les sites qui autorisent encore les scripts personnalisés avec le script Get-SPOSite fourni plus haut ;
• priorisez la modernisation par criticité métier, pas par volume de pages ;
• testez les outils PnP Modernization sur un échantillon avant un déploiement à grande échelle.

Si votre organisation ne détecte aucun contenu classique actif lors de cette évaluation, aucune action supplémentaire n'est nécessaire — mais le vérifier maintenant coûte beaucoup moins cher que de le découvrir en 2028, quand le paramètre DenyAddAndCustomizePages sera définitivement verrouillé. Un message center a été envoyé à tous les tenants (MC1464926 et MC1464924) ; consultez la documentation officielle Microsoft Learn référencée sous l'alias aka.ms/ClassicUserCreatedPageDeprecation pour le détail complet des FAQ et des mises à jour du calendrier.