SharePoint et HTML : du Script Editor aux nouvelles pages HTML natives

Pendant longtemps, personnaliser une page SharePoint avec du HTML revenait à choisir entre deux extrêmes : une liberté presque totale sur les environnements classiques, ou un développement SPFx à maintenir pour les pages modernes.

Microsoft vient d’annoncer une troisième voie : les pages HTML natives dans SharePoint Online. Elles pourront être créées avec Copilot ou simplement importées dans la bibliothèque Site Pages, puis modifiées et publiées comme des pages SharePoint.

Ce qui change ?

Pour afficher une page HTML travaillée dans SharePoint, il ne sera plus systématiquement nécessaire de développer, packager et déployer une solution SPFx. Mais cette simplicité repose sur un environnement volontairement limité et isolé.

Attention au calendrier :

au 29 septembre 2026, la fonctionnalité n’est pas encore disponible dans tous les tenants. La préversion publique doit commencer début octobre 2026. Le déploiement mondial en disponibilité générale est prévu de mi-novembre à fin décembre 2026.

Avant : une grande liberté sur SharePoint on-premises

Sur les sites SharePoint classiques, notamment en on-premises, les équipes pouvaient intervenir très profondément sur l’affichage :

personnalisation des Master Pages et des Page Layouts ;
ajout de HTML, de CSS et de JavaScript avec les Web Parts Content Editor et Script Editor ;
utilisation de JSLink, de scripts stockés dans Site Assets ou de fichiers chargés depuis un serveur externe ;
modification directe du DOM pour transformer le rendu d’une page.

C’était pratique. Un administrateur ou un intégrateur pouvait construire rapidement une interface sur mesure sans créer un véritable composant applicatif.

Le problème ? Le script s’exécutait dans le contexte de l’utilisateur qui consultait la page. Il pouvait donc accéder à ce que cet utilisateur avait le droit de consulter. De plus, une personnalisation reposant sur la structure HTML interne de SharePoint pouvait casser après une mise à jour.

Une liberté difficile à gouverner :

Microsoft rappelle qu’une fois les scripts personnalisés autorisés, il devient difficile de contrôler finement le code inséré, son emplacement et ses capacités. Cette souplesse avait donc une vraie contrepartie en matière de sécurité et de maintenance.

Hier : pour faire du sur-mesure moderne, il fallait passer par SPFx

Avec les pages modernes de SharePoint Online, Microsoft a fermé la porte à l’injection directe de code dans les Web Parts standards. La Web Part Text ne permet pas d’éditer le HTML et la Web Part Embed accepte principalement des contenus intégrés en iframe, sans balise <script>.

La méthode supportée pour créer une expérience personnalisée est alors devenue le SharePoint Framework, ou SPFx.

Pour afficher du HTML ou une petite application dans une page moderne, il fallait généralement :

récupérer ou développer une Web Part SPFx ;
installer et maintenir l’environnement Node.js, les dépendances npm et la chaîne de compilation ;
compiler et packager la solution au format .sppkg ;
importer le package dans l’App Catalog ;
valider son déploiement, son périmètre et, si nécessaire, ses permissions API ;
ajouter ensuite la Web Part aux pages concernées.

Pour une véritable application métier, cette approche reste logique. SPFx est le framework officiel, gouverné et supporté par Microsoft. En revanche, pour afficher une simple page HTML, le niveau d’effort pouvait sembler disproportionné.

Le risque ne vient pas de SPFx lui-même

Il faut être précis : SPFx n’est pas une faille de sécurité. Le risque apparaît surtout lorsqu’un administrateur télécharge un composant tiers, le package sans auditer son code, puis le déploie largement dans son tenant.

Point de vigilance	Risque associé
Package tiers	Le code s’exécute dans le navigateur et dans le contexte de l’utilisateur connecté.
Dépendances npm	Une bibliothèque vulnérable ou abandonnée ajoute un risque de chaîne d’approvisionnement.
Déploiement global	L’option de déploiement sur l’ensemble des sites augmente fortement le périmètre d’exposition.
Permissions API	Des autorisations trop larges peuvent étendre les capacités du composant au-delà du besoin initial.
Maintenance	Versions SPFx, Node.js, React et dépendances doivent rester compatibles et suivies.

