Une équipe Teams se crée vite; la fermer demande du courage
J’aime les outils qui permettent à une équipe de commencer sans attendre un comité. Au printemps 2020, créer un espace Teams en quelques minutes permettait de travailler immédiatement. Presque un an plus tard, la facilité a produit un inventaire de projets, comités et essais dont le propriétaire n’est plus toujours évident.
Une équipe Teams n’est pas un contenant isolé. Sa création s’appuie sur un groupe Microsoft 365, des identités dans Azure Active Directory, un site SharePoint pour les fichiers des canaux, une boîte et un calendrier Exchange, puis les conversations et réunions de Teams. Un fichier partagé dans une conversation individuelle peut plutôt vivre dans le OneDrive de la personne qui l’a envoyé. Le même écran masque donc plusieurs emplacements et cycles de vie.
Équipe Teams
├─ groupe Microsoft 365 → membres et propriétaires
├─ SharePoint → fichiers des canaux et versions
├─ Exchange → boîte/calendrier du groupe
├─ Teams → canaux, messages et réunions
└─ applications → onglets, bots et connecteurs externes
Cette structure explique pourquoi supprimer au hasard est risqué. Archiver une équipe rend généralement son contenu en lecture seule dans Teams sans effacer immédiatement les services derrière. Une politique de rétention peut encore empêcher la suppression définitive. À l’inverse, retirer une personne de l’équipe ne révoque pas nécessairement un lien de partage direct accordé auparavant dans SharePoint.
Je définirais un cycle de vie léger :
- Demande : but, deux propriétaires, sensibilité et durée prévue;
- Active : membres gérés par groupe, partage externe selon la classification;
- Révision : rappel aux propriétaires après six ou douze mois;
- Archivée : lecture seule, applications et automatisations vérifiées;
- Conservée ou supprimée : décision appliquée selon les obligations;
- Vérifiée : recherche, permissions et récupération testées après l’action.
Un job peut repérer les équipes sans activité récente, mais il ne devrait pas décider seul que leur contenu ne vaut rien. Il envoie une demande aux propriétaires, escalade lorsqu’ils ont quitté et conserve la réponse. Si les deux propriétaires sont inactifs, un groupe de gouvernance reçoit la décision au lieu de laisser l’espace orphelin.
Les permissions suivent la classification. Une équipe publique interne n’a pas la même politique qu’un dossier d’acquisition. Les invités doivent avoir une organisation, un répondant et une date d’expiration. Les liens « toute personne ayant le lien » sont simples, mais difficiles à révoquer personne par personne. Pour du contenu sensible, je préfère des personnes authentifiées, un accès conditionnel et un journal de partage.
La panne la plus commune n’est pas toujours un serveur indisponible. C’est un propriétaire supprimé dont le Power Automate utilisait la connexion personnelle. Avant d’archiver, je dresse l’inventaire des onglets, connecteurs, flux et comptes qui dépendent de l’équipe. Un flux important passe sous une identité gérée et possède une relève; un petit essai est fermé avec son espace.
La conservation mérite un vocabulaire clair. Archiver pour le travail courant, conserver pour une obligation et sauvegarder pour restaurer après une perte sont trois mécanismes différents. L’historique de versions SharePoint aide après une modification, mais ne remplace pas un plan de récupération face à une erreur massive ou une compromission. Je teste la restauration d’un fichier, de ses versions et de ses permissions avec un compte ordinaire.
Je ne placerais pas trois formulaires devant Créer. Je demanderais deux propriétaires, un niveau de sensibilité et une date de révision, puis j’automatiserais les rappels et l’inventaire. La pratique qui garde Microsoft 365 utilisable n’est pas de bloquer les nouveaux espaces; c’est de donner à chacun une identité, une responsabilité et une sortie avant que les personnes originales disparaissent.