Comment passer de drives partagés à un DAM

Quitter un drive partagé ne se réduit pas à copier des fichiers. Copier les fichiers est la partie facile, et cela prend un week-end. Le vrai travail consiste à convertir dix ans de noms de dossiers, de conventions de nommage et de mémoire collective en métadonnées, sans laisser en plan les milliers de liens Drive qui se trouvent dans des présentations, des wikis, des fils d’emails et les boîtes de réception de partenaires.

Ce guide décrit la marche à suivre. Il suppose que vous avez décidé de migrer ; les parties 1, 2 et 3 examinent si vous devriez le faire. Si vous quittez SharePoint plutôt que Drive ou Dropbox, le guide de migration depuis SharePoint en est la version pour une bibliothèque dotée de types de contenu et d’un magasin de termes.

Étape 1 : décider par écrit de ce qui migre

L’erreur la plus coûteuse est de décider de tout migrer, car « tout » dans un drive partagé inclut des fichiers de travail, des copies personnelles, des exports dont personne n’a besoin et huit ans de livrables clients qui n’ont jamais été des médias.

Rédigez trois listes avant toute autre chose.

Migre maintenant. Les médias de marque, les campagnes en cours, les photos produit encore utilisées, le jeu de logos et de templates. En général de 10 à 20 % du lecteur en nombre de fichiers, et la partie qui porte presque toute la valeur.

Migre plus tard, ou jamais. L’archive historique. Faites-en une décision explicite, avec sa propre justification, plutôt qu’un choix par défaut. Une archive que personne n’a ouverte depuis trois ans peut rester où elle est, être migrée lors d’une seconde passe, ou être migrée à froid avec un minimum de métadonnées pour être au moins interrogeable par son contenu.

Reste dans le lecteur. Les fichiers de travail : PSD en calques en cours de modification, répertoires de projets, packages InDesign, exports de travail, et tout document qui n’est pas un média. Voir l’étape 9.

La liste du périmètre est ce qu’on vous demandera de modifier trois semaines plus tard. L’avoir écrite vous permet de dire ce que coûte le changement.

Étape 2 : faire l’inventaire avant de toucher à quoi que ce soit

Il vous faut quatre chiffres avant de pouvoir planifier, et les deux plateformes vous les fournissent.

• Nombre total de fichiers et nombre total d’octets, par dossier de premier niveau. La console d’administration de Google indique le stockage par utilisateur et par drive partagé ; celle de Dropbox indique la taille des dossiers d’équipe. Pour un inventaire fichier par fichier, l’API Drive avec files.list et fields=files(id,name,mimeType,size,parents,createdTime,modifiedTime,owners) produit un tableur que vous pouvez trier.
• Répartition par type de fichier. Le rapport entre images, vidéos, documents et fichiers de design détermine à la fois l’estimation du stockage et la durée du traitement de l’autre côté.
• Répartition par ancienneté. Les fichiers non modifiés depuis trois ans sont des candidats à l’archive et doivent être traités comme tels dans le périmètre.
• Doublons. Comptez les fichiers de taille identique en première approximation. Le chiffre sera plus élevé que prévu.

Deux chiffres de la partie 1 contraignent le plan et méritent d’y figurer dès maintenant : un drive partagé Google contient au plus 500 000 éléments, corbeille et raccourcis compris, et chaque utilisateur ne peut importer et copier que 750 Go en 24 heures. Le second détermine la vitesse à laquelle vous pouvez extraire les fichiers.

Étape 3 : lire l’arborescence avant de la casser

C’est l’étape qui distingue une bonne migration d’une migration rapide.

Un chemin comme Marketing/2024/Q3/Nordics/Product/Kettle/Lifestyle/hero_kettle_oslo_final.jpg n’est pas du désordre. Ce sont sept informations que quelqu’un a encodées délibérément : service, année, trimestre, marché, catégorie, produit, type de prise de vue. Ce sont exactement les champs de métadonnées que vous allez créer. Jeter l’arborescence et tout réindexer à la main représente des semaines de travail pour reproduire des informations que vous avez déjà.

La marche à suivre :

1. Exportez tous les chemins complets du périmètre.
2. Triez les segments de chemin distincts par fréquence. Les quarante premiers segments forment votre taxonomie, révélée plutôt que conçue.
3. Affectez chaque segment récurrent à un champ : l’année à un champ de date, Nordics au marché, Kettle au produit, Lifestyle au type de prise de vue.
4. Repérez les segments qui ne signifient rien (Nouveau dossier, temp, Trucs de Jean, FINAL FINAL). Ce sont les parties de l’arborescence sans information, et elles vous indiquent quelles branches demandent une revue humaine.
5. Rédigez la correspondance sous forme de tableau et faites-la vérifier par deux personnes qui utilisent la bibliothèque.

