Vous hésitez entre renommer un site SharePoint Online, changer son adresse (URL) ou aller jusqu’au renommage du domaine du tenant ? Ce guide clair et actionnable explique ce qui change (ou pas), les bonnes pratiques, et fournit des check‑lists et commandes PowerShell prêtes à l’emploi.
Renommer un site SharePoint change‑t‑il son URL ?
Vue d’ensemble de la question
Lorsqu’on modifie le nom (le titre affiché) d’un site SharePoint Online, l’URL du site reste‑t‑elle identique ? Après ce changement de nom, le site devient‑il accessible à une nouvelle adresse du type https://tenant.sharepoint.com/sites/NouveauNom ?
Réponse et solution
- Non. Renommer le nom/titre du site n’affecte pas l’URL. Les anciens liens continuent de fonctionner et il n’existe pas automatiquement d’URL assortie du nouveau nom (pas de
…/NouveauNomgénérée toute seule). - Pour modifier l’URL, il faut effectuer un changement d’adresse du site depuis le Centre d’administration SharePoint (fonction « Modifier l’adresse du site ») ou via PowerShell (
Start-SPOSiteRename).
À retenir en un coup d’œil
| Action | Ce qui change | Ce qui ne change pas | Redirections | Outils / où le faire | Risques/Impacts |
|---|---|---|---|---|---|
| Renommer le nom du site | Titre affiché, libellés dans la navigation | URL du site, ID du site, droits | Aucune redirection créée (l’URL ne change pas) | Paramètres du site > Nom | Impact visuel uniquement, sans coupure |
| Changer l’adresse du site | URL complète du site (/sites/… ou /teams/…) | Contenus, permissions, ID du site | Redirection automatique des anciens liens vers la nouvelle URL | Centre d’administration SharePoint ou PowerShell (Start-SPOSiteRename) | Brève fenêtre d’indisponibilité/lecture seule ; il faut mettre à jour favoris, onglets Teams, flux, apps |
| Renommer le domaine du tenant | Racine de toutes les URL (contoso.sharepoint.com → fabrikam.sharepoint.com) | Noms des sites, contenus, droits | Redirections depuis l’ancien domaine pendant une période limitée (1 an) | Centre d’administration M365 / PowerShell (Start-SPOTenantRename) | Opération organisation‑wide, planification et communication indispensables |
Procédure pas à pas : renommer uniquement le nom du site
- Ouvrez le site cible > Paramètres (engrenage) > Informations sur le site.
- Modifiez le Nom et la Description si besoin, puis Enregistrer.
- Vérifiez la navigation, les hubs et le titre affiché dans Teams si le site est connecté à une équipe.
Procédure pas à pas : changer l’adresse (URL) d’un site
Option 1 — Centre d’administration SharePoint
- Accédez au Centre d’administration SharePoint > Sites actifs.
- Sélectionnez le site > Modifier l’adresse.
- Entrez la nouvelle URL (
/sites/NouveauNomou/teams/NouveauNom), puis validez. - Planifiez le créneau (quelques minutes d’impact possible) et informez vos utilisateurs.
Option 2 — PowerShell
# 1) Se connecter au service SharePoint Online
Connect-SPOService -Url https://<tenant>-admin.sharepoint.com
# 2) Lancer le renommage d’adresse de site
Start-SPOSiteRename ` -Identity https://<tenant>.sharepoint.com/sites/AncienNom`
-NewSiteUrl https\://\.sharepoint.com/sites/NouveauNom \`
-NoWait Bonnes pratiques lors d’un changement d’adresse
- Planifier une fenêtre (impact court mais réel, surtout sites volumineux).
- Communiquer en amont : date, impact, nouvelle URL, ce qui change/ne change pas.
- Mettre à jour immédiatement après : favoris, onglets Teams, applications métiers, flux Power Automate, Power Apps, connecteurs, signets de navigation, scripts.
- Vérifier la recherche, la navigation hub, les liens intégrés, les webparts et les « Raccourcis vers OneDrive ».
- Contrôler les webhooks et abonnements Graph si vous avez des intégrations custom.
Points d’attention spécifiques à Teams, OneDrive et la recherche
- Teams : les onglets Files et tout onglet qui pointe vers une page SharePoint doivent être revalidés. La redirection aide, mais mettez à jour les URL codées en dur.
- OneDrive : les « Ajouter un raccourci à OneDrive » continuent de suivre la ressource, mais revalidez dans les postes pilotés (GPO/Intune) si des chemins étaient ancrés.
- Recherche : laissez à l’index le temps de refléter la nouvelle adresse ; testez les requêtes clés et les signets.
Et si l’on renomme le domaine SharePoint du tenant ?
Vue d’ensemble de la question
Que se passe‑t‑il si l’on passe par exemple de https://contoso.sharepoint.com à https://fabrikam.sharepoint.com ? Les anciens liens restent‑ils valides ?
Réponse et solution
- Le renommage de domaine s’applique à tous les sites SharePoint et OneDrive de l’organisation.
- Redirections : Microsoft assure des redirections depuis l’ancien domaine vers le nouveau pendant 1 an. Profitez‑en pour tout mettre à jour (liens, intégrations, documentations) avant l’échéance.
- C’est une opération sensible : pré‑requis, limitations, tests et communication sont indispensables. Côté automatisation, le pilote est
Start-SPOTenantRename.
Ce qui est affecté par un renommage de domaine
- Toutes les URL SharePoint/OneDrive : sites d’équipe, sites de communication, sites personnels (
…-my.sharepoint.com), pages modernes, bibliothèques, etc. - Intégrations : connecteurs Power Automate/Power Apps, applications internes, scripts, webhooks, Azure Functions, pages d’apps SPFx, applications Teams qui référencent des URL SharePoint.
- Synchronisation : les clients OneDrive/Sync détectent en général la redirection, mais une réinitialisation contrôlée peut être nécessaire sur des postes verrouillés.
Ce qui n’est pas automatiquement ajusté
- Les URL codées en dur (intranets, applications métiers, mails, manuels, scripts, GPO, profils). Il faut les remplacer.
- Les URI de redirection d’apps (Azure AD, SPFx, apps externes) si elles contiennent le domaine SharePoint.
- Les connecteurs/abonnements (Graph, webhooks) : pensez recréation si nécessaire.
Pré‑requis et préparation
| Élément | Exigence / recommandation | Pourquoi c’est important |
|---|---|---|
| Fenêtre de maintenance | Choisir une plage calme (soirée/week‑end) | Réduire l’impact perçu, limiter les collisions d’édition |
| Communication | Message J‑7, J‑1, J0 avec liens nouveaux/anciens | Éviter les tickets, guider la mise à jour des favoris |
| Cartographie des dépendances | Inventorier intégrations, scripts, connecteurs | Mettre à jour tout ce qui référence l’ancien domaine |
| Plan de test | Scénarios de bout en bout (Teams ↔ SharePoint ↔ Power Automate) | Valider les parcours critiques avant/après |
| Plan de repli | Procédures pour clients Sync/Teams, caches, DNS locaux | Réduire le MTTR si incident utilisateur |
Commande PowerShell de haut niveau
# Connexion à l'administration SharePoint Online
Connect-SPOService -Url https://<tenant>-admin.sharepoint.com
# Lancer le renommage de domaine
Start-SPOTenantRename ` -DomainName <nouveau-domaine-sans .sharepoint.com>`
-ScheduledDateTime "2025-09-15T22:00:00" Conseils : planifiez en dehors des pics, vérifiez les politiques de rétention/litiges, et préparez un plan de communication (modèle ci‑dessous).
Modèle d’annonce interne que vous pouvez réutiliser
Objet : Renommage du domaine SharePoint – <Date/Heure>
Bonjour,
Nous renommerons le domaine SharePoint/OneDrive de \ vers \ le \ à \.
Impact : redirections automatiques pendant 1 an ; brèves indisponibilités possibles.
À faire : mettre à jour vos favoris/onglets Teams après l’opération.
Nouvelle base d’URL : https\://\.sharepoint.com
Merci de votre coopération. Migration SharePoint 2019 on‑prem vers Microsoft 365 : échec lié à un nom du type « /OMC‑Sharepoint – 80 » (espaces) ?
Vue d’ensemble
Votre analyse passe mais la migration échoue. Vous soupçonnez que les espaces (ou la mention « … – 80 ») empêchent la résolution de l’URL. Faut‑il renommer ? Pas si vite.
Ce que signifie réellement « SharePoint – 80 »
Le libellé « SharePoint – 80 » correspond généralement au nom du site IIS (ou de l’application Web) sur le serveur on‑premise, pas à l’URL que consomme l’outil de migration. Les espaces dans ce libellé ne sont pas la cause directe de l’échec.
Checklist de diagnostic rapide
- Cibler la vraie URL de la collection de sites, par exemple
http://serveur:80/sites/Collectionouhttps://intranet.domaine.local/sites/Collection. Testez depuis la machine qui lance l’outil de migration (navigateur,Invoke-WebRequest). - Comptes et droits : le compte utilisé doit être administrateur de collection de sites sur la source et disposer des droits adéquats côté Microsoft 365.
- Authentification : validez NTLM/Kerberos. Si Kerberos est attendu, vérifiez SPN, délégation et absence de double‑saut.
- Réseau/DNS : résolution DNS ou
hostslocale, accès aux ports 80/443, absence de proxy bloquant. - Chemins avec espaces dans des sous‑sites ou bibliothèques : c’est supporté (
%20en URL). Copiez/collez l’URL exactement telle qu’affichée par le navigateur. - Essai minimal : migrez une petite bibliothèque vers un site de test M365 pour isoler (journalisez les erreurs de l’outil).
- Host header propre : si l’URL source est « peu propre », créez/validez un en‑tête d’hôte via Alternate Access Mappings (AAM) et utilisez cette URL dans l’outil.
Bonnes pratiques de préparation à la migration
- Inventaire : listez collections, quotas, features activées, tailles, solutions farm, personnalisations (master pages, JS, InfoPath, workflows 2010/2013).
- Hygiène : supprimez contenus orphelins, versions excédentaires, recycle bin volumineux, et fixez les checked‑out bloquants.
- Compatibilité : anticipez les remplacements (Flow/Power Automate pour workflows 2010, modern pages pour publishing classiques, SPFx pour scripts personnalisés).
- Tests : effectuez une « migration pilote » sur un périmètre restreint, puis montez en charge.
Script d’auto‑vérification réseau (exemple)
# À exécuter depuis la machine de migration
# 1) Résolution DNS
Resolve-DnsName intranet.domaine.local
# 2) Reachability HTTP/HTTPS
Test-NetConnection intranet.domaine.local -Port 80
Test-NetConnection intranet.domaine.local -Port 443
# 3) Test basique d'authentification
Invoke-WebRequest [https://intranet.domaine.local/sites/Collection](https://intranet.domaine.local/sites/Collection) -UseDefaultCredentials Faut‑il renommer la source on‑prem ?
Évitez un renommage à la hâte. Dans l’immense majorité des cas, la bonne URL + les bons droits + la résolution réseau correcte débloquent la migration. Réservez un renommage IIS/host headers aux contextes où l’URL est véritablement inutilisable depuis la zone « Extranet/Internet » de la machine de migration.
Scénarios concrets et décisions guidées
Scénario A : simple correction de libellé
Votre intranet s’appelle « Projets Europe » et vous voulez « Projets EMEA ». Action : renommez le nom du site. Impact : visuel uniquement, aucune coupure, aucun lien à changer.
Scénario B : URL obsolète ou non conforme
Votre site s’appelle « Achats » mais l’URL est /sites/Finance. Action : changer l’adresse (/sites/Achats). Impacts : brève coupure potentielle, redirection automatique des anciens liens, mise à jour des intégrations recommandée.
Scénario C : changement d’identité d’entreprise
Vous passez de Contoso à Fabrikam et vous souhaitez harmoniser toutes les URL. Action : renommer le domaine. Impacts : organisation‑wide, redirections d’un an, mise à jour intensive des outils et documentations, tests/communication obligatoires.
Impacts applicatifs et actions recommandées
| Composant | Renommer le nom du site | Changer l’adresse du site | Renommer le domaine du tenant | Action recommandée |
|---|---|---|---|---|
| Teams (onglets et canaux) | Aucun impact fonctionnel | Valider onglets « Site web »/Wiki/Lists | Revalider tous les onglets qui référencent des URL | Mettre à jour les onglets qui utilisent des liens codés en dur |
| Power Automate | Stable | Reconnecter si l’URL est intégrée au connecteur | Revérifier connexions/URLs d’actions | Exporter/Importer si nécessaire, ou modifier les connexions |
| Power Apps | Stable | Mettre à jour les DataSources SharePoint | Reconfigurer connexions/permissions | Republier après mise à jour |
| OneDrive Sync | Stable | Peut suivre la redirection, revalider sur postes gérés | Peut nécessiter réinitialisation contrôlée | Préparer script de reset OneDrive si besoin |
| Signets/favoris | Pas d’action | À mettre à jour | À mettre à jour | Publier des listes de liens corrigés |
| Webhooks / Graph | Pas d’action | À vérifier | Probablement à recréer | Inventorier et recréer après renommage |
Foire aux questions
Combien de temps dure le changement d’adresse d’un site ?
La durée varie selon le volume et la complexité : elle peut se compter en minutes pour un site standard. Pendant une partie de l’opération, le site peut passer en mode lecture seule.
Les liens existants vers l’ancienne adresse de site continuent‑ils de fonctionner ?
Oui, une redirection automatique est créée lorsque vous changez l’adresse d’un site. Cela permet de préserver la plupart des liens historiques (bookmarks, documents, e‑mails). Mais mettez à jour les intégrations et scripts qui embarquent l’URL en dur.
Puis‑je renommer le domaine, puis renommer des sites ensuite ?
Oui. L’ordre recommandé est souvent : renommage de domaine (si nécessaire) puis changements d’adresses de sites résiduels. De cette façon, vous évitez les doubles migrations d’URL.
Le renommage du domaine affecte‑t‑il les sites classiques (publishing) ?
Oui, car l’URL racine change pour tout le tenant. Testez particulièrement les pages avec liens codés en dur, scripts personnalisés et master pages anciennes.
Quid des liens externes partagés avec des partenaires ?
Les redirections aident, mais informez vos partenaires des nouvelles URL et republiez les liens si nécessaire, surtout pour les accès limités dans le temps.
Plans d’action prêts à l’emploi
Plan rapide : changer l’adresse d’un site sans frictions
- Avant : validez propriétaires, volumétrie, dépendances (Teams, Power Automate), choisissez un créneau.
- Pendant : lancez « Modifier l’adresse du site » (ou
Start-SPOSiteRename), surveillez l’avancement. - Après : contrôlez navigation, recherche, onglets Teams ; mettez à jour liens et applications ; communiquez « c’est fait ».
Plan robuste : renommage de domaine SharePoint
- Préparer : sponsors, jalons, cartographie des dépendances, messages J‑7/J‑1/J0.
- Tester : maquette (sandbox), tests bout‑en‑bout, scripts de vérification post‑op.
- Exécuter : lancer
Start-SPOTenantRenamedans la fenêtre prévue, support en temps réel. - Finaliser : campagne de mise à jour des liens et documentation, revue de conformité.
Résumé exécutable
- Changer le nom d’un site n’a aucun effet sur l’URL ; pour une nouvelle URL, utilisez Modifier l’adresse du site (Centre d’administration) ou
Start-SPOSiteRename. - Renommer le domaine du tenant change toutes les adresses ; l’ancien domaine redirige 1 an : mettez à jour liens et intégrations avant l’échéance.
- Migration 2019 → M365 : ciblez la vraie URL de collection, vérifiez droits, réseau et authentification ; les espaces dans le nom IIS ne sont pas le problème.
Annexes : commandes utiles
Changer l’adresse d’un site SharePoint Online
Connect-SPOService -Url https://<tenant>-admin.sharepoint.com
Start-SPOSiteRename `
-Identity https://<tenant>.sharepoint.com/sites/AncienNom `
-NewSiteUrl https://<tenant>.sharepoint.com/sites/NouveauNom `
-NoWait
Renommer le domaine SharePoint du tenant
Connect-SPOService -Url https://<tenant>-admin.sharepoint.com
Start-SPOTenantRename `
-DomainName <nouveau-domaine> `
-ScheduledDateTime "2025-09-15T22:00:00"
Vérifications post‑op
# 1) Recherche
# Vérifier que des mots-clés clés retournent des résultats du site renommé
# 2) Teams
# Ouvrir les canaux clés et valider les onglets « Site web » / Listes / Pages
# 3) Power Automate
# Ouvrir les flux critiques, tester un déclenchement et une action SharePoint
Conclusion : renommer un site est un changement visuel ; changer l’adresse touche l’URL et requiert préparation ; renommer le domaine est une opération globale qui nécessite projet, tests et communication. En suivant les check‑lists ci‑dessus et en utilisant les commandes PowerShell appropriées, vous sécurisez vos changements tout en minimisant l’impact utilisateur.