Dans cet article
- Type de passerelle et gestion des utilisateurs
- Utilisateurs de « l’autre côté »
- Fonctionnalités et limites asymétriques
- Architecture
- Conclusion
- Questions fréquentes
Nous vivons dans un monde où la plupart des outils sont connectés, soit nativement, soit au moyen de connecteurs comme Zapier, Make ou n8n.
Il est devenu naturel d’ouvrir un outil récemment adopté, de consulter les intégrations disponibles et de le relier à l’environnement existant.
C’est naturel pour la plupart des outils, certes, mais étonnamment pas pour les outils de collaboration eux-mêmes. Slack, Teams, Google Chat, WhatsApp et Discord ne proposent aucun moyen natif de se connecter entre eux.
Pourquoi ? Très probablement parce qu’ils se considèrent comme des concurrents. Leurs éditeurs cherchent à maximiser le nombre d’abonnements, et connecter leur produit à une plateforme rivale pourrait signifier vendre moins de licences.
Nous avons déjà présenté les différentes solutions permettant de connecter Slack et Teams dans cet article. Cette fois, nous allons examiner en détail les obstacles auxquels vous serez confronté si vous créez vous-même une passerelle Slack↔Teams personnalisée.
Type de passerelle et gestion des utilisateurs
La première chose à définir, car elle façonnera l’ensemble du projet, est le type de passerelle que vous allez créer.
À première vue, connecter Slack et Teams peut sembler simple. En réalité, il existe de nombreuses façons de le faire, et aucune ne s’impose comme une évidence.
Voici les principales options, en nous intéressant à la manière dont chacune représente les utilisateurs de « l’autre côté » :
- Doubles licences des deux côtés
Chaque utilisateur doit disposer d’une licence Slack et d’une licence Teams, qu’il les utilise ou non. Cette solution offre une expérience symétrique des deux côtés, mais c’est aussi la plus coûteuse.
- Doubles licences d’un seul côté
Un seul côté (Slack ou Teams) dispose de doubles licences. L’expérience est fluide de ce côté, tandis que l’autre doit toujours gérer les utilisateurs « absents ». Il s’agit d’une solution intermédiaire en matière de coût, et de celle choisie par convly.
- Aucune double licence
Aucun utilisateur ne dispose d’une double licence. Les utilisateurs « absents » doivent être gérés des deux côtés au moyen d’applications dédiées. Cette option présente le coût d’exploitation le plus faible, mais offre une expérience imparfaite des deux côtés et nécessite l’installation d’une application pour chaque nouvelle entreprise externe avec laquelle vous communiquez.
- Plusieurs applications
Une approche plus inhabituelle consiste à représenter les utilisateurs de « l’autre côté » au moyen de plusieurs applications. Elle peut fonctionner lorsqu’il suffit de représenter un nombre limité d’utilisateurs, mais devient rapidement difficile à gérer dans le cas contraire.
- Plusieurs invités
Cela peut sembler être la solution idéale pour représenter les utilisateurs de « l’autre côté », mais il y a un inconvénient. Le nombre d’utilisateurs invités n’est pas illimité dans Slack et, généralement, ils ne peuvent pas être créés par programmation. Cette option convient surtout lorsque la liste des utilisateurs reste relativement stable.
Utilisateurs de « l’autre côté »
Par utilisateurs de « l’autre côté » ou « absents », nous entendons ceux qui se trouvent sur l’autre plateforme de collaboration : les utilisateurs Teams vus depuis Slack, ou les utilisateurs Slack vus depuis Teams.
Dans la plupart des cas, ces utilisateurs doivent être représentés sur une plateforme où ils n’existent pas réellement. Déterminer comment les représenter est essentiel et soulève toute une série de questions :
- Comment matérialiser leurs messages ?
- Comment engager une conversation privée avec eux ?
- Comment représenter les messages privés échangés avec eux ?
- Comment représenter les fichiers et les images qu’ils partagent ?
- Comment les ajouter à des canaux ou les en retirer ?
- Comment savoir s’ils font réellement partie d’un canal ?
- Comment représenter leurs réactions ?
Et bien d’autres encore. Chaque question comporte ses propres particularités, et les réponses peuvent évoluer selon la licence Slack ou Teams utilisée, ou au fil des mises à jour des API.
Fonctionnalités et limites asymétriques
Après avoir choisi votre type de passerelle pour connecter Slack et Teams et défini comment représenter les utilisateurs absents, vous pouvez commencer à examiner les défis propres à chaque plateforme.
Slack et Teams sont tous deux des outils de collaboration dans lesquels les utilisateurs échangent principalement des messages. Ils semblent donc équivalents en surface. Mais lorsque l’on entre dans les détails, chacun possède des particularités incontournables.
- Canaux, conversations de groupe, messages privés multiples et conversations de réunion
Dans Slack, tout repose sur les « canaux ». Teams, en revanche, propose plusieurs types de conversations : des canaux (qui ne fonctionnent pas vraiment comme ceux de Slack), des conversations de groupe nommées ou non qui se rapprochent davantage des canaux Slack, des messages privés multiples et des conversations de réunion. Une partie du défi consiste à décider s’il faut les relier et, le cas échéant, comment le faire tout en tenant compte des particularités de chaque type de conversation.
- Fils de discussion et réponses
Slack est réputé pour permettre la création de fils sur tous les messages, ce qui peut dérouter les nouveaux utilisateurs. Dans Teams, les fils n’existent que dans les canaux. Dans les « conversations », seules des « réponses » classiques sont disponibles. Définir la logique nécessaire pour maintenir leur synchronisation devient complexe dès lors que l’on tient compte de tous les cas particuliers : suppression, transfert ou modification d’un message, ou encore ajout de réactions.
- Fichiers et images
Slack gère simplement les images en les stockant dans sa propre infrastructure. Du côté de Teams, tous les contenus partagés reposent sur SharePoint et OneDrive. Cela peut sembler anodin, mais cette différence cache une réelle complexité : le choix entre OneDrive et SharePoint dépend du contexte (le type de conversation), les bonnes personnes doivent disposer des autorisations nécessaires pour accéder à chaque fichier, les limites de taille doivent être respectées, etc.
- Différences entre les limites
Il faut également gérer les limites brutes : taille maximale des messages, taille maximale des fichiers, nombre maximal d’utilisateurs par conversation de groupe ou canal, nombre de réactions par message, et bien plus encore. Selon le cas, il est parfois possible de trouver un compromis. Sinon, les erreurs doivent être prises en charge.
Architecture
La complexité fonctionnelle décrite ci-dessus est une chose, mais connecter Slack et Teams ne s’arrête pas là. Cela exige également une architecture solide capable de répondre à bon nombre des enjeux suivants.
- Faible latence
L’un des plus importants. Il est essentiel que les messages échangés entre Slack et Teams soient transférés aussi rapidement que possible, malgré l’étape d’adaptation nécessaire pour respecter le format de l’autre plateforme. Nous parlons ici de millisecondes.
- Évolutivité
Le complément indispensable d’une faible latence. L’architecture doit pouvoir absorber un volume important et croissant de messages et d’utilisateurs. Nous pouvons ici parler de millions de messages.
- Indépendance vis-à-vis des API
Placée entre les API de Slack et de Teams, l’architecture doit se connecter aux deux en tenant compte de leurs différences de fonctionnement. Slack utilise une API REST standard, tandis que Teams passe par Microsoft Graph et implique plusieurs services, dont certains se chevauchent.
- Gestion des erreurs et des nouvelles tentatives
Comme la plupart des échanges entre Slack et Teams s’effectuent en temps réel par l’intermédiaire de webhooks, une gestion rigoureuse des erreurs et des nouvelles tentatives est essentielle pour garantir qu’aucun message ne soit perdu ou dupliqué. Cela peut nécessiter des files d’attente multithreads dotées de mécanismes de séquençage.
- Sécurité et chiffrement
Enfin, la sécurité doit être intégrée dès le départ afin que le projet respecte les normes actuelles du secteur : demander le minimum d’autorisations nécessaires, stocker le moins de données possible et tout chiffrer.
Conclusion
Comme nous l’avons vu tout au long de cet article, créer un connecteur Slack↔Teams est un projet de grande ampleur. Pour combler les différences importantes entre les deux plateformes, de nombreux aspects doivent être pris en compte : gestion et expérience des utilisateurs, adaptation des fonctionnalités, architecture, sécurité et évolutivité. Sans oublier que les deux API continuent d’évoluer au fil du temps.
Si vous préférez ne pas vous lancer vous-même dans un tel projet, vous pouvez confier l’ensemble à convly. Nous avons acquis une solide expérience dans l’exploitation d’une plateforme de synchronisation Slack↔Teams qui accorde une grande importance à l’expérience utilisateur et à la sécurité.