Les noms de fichiers sont une seconde source et se traitent de la même façon. Des conventions comme hero_, _final, _v3, _CMYK, _1080x1080, les codes de marché et les références produit sont autant de champs qui n’attendent qu’une expression régulière pour être extraits.

Le guide de la taxonomie explique comment concevoir la structure qui en résulte, et le guide des bonnes pratiques de métadonnées indique quels champs rendre obligatoires.

Étape 4 : récupérer les métadonnées déjà présentes dans les fichiers

Cette étape n’a pas d’équivalent dans une migration SharePoint, et c’est le plus gros gain disponible ici.

Comme le décrit la partie 2, les photos professionnelles arrivent avec les champs IPTC et XMP renseignés : légende, mots-clés, créateur, mention de copyright, crédit, conditions d’utilisation des droits et noms de lieux. Un drive partagé ne les a jamais lus, donc personne dans votre équipe ne sait qu’ils existent. Ils étaient dans les fichiers depuis le début.

Avant de migrer, prélevez un échantillon de deux cents images de différentes années et de différentes sources, et vérifiez combien contiennent un champ Description ou Mots-clés renseigné. Sur une bibliothèque qui a reçu des livraisons d’agences et de banques d’images, la réponse est en général une part importante.

Toute ingestion sérieuse lira ces champs à l’import et les fera correspondre au schéma de la bibliothèque : dix ans de légendes de photographes arrivent alors sous forme de texte interrogeable dès le premier jour, sans travail manuel. Vérifiez que la correspondance est configurée avant le chargement en masse, car la relancer ensuite demande plus de travail que de la faire d’abord.

Étape 5 : traiter les doublons pendant le transfert, pas après

Une bibliothèque organisée en dossiers accumule des fichiers presque identiques, car copier est la façon dont on partage et exporter est la façon dont on redimensionne. Chacun d’eux sera migré fidèlement si vous ne l’arrêtez pas.

Faites-le pendant que les fichiers sont en transit plutôt qu’après leur arrivée : revoir une bibliothèque dédupliquée de 40 000 médias n’a rien de commun avec revoir une copie fidèle de 140 000 fichiers.

• Doublons exacts, par somme de contrôle : gardez-en un, notez les autres chemins comme éléments pour la correspondance de l’étape 3, supprimez le reste.
• Quasi-doublons, c’est-à-dire copies redimensionnées, recompressées ou légèrement recadrées de la même image : ils demandent une comparaison du contenu. La détection des quasi-doublons en explique le mécanisme et la détection des doublons définit le terme.
• Les dérivés ne sont pas des doublons et ne doivent pas être supprimés. Un TIFF d’impression et un JPEG web de la même photo deviennent un seul média avec deux déclinaisons, le changement structurel qui empêche les deux fichiers de diverger à nouveau.

Attendez-vous à une baisse d’un tiers ou plus du nombre de fichiers. Ce chiffre est la preuve la plus claire que la migration valait la peine.

Étape 6 : être honnête sur les versions

La partie 1 pose la règle : la documentation de Google indique qu’une version d’un fichier importé « peut être définitivement supprimée au bout de 30 jours ou s’il existe 100 versions plus récentes ». Dropbox conserve 30, 180 ou 365 jours selon le plan.

La conséquence pour une migration est simple, et mieux vaut la dire tôt aux parties prenantes. Les versions historiques que vous espérez conserver ont, pour la plupart, déjà disparu. La migration n’en est pas la cause ; cela s’est produit discrètement au fil des années précédentes.

Ce que vous pouvez reprendre, c’est le fichier actuel, ses dates de création et de modification, et son propriétaire. Considérez la migration comme le moment où commence un véritable historique de versions, et dites-le, plutôt que de promettre une reconstitution que vous ne pouvez pas livrer.

Étape 7 : migrer par tranches et rythmer l’extraction

Pas un transfert en bloc. Des tranches, chacune correspondant à une sous-arborescence qui renvoie à un ensemble cohérent de métadonnées, afin de vérifier que la correspondance fonctionne avant la tranche suivante.

La première tranche doit être petite, récente et utilisée par les personnes qui jugeront le projet : le jeu de médias de marque, ou la campagne du trimestre en cours. Chargez-la, vérifiez que la correspondance dossier-champ a produit des valeurs cohérentes, vérifiez que l’IPTC est bien arrivé, puis corrigez la correspondance et chargez la suivante.

