Use case
Migrer un stockage objet : ce que la copie des fichiers ne révèle pas
Migration du stockage d'un DAM vers Azure Blob Storage : 18 écarts de référencement détectés, une bascule en 30 minutes et trois parcours métier validés.
5 min de lectureYasser LAKRAIMI
- Migration
- Azure
- DAM
- Cloud
Une migration peut copier tous les fichiers et pourtant interrompre la production d’un catalogue. We Are Beebay a accompagné l’un de ses clients dans la migration du stockage objet de son application de gestion des ressources numériques (Digital Asset Management, DAM) vers Azure Blob Storage. Ce DAM centralise, organise et met à disposition les images et documents nécessaires aux applications et à la production de catalogues.
Un changement de stockage qui touchait toute la chaîne catalogue
Le client s’appuyait déjà sur Azure pour une partie de son système d’information. Maintenir un stockage compatible S3 distinct imposait des pratiques d’exploitation et de gestion des accès supplémentaires. Le choix d’Azure Blob Storage répondait donc à une volonté de rationalisation, au prix d’un changement d’interface. Pour limiter cette dépendance dans le DAM, l’équipe a retenu une couche d’abstraction applicative.
Au départ, la migration semblait tenir en trois opérations : inventorier, copier, modifier la configuration. L’audit a montré qu’un objet présent dans Azure ne devient pas automatiquement exploitable par les applications.
Sur plus de 6 000 images et 800 fichiers Excel, le rapprochement entre les chemins applicatifs et les objets stockés a révélé 18 écarts de référencement. Détectés pendant l’audit, ils n’étaient pas des pertes provoquées par le transfert. L’équipe les a analysés et corrigés avant la bascule.
Les dépendances concernaient quatre composants : la base SQL conservait des chemins d’images, l’interface construisait les URL, le backend gérait les accès et les téléchargements, et les exports transmettaient des liens à l’outil catalogue. Copier les fichiers sans adapter ces usages aurait pu rendre des aperçus indisponibles ou des catalogues incomplets.
Trois choix d’architecture et leurs compromis
1. Préserver la portabilité du code métier
L’API S3 est un standard de fait du stockage objet, mais Azure Blob Storage ne l’expose pas nativement. [1] L’équipe a isolé la lecture, l’écriture et la suppression derrière une interface commune, avec une implémentation par fournisseur. Ce choix limite les adaptations du code métier et facilite une future sortie d’Azure ; il ne rend pas automatiquement portables les URL, les autorisations ou les intégrations externes.
2. Distinguer la référence produit de l’adresse du fichier
Le DAM utilise des clés logiques stables pour les images, par exemple produits/1234/visuel.jpg, plutôt que l’URL d’un fournisseur. Mais les liens contenus dans un export Excel peuvent être consultés plusieurs heures ou jours après sa génération. L’accès aux images doit donc être reconstruit pour l’export : une clé stable ne répare pas un ancien lien figé.
3. Sécuriser les images privées sans bloquer les catalogues
Pour les outils catalogue, le DAM produit lors de la préparation de l’export des liens SAS temporaires : leur périmètre et leur validité sont adaptés aux permissions et au délai de mise en page. Le conteneur Azure reste privé, sans accès anonyme ; toutefois, un lien SAS valide est utilisable par toute personne qui le détient, dans les limites accordées. La diffusion des fichiers Excel contenant ces liens doit donc rester contrôlée. Un nouvel export peut renouveler les URL sans changer les références métier. [2]
Quatre étapes, deux preuves de réussite
Après l’audit et les premières adaptations applicatives, l’équipe a lancé une copie initiale non destructive de l’historique avec rclone copy. Pendant la semaine de coexistence, les nouveaux fichiers ont été écrits dans les deux stockages. Cette double écriture ne dispense pas de contrôler les modifications, les suppressions et les éventuels échecs d’un côté : une comparaison finale précède la bascule. rclone sync peut supprimer des objets, d’où l’intérêt d’un --dry-run. Enfin, deux validations se complètent : rclone check pour la cohérence des objets, puis les tests des parcours métier du DAM et du catalogue. [3]
Après la bascule : les résultats qui comptent
Le chantier a mobilisé deux semaines d’audit, de refactorisation, d’adaptation et de validation, suivies d’une semaine de double écriture. Dans une fenêtre de bascule de 30 minutes, l’équipe a suspendu les nouvelles écritures, comparé les données entre les deux stockages et activé Azure Blob Storage comme stockage principal. Les écritures ont ensuite repris sur Azure.
Après la bascule, les tests ont confirmé le fonctionnement des trois parcours critiques : affichage des images, téléchargements et exports destinés à la production catalogue. La résolution des 18 écarts de référencement avait également été contrôlée avant la mise en production.
Le plan de retour arrière prévoyait un retour conditionné à la réconciliation des nouvelles écritures effectuées sur Azure : réactiver directement l’ancien stockage aurait pu laisser de côté des visuels ajoutés depuis la bascule. Le repli restait donc possible, mais nécessitait ce contrôle supplémentaire.
Ce qu’il faut retenir avant votre prochaine migration
Trois enseignements ressortent du chantier : cartographier les consommateurs avant les objets, découpler les références métier des URL du fournisseur, et mesurer la réussite sur les parcours applicatifs, pas sur le seul transfert.
Pour votre prochaine migration, cinq questions permettent de cadrer le risque : quels objets sont utilisés ? Où les liens sont-ils enregistrés ? Qui peut y accéder, et pour combien de temps ? Comment gérer les dernières écritures et le retour arrière ? Combien coûtera la coexistence ?
Le verrou financier évolue, le verrou technique reste. Pour les services concernés dans l’Union européenne, le Data Act prévoit la suppression des frais spécifiques de changement de fournisseur à partir du 12 janvier 2027. Les adaptations applicatives et les tests métier restent nécessaires ; des règles distinctes concernent certains usages simultanés de services. [4]
Une action cette semaine : rechercher les noms de buckets, domaines et chemins de stockage dans le code, la base SQL, les scripts et les exports. Leur dispersion révèle souvent davantage de risques que le volume à copier.
Cartographions vos dépendances avant la bascule. We Are Beebay accompagne l’audit, les arbitrages d’architecture, le transfert contrôlé et la validation des usages métier. Parlons de votre migration.
