MP4 vs WebM : le meilleur format pour la vidéo web en 2026
La réponse courte (et pourquoi c'est compliqué)
Si tu as besoin d'un seul format vidéo pour le web en 2026, la réponse est le MP4 avec encodage H.264. Il reste le grand gagnant en matière de compatibilité brute. Tous les navigateurs, tous les appareils et toutes les smart TV le lisent sans aucun problème. Le WebM, qui utilise l'encodage VP9 ou AV1, offre une meilleure compression et une meilleure qualité d'image pour la même taille de fichier, mais il traîne quelques casseroles. Safari n'a bénéficié du décodage matériel complet de l'AV1 que fin 2024, et certains anciens appareils Android peuvent encore avoir du mal avec le VP9. Pour la plupart des éditeurs, la vraie réponse est simple : proposer les deux. Un fichier WebM comme source principale avec un MP4 en solution de repli (fallback) couvre 99,8 % des appareils, ce qui te donne le meilleur des deux mondes en termes de qualité et de bande passante. L'élément HTML5 <video> rend cela étonnamment facile grâce aux balises <source> multiples. La véritable complexité ne réside pas dans le code, mais dans la logistique. Tu dois prendre en compte le temps d'encodage, les coûts de stockage, les frais de CDN, et te demander si ton CMS ou ta plateforme vidéo te permettra ne serait-ce que de téléverser deux versions du même fichier. Cet article décortique ces compromis avec des chiffres concrets, pour t'aider à choisir une solution adaptée à ton vrai flux de travail, et pas seulement à un idéal théorique.
Analyse des codecs : ce qu'il y a vraiment dans chaque conteneur
MP4 et WebM ne sont que des conteneurs. Imagine-les comme des fichiers ZIP contenant des flux vidéo et audio compressés. Le format du conteneur lui-même est bien moins important que le codec qui fait tout le travail à l'intérieur. Les fichiers MP4 contiennent presque toujours de la vidéo H.264 (AVC) et de l'audio AAC. Le H.264 est un vieux standard datant de 2003, mais il a été affiné pendant plus de deux décennies. Un flux H.264 1080p à 4 Mbps rend très bien sur la plupart des écrans. Bien que le MP4 supporte aussi le H.265 (HEVC), qui offre une qualité similaire pour la moitié du débit, son adoption a été un vrai bazar. Les frais de licence ont rendu les éditeurs de navigateurs hésitants, et même mi-2026, Chrome ne décode pas le HEVC nativement sur toutes les plateformes. Google a conçu le WebM comme un format ouvert et libre de droits pour le web. Il peut utiliser les codecs VP8, VP9 ou AV1 avec de l'audio Vorbis ou Opus. Le VP9 offre une compression 30 à 50 % supérieure à celle du H.264 pour une qualité équivalente. L'AV1 va encore plus loin ; les tests internes de YouTube montrent que l'AV1 peut réduire la taille des fichiers de 30 % supplémentaires par rapport au VP9. Mais cette efficacité a un prix élevé : le temps d'encodage. Avec son préréglage le plus lent et de la plus haute qualité (cpu-used=0), l'encodage AV1 avec libaom peut prendre 50 à 100 fois plus de temps qu'un encodage H.264 standard. Pour la publication web en pratique, cela fait du VP9 dans un conteneur WebM le compromis idéal pour 2026. Tu obtiens des gains de compression significatifs par rapport au H.264 et des vitesses d'encodage qui sont réellement gérables sans avoir besoin d'une ferme de serveurs dédiée.
Support des navigateurs et appareils en 2026
Le support par les navigateurs est un sujet en constante évolution. Voici un état des lieux à la mi-2026. Le support du MP4/H.264 est simple : il est universel. Chrome, Firefox, Safari, Edge, Opera, Samsung Internet... tous les principaux navigateurs sur toutes les plateformes le gèrent nativement. Aucune exception, aucune note de bas de page. Le WebM/VP9 est également largement supporté, disponible dans Chrome (depuis la v29), Firefox (depuis la v28), Edge (depuis la v14) et Opera. Apple a finalement ajouté le support du VP9 dans Safari 14 en 2020, couvrant iOS 14 et macOS Big Sur. Le piège ? Les appareils bloqués sur iOS 13 ou une version antérieure, un segment de trafic petit mais bien réel, ne peuvent pas lire le WebM VP9. Ne pars pas du principe que ce n'est pas ton public ; vérifie tes statistiques. Les utilisateurs en entreprise et dans l'éducation ont souvent des cycles de renouvellement de matériel étonnamment longs. Le support du WebM/AV1 est bien meilleur qu'il y a quelques années. Chrome, Firefox et Edge décodent l'AV1 depuis un certain temps. Côté Apple, Safari sur les Mac Apple Silicon bénéficie du décodage AV1 accéléré par le matériel, tout comme l'iPhone 15 Pro et les modèles plus récents. Les iPhones plus anciens se rabattent sur le décodage logiciel, ce qui dévore la batterie et peut entraîner des pertes d'images sur les vidéos 4K. Le décodage logiciel est la recette parfaite pour un téléphone qui chauffe et un utilisateur mécontent. Si ton public est majoritairement sur iOS et que tu te soucies de l'autonomie de leur batterie, le VP9 est le codec WebM le plus sûr. Conclusion : pour un site grand public avec un mélange d'utilisateurs sur ordinateur et mobile, une source principale en WebM/VP9 avec un fallback en MP4/H.264 est la configuration la plus sûre et la plus intelligente.
Taille de fichier et qualité : les vrais chiffres
Les affirmations abstraites sur les taux de compression n'aident pas à gérer les budgets de stockage. Regardons quelques chiffres concrets issus d'un clip source de 2 minutes en 1080p à 30 ips, encodé avec FFmpeg et le pipeline de CocoConvert. Notre référence est un MP4 avec H.264 (x264, CRF 23, preset medium), qui pèse 87 Mo. C'est le choix par défaut pour de nombreux développeurs, et la qualité est solide, avec un score VMAF d'environ 93 pour ce clip. Passer au WebM avec VP9 (libvpx-vp9, CRF 33, two-pass) réduit la taille du fichier à 54 Mo. Le score VMAF est légèrement supérieur, à 94, ce qui signifie que le fichier est plus petit avec une qualité marginalement meilleure. Cette efficacité n'est pas gratuite ; l'encodage en deux passes a pris environ 4 fois plus de temps que la version H.264 sur la même machine. Un encodage AV1 dans un conteneur WebM (libaom-av1, CRF 30, cpu-used=4) nous amène à seulement 41 Mo, avec un score VMAF de 95. Le paramètre `cpu-used=4` est un bon compromis, nettement plus rapide que le `cpu-used=0` quasi inutilisable, mais toujours environ 12 fois plus lent que notre référence H.264. Qu'est-ce que cela signifie pour ton budget ? Pour un site avec 500 vidéos de produits d'une durée moyenne de 90 secondes, passer d'une approche H.264 uniquement à une approche privilégiant le VP9 réduit le stockage vidéo principal d'environ 3,2 To à seulement 2,0 To. Avec des prix de CDN typiques de 0,02 € à 0,085 € par Go, ces économies de stockage et de bande passante s'accumulent rapidement à mesure que tu grandis. Une petite remarque sur les paramètres AV1 de CocoConvert : pour que les conversions restent rapides sur une infrastructure partagée, il utilise `cpu-used=5`. Si tu as besoin de la qualité la plus élevée possible pour des encodages AV1 d'archivage (`cpu-used=0` ou `1`), tu auras besoin d'une installation FFmpeg en local ou d'un service de transcodage dédié qui te permet de configurer ces préréglages.
Quand choisir le MP4 plutôt que le WebM
Parfois, le MP4 n'est pas seulement la solution de repli, c'est le seul choix sensé. Le WebM est excellent pour la diffusion sur le web, mais il montre ses limites dans quelques domaines clés. **E-mails et messageries :** La vidéo intégrée dans les e-mails est un champ de mines notoire. Outlook sous Windows ignorera complètement ta balise vidéo HTML5. Alors qu'Apple Mail lit les MP4 directement sur iOS, aucun client majeur ne touchera à un fichier WebM. Pour les campagnes par e-mail, le MP4 est ta seule option. **Téléchargements de vidéos :** Si tu permets aux utilisateurs de télécharger des vidéos pour les regarder hors ligne, propose-leur un MP4. Même si un utilisateur averti avec VLC peut tout lire, les lecteurs multimédias par défaut de Windows, macOS et de la plupart des smart TV ne gèrent pas le WebM. Utiliser le MP4 t'évitera une avalanche de tickets de support du type « la vidéo ne se lance pas ». **Uploads sur les réseaux sociaux :** Toutes les plateformes sociales — Twitter/X, Instagram, TikTok, LinkedIn, Facebook — sont conçues autour du MP4. Elles acceptent les MP4 et les transcodent de leur côté. La plupart rejetteront purement et simplement un upload WebM ou, pire, le transformeront en un désastre illisible. Exporte toujours le contenu pour les réseaux sociaux en MP4. **Anciennes plateformes CMS :** Avant de passer des heures à encoder une bibliothèque de fichiers WebM, vérifie si ta plateforme peut ne serait-ce que les utiliser. D'anciens plugins WordPress, certains systèmes LMS, et même certaines versions de Wistia n'acceptent que les uploads MP4. Une vérification rapide de la documentation peut t'épargner un énorme mal de tête. **Matériel et montage :** Tes rushs provenant de caméras, d'enregistreurs d'écran et de cartes de capture seront presque toujours en MP4 ou MOV. Le WebM est un format de diffusion, pas un format de production. Aucun monteur vidéo professionnel ne l'utilise pour ses projets. C'est pour la ligne d'arrivée, pas la ligne de départ.
Mettre en place les deux formats : le HTML et le workflow
Proposer les deux formats est bien plus simple que ce que la plupart des développeurs pensent. La magie réside dans l'élément HTML5 `<video>`, qui vérifie chaque balise `<source>` dans l'ordre et lit la première qu'il comprend. <video controls width="1280" height="720" preload="metadata"> <source src="/video/product-demo.webm" type="video/webm; codecs=vp9,opus"> <source src="/video/product-demo.mp4" type="video/mp4"> Votre navigateur ne supporte pas la vidéo HTML5. </video> Les navigateurs modernes qui peuvent gérer le WebM VP9 liront la première source. Tous les autres se rabattront gracieusement sur le MP4. Inclure le paramètre `codecs` dans l'attribut `type` est une optimisation intelligente ; cela permet au navigateur de décider encore plus vite, sans avoir à télécharger une partie du fichier. Le workflow pour créer les deux fichiers à partir d'un seul master est simple. L'outil de conversion par lots de CocoConvert peut prendre un dossier de fichiers sources et générer à la fois du MP4 et du WebM en même temps. Il te suffit de téléverser ton master, de choisir « MP4 (H.264) » et « WebM (VP9) » comme formats de sortie, d'ajuster tes paramètres de qualité, et tu obtiendras un ZIP avec les deux versions. Pour une vidéo web 1080p typique, un CRF de 23 pour le H.264 et de 33 pour le VP9 te donnera une qualité visuelle quasi identique. Voici une astuce cruciale pour l'automatisation : garde des noms de fichiers identiques à l'exception de l'extension (par ex., `product-demo.webm` et `product-demo.mp4`). Cela rend trivial pour ton système de templating de construire les chemins des `<source>` sans avoir besoin d'une recherche en base de données pour chaque vidéo. Il est important de connaître les limites de cette approche. CocoConvert ne génère pas actuellement de flux à débit adaptatif (ABR) comme le HLS ou le DASH. Si tu gères des vidéos longues où les utilisateurs peuvent naviguer dans la timeline ou avoir des débits réseau variables, tu auras besoin de l'ABR. Cela nécessite une plateforme vidéo dédiée (comme Mux, Cloudflare Stream ou Bunny.net) ou une configuration FFmpeg auto-hébergée plus complexe. Cependant, pour des clips plus courts de moins de 10 minutes, cette méthode de diffusion avec un seul fichier WebM/MP4 est parfaitement adaptée.
Le verdict pour 2026
Sur le plan purement technique, le WebM avec VP9 est le meilleur format pour la vidéo web en 2026. Il offre des fichiers plus petits pour une qualité égale ou supérieure, et le support des navigateurs est maintenant assez large pour en faire le choix principal pour la plupart des sites web. L'AV1 est le successeur désigné, mais son coût d'encodage élevé et les lacunes persistantes dans le support matériel sur iOS signifient que c'est encore un choix stratégique, pas une simple option par défaut. Mais le MP4 avec H.264 est loin d'être obsolète. Il reste absolument essentiel comme solution de repli universelle. C'est aussi le seul format qui fonctionne pour les e-mails, les uploads sur les réseaux sociaux, les téléchargements et de nombreuses plateformes plus anciennes. Il n'est pas près de disparaître. Donc, voici mes recommandations pratiques : * **Vidéo de site web générale :** Utilise le WebM/VP9 comme source principale, avec un fallback en MP4/H.264. * **Réseaux sociaux et e-mails :** MP4 uniquement. Sans exception. * **Fichiers téléchargeables :** MP4 uniquement, pour maximiser la compatibilité. * **Sites à fort trafic :** Si les coûts de CDN sont une préoccupation majeure, il vaut la peine d'explorer un fallback à plusieurs niveaux : AV1 pour les navigateurs les plus récents, puis VP9, puis H.264. * **Clips très courts (< 30s) :** Pour les vidéos très courtes, la différence de taille de fichier est minime. S'en tenir uniquement au MP4 est plus simple et tout à fait acceptable. Au final, tu jongles avec quatre éléments : la compatibilité, la taille des fichiers, le temps d'encodage et la complexité du workflow. La bonne réponse dépend entièrement des appareils de ton public, de ton budget d'hébergement et du temps que tu veux consacrer à ton pipeline vidéo. Pour la plupart des sites de petite et moyenne taille, l'approche à deux formats est un excellent compromis. Sa mise en place prend moins d'une demi-heure et commence immédiatement à économiser de la bande passante sans créer de casse-tête de compatibilité.