Teams aura enfin sa sauvegarde native : 30 jours de répit et beaucoup de points d’interrogation
Restaurer un canal Teams après une suppression malencontreuse ou une compromission de compte relevait jusqu’ici de l’archéologie appliquée : les fichiers se cherchent dans SharePoint, les messages se réclament à l’API, et le reste se confie à l’optimisme. La récupération passe aujourd’hui par l’API Teams pour les données brutes comme les conversations, et par SharePoint pour les fichiers. Microsoft semble enfin décidé à corriger cet état de fait : l’entrée 570668 de sa feuille de route, publiée début septembre 2026, décrit une fonction native de sauvegarde et de restauration pour Teams.
Le principe se résume simplement. Il s’agira de ramener une équipe, ses canaux standard, privés et publics, ainsi que les données sous-jacentes comme les fichiers et les messages échangés dans les canaux, vers un état antérieur réputé sain, après une modification accidentelle ou une compromission de sécurité. La rétention annoncée est de 30 jours, et le déploiement doit débuter en décembre 2026. Il commencera par Teams sur le web, qui change prochainement de domaine, ce qui ajoutera un chantier de plus au calendrier des administrateurs, déjà peu réputé pour ses périodes de repos. Le statut reste « en développement » : tout ce qui précède est donc au futur, et pour l’instant au conditionnel.
Pour mesurer l’intérêt de l’annonce, il faut rappeler d’où l’on part. Les éléments supprimés des sites SharePoint d’équipe transitent par une corbeille qui les conserve 93 jours, tandis que les messages d’équipe ne sont pas couverts par les mécanismes de récupération intégrés. Tout un écosystème d’éditeurs tiers vit de cette lacune depuis des années. Voir Microsoft s’y attaquer est donc réjouissant, à condition de regarder les détails de près.
Trente jours, c’est court. Microsoft propose déjà Microsoft 365 Backup, avec des points de restauration toutes les 10 minutes sur Exchange pour l’année écoulée, et une conservation d’un an. Face à cela, une fenêtre de 30 jours pour Teams paraît étroite. Un incident découvert lors d’une revue trimestrielle, une suppression malveillante repérée avec retard ou une demande d’audit portant sur un état antérieur : dans tous ces scénarios, le trente et unième jour ressemble à un mur. Rien n’indique pour l’instant que cette durée soit paramétrable.
Le flou technique est l’autre sujet. Microsoft n’a pas publié de documentation complète, et les questions sur les points de restauration comme sur l’emplacement de l’interface restent ouvertes. On ignore donc la granularité réelle : restaure-t-on une équipe entière, un canal, un fichier isolé ? La restauration se fait-elle en place, avec écrasement du contenu actuel, ou vers une nouvelle équipe ? Comment sont gérés les conflits ? Le sujet n’est pas anodin : un éditeur tiers rappelle que l’API Graph ne permet pas de restaurer des messages de canal dans l’équipe d’origine. Réinjecter des messages en conservant auteurs et horodatages a toujours été l’exercice le plus ingrat de la discipline. Microsoft dispose de moyens que les éditeurs tiers n’ont pas, mais il faudra le démontrer.
Le périmètre demande aussi de la vigilance. La roadmap ne mentionne pas les conversations privées, 1:1 et de groupe, mais uniquement les messages échangés dans les canaux, et ne relie pas explicitement la fonction à Microsoft 365 Backup. Or la documentation de Microsoft 365 Backup indique que seuls les fichiers des sites SharePoint associés aux canaux sont couverts, et que les conversations ne le sont pas encore. Autre détail : l’entrée ne cite que le cloud public standard (Worldwide Standard Multi-Tenant). Les organisations relevant de GCC, GCC High ou DoD, ou simplement soumises à des exigences de souveraineté, devront attendre un éventuel élargissement. Signalons enfin que la terminologie employée (canaux « publics ») ne correspond pas exactement aux types de canaux Teams (standard, privés, partagés), signe que la documentation reste à écrire.
Restent deux questions que tout architecte posera. La première concerne la licence : fonction incluse, ou facturée à la consommation comme Microsoft 365 Backup ? Le budget d’une DSI mérite mieux qu’une découverte en janvier. La seconde concerne l’isolation. On ignore tout de l’architecture, mais une sauvegarde qui vit dans le même tenant, administrée par les mêmes rôles, partage le sort de ce tenant lorsqu’un compte à privilèges est compromis. La vieille règle 3-2-1 n’est pas obsolète parce qu’un bouton « Restaurer » apparaît dans une console. C’est une lecture d’architecte, à confirmer par la documentation à venir.
Que faire d’ici décembre ? Ne pas résilier les solutions de sauvegarde tierces, tout d’abord : la fonction annoncée complète un dispositif, elle ne le remplace pas à ce stade. Il est utile de formaliser un objectif de point de reprise et de durée de reprise pour Teams, de lister explicitement ce qui restera hors périmètre (conversations privées, par exemple), puis de prévoir un test de restauration dès la préversion. Un plan de continuité qui n’a jamais été rejoué reste un vœu pieux.
En attendant, la meilleure sauvegarde de Teams demeure celle d’hier : un administrateur qui hésite avant de supprimer l’équipe « Projet Test (ancien) » un vendredi à 17 h 🙂