Deux limites de débit déterminent la vitesse d’extraction, toutes deux issues de la partie 1. Le plafond de 750 Go par utilisateur et par 24 heures s’applique aux copies comme aux imports. L’API Drive autorise 1 To de sortie par projet et par 24 heures, et renvoie 403 ou 429 en cas de dépassement du quota par minute, avec un backoff exponentiel comme traitement documenté.

Pour une bibliothèque de 5 To, cela représente au minimum cinq jours de transfert, et en pratique une à deux semaines traitement compris. Construisez le calendrier sur cette base, pas sur un week-end.

N’oubliez pas les clients de bureau. Des fichiers existent sur les portables comme dans le cloud, et un designer dont la synchronisation sélective est désactivée peut détenir le seul exemplaire de quelque chose. Demandez avant de désactiver l’ancien système.

Étape 8 : traiter les liens qui vont casser

C’est la partie la plus difficile du départ d’un drive partagé, et celle que la plupart des guides de migration passent sous silence.

Un lien Drive ou Dropbox est un identifiant opaque. Il apparaît dans des présentations, des pages de wiki, des bases Notion, Confluence, des tickets Jira, des fils d’emails, des messages Slack, des newsletters programmées, des portails partenaires et des briefs fournisseurs. Il n’existe aucune redirection. Quand le fichier bouge, le lien renvoie une erreur 404 ou, pire, continue de fonctionner et sert une copie périmée d’un lecteur que plus personne ne maintient.

Il n’existe pas de solution complète. Il existe un enchaînement qui limite les dégâts :

1. Ne supprimez pas la source. Passez l’ancien lecteur en lecture seule au basculement et conservez-le au moins un trimestre. Une copie périmée en lecture seule est un problème bien plus petit qu’un lien mort, et elle vous fait gagner du temps.
2. Corrigez vous-même les liens les plus fréquentés. Le site web, les templates, les pieds d’email, les documents destinés aux partenaires, les vingt pages de wiki les plus consultées. C’est une liste courte, et elle couvre l’essentiel du trafic réel.
3. Publiez une table de correspondance. Ancien chemin vers nouvelle URL du média, dans une page où l’on peut chercher. Quand quelqu’un tombe sur un lien cassé, c’est ce qu’il cherche.
4. Remplacez le partage externe par quelque chose de durable. Les liens que vous avez donnés aux agences et aux distributeurs doivent devenir un accès à un portail de marque plutôt que de nouveaux liens de fichiers, pour que la prochaine migration ne répète pas cette étape.
5. Acceptez la traîne. Certains liens de certaines vieilles présentations vont casser. Dites-le à l’avance plutôt que de le découvrir sous forme de réclamation.

Vous pouvez éviter ce problème pour l’avenir. Si les tiers externes ont un accès au portail plutôt que des liens de fichiers, et si les pages internes pointent vers des URL de médias plutôt que vers des chemins de stockage, la prochaine migration n’aura pas d’étape 8.

Étape 9 : décider de ce qui reste, et empêcher le lecteur de se remplir à nouveau

Le lecteur ne disparaît pas. Il cesse d’être la photothèque.

Reste dans le lecteur : documents, contrats, tableurs, présentations, répertoires de projets, fichiers de travail modifiables en cours d’édition, et tout ce qu’une personne ouvre plutôt que ce que l’entreprise publie.

Va dans la bibliothèque : tout ce qui est terminé, partagé, réutilisé, publié ou soumis à des droits.

La frontière demande une règle que les gens peuvent appliquer sans poser de question. La règle qui tient dans une vraie équipe est : si quelqu’un en dehors de votre équipe proche peut en avoir besoin, cela va dans la bibliothèque.

Fermez ensuite le chemin qui remplit à nouveau le lecteur. Si le dossier de campagne existe toujours et que les gens y ont encore un accès en écriture, des fichiers continueront d’y arriver. Passez-le en lecture seule le jour même de l’ouverture de la bibliothèque, pas un mois plus tard, et expliquez pourquoi à l’avance.

Étape 10 : vérifier avec des chiffres

Des vérifications qui produisent un chiffre plutôt qu’une impression :

