Intégration d'un espace de stockage de fichiers
Une référence stable, pas un lien Drive copié
Nous relions Drive, SharePoint, Box ou Dropbox au dossier métier. Droits, durée de conservation, renouvellement des accès : le fichier reste chez votre hébergeur.
- Connecteurs fichiers en production
- référence vs copie tranché
- tokens suivis
Qu'est-ce que l'intégration d'un espace de fichiers et quand la faire développer ?
Intégrer un espace de stockage, c'est faire déposer, retrouver et partager un document depuis votre application, tout en laissant Drive, SharePoint, Box ou Dropbox porter le fichier. Les liens collés dans un champ texte cassent. On fait développer le connecteur quand le dossier métier doit lister les pièces, quand un dépôt doit respecter l'arborescence et les droits, ou quand un lien temporaire ne doit plus expirer dans le dos de l'utilisateur. Cette catégorie maille plus qu'elle ne vise un mot-clé générique : api ged et api stockage fichiers n'ont pas de volume propre.
Les espaces de fichiers que nous intégrons

Microsoft 365
SharePoint et OneDrive, souvent déjà dans le tenant de vos équipes.

Google Drive
Drive, et parfois Sheets, pour les pièces et les tableaux du dossier.

Box
Une GED entreprise, quand la gouvernance documentaire est déjà là.

Dropbox
Le partage de fichiers, à relier au dossier plutôt qu'à un lien magique.
Ce qui rend un dossier vide
Le drive stocke. Tant que l'application n'a qu'une URL collée, le lien meurt, les droits divergent, le token expire.
Le lien Drive est mort, le dossier est vide
Nous stockons un identifiant de fichier, pas une URL copiée. Le lien se reconstruit, les droits se revérifient.
On ne sait pas qui a le droit de voir la pièce
Le dépôt reprend vos règles métier (compte, rôle) vers le drive. Un document client n'est plus dans un dossier « partagé à tout le monde ».
Chaque équipe range à sa façon
Une arborescence posée au cadrage : dossier client, type de pièce, millésime. Le connecteur crée le chemin, il ne le devine pas.
Le token Microsoft a expiré, plus rien ne s'uploade
Rafraîchissement, alerte, parcours de reconnexion. Un drive sourd se voit avant la clôture du dossier.
Ce que chaque espace de fichiers implique concrètement

Box
GED entrepriseUne GED souvent déjà gouvernée. L'intégration se juge sur le dépôt depuis le métier, la recherche dans le dossier, et le respect des politiques déjà en place. Nous n'inventons pas ici de quotas d'API.
- Dépôt depuis l'application
- Politique documentaire respectée
- Périmètre tranché au cadrage

Dropbox
Partage de fichiersUn espace de partage encore fréquent chez les PME. Un lien Dropbox collé dans un champ n'est pas un connecteur : identifiant, expiration, droits. Le cadrage fixe ce qui est stocké chez vous (métadonnées) et ce qui reste chez Dropbox (binaire).
- Lien stable, pas une URL copiée
- Métadonnées dans le dossier
- Binaire chez le fournisseur

Google Drive
Drive et SheetsDrive pour les fichiers, parfois Sheets pour un tableau vivant. Le volume d'API Drive et Sheets existe ; la page catégorie maille vers le besoin dossier. Identifiant de fichier, dossiers parents, partage : se cadrent avant le premier upload.
- Fichier rattaché au dossier métier
- Partage cadré
- Sheets seulement si le tableau est un livrable