La disparition des Web Parts SPFx isolées par domaine illustre également cette dépendance au cycle de vie de la plateforme. Microsoft a demandé leur migration vers des Web Parts standards avant avril 2026, avec un changement important : les permissions auparavant isolées doivent désormais être accordées au niveau de l’organisation.

Aujourd’hui : SharePoint accueille enfin des pages HTML natives

Avec la fonctionnalité annoncée dans le Message Center sous la référence MC1479517 et dans la roadmap sous l’identifiant 569208, SharePoint Online va permettre de stocker un fichier .html directement dans la bibliothèque Site Pages, de l’afficher comme une page, de le modifier puis de le publier.

Deux scénarios sont prévus :

créer une page avec Copilot à partir d’un prompt et de fichiers de contexte ;
importer une page HTML existante, seule ou accompagnée de son dossier de ressources.

Un propriétaire de site devra d’abord ouvrir la bibliothèque Site Pages, sélectionner File types, puis activer Allow HTML files. Les auteurs pourront ensuite utiliser + New > HTML page ou importer leur fichier depuis la bibliothèque.

Licence Copilot :

elle est nécessaire pour créer ou transformer la page depuis le volet conversationnel de Copilot. Elle n’est pas requise pour importer un fichier HTML, modifier directement le texte, publier la page ou la consulter.

Comment Microsoft sécurise ces pages ?

Microsoft ne réactive pas l’ancien modèle du Script Editor. La page HTML est rendue dans un iframe sandboxé, séparé de l’en-tête, du pied de page et de la navigation SharePoint. Des règles CSP ajoutent une seconde barrière.

❌ Ce qui reste bloqué

les appels fetch arbitraires ;
les appels sortants vers des API ;
les scripts chargés depuis un CDN tiers ;
la communication entre tenants ;
l’accès au localStorage du navigateur.

✅ Ce qui est pris en charge

HTML, CSS et JavaScript contenus dans le fichier ;
images en base64 ou hébergées dans le même domaine ;
Chart.js, Mermaid, React, Fluent UI et Babylon via un CDN géré par Microsoft ;
liens vers des domaines autorisés dans HTML Field Security ;
publication et permissions SharePoint existantes.

La taille maximale d’une page HTML importée est de 10 Mo. Les ressources intégrées peuvent être envoyées dans Site Assets. Une page publiée reste visible uniquement par les utilisateurs disposant déjà des autorisations nécessaires : la publication n’accorde pas de nouveaux droits.

Une page HTML native ne remplace pas encore une page moderne

La première version comporte plusieurs limites importantes. Microsoft indique notamment l’absence de coédition, de brouillons privés, de planification, de commentaires, de réactions, d’enregistrement comme modèle et de promotion en actualité. L’amplification vers Teams et Viva Engage n’est pas non plus disponible.

Autre point de gouvernance : Microsoft documente actuellement un contrôle au niveau de la bibliothèque Site Pages, mais pas de bouton de désactivation globale au niveau du tenant.

HTML natif ou SPFx : que faut-il choisir ?

Besoin	Choix conseillé	Pourquoi ?
Landing page, guide visuel, rapport ou présentation interactive	Page HTML native	Import simple, rendu riche et isolation native.
Web Part réutilisable sur de nombreux sites	SPFx	Déploiement, propriétés configurables et cycle de vie applicatif.
Appels Graph, API métier ou données tierces	SPFx	Les appels API arbitraires sont bloqués dans les pages HTML natives.
Actualité avec commentaires, planification et diffusion	Page moderne	Les fonctions éditoriales ne sont pas encore disponibles pour les pages HTML.

Pour moi…

cette nouveauté remet le HTML à sa juste place dans SharePoint. Une page de contenu riche ne devrait pas obliger un administrateur à maintenir tout un projet SPFx. En revanche, dès que le besoin devient applicatif, connecté ou réutilisable, SPFx reste le bon outil.

Action recommandée :

identifiez les solutions SPFx déployées uniquement pour afficher du contenu HTML. Elles pourront peut-être être simplifiées lorsque la fonctionnalité sera disponible dans votre tenant. Ne migrez toutefois pas les composants qui dépendent de Graph, d’API externes ou de permissions applicatives.

Et vous ?

Utilisez-vous encore des Web Parts SPFx uniquement pour intégrer du HTML dans vos pages SharePoint ?