La création automatisée de sites SharePoint est depuis longtemps un besoin récurrent dans les organisations : nouveaux projets, nouvelles équipes, départements qui évoluent, portails internes… Chaque fois, il faut provisionner un site cohérent, configuré, prêt à l’usage. Jusqu’à récemment, cette opération passait surtout par les API SharePoint historiques ou par des scripts PnP/PowerShell avec des permissions très élevées. Une solution efficace, certes, mais rarement élégante et loin d’être optimale en matière de sécurité.
C’est précisément ce que Microsoft vient de changer. Avec l’arrivée du support de la création de sites dans Microsoft Graph, une nouvelle porte s’ouvre pour les équipes de développement, les architectes et les responsables de gouvernance Microsoft 365. L’API est encore en version beta, mais elle introduit un modèle nettement plus moderne, plus sécuritaire et surtout plus intégré dans l’écosystème Graph.
Une évolution importante pour SharePoint… et pour les développeurs
L’annonce faite par l’équipe SharePoint est simple : il est désormais possible de créer des collections de sites via un appel REST unifié, utilisable depuis n’importe quel langage ou plateforme capable d’envoyer une requête HTTP.
Et surtout, ce nouvel endpoint permet d’utiliser un scope beaucoup plus raisonnable que le traditionnel Sites.FullControl.All. Microsoft introduit maintenant Sites.Create.All, un droit plus ciblé, qui respecte justement ce que les architectes réclament depuis longtemps : appliquer le principe du moindre privilège.
Concrètement, on peut enfin créer un site SharePoint via Graph, que ce soit un site de communication, un team site ou un site lié à un groupe Microsoft 365, sans ouvrir toutes les portes du tenant à l’application.
L’appel Graph : simple, propre, efficace
L’API repose sur un appel HTTP clairement structuré :
POST https://graph.microsoft.com/beta/sitesC’est direct, lisible, moderne. On fournit un objet JSON décrivant le site à créer, son nom, son URL finale, son modèle et quelques métadonnées clés.
Voici par exemple un site de communication minimal :
{
"name": "Communication Site Test",
"webUrl": "https://contoso.sharepoint.com/sites/commsite1",
"locale": "en-US",
"description": "Test Site Description",
"template": "sitepagepublishing",
"ownerIdentityToResolve": {
"email": "ryan@contoso.com"
}
}Le champ le plus stratégique, ici, est template. Il détermine la nature du site :
sitepagepublishing→ site de communicationsts→ team site classique (sans groupe Microsoft 365)group→ site associé à un groupe Microsoft 365
Avec ce simple paramètre, tu contrôles entièrement le contexte collaboratif du site, un vrai gain en clarté et en prévisibilité.
Lorsque l’appel réussit, le service renvoie un 202 Accepted et crée une opération longue dont tu peux suivre le statut via le header Location. Ce mécanisme évite de bloquer les requêtes et s’intègre naturellement dans des workflows d’automatisation.
Ce que cette API change réellement dans les organisations
L’impact dépasse largement le domaine purement technique. Pour les entreprises qui souhaitent automatiser leurs environnements Microsoft 365, cette API ouvre la voie à un provisioning structuré, maîtrisé et aligné avec les bonnes pratiques de sécurité.
Moins de privilèges, plus de gouvernance
La possibilité d’utiliser Sites.Create.All, combiné si besoin avec Sites.Selected, permet de créer une application qui n’a que les droits nécessaires, ni plus ni moins. C’est un changement majeur par rapport aux anciennes méthodes qui donnaient des permissions potentiellement risquées sur l’ensemble des sites existants.
Une vraie standardisation des sites
Grâce à la création via Graph, il devient facile d’enchaîner une série d’actions automatisées : configuration des bibliothèques, application de modèles, ajout de métadonnées, mise en place des permissions…
On peut orchestrer tout ça dans un seul pipeline, en mode Infrastructure-as-Code ou automatisation serverless.
Une intégration naturelle dans le reste de l’écosystème Microsoft 365
Teams, Groupes Microsoft 365, utilisateurs, rôles, stockage OneDrive, sécurité… Tout passe par Graph.
Pouvoir créer des sites SharePoint dans la même logique rend les solutions beaucoup plus cohérentes et plus simples à maintenir.
Quelques points d’attention avant de l’adopter
Bien que très prometteuse, l’API reste en version beta. Cela signifie plusieurs choses :
- le schéma peut encore évoluer ;
- certains SDK ne l’intègrent pas encore ;
- il faut rester attentif aux changements dans la documentation.
Rien d’alarmant, mais cela implique une vigilance continue, surtout si tu prévois un déploiement en environnement critique.
L’arrivée de la création de sites SharePoint dans Microsoft Graph représente une étape importante dans la modernisation de l’écosystème Microsoft 365. Plus simple, plus sécuritaire et mieux intégrée, cette API offre enfin une façon élégante d’automatiser un processus qui, jusque-là, restait fragmenté et parfois délicat à sécuriser.
Que tu sois développeur, architecte ou responsable de la gouvernance, cette fonctionnalité ouvre de nouvelles perspectives : automatisation fluide, standardisation des environnements, amélioration du contrôle des permissions et une meilleure intégration entre les différents services Microsoft 365.