Microsoft 365
SharePoint, OneDriveSharePoint et OneDrive via Microsoft Graph. Utile quand l'entreprise est déjà sur Microsoft 365. Sans routes inventées : le cadrage fixe sites, bibliothèques, permissions et le même sujet de token que l'agenda Outlook. Un dump « tout le tenant » n'est pas une intégration.
- Pièce dans la bibliothèque du dossier
- Permissions alignées sur le métier
- Graph cadré, pas le tenant entier
Quatre façons de faire vivre la pièce dans le dossier
Le dossier liste ses pièces
L'identifiant de fichier est dans le métier. Ouvrir le dossier, c'est voir les documents, pas un Drive à côté.
Dépôt à l'entrée d'un workflow
L'upload crée la pièce au bon endroit, avec les droits du compte. Pas un glisser-déposer folklorique.
Partage temporaire cadré
Lien à durée de vie, périmètre du compte. Le « lien éditeur » ouvert à tout le monde sort du rituel.
Recherche dans le périmètre du compte
On cherche dans ce que le rôle a le droit de voir. Pas un crawl de tout le tenant.
Métier, IT, sécurité : qui mappe les droits
Nous ne « branchons pas Drive ». Nous posons l'id de document dans le produit et le mapping des rôles.
Le métier ouvre un dossier complet
Les pièces sont là. Plus de « le lien ne marche plus » en rendez-vous client.
L'IT cesse d'être le dépanneur de tokens
Expiration, révocation, rotation : un runbook. Microsoft et Google révoquent, ce n'est pas un bug rare.
La sécurité mappe rôles métier et ACL drive
Les droits du drive ne sont pas vos rôles. Nous les faisons correspondre, explicitement.
L'archive n'est pas un second silo
On ne duplique le binaire que si la conformité l'impose. Sinon, référence.
Ce que nous avons livré, et qui s'applique ici
Ce qu'un espace de fichiers force comme méthode
Référence vs copie
Id de fichier dans le métier, binaire dans le drive, sauf archive imposée.
Livrable : choix référence / copieMapping des droits
Matrice rôles / ACL, partage, révocation.
Livrable : matrice de droitsPolitique de rétention
Durées, suppression, hold, responsable.
Livrable : politique de rétentionRotation des tokens
Refresh, alerte d'expiration, parcours de re-consentement.
Livrable : runbook tokensCe que personne ne vous dit avant de signer
Une URL copiée n'est pas une référence
Les liens expirent, les fichiers bougent. On stocke l'identifiant fournisseur, on reconstruit l'accès.
Les droits du drive ne sont pas vos rôles métier
Sans mapping, un « partage éditeur » ouvre trop. Le cadrage aligne compte applicatif et ACL du drive.
Le binaire n'a pas à vivre deux fois
Sauf contrainte d'archive, le fichier reste chez le fournisseur. Votre base porte les métadonnées et le lien stable.
Le token Microsoft ou Google se révoque
Sans parcours de reconnexion, l'upload meurt un lundi. Microsoft et Google révoquent les tokens : c'est un livrable (refresh, alerte, re-consentement), pas un raffinement de fin de projet.
Ce que nous mesurons sur un projet fichiers
Intégration d'un espace de fichiers : vos questions
Trois étapes. D'abord figer l'arborescence, les droits et ce que vous stockez (métadonnées vs binaire). Ensuite brancher OAuth avec les scopes minimaux, poser l'identifiant de fichier comme référence, et une file d'upload avec reprise. Enfin recetter partage, révocation et fichier déplacé. La difficulté n'est pas d'envoyer un octet, c'est de le retrouver six mois plus tard avec les bons droits.
Lister les pièces d'un dossier se chiffre bien plus bas qu'une sync d'arborescence multi-sites avec mapping de droits. Le nettoyage du drive existant pèse autant que le connecteur. Nous cadrons le périmètre en amont et donnons une estimation ferme.
Presque jamais. Le drive reste le stockage, l'application reste le dossier. Dupliquer les binaires coûte cher et pose un problème de fraîcheur. On ne migre que ce que l'archive ou la conformité impose, et on le dit au cadrage.
Celui que vos équipes utilisent déjà. L'intégration ne justifie pas un changement de suite bureautique. Les deux se branchent ; les tokens et les permissions se cadrent dans chaque écosystème. Sheets et SharePoint se traitent comme des cas, pas comme « tout Google » ou « tout Microsoft ».
En stockant l'identifiant du document sur la pièce ERP, et en laissant le binaire dans Drive, SharePoint ou la GED. L'ERP n'est pas un disque. Nous mappous qui a le droit de voir la pièce vers les ACL du drive, et nous recettons le fichier déplacé, le lien mort et le token révoqué. La page ERP traite les types de pièces ; ici le sujet est que la référence survive au temps. Un commentaire avec une URL Drive n'est pas une intégration.
Référence dans le dossier, ou copie du binaire ?
30 minutes pour trancher Drive vs SharePoint, le mapping des droits et ce que vous refusez de dupliquer.
Parler de mon projet fichiers


