Slack s’est imposé comme une référence de la messagerie d’équipe, mais son coût par utilisateur et sa place dans un écosystème parfois éclaté poussent de nombreuses entreprises à le remplacer par Microsoft Teams, déjà inclus dans la plupart des licences Microsoft 365. La migration ne consiste pas à recréer des salons : il s’agit de transférer un historique de conversations, des fichiers partagés et des automatisations, tout en reconstruisant une culture de la communication interne cohérente.
Pourquoi remplacer Slack par Microsoft Teams ?
La première motivation est économique : lorsque votre organisation paie déjà des licences Microsoft 365 avec Teams inclus, maintenir un abonnement Slack parallèle représente un budget redondant pour des fonctionnalités qui se recouvrent largement. La seconde est la centralisation : Teams réunit le chat, la visioconférence, le stockage SharePoint, la coédition Office et la téléphonie dans un même client, adossé à la gouvernance de Microsoft Entra ID et à la conformité (rétention, eDiscovery, DLP) de l’écosystème Microsoft.
Les différences concrètes sont réelles : Slack raisonne en workspaces avec des canaux publics ou privés et des messages en threads souples ; Teams raisonne en équipes et canaux, chaque équipe s’appuyant sur un site SharePoint et un groupe Microsoft 365 pour le stockage et les permissions. Traduire une topologie dans l’autre est le cœur du travail de conception.
Cartographier l’existant avant de migrer
Une migration Slack vers Teams commence par un audit exhaustif du workspace source :
- Les canaux : liste, caractère public ou privé, membres, objectif, canaux archivés.
- Les utilisateurs : comptes actifs, invités (single-channel ou multi-channel), bots et applications connectées.
- Les messages : volume, historique à conserver, messages épinglés, fichiers partagés dans les conversations.
- Les intégrations : applications tierces, webhooks entrants et sortants, workflows automatisés, commandes slash personnalisées.
- Les usages : qui utilise quoi, quels sont les canaux vivants, lesquels sont morts mais contiennent de la connaissance à archiver.
Cet inventaire permet de décider ce qui doit être migré fidèlement, ce qui doit être restructuré, et ce qui peut être archivé sans être transféré.
Concevoir la cible Teams
La conception de la cible est l’étape où l’on gagne ou l’on perd la bataille de l’adoption. Une règle d’or : ne pas reproduire mécaniquement chaque canal Slack en un canal Teams, mais regrouper par équipe logique (département, projet, communauté) puis décliner les canaux au sein de chaque équipe. Chaque équipe Teams hérite d’un espace de fichiers SharePoint, d’un bloc-notes OneNote et d’un calendrier, ce qui modifie la répartition des contenus par rapport à Slack, où les fichiers flottent dans les conversations.
Les threads de Slack doivent être décidés : Teams supporte les réponses en fil de discussion, mais l’expérience diffère. Les messages épinglés et les canaux de type annonce trouvent des équivalents (publications, canaux de type announcement). Les bots et apps n’ont pas tous d’équivalent direct : il faut dresser un tableau de correspondance et identifier les intégrations à réécrire, par exemple via Power Automate ou les connecteurs de Teams.
Les étapes de la migration
- Préparer Microsoft Teams : créer la structure d’équipes et de canaux, définir les politiques de gouvernance (création, nommage, cycle de vie) et les permissions.
- Choisir l’outil de transfert : selon le volume et le besoin de fidélité, utiliser l’outil de migration officiel de Microsoft, un connecteur tiers spécialisé, ou une API personnalisée pour les cas particuliers.
- Migrer les canaux et les messages : transférer l’historique avec horodatage et auteurs, en respectant les threads et en rattachant les fichiers aux bibliothèques SharePoint cibles.
- Migrer les fichiers : déplacer les documents partagés vers les sites SharePoint des équipes, en conservant les métadonnées essentielles.
- Recréer les automatisations : porter les webhooks, les rappels et les intégrations vers les applications ou les flux Power Automate.
- Tester sur un périmètre pilote : valider avec un groupe représentatif la fidélité des conversations, des permissions et des fichiers.
- Basculer et communiquer : geler l’écriture sur Slack (lecture seule), activer Teams, former et accompagner.
- Archiver et décommissionner : exporter l’archive de Slack pour conformité, puis résilier les licences.
Les pièges à éviter
Le premier piège est la perte d’historique : les messages, surtout dans les canaux privés, ne sont pas toujours exportables sans droits administrateur étendus ; il faut exporter avant toute chose. Le deuxième est la fidélité des threads : un transfert qui aplatit les fils de discussion détruit la lisibilité des conversations techniques. Le troisième est l’accès des invités : les invités multi-canaux de Slack n’ont pas d’équivalent direct, et leur migration doit être traitée au cas par cas (accès invité Teams, ou compte externe). Le quatrième est l’éclatement des fichiers : rattacher chaque fichier au bon site SharePoint et recréer les permissions demande une correspondance fine des canaux.
| Piège | Conséquence | Parade |
|---|---|---|
| Export incomplet des canaux privés | Historique perdu | Exporter avec des droits étendus avant toute opération |
| Threads aplatis | Conversations illisibles | Valider la restitution des fils sur un échantillon |
| Invités non gérés | Accès externes rompus | Cartographier les invités et leurs droits en amont |
| Intégrations non portées | Automatisations cassées | Tableau de correspondance apps/webhooks vers Power Automate |
Gouvernance, rétention et conformité
Migrer vers Microsoft Teams est l’occasion de professionnaliser la gouvernance de la communication interne. L’écosystème Microsoft 365 apporte des capacités absentes de Slack : les politiques de rétention définissent la durée de conservation des messages et des fichiers, l’eDiscovery permet de rechercher du contenu pour des besoins légaux ou RH, et la prévention des pertes de données (DLP) bloque le partage d’informations sensibles (données bancaires, données personnelles) hors des canaux autorisés.
Deux chantiers méritent une attention particulière. Le premier est la maîtrise de la création des équipes : sans politique de nommage et de cycle de vie, Teams se transforme rapidement en un fouillis d’équipes orphelines ; définissez qui peut créer des équipes, imposez des préfixes ou des conventions, et prévoyez un archivage automatique des équipes inactives. Le second est la gestion des invités et des accès externes : les invités multi-canaux de Slack n’ont pas d’équivalent direct, et il faut définir une stratégie (accès invité Teams, canal partagé, ou compte externe) tout en respectant les règles de sécurité. Ces paramètres, configurés avant la bascule, transforment la migration en une remise à plat de la gouvernance plutôt qu’en un simple transfert de contenus.
Bonnes pratiques et conduite du changement
Traitez la migration comme un projet de conduite du changement autant que comme un projet technique. Impliquez des ambassadeurs par équipe, formez aux différences d’usage (la notion d’équipe contre celle de workspace, la recherche, la visioconférence intégrée) et laissez Slack accessible en lecture seule pendant quelques semaines pour que chacun retrouve ses repères. Mesurez l’adoption : nombre de messages actifs, de réunions créées, de fichiers déposés dans Teams après bascule.
Chez Performances Digital, nous prenons en charge la migration Slack vers Microsoft Teams de bout en bout : audit du workspace, conception de la topologie cible, transfert de l’historique et des fichiers, portage des automatisations et accompagnement des équipes. Notre objectif : une communication interne recentrée, des coûts maîtrisés et aucune connaissance perdue.
Centraliser votre communication interne sur Microsoft Teams est une opportunité de simplifier votre stack tout en réduisant vos coûts. Demandez votre devis gratuit : nous auditerons votre workspace Slack et vous remettrons une feuille de route de migration adaptée à la taille de vos équipes.
