Microsoft Teams : « Nous n’avons pas pu compléter cette action » lors de la création d’une équipe — diagnostic et correctifs

Vous ne pouvez plus créer de nouvelles équipes dans Microsoft Teams et le message « Nous n’avons pas pu compléter cette action »/« No pudimos completar esta acción » s’affiche ? Voici une méthode éprouvée pour rétablir la création d’équipes et un guide de diagnostic complet.

Sommaire

Symptôme

Sur un locataire Microsoft 365 (abonnement professionnel individuel), la création d’équipes a cessé de fonctionner du jour au lendemain. Toute tentative aboutissait au message d’échec générique : « Nous n’avons pas pu compléter cette action » (selon la langue du client, « No pudimos completar esta acción », « We couldn’t complete this action », etc.).

Le problème affectait à la fois le client de bureau et le client web de Teams.

Solution rapide qui a débloqué la situation

Se connecter au Centre d’administration Microsoft 365 et ouvrir le Centre d’administration Teams. Vérifier que l’utilisateur détient bien les autorisations attendues et que la création d’équipes est autorisée pour l’organisation.
Créer une équipe depuis le Centre d’administration : via Équipes > Gérer les équipes > Ajouter, créer une équipe « test ». L’opération aboutit.

Une fois cette équipe créée par l’admin center, la création via l’application Teams (bureau et web) s’est remise à fonctionner normalement pour l’utilisateur.

Constat : exécuter l’action côté admin center a vraisemblablement réinitialisé ou propagé correctement les stratégies et paramètres sous-jacents (Microsoft 365 Groups, stratégies Teams, étiquettes, etc.), levant un état incohérent qui bloquait la création côté clients.

Pourquoi cette manœuvre peut fonctionner ?

Créer une équipe déclenche, en arrière-plan, la création d’un groupe Microsoft 365, l’affectation de stratégies Teams et la préparation des ressources (SharePoint, Planner, etc.). Quand un paramètre du locataire est modifié (par exemple la restriction de création de groupes ou une étiquette de sensibilité qui s’applique aux conteneurs), il arrive que les clients gardent un état caché incohérent (cache local, jetons, réplication incomplète). L’admin center, en revanche, appelle directement les services avec des autorisations élevées et force la réconciliation des dépendances : une fois la première équipe créée, les clients retrouvent un chemin fonctionnel.

Procédure de diagnostic recommandée

Avant d’ouvrir un ticket, déroulez cette check‑list. Elle vous fera gagner du temps et vous permettra d’exclure l’essentiel.

Étape	But
Vérifier les stratégies Teams et les paramètres de groupes dans Entra ID/Azure AD (« Les utilisateurs peuvent créer des groupes Microsoft 365 »).	Confirmer que la création n’est pas restreinte par la configuration du locataire.
Tester la création depuis le client web (teams.microsoft.com).	Écarter un problème propre au client de bureau.
Mettre l’application Teams à jour puis redémarrer.	Exclure un bug déjà corrigé dans une version plus récente.
Consulter l’état du service (Admin > Santé du service).	Identifier un incident Microsoft affectant la fonctionnalité.
Vider le cache local de Teams (`%AppData%\Microsoft\Teams` ou `%LocalAppData%\Packages\MSTeams_8wekyb3d8bbwe\LocalCache`).	Supprimer des données corrompues pouvant empêcher des opérations.
Si nécessaire, ouvrir une demande de support Microsoft.	Escalader le problème avec journaux et informations de locataire.

Causes fréquentes et correctifs associés

