ITSkillsCenter
Business Digital

Gouverner Microsoft Teams : nommage, cycle de vie, archivage

13 min de lecture

Microsoft Teams ouvre par défaut grand la porte : tout le monde peut créer une équipe, n’importe quand, sur n’importe quel sujet. Sans gouvernance, on récolte au bout de six mois quarante équipes dont la moitié est inactive, des doublons, des canaux abandonnés et un moteur de recherche qui retourne quinze versions du même fichier. Ce tutoriel met en place les trois leviers fondamentaux de gouvernance : la politique de nommage des groupes, l’expiration automatique, la restriction de la création.

Article principal : Microsoft 365 pour PME — architecture et gouvernance.

Prérequis

  • Un locataire Microsoft 365 avec au moins une licence Microsoft Entra ID P1 par utilisateur impacté (incluse dans Microsoft 365 Business Premium).
  • Un compte avec le rôle Administrateur global ou Administrateur des groupes dans Microsoft Entra ID.
  • PowerShell 7 et le module Microsoft.Graph installé.
  • Un groupe de sécurité SG-Createurs-Equipes qui contiendra les utilisateurs autorisés à créer des équipes (à créer si absent).
  • Niveau attendu : administrateur Microsoft 365 confirmé.
  • Temps : 90 minutes la première fois.

Étape 1 — Décider du modèle de nommage avant tout

La politique de nommage est une décision irréversible dans la pratique : une fois qu’une équipe est créée, son nom influence l’URL du site SharePoint sous-jacent et l’adresse mail du groupe. Renommer une équipe deux mois après sa création casse les marque-pages des utilisateurs. La règle pratique consiste donc à arrêter le modèle avant la première équipe.

Le modèle qui fonctionne dans la majorité des PME se construit en deux ou trois préfixes thématiques courts. EQP- pour les équipes projet à durée limitée, SVC- pour les services pérennes (Direction, RH, Comptabilité, Commercial), EXT- pour les équipes incluant des invités externes (clients, partenaires, prestataires). On y ajoute parfois un suffixe d’attribut Entra ID — typiquement [Department] — qui se substitue automatiquement à la valeur du département de l’utilisateur créateur. Cette substitution garantit qu’une équipe créée par un commercial reçoit le suffixe « Commercial » sans intervention.

Avant d’écrire la politique, on liste aussi les mots à bloquer : CEO, Direction, Comptabilité, Paie, RH, Confidentiel — autrement dit les termes qu’un utilisateur lambda ne doit pas pouvoir utiliser pour s’arroger une légitimité qu’il n’a pas. La politique de blocage interdit la création, pas la lecture : les équipes existantes qui contiendraient ces mots restent intactes.

Étape 2 — Activer la politique de nommage des groupes Microsoft 365

La politique de nommage ne se configure plus via l’interface graphique du centre Entra (Microsoft a retiré l’option dans le portail moderne) ; elle se configure exclusivement via PowerShell ou Microsoft Graph. La commande ci-dessous crée la politique en une fois.

# Activation de la politique de nommage des groupes Microsoft 365
Connect-MgGraph -Scopes "Directory.ReadWrite.All"
$template = Get-MgDirectorySettingTemplate | Where-Object { $_.DisplayName -eq "Group.Unified" }
$params = @{
  TemplateId = $template.Id
  Values = @(
    @{ Name = "PrefixSuffixNamingRequirement"; Value = "EQP-[GroupName]-[Department]" },
    @{ Name = "CustomBlockedWordsList"; Value = "CEO,Direction,RH,Paie,Confidentiel" }
  )
}
New-MgDirectorySetting -BodyParameter $params

Le bloc charge le modèle de configuration « Group.Unified » (présent dans tous les locataires) puis crée une instance de configuration qui impose le préfixe EQP- et le suffixe -[Department]. La sortie est un objet DirectorySetting avec un Id qu’on conserve ; il sert à modifier la politique plus tard sans avoir à la recréer. Pour vérifier l’effet, un utilisateur tente de créer une équipe Teams nommée « Test » — il doit voir le nom transformé en « EQP-Test-Commercial » (selon son département) avant validation. Si le mot « Direction » figure dans le nom, la création est refusée avec un message indiquant le mot bloqué.

Étape 3 — Configurer la politique d’expiration des groupes

Une équipe inactive depuis 365 jours sans renouvellement explicite est mise à la corbeille puis supprimée trente jours plus tard. La politique d’expiration des groupes Microsoft 365 met en place ce cycle de vie sans intervention manuelle. Elle s’applique uniformément à toutes les équipes du locataire ou à un sous-ensemble explicite.

