Pourquoi la vidéo mal gérée plombe l'admin Drupal
Le problème commence à l'upload. Un éditeur dépose un fichier MP4 de quelques centaines de mégaoctets dans la Media Library de Drupal. Sans configuration spécifique, plusieurs choses se produisent simultanément.
Le serveur web reçoit l'upload directement. Le fichier transite par PHP, consomme de la mémoire, et dépasse souvent les limites par défaut de upload_max_filesize et post_max_size. Résultat : un message d'erreur cryptique, le fichier perdu, et un contributeur frustré.
L'encodage se fait souvent dans le même processus. Si un module tente de générer une miniature ou de transcoder la vidéo à la réception, il mobilise les ressources du serveur pendant la durée de l'opération — potentiellement plusieurs minutes pour un fichier lourd.
Les vidéos s'accumulent dans le répertoire files/. Quelques centaines de vidéos, et le volume de stockage sur le serveur applicatif explose. La sauvegarde prend plus longtemps, le déploiement aussi.
La solution n'est pas un module magique. C'est une séparation des responsabilités : chaque étape du cycle de vie de la vidéo — upload, encodage, stockage, diffusion — est confiée à l'outil le plus adapté.
L'architecture cible : sortir l'encodage et le stockage du CMS
1. Upload direct vers le stockage externe
L'upload ne doit pas passer par le serveur Drupal. La vidéo brute va directement vers un stockage objet — un bucket S3 (AWS, Scaleway, OVHcloud, ou tout fournisseur compatible S3) — depuis le navigateur de l'éditeur. Drupal génère une URL pré-signée côté serveur et la transmet au client. Le navigateur envoie le fichier directement vers le bucket. Le serveur Drupal ne voit passer que la requête de génération d'URL et la confirmation d'upload.
Le module S3 File System (s3fs) ou Flysystem permet d'intégrer un stockage S3-compatible comme système de fichiers Drupal.
2. Encodage asynchrone hors CMS
Une fois la vidéo brute dans le bucket, un service d'encodage prend le relais. Il transcoder la vidéo en plusieurs formats (MP4 H.264, WebM VP9, HLS pour le streaming adaptatif), génère les miniatures et les sous-titres si nécessaire, puis dépose les fichiers traités dans un dossier de destination.
AWS Elastic Transcoder, AWS MediaConvert, Mux, Cloudflare Stream ou une instance FFmpeg gérée par une file de tâches remplissent ce rôle selon le budget et les contraintes opérationnelles. Drupal n'encode rien : il écoute la fin de l'encodage via un webhook, met à jour l'entité Media avec les URLs des fichiers traités, et déclenche la génération des miniatures côté CMS.
3. Stockage externalisé, structuré par usage
Une organisation efficace distingue : raw/ (la vidéo source non encodée), encoded/ (les sorties d'encodage par identifiant et résolution), thumbnails/ (les miniatures générées automatiquement), captions/ (les fichiers de sous-titres .vtt, .srt). Cette structure simplifie la rotation des fichiers, les politiques de rétention, et les permissions par dossier.
4. Diffusion via CDN
Les fichiers encodés ne sont pas servis depuis le bucket directement mais via un CDN positionné devant. CloudFront, Cloudflare, BunnyCDN ou Fastly mettent les fichiers en cache au plus près des utilisateurs, absorbent les pics de trafic, et gèrent la reprise de lecture (Range requests) sans toucher au serveur applicatif.
Côté back-office : préserver l'expérience éditeur
Formulaires adaptés à l'upload asynchrone
L'éditeur voit un widget qui envoie le fichier directement vers le stockage externe via une URL pré-signée, affiche une barre de progression pendant l'upload, un indicateur "encodage en cours" une fois l'upload terminé, puis passe automatiquement en prévisualisation quand l'encodage est prêt.
Gestion des erreurs et états intermédiaires
Ces états doivent être gérés explicitement, pas silencieusement : Upload en attente, Encodage en cours, Encodage échoué (avec un message actionnable à l'éditeur), Disponible. Ces états se modélisent avec un champ de statut sur l'entité Media, géré par le webhook et visible dans l'interface d'édition.
Métadonnées exploitables : ce que Drupal doit conserver
Drupal reste la source de vérité des métadonnées, même si les fichiers vivent ailleurs. Les champs à conserver sur l'entité Media : durée en secondes, formats disponibles, URL de lecture principale (HLS ou MP4), URL de miniature, identifiant de job d'encodage, statut d'encodage, sous-titres disponibles par langue.
Ces métadonnées permettent à Drupal de construire le markup Schema.org VideoObject complet, d'alimenter un sitemap vidéo pour le SEO, et de générer le code d'intégration sans aller interroger le service externe à chaque rendu de page.
Par où commencer
Cette architecture se met en place par étapes. Étape 1 : externaliser le stockage avec S3 File System ou Flysystem. Étape 2 : connecter le service d'encodage et configurer le webhook de fin d'encodage. Étape 3 : adapter les formulaires de la Media Library pour refléter le workflow asynchrone. Étape 4 : mettre en place le CDN pour la diffusion. Étape 5 : enrichir les métadonnées et connecter le sitemap vidéo.
Ce que DrupaLabs peut faire
DrupaLabs accompagne les organisations qui veulent structurer leur gestion vidéo dans Drupal : choix du service d'encodage adapté à l'échelle et aux contraintes, configuration du stockage externalisé, adaptation des workflows éditoriaux, et intégration du player dans le front-end. L'architecture s'appuie sur des briques standards — S3, FFmpeg ou son équivalent cloud, CDN — assemblées autour du Media module core.
Tout commence par un état des lieux de votre configuration actuelle.
Un projet web en tête ?
Commençons par un diagnostic : ce qui vous ralentit, et par où commencer.
Demander un diagnostic