Symptôme/indice	Cause probable	Correctif recommandé
Le message d’erreur apparaît immédiatement après « Créer une équipe ».	Restriction de création des groupes Microsoft 365 activée et l’utilisateur n’appartient pas au groupe autorisé.	Ajouter l’utilisateur au groupe autorisé ou lever la restriction (voir section « Vérifications PowerShell/Graph »).
La nouvelle équipe n’apparaît jamais mais aucune erreur détaillée n’est visible.	Incohérence de stratégies (propagation incomplète) ou cache client corrompu.	Créer une équipe via l’admin center (déclenche une resynchronisation), puis vider le cache client et relancer Teams.
Le bouton « Créer une équipe » a disparu pour certains utilisateurs.	Application récente d’un groupe d’administration limitant la création de groupes/équipes.	Contrôler la stratégie « GroupCreationAllowedGroupId » ; vérifier la présence de l’utilisateur dans ce groupe.
L’utilisateur voit des étiquettes obligatoires lors de la création mais ne peut pas finaliser.	Étiquettes de sensibilité (conteneurs) requises sans publication correcte au profil de l’utilisateur.	Publier l’étiquette au bon périmètre et s’assurer qu’elle autorise la création de groupes/équipes.
Le problème survient juste après des changements de licences.	Provisionnement différé des services associés (SharePoint, Planner, etc.).	Conserver une première création côté admin center puis retester côté client.
Uniquement le client de bureau échoue, le web fonctionne.	Cache ou profil Teams côté machine.	Nettoyer les dossiers de cache (Windows/macOS) et réauthentifier.

Vérifications via PowerShell / Microsoft Graph

Si vous avez les droits adéquats, quelques commandes permettent de confirmer rapidement la posture du locataire. Utilisez de préférence le module Microsoft.Graph (le module AzureAD classique est en fin de vie).

1. Lire la configuration « Group.Unified » (création de groupes)

Avec Microsoft Graph PowerShell

Install-Module Microsoft.Graph -Scope CurrentUser
Import-Module Microsoft.Graph
Connect-MgGraph -Scopes "Directory.Read.All","Group.Read.All"

# Récupérer les paramètres de répertoire

$dirSettings = Get-MgDirectorySetting

# Chercher le bloc Group.Unified

$groupUnified = $dirSettings | Where-Object DisplayName -eq "Group.Unified"

# Afficher les valeurs clés

$groupUnified.Values | Format-Table Name, Value

# Identifier le groupe autorisé (si restriction active)

$allowedId = ($groupUnified.Values | Where-Object Name -eq "GroupCreationAllowedGroupId").Value
if ($allowedId -and $allowedId -ne "00000000-0000-0000-0000-000000000000") {
"Restriction active. Groupe autorisé : $allowedId"
}

Avec AzureAD (héritage)

Install-Module AzureAD -Scope CurrentUser
Connect-AzureAD

# Paramètres de répertoire

$dirSettings = Get-AzureADDirectorySetting
$groupUnified = $dirSettings | Where-Object DisplayName -eq "Group.Unified"
$groupUnified.Values | Format-Table Name, Value

2. Vérifier l’appartenance de l’utilisateur au groupe autorisé

# Remplacer par l'UPN de l'utilisateur
$userUpn = "utilisateur@domaine.tld"

$user = Get-MgUser -UserId $userUpn
if ($allowedId) {
$members = Get-MgGroupMember -GroupId $allowedId -All
$isMember = $members | Where-Object Id -eq $user.Id
if ($isMember) {
"L'utilisateur EST autorisé à créer des groupes/équipes."
} else {
"L'utilisateur N'EST PAS autorisé. Ajoutez-le au groupe autorisé ou retirez la restriction."
}
}

3. Contrôler rapidement les étiquettes de sensibilité (conteneurs)

Si votre organisation impose une étiquette pour la création de groupes/équipes, vérifiez que l’étiquette est publiée au bon public et qu’elle autorise la création. Un contrôle minimal peut se faire via le module de conformité :

# Nécessite les autorisations de conformité
Install-Module ExchangeOnlineManagement -Scope CurrentUser
Connect-IPPSSession
Get-LabelPolicy | Format-Table Name, Mode
# Selon la configuration, vérifier dans les paramètres avancés que l'étiquette n'interdit pas la création de groupes/équipes.

Nettoyer le cache Teams (quand le client est en cause)

Le cache corrompu est une cause fréquente d’erreurs côté client. Procédez ainsi :

Fermer complètement Teams (quitter depuis la zone de notification).
Windows (Teams classique) : supprimer le contenu de %AppData%\Microsoft\Teams (dossiers Cache, databases, IndexedDB, etc.).
Windows (nouvelle version en MSIX) : %LocalAppData%\Packages\MSTeams_8wekyb3d8bbwe\LocalCache.
macOS : ~/Library/Application Support/Microsoft/Teams.
Relancer Teams et s’authentifier de nouveau.