# Politique d'expiration : 365 jours, applicable à toutes les équipes
Connect-MgGraph -Scopes "Directory.ReadWrite.All"
$body = @{
  groupLifetimeInDays = 365
  managedGroupTypes = "All"
  alternateNotificationEmails = "gouvernance@exemple.com"
} | ConvertTo-Json
Invoke-MgGraphRequest -Method PATCH -Uri "https://graph.microsoft.com/v1.0/groupLifecyclePolicies" -Body $body -ContentType "application/json"

La politique applique 365 jours de durée de vie. Microsoft applique d’abord un renouvellement automatique fondé sur l’activité : une équipe sur laquelle un membre envoie un message, ouvre un fichier SharePoint ou visite un canal dans la fenêtre des 35 derniers jours avant expiration est renouvelée silencieusement, sans notification. Si aucune activité n’est détectée, 30, 15 et 1 jour avant l’expiration, le propriétaire reçoit un courriel automatique avec un lien de renouvellement — un clic sur ce lien réinitialise le compteur pour 365 jours. Si aucun propriétaire ne renouvelle, l’adresse gouvernance@exemple.com est notifiée en repli, et la corbeille conserve l’équipe pendant 30 jours, restaurable par un administrateur. La sortie attendue est un statut HTTP 204 ou 200 OK.

L’usage est nuancé : pour les équipes projet, 365 jours est cohérent. Pour les équipes de service pérennes (Direction, RH), 365 jours produit du bruit inutile — un responsable RH ne va pas « renouveler » l’équipe RH chaque année. Dans ce cas, on utilise managedGroupTypes = "Selected" et on liste explicitement les équipes projet via l’API /groupLifecyclePolicies/{id}/addGroup.

Étape 4 — Restreindre la création d’équipes

Par défaut, n’importe quel utilisateur peut créer une équipe. Pour une PME en phase d’amorçage, c’est trop ouvert : on bascule sur le modèle « création par un cercle restreint ». La politique se construit en deux temps : créer le groupe de sécurité qui liste les créateurs autorisés, puis configurer Microsoft 365 Groups pour interdire la création par défaut.

# Création du groupe de sécurité des créateurs
Connect-MgGraph -Scopes "Group.ReadWrite.All","Directory.ReadWrite.All"
$grp = New-MgGroup -DisplayName "SG-Createurs-Equipes" -MailEnabled:$false -MailNickname "sg-createurs-equipes" -SecurityEnabled
$grp.Id

# Activation de la restriction de création
$template = Get-MgDirectorySettingTemplate | Where-Object { $_.DisplayName -eq "Group.Unified" }
$existing = Get-MgDirectorySetting | Where-Object { $_.DisplayName -eq "Group.Unified" }
if (-not $existing) {
  $params = @{
    TemplateId = $template.Id
    Values = @(
      @{ Name = "EnableGroupCreation"; Value = "false" },
      @{ Name = "GroupCreationAllowedGroupId"; Value = $grp.Id }
    )
  }
  New-MgDirectorySetting -BodyParameter $params
} else {
  Update-MgDirectorySetting -DirectorySettingId $existing.Id -Values @(
    @{ Name = "EnableGroupCreation"; Value = "false" },
    @{ Name = "GroupCreationAllowedGroupId"; Value = $grp.Id }
  )
}

Le bloc crée le groupe de sécurité, capture son Id et l’utilise pour configurer la politique. Le test pratique consiste à se connecter avec un compte qui n’est pas membre du groupe et à tenter de créer une équipe — l’option doit être absente du menu Teams. À l’inverse, un membre du groupe doit conserver l’option de création. On ajoute progressivement les chefs de service à SG-Createurs-Equipes à mesure que la politique éditoriale interne s’installe.

Étape 5 — Distinguer canaux standards, privés et partagés

Teams propose trois types de canaux dont la mécanique de stockage et de permissions est radicalement différente. Le réflexe à acquérir est de choisir le bon type au moment de la création parce qu’on ne peut pas convertir un canal standard en canal privé après coup.

Le canal standard est visible par tous les membres de l’équipe : ses fichiers sont stockés dans le site SharePoint principal de l’équipe, dans une bibliothèque Documents avec un dossier portant le nom du canal. Les permissions héritent de l’équipe. C’est le type par défaut, à utiliser pour 95 % des canaux.