Vérification	Résultat satisfaisant
Nombre de médias dans la bibliothèque comparé au nombre de fichiers du périmètre moins les doublons	à quelques pour cent près, chaque écart étant expliqué
Médias avec une légende ou des mots-clés renseignés	élevé si l’étape 4 a fonctionné ; proche de zéro signifie que la correspondance IPTC n’a pas été configurée
Médias dont un champ obligatoire est vide	une liste que vous pouvez traiter, pas une surprise
Recherche de dix demandes réelles du mois dernier	trouvées en une requête, par quelqu’un qui n’a pas construit la bibliothèque
Les vingt liens entrants les plus fréquentés	fonctionnels
Stockage utilisé comparé à l’estimation	dans la fourchette, sinon vous avez raté un réglage de déclinaison

Faites la vérification de recherche avec quelqu’un qui n’était pas dans le projet. La personne qui a construit la taxonomie retrouve toujours les choses.

Calendrier

Ordres de grandeur, à partir du nombre de fichiers du périmètre, pour une personne responsable qui y travaille en plus d’autres tâches, et une migration qui inclut les étapes 3 à 5 plutôt qu’une copie à plat.

Médias dans le périmètre	Durée	Où passe le temps
Moins de 5 000	1 à 2 semaines	Correspondance et revue ; le transfert est trivial
5 000 à 50 000	3 à 6 semaines	Analyse des chemins, traitement des doublons, vérification tranche par tranche
50 000 à 250 000	2 à 4 mois	Rythme du transfert face au plafond quotidien, plus capacité de revue
Plus de 250 000	un trimestre ou plus	Presque entièrement de la revue humaine et du rattrapage de droits

Le transfert est rarement la contrainte. En revanche, décider comment nommer les choses l’est.

Questions fréquentes

Combien de temps faut-il pour migrer de Google Drive vers un DAM ?

Pour un périmètre de moins de 5 000 médias, une à deux semaines. Pour 50 000, environ un mois. Au-delà de 250 000, un trimestre ou plus. Le transfert des fichiers est limité par le plafond de Google de 750 Go par utilisateur et par 24 heures : une bibliothèque de 5 To demande au moins cinq jours d’extraction. Tout le reste est de la correspondance de métadonnées et de la revue humaine, ce qui fixe réellement le calendrier.

Puis-je garder mon arborescence de dossiers ?

Gardez-la sous forme de métadonnées, pas de dossiers. Chaque segment de chemin récurrent correspond à un champ : année, marché, produit, type de prise de vue, campagne. Cela conserve l’information et supprime la contrainte qu’un fichier ne puisse être qu’à un seul endroit. La plupart des bibliothèques gardent aussi une petite structure de collections qui ressemble à des dossiers pour la navigation, alimentée par les mêmes champs.

Vais-je perdre mon historique de versions ?

Il en reste peu. La documentation de Google indique que les versions des fichiers importés « peuvent être définitivement supprimées au bout de 30 jours ou s’il existe 100 versions plus récentes », et Dropbox conserve de 30 à 365 jours selon le plan. Ce qui migre, c’est le fichier actuel avec ses dates et son propriétaire. Considérez la migration comme le début d’un véritable historique de versions plutôt que comme son transfert.

Comment exporter les fichiers et les métadonnées de Google Drive ?

Pour l’inventaire, l’API Drive files.list avec un paramètre fields explicite fournit les chemins, tailles, types, propriétaires et horodatages sous forme de données structurées. Pour les fichiers eux-mêmes, utilisez un connecteur DAM s’il en existe un : il gère la pagination, les nouvelles tentatives et le backoff face aux quotas de l’API. Google Takeout est conçu pour les comptes personnels et convient mal à une bibliothèque d’équipe.

Que doit-il rester dans Google Drive après la migration ?

Les documents, contrats, tableurs, présentations, répertoires de projets et fichiers de travail modifiables. Le lecteur reste le bon endroit pour ce que les gens modifient. La bibliothèque contient ce que l’entreprise publie, partage ou ce qui est soumis à des obligations de droits. Une règle suffit à garder la frontière praticable : si quelqu’un en dehors de votre équipe proche peut en avoir besoin, cela va dans la bibliothèque.

Que deviennent tous les liens Drive de nos présentations et wikis ?

Certains vont casser, et aucune redirection ne permet de l’éviter. Gardez l’ancien lecteur en lecture seule au moins un trimestre, corrigez vous-même les liens les plus fréquentés, publiez une page de correspondance entre anciens chemins et nouveaux médias, et orientez les tiers externes vers un accès au portail plutôt que de leur donner de nouveaux liens de fichiers. Prévoyez une traîne de liens cassés dans d’anciens documents et dites-le avant le basculement.

---

Précédent dans la série : liens partagés, droits et piste d’audit. Pour le projet plus large autour de la migration, voir le guide de mise en œuvre d’un DAM.