Remarque : ces suppressions n’affectent pas les données serveur (équipes, conversations). Elles ne touchent que les fichiers locaux de cache et d’état.

Bonnes pratiques pour éviter les récidives

Documenter explicitement tout changement de politique (restriction de création de groupes, étiquettes, stratégies Teams) et l’auteur du changement.
Utiliser un groupe d’autorisation dédié pour la création de groupes (si restriction nécessaire) et y inscrire les administrateurs/chefs de projet concernés.
Après un changement sensible, valider le scénario clé (création d’une équipe test) depuis le client et depuis l’admin center.
Mettre en place une vérification périodique du paramètre Group.Unified (surveillance de dérives).
Former les utilisateurs aux étiquettes de sensibilité si elles sont requises lors de la création d’équipes.

Checklist express (à coller dans votre runbook)

Le bouton « Créer une équipe » est-il visible ? Si non, suspecter une restriction de création.
Test de création sur le web. Si OK sur web mais KO sur bureau : nettoyer le cache.
Lire Group.Unified et la valeur GroupCreationAllowedGroupId.
Confirmer l’appartenance de l’utilisateur au groupe autorisé (le cas échéant).
Vérifier les étiquettes (publication/portée/paramètres).
Créer une équipe depuis l’admin center pour déclencher la resynchronisation.
Si le problème persiste, rassembler les journaux et ouvrir un ticket support.

Journalisation utile pour un ticket

Logs Teams : dans le client, Aide & commentaires > Collecter les journaux (ou le raccourci de diagnostic), puis joindre le fichier généré.
Heure exacte des tentatives, UPN de l’utilisateur, nom du locataire, version du client Teams, captures d’écran du message d’erreur.
Sorties PowerShell : captures anonymisées de Group.Unified, appartenance au groupe autorisé, statut des étiquettes.

FAQ rapide

Q : Les stratégies Teams suffisent‑elles à contrôler la création d’équipes ?
R : Non. La capacité à créer une équipe dépend avant tout de la création des groupes Microsoft 365. Les stratégies Teams influent sur l’expérience (canaux, apps), mais la clé est du côté Group.Unified et, le cas échéant, des étiquettes de sensibilité.

Q : Pourquoi l’admin center réussit‑il alors que le client échoue ?
R : L’admin center appelle des chemins d’exécution « serveur‑à‑serveur » avec des privilèges d’administration, ce qui peut forcer la réconciliation des dépendances. Le client, lui, s’appuie sur l’état local (cache) et des jetons utilisateur qui peuvent être incohérents.

Q : Faut‑il laisser la restriction de création de groupes complètement désactivée ?
R : Pas nécessairement. Dans les organisations plus grandes, limiter la création à un groupe d’utilisateurs autorisés est pertinent. Assurez‑vous simplement que les personnes concernées (admins, PMO) sont bien membres de ce groupe.

Q : Une étiquette de sensibilité peut‑elle empêcher une création d’équipe ?
R : Oui. Les étiquettes « conteneur » peuvent imposer qui peut créer des équipes, si les invités sont autorisés, et d’autres paramètres. Une étiquette mal publiée ou trop restrictive provoque un échec dès l’étape de création.

Q : Et si la création échoue uniquement pour un compte précis ?
R : Comparez ses appartenances (groupes de sécurité, rôles, licences) avec un compte qui réussit. Les écarts d’appartenance au groupe autorisé ou de publication d’étiquette expliquent souvent la différence.

Cas observé : petit environnement, administrateur = utilisateur

Dans les structures réduites où la même personne est à la fois utilisateur et administrateur, un changement involontaire dans le portail Entra ID / Paramètres / Groupes (ex‑« Azure AD »), tel que l’activation de la restriction de création des groupes, constitue la cause la plus courante. Dans ce cas, deux options :

désactiver la restriction globale ;
ou conserver la restriction mais ajouter l’administrateur au groupe autorisé.