Le canal privé est visible uniquement par un sous-ensemble de membres de l’équipe : ses fichiers sont stockés dans un site SharePoint séparé, dédié à ce canal, avec ses propres permissions. C’est utile pour cloisonner une discussion sensible (par exemple un comité de direction au sein d’une équipe Direction). On l’utilise avec parcimonie : chaque canal privé crée un site SharePoint supplémentaire à gouverner.

Le canal partagé permet d’inclure des personnes hors de l’équipe (et même hors du locataire, en B2B direct) dans un canal donné. Il est puissant pour la collaboration avec des partenaires ; il exige une configuration de la fédération B2B et n’est pas activé par défaut dans tous les locataires.

# Activer la création de canaux partagés (pour collaboration externe)
Connect-MgGraph -Scopes "Policy.ReadWrite.AuthenticationMethod"
$body = @{
  isCrossTenantAccessEnabled = $true
} | ConvertTo-Json
Invoke-MgGraphRequest -Method PATCH -Uri "https://graph.microsoft.com/v1.0/policies/crossTenantAccessPolicy/default" -Body $body -ContentType "application/json"

L’appel ouvre la fédération B2B direct au niveau de la politique d’accès cross-tenant. Sans cette ouverture, les canaux partagés ne peuvent inclure que des comptes du même locataire, ce qui réduit leur intérêt. Une fois activé, on configure cas par cas, dans le centre d’administration Entra → External Identities → Cross-tenant access settings, les locataires partenaires autorisés.

Étape 6 — Activer les étiquettes de confidentialité sur les groupes

Les étiquettes de confidentialité Microsoft Purview, appliquées aux groupes Microsoft 365, sont un outil de gouvernance avancé qui pilote en un clic les paramètres de confidentialité d’une équipe : niveau d’accès externe autorisé, accès depuis des appareils non gérés, statut public ou privé, intégration aux politiques de prévention des fuites de données.

L’activation se fait en deux étapes : créer les étiquettes dans le portail Microsoft Purview (Conformité), puis publier une politique d’application. Une PME démarre typiquement avec trois étiquettes : Public (équipe ouverte, accès interne large), Interne (équipe fermée, pas d’invité externe), Confidentiel (équipe privée, accès depuis appareils gérés uniquement, pas d’invité externe).

# Activer les étiquettes pour les groupes M365 (côté Entra)
Connect-MgGraph -Scopes "Directory.ReadWrite.All"
$template = Get-MgDirectorySettingTemplate | Where-Object { $_.DisplayName -eq "Group.Unified" }
$existing = Get-MgDirectorySetting | Where-Object { $_.DisplayName -eq "Group.Unified" }
Update-MgDirectorySetting -DirectorySettingId $existing.Id -Values @(
  @{ Name = "EnableMIPLabels"; Value = "true" }
)

Cette commande active l’intégration des étiquettes de confidentialité côté Entra. Une fois publiées dans Purview, les étiquettes apparaissent au moment de la création d’une équipe ; le créateur doit en choisir une, et selon l’étiquette choisie, certaines options (autoriser les invités, rendre l’équipe publique) sont automatiquement verrouillées. Cette mécanique remplace la maintenance manuelle de scripts de configuration et donne une trace d’audit centralisée dans Purview.

Étape 7 — Auditer le parc et identifier les équipes à archiver

La meilleure politique du monde ne nettoie pas le passé. Pour les équipes créées avant la mise en place de la gouvernance, on conduit un audit semestriel qui identifie les équipes dormantes (aucune activité depuis 90 jours), les équipes orphelines (sans propriétaire actif) et les équipes redondantes.

# Liste des équipes inactives depuis 90 jours
Connect-MgGraph -Scopes "Reports.Read.All","Group.Read.All"
$rapport = Invoke-MgGraphRequest -Method GET -Uri "https://graph.microsoft.com/v1.0/reports/getTeamsActivityCounts(period='D90')" -OutputType HttpResponseMessage
$contenu = $rapport.Content.ReadAsStringAsync().Result
[System.IO.File]::WriteAllText("teams-activity.csv", $contenu, [System.Text.Encoding]::UTF8)

Le rapport téléchargé est un fichier CSV qui dénombre, par équipe et par jour, les messages, les réunions et les fichiers partagés. On l’ouvre dans Excel, on filtre les équipes dont la somme des activités sur 90 jours est nulle, et on examine chacune pour décider : archiver (équipe terminée mais à conserver pour traçabilité), supprimer (équipe sans valeur historique), revivifier (équipe utile mais oubliée — on relance la communication interne).

