Brancher kDrive sur Slack, Notion et le reste : intégrer un cloud européen dans son stack SaaS
Personne ne vit dans un écosystème unique. Même les entreprises les plus investies dans Google Workspace utilisent Slack pour le chat, Notion pour la documentation, Trello ou Asana pour la gestion de projet, et un CRM qui n’est ni Google ni Microsoft. La question quand on migre son stockage vers un cloud européen comme kDrive n’est pas “est-ce que je dois tout remplacer ?” – c’est “est-ce que mon nouveau cloud peut cohabiter avec le reste ?”. Le guide sur l’écosystème kSuite et ses intégrations cadre la suite dans son ensemble ; ici, on s’intéresse à la cohabitation avec le monde extérieur. Et la bonne nouvelle, c’est que les protocoles ouverts et les plateformes d’automatisation rendent cette cohabitation plus simple qu’on ne le croit.
kDrive n’a pas de marketplace d’intégrations comme Google Drive (qui propose des centaines de connecteurs natifs). C’est un fait. Mais kDrive supporte WebDAV, dispose d’une API REST documentée, et fonctionne avec les plateformes d’automatisation comme Zapier et Make (ex-Integromat). En pratique, cela signifie que la plupart des scénarios d’intégration sont possibles – ils demandent juste un peu plus de configuration que chez Google.
Les trois niveaux d’intégration
Le premier niveau, c’est l’intégration manuelle par liens. Quand vous partagez un fichier kDrive, vous obtenez un lien public ou protégé par mot de passe. Ce lien se colle dans un message Slack, une carte Trello, une page Notion, un ticket Jira. C’est basique, mais c’est universel : aucun connecteur nécessaire, aucune configuration, et ça fonctionne avec n’importe quel outil qui accepte des URL.
Le deuxième niveau, c’est l’automatisation via Zapier ou Make. Ces plateformes permettent de créer des workflows déclenchés par des événements. Exemples concrets : “quand un nouveau fichier apparaît dans le dossier kDrive /factures, envoyer une notification Slack” ; “quand une carte Trello passe en colonne Terminé, déplacer le fichier associé dans kDrive /archives” ; “quand un formulaire Typeform est soumis, créer un dossier kDrive au nom du client”. kDrive est disponible comme application sur Make, ce qui ouvre des centaines de combinaisons.
Le troisième niveau, c’est l’intégration programmatique via WebDAV ou l’API REST. C’est le terrain des développeurs et des scripts d’automatisation maison. On en parle en détail dans les pages dédiées.
WebDAV : le pont technique universel
WebDAV est un protocole qui permet de monter un espace kDrive comme un disque réseau sur n’importe quel système d’exploitation. C’est aussi la porte d’entrée pour les scripts : un cron job qui sauvegarde des fichiers sur kDrive via WebDAV, un outil de backup qui cible un répertoire distant, un CMS qui stocke ses assets dans le cloud. Le guide sur WebDAV et l’accès programmatique donne les endpoints et les exemples de configuration.
API REST : pour les intégrations sur mesure
Quand WebDAV ne suffit pas (gestion fine des permissions, métadonnées, partages programmatiques), l’API REST d’Infomaniak prend le relais. Le guide sur l’API cloud pour développeurs documente les cas d’usage et les limites de cette API.
Les limites honnêtes
L’écosystème d’intégrations de kDrive n’est pas comparable à celui de Google Drive ou Dropbox. Il n’y a pas de connecteur natif Slack pour parcourir ses fichiers kDrive directement dans Slack. Il n’y a pas d’extension Notion qui affiche un aperçu du document kDrive. Il n’y a pas d’intégration Adobe Creative Cloud.
Pour les PME qui utilisent des outils mainstream et qui ont besoin de partager des liens et d’automatiser des workflows simples, kDrive s’intègre correctement via Zapier/Make et les liens de partage. Pour les entreprises qui dépendent d’intégrations profondes avec des dizaines d’outils SaaS, Google Drive reste plus connecté – c’est le prix de l’effet de réseau.
Le compromis pragmatique pour beaucoup d’équipes : utiliser kDrive comme stockage souverain principal et garder une connexion Google Drive ou Dropbox minimale pour les rares outils qui exigent une intégration native. Ce n’est pas idéal d’un point de vue simplification, mais c’est réaliste – et ça permet de garder 90 % de ses données en Europe tout en conservant les workflows critiques.