Parfois, le simple fait de créer une équipe depuis l’admin center « réveille » la configuration et restaure immédiatement la création côté clients.

Procédure détaillée (pas à pas) pour rétablir la création

Contrôles rapides : vérifier les licences actives du compte, se déconnecter/reconnecter à Teams.
Web vs. bureau : si la création fonctionne sur le web, suspecter le cache du client de bureau (nettoyer, voir plus haut).
Paramètres de groupes :
- Lire Group.Unified et la valeur EnableGroupCreation.
- Si EnableGroupCreation = False et GroupCreationAllowedGroupId ≠ 00000000-0000-0000-0000-000000000000, alors seule l’appartenance au groupe autorisé permet de créer.
Étiquettes (si utilisées) : confirmer la publication au bon public et le paramétrage « Autoriser la création de groupes/équipes ».
Test admin center : créer une équipe « TEST‑Déblocage ». Si cela réussit, retenter immédiatement la création depuis l’application.
Post‑mortem : consigner l’origine (politique changée, étiquette non publiée, cache corrompu) et mettre en place une surveillance.

Modèle de communication utilisateur (si l’incident est large)

Vous pouvez adapter ce texte :

Objet : Création d’équipes temporairement perturbée
Nous avons identifié un problème empêchant la création d’équipes (« Nous n’avons pas pu compléter cette action »). Un correctif a été appliqué via le centre d’administration. Si le message persiste dans votre client de bureau, fermez Teams, nettoyez le cache puis relancez l’application. Aucun contenu n’a été perdu.

Récapitulatif

Le message d’erreur masque souvent une restriction M365 Groups, une étiquette mal publiée ou un cache en mauvais état.
Créer une équipe via l’admin center déclenche la resynchronisation des paramètres et débloque fréquemment la situation.
Automatisez les contrôles PowerShell (Group.Unified, groupe autorisé, appartenance) pour accélérer vos diagnostics.

Annexe : script de contrôle rapide

Ce mini‑script lit l’état clé et vous indique si l’utilisateur peut créer des groupes/équipes.

# Pré-requis : Microsoft.Graph
param(
  [Parameter(Mandatory=$true)][string]$UserUpn
)

Import-Module Microsoft.Graph
Connect-MgGraph -Scopes "Directory.Read.All","Group.Read.All"

$groupUnified = Get-MgDirectorySetting | Where-Object DisplayName -eq "Group.Unified"
$enabled = ($groupUnified.Values | Where-Object Name -eq "EnableGroupCreation").Value
$allowedId = ($groupUnified.Values | Where-Object Name -eq "GroupCreationAllowedGroupId").Value

Write-Host "EnableGroupCreation = $enabled"
Write-Host "GroupCreationAllowedGroupId = $allowedId"

if ($enabled -eq "True") {
Write-Host "Création de groupes : AUTORISÉE pour tous les utilisateurs." -ForegroundColor Green
} elseif ($allowedId -and $allowedId -ne "00000000-0000-0000-0000-000000000000") {
$user = Get-MgUser -UserId $UserUpn
$members = Get-MgGroupMember -GroupId $allowedId -All
if ($members | Where-Object Id -eq $user.Id) {
Write-Host "Création de groupes : AUTORISÉE pour $UserUpn (membre du groupe autorisé)." -ForegroundColor Green
} else {
Write-Host "Création de groupes : REFUSÉE pour $UserUpn (non membre du groupe autorisé)." -ForegroundColor Red
}
} else {
Write-Host "Création de groupes : REFUSÉE globalement." -ForegroundColor Red
}

Conclusion

Face à l’erreur « Nous n’avons pas pu compléter cette action » lors de la création d’une équipe, adoptez une approche structurée : valider les paramètres Group.Unified, contrôler les étiquettes, écarter un problème de cache et, si besoin, forcer la resynchronisation en créant une équipe via le centre d’administration. Dans la grande majorité des cas, cette combinaison règle immédiatement le blocage et stabilise l’expérience pour les utilisateurs.

Microsoft Teams : « Nous n’avons pas pu compléter cette action » lors de la création d’une équipe — diagnostic et correctifs