L’archivage d’une équipe se fait depuis le centre d’administration Teams, ou via PowerShell : Set-Team -GroupId <id> -Archived $true. L’archivage met l’équipe en lecture seule pour tous les membres, fige les canaux et libère la consommation de licences ; les fichiers SharePoint sous-jacents restent accessibles. C’est le geste de gouvernance le plus important en routine : archiver vaut mieux que supprimer dans 90 % des cas.

Étape 8 — Vérification et tableau de bord récurrent

Pour clôturer la mise en place, on contrôle que les politiques sont actives et on prépare un tableau de bord trimestriel.

# Vérification consolidée
Connect-MgGraph -Scopes "Directory.Read.All"
"=== POLITIQUE DE NOMMAGE ==="
(Get-MgDirectorySetting | Where-Object { $_.DisplayName -eq "Group.Unified" }).Values | Format-Table

"=== POLITIQUE D'EXPIRATION ==="
Invoke-MgGraphRequest -Method GET -Uri "https://graph.microsoft.com/v1.0/groupLifecyclePolicies"

"=== NOMBRE D'EQUIPES TOTAL ==="
(Get-MgGroup -Filter "resourceProvisioningOptions/Any(x:x eq 'Team')" -All).Count

Le rapport doit afficher le préfixe et le suffixe configurés, la durée de vie en jours, et le nombre total d’équipes. Si l’une de ces sorties est vide ou erronée, on remet la commande de configuration correspondante. Ce script tient lieu de vérification mensuelle : en l’exécutant chaque premier du mois, on détecte une politique désactivée par un autre administrateur ou un changement de plateforme.

Erreurs fréquentes

Erreur Cause Solution
La politique de nommage n’est pas appliquée Pas de licence Entra ID P1 sur le créateur Vérifier l’attribution de licence dans le centre d’administration
Une équipe a expiré et personne n’a vu le courriel Le propriétaire est parti, pas de propriétaire de repli Toujours nommer deux propriétaires par équipe ; alternateNotificationEmails en filet
Restriction de création trop stricte, blocage opérationnel Groupe créateur trop petit Ajouter les chefs de service au groupe au lieu d’élargir la politique
Canaux privés multiples qui prolifèrent Confusion canal privé / canal partagé Atelier dédié, canal privé uniquement pour cloisonnement intra-équipe
Équipe archivée puis besoin de la réactiver Archivage trop rapide sans concertation Set-Team -Archived $false réactive sans perte ; mais valider la décision en amont

FAQ

La politique de nommage s’applique-t-elle aux équipes existantes ?

Non. Elle ne s’applique qu’aux nouvelles équipes créées après son activation. Les équipes existantes conservent leur nom d’origine. Pour normaliser le passé, on renomme manuellement les équipes critiques en respectant la convention ; pour les équipes secondaires, on les laisse telles quelles et on attend leur archivage naturel.

Que devient une équipe Teams quand on supprime son groupe Microsoft 365 ?

Tout est supprimé en cascade : l’équipe Teams, le site SharePoint, la boîte mail partagée, le calendrier de groupe, le bloc-notes OneNote. Microsoft conserve l’ensemble dans un état soft-delete pendant 30 jours pendant lesquels un administrateur peut tout restaurer via Restore-MgDirectoryDeletedItem. Au-delà, les données sont purgées définitivement.

Faut-il créer un canal général ou créer une équipe par projet ?

Le canal général sert à la coordination de l’équipe entière. Pour un projet ponctuel impliquant des membres de plusieurs équipes existantes, on crée une nouvelle équipe projet dédiée plutôt qu’un canal — un projet a une fin, le canal d’une équipe pérenne reste après le projet et brouille la lecture historique.

Peut-on imposer la confidentialité d’une équipe (privée par défaut) ?

Oui, via les étiquettes de confidentialité Microsoft Purview. On peut publier une politique qui force toute nouvelle équipe à choisir une étiquette, et configurer cette étiquette pour qu’elle impose le mode privé et interdise les invités externes. Cette mécanique est plus robuste que les conventions documentées qu’on demande aux créateurs de suivre.

Tutoriels associés

Ressources officielles

#cluster-microsoft-365-pme #cluster-satellite #Microsoft 365 #Microsoft Teams #pme-afrique
Sponsoriser ce contenu

Cet emplacement est à vous

Position premium en fin d'article — c'est l'instant où les lecteurs sont le plus engagés. Réservez cet espace pour votre marque, votre formation ou votre offre.

Recevoir nos tarifs
Publicité

Articles Similaires