Découpeur vidéo, gratuit

Découpez des fichiers vidéo en réglant le début et la fin. Mode rapide ou précis.

Vos fichiers ne quittent jamais votre appareil

Glissez-déposez un fichier vidéo ici

ou cliquez pour parcourir · MP4, WebM, MOV, AVI, MKV (max 2 Go)

Comment ça marche

  1. Chargez un fichier vidéo : sélectionnez n'importe quel fichier MP4, WebM, MOV ou AVI de votre appareil, aucun envoi vers un serveur.
  2. Réglez les points de découpe : utilisez les poignées de la timeline ou saisissez des heures précises de début et de fin pour définir le clip à conserver.
  3. Prévisualisez la découpe : lisez le segment sélectionné pour confirmer la coupe avant l'export.
  4. Téléchargez le clip : exportez la vidéo découpée directement sur votre appareil au format d'origine.

Pourquoi utiliser le découpeur vidéo ?

La plupart des applications d'édition vidéo nécessitent une installation, un abonnement ou un envoi vers des serveurs cloud. Ce découpeur basé sur le navigateur traite la vidéo entièrement sur votre appareil via WebCodecs et FFmpeg.wasm, vos images ne quittent jamais votre machine. Il est idéal pour couper rapidement des intros et des outros, isoler des clips pour les réseaux sociaux, retirer des segments indésirables d'un enregistrement et découper avant partage. Aucune perte de qualité par ré-encodage sauf si vous choisissez un format de sortie différent, et aucune limite de taille au-delà de la mémoire disponible de votre appareil.

Formats pris en charge

Couper, rogner, diviser, et pourquoi les mots importent

Dans le langage courant « rogner », « couper » et « diviser » sont interchangeables. Dans l’outillage vidéo ils décrivent trois opérations différentes. Un rognage retire du contenu au début et/ou à la fin et garde tout au milieu. Un coupe en terminologie éditoriale est la frontière entre deux plans adjacents dans un montage fini. Un division prend un clip et le divise en deux clips à un point choisi. Du point de vue de l’utilisateur, cet outil effectue un rognage, vous définissez un début et une fin, et il garde ce qui est entre les deux.

La question intéressante est comment il retire les octets indésirables. Deux approches fondamentalement différentes produisent des fichiers différents.

Fast (stream copy) vs Précis (ré-encodage)

Le stream copy, mode « Fast », ne regarde pas du tout l’image. Il ouvre le conteneur, trouve les plages d’octets correspondant à la fenêtre temporelle demandée, copie ces octets verbatim dans un nouveau conteneur, corrige l’index et les timestamps, et écrit le résultat. Pas de décodage, pas de ré-encodage, pas de perte de qualité. Sur une machine moderne un fichier H.264 de 500 Mo peut être rogné de cette façon en bien moins d’une seconde parce que le travail est essentiellement de l’E/S de fichier, pas de l’arithmétique. Le hic : l’opération de copie ne peut commencer et finir que sur certaines images, spécifiquement les I-frames : et celles-ci ne sont pas nécessairement là où vous avez pointé. Donc le début du clip résultant peut se décaler vers l’avant ou l’arrière de zéro à dix secondes, selon les réglages du codec utilisés quand le fichier a été encodé à l’origine.

Le ré-encodage, mode « Précis », décode toute la section affectée en pixels bruts, jette les images avant le début demandé et après la fin demandée, puis ré-encode le reste. Cela produit un clip qui commence et finit exactement à l’image choisie (à l’image près, en terminologie industrielle) au prix d’un encodage complet. Un encodage complet est des centaines ou milliers de fois plus lent qu’un stream copy et introduit une génération de perte de compression parce que les codecs avec perte ne sont pas idempotents : encoder, décoder et ré-encoder la même image ne vous redonne pas exactement la même image. La perte est petite à hauts débits mais elle est non nulle, et elle s’accumule si le même fichier est rogné de manière répétée.

Le chemin Fast est correct pour 95 % des cas où l’utilisateur retire intros, outros ou du matériel grossier en début ou fin et ne se soucie pas que la coupe soit à une demi-seconde de l’endroit pointé. Le chemin Précis est le bon outil quand la coupe doit atterrir sur une image spécifique, un punchline, un effet sonore, un repère de synchro pour un montage en aval.

I-frames, P-frames, B-frames, et le GOP

Chaque codec vidéo moderne (H.264, H.265 (HEVC), VP9, AV1) compresse la vidéo en exploitant le fait que les images consécutives sont presque la même image. Plutôt que d’encoder chaque image indépendamment, le codec encode une petite fraction d’images en entier et le reste comme différences par rapport à leurs voisines. Les images complètes sont les I-frames (codées intra). Les images de différence existent en deux variétés : P-frames (prédites à partir d’images antérieures seulement) et B-frames (codées bidirectionnellement, elles peuvent référencer des images antérieures et postérieures). La séquence I, puis une série de P et B frames, puis un autre I, s’appelle un Group of Pictures, ou GOP. À l’intérieur d’un GOP, aucune image ne peut être décodée sans référence à l’I-frame au début. À travers les GOPs il n’y a pas de dépendance : un lecteur peut entrer dans le fichier à n’importe quel I-frame et commencer à décoder à partir de là.

C’est pourquoi le rognage par stream copy est contraint aux limites de keyframes. Pour démarrer un nouveau fichier à une non-I-frame, il faudrait décoder l’I-frame au début du GOP, puis décoder chaque P et B frame jusqu’à votre point choisi, puis commencer à écrire, ce qui est exactement ce que le chemin Précis fait. Un fichier H.264 typique utilise une longueur de GOP de deux à quatre secondes. libx264 de FFmpeg utilise par défaut environ 250 images (~10 secondes à 25 ips, ~8,3 secondes à 30 ips). Les fournisseurs de streaming raccourcissent ça à deux secondes pour s’aligner sur les frontières de segment HLS et DASH. H.265 tolère des GOP plus longs plus efficacement et est souvent configuré à quatre à dix secondes. VP9 (libvpx) a par défaut une distance maximale entre keyframes de 240 images. AV1 atterrit typiquement dans la plage de 2-6 secondes. L’implication pratique : un utilisateur demandant une coupe à minute 1 seconde 30 peut, selon ce avec quoi le fichier a été encodé à l’origine, finir avec un résultat de stream copy qui commence n’importe où entre minute 1 seconde 24 et minute 1 seconde 32.

Une brève histoire de FFmpeg

FFmpeg a été démarré le 20 décembre 2000 par Fabrice Bellard, l’informaticien français qui avait précédemment écrit le virtualiseur QEMU et le compilateur C TCC. Il a commité sous le pseudonyme Gérard Lantau. Le nom vient de « FF » pour fast forward et « mpeg » pour la famille de codecs qu’il était à l’origine conçu pour gérer. L’architecture a depuis le début séparé l’implémentation des codecs (libavcodec) du parsing de conteneur (libavformat), c’est pourquoi FFmpeg a été si facilement étendu au fil des années. Bellard a confié la maintenance à Michael Niedermayer en 2004. Le projet a survécu à un fork célèbre en 2011 quand un groupe de développeurs s’est séparé en un projet appelé Libav suite à des désaccords de gouvernance ; les deux projets se sont re-fusionnés en esprit (sinon formellement) vers 2018, avec la plupart des améliorations de Libav remontées dans FFmpeg.

Aujourd’hui FFmpeg est l’infrastructure silencieuse sous une énorme fraction de la vidéo mondiale, YouTube, Netflix, VLC, OBS Studio, Audacity, HandBrake, Plex et la plupart des pipelines de diffusion professionnels l’utilisent quelque part dans leur stack. La version stable actuelle en 2026 est dans la série 8.x. La licence est duale LGPL-2.1-or-later ou GPL-2.0-or-later selon les composants optionnels activés à la compilation.

FFmpeg.wasm, FFmpeg dans le navigateur

En novembre 2020, un ingénieur taiwanais nommé Jerome Wu : déjà connu pour le port Tesseract.js du moteur OCR Tesseract, a publié la première version de FFmpeg.wasm, une compilation WebAssembly de FFmpeg qui tourne entièrement dans le navigateur. Il a annoncé le projet le 4 novembre 2020. En 2026 le projet a considérablement mûri, avec la version actuelle dans la série 0.12 et des forks de communauté actifs. Le paquet npm bundle maintenant le binaire WebAssembly de base, un wrapper JavaScript qui gère le passage de messages entre le thread principal et le worker thread qui exécute le WASM, et un système de fichiers virtuel qui laisse l’utilisateur déplacer des fichiers à l’aide d’objets Blob et File JavaScript ordinaires.

Le projet a une exigence notoire qui attrape chaque développeur qui tente de le déployer pour la première fois. FFmpeg.wasm utilise SharedArrayBuffer, l’API JavaScript pour partager de la mémoire entre le thread principal et les worker threads. Après la divulgation des vulnérabilités CPU Spectre et Meltdown en 2018, les navigateurs ont durci les conditions : la page doit être servie avec deux en-têtes HTTP spécifiques, Cross-Origin-Opener-Policy: same-origin et Cross-Origin-Embedder-Policy: require-corp, et chaque ressource cross-origin sur la page doit soit opter pour le CORS soit venir de la même origine. Sans ces en-têtes, SharedArrayBuffer est undefined et FFmpeg.wasm ne s’initialisera pas. Chrome applique cela strictement ; Firefox et Edge suivent Chrome ; Safari a rejoint à partir de la version 15.2.

Formats de conteneur

Un conteneur est l’enveloppe du fichier. Il n’encode pas l’image ; il emballe les images et l’audio encodés avec le timing et les métadonnées.

APIs vidéo du navigateur, ce qui est réellement disponible

L’élément HTML5 <video> est devenu une Recommandation W3C le 28 octobre 2014, après environ une décennie de développement. Avant HTML5, intégrer de la vidéo signifiait Adobe Flash ou Microsoft Silverlight. L’élément en soi n’a pas d’API d’édition, il n’y a pas de méthode video.trim(start, end), pas de video.cut(), pas de moyen intégré d’extraire un segment. Pour faire quoi que ce soit au-delà de play, pause et seek, le développeur doit se tourner vers une API de plus bas niveau ou compiler FFmpeg dans la page.

Media Source Extensions (MSE) est une spécification W3C qui laisse JavaScript construire le flux d’octets qui alimente l’élément <video>. A atteint Candidate Recommendation en 2014 ; utilisé en production par YouTube dès septembre 2013 et par Netflix à partir de juin 2014. Son cas d’usage principal est le streaming adaptatif (il n’expose pas les images décodées, donc il ne peut pas effectuer un ré-encodage seul. WebCodecs est l’alternative de plus bas niveau) expose directement à JavaScript les implémentations de codec vidéo et audio intégrées du navigateur, avec les interfaces VideoDecoder et VideoEncoder. WebCodecs a été officiellement livré dans Chrome 94 le 21 septembre 2021 après un origin trial dans Chrome 93, et a depuis atteint Firefox et Safari. L’état de l’art actuel est que les outils utilisent WebCodecs quand il est disponible et que le codec est supporté, et se rabattent sur FFmpeg.wasm sinon. Cet outil utilise les deux.

Limites de longueur des plateformes sociales, pourquoi les gens ouvrent des trimmers

Une grande partie de la demande pour le rognage basé sur navigateur vient de la préparation de vidéos pour téléversement sur plateformes sociales, chacune avec sa propre longueur maximale :

Ces chiffres bougent constamment au fur et à mesure que les plateformes itèrent, mais le motif général de « la plateforme X rejettera votre téléversement s’il dépasse Y minutes » est durable, et est une des raisons les plus courantes pour lesquelles un utilisateur final ouvre un trimmer en premier lieu.

Quand un éditeur de bureau est le meilleur outil

Pour les utilisateurs pour qui un trimmer navigateur est insuffisant, l’écosystème professionnel tourne autour de quelques applications de bureau établies. Apple ProRes est une famille de codecs intermédiaires introduite par Apple en avril 2007 aux côtés de Final Cut Studio 2, conçue pour l’édition, pas la livraison. Final Cut Pro, sorti à l’origine en 1999 par Macromedia et acquis par Apple un an plus tard, a été reconstruit et re-publié sous le nom de Final Cut Pro X le 21 juin 2011 ; macOS-seul et l’éditeur standard dans une grande partie du monde documentaire et de la diffusion. DaVinci Resolve, à l’origine un système d’étalonnage colorimétrique haut de gamme, a été acquis par Blackmagic Design en 2009 et progressivement reconstruit en une suite complète d’édition/post audio/effets visuels/étalonnage, disponible pour macOS, Windows et Linux, avec une version de base gratuite qui a changé l’économie du marché de l’édition substantiellement. Adobe Premiere Pro est le troisième acteur majeur et domine une grande partie de l’industrie du cinéma et de la TV. Aucun de ceux-ci n’est approprié pour l’utilisateur qui veut retirer les dix premières secondes d’un clip enregistré au téléphone avant de le poster sur TikTok, ce qui est exactement la lacune qu’un trimmer navigateur comble.

Pourquoi « pas de téléversement » importe ici spécifiquement

La propriété la plus importante d’un trimmer vidéo basé sur navigateur est que le fichier ne quitte pas la machine de l’utilisateur. Les données vidéo sont chargées depuis une entrée File directement dans la mémoire JavaScript, traitées par WebAssembly à l’intérieur du processus du navigateur, et le résultat est offert en téléchargement. Pas de téléversement, pas de tiers qui peut lire le fichier, pas de facture cloud qui s’échelle avec le nombre d’utilisateurs, pas de politique de rétention de données à écrire ou auditer. Pour le contenu sensible (réunions enregistrées, séquences personnelles, tout ce qui ne pourrait pas être téléversé à un tiers pour des raisons légales ou contractuelles) c’est la seule architecture qui a du sens.

L’inconvénient est que l’utilisateur paie le coût de calcul. Un trimmer qui tourne sur une ferme de serveurs peut ré-encoder un clip 4K en quelques secondes parce qu’il a accès au matériel d’encodage GPU ; la même opération dans FFmpeg.wasm tournant en logiciel sur un CPU de laptop peut prendre une minute ou deux. Le chemin Fast (stream copy) contourne largement cela en évitant l’encodage du tout, c’est pourquoi c’est le bon défaut pour presque chaque cas d’usage de rognage occasionnel. Le chemin Précis (ré-encodage) est le bon défaut seulement quand l’utilisateur a explicitement besoin de précision à l’image près au prix d’une attente.

Plus de questions

Pourquoi mon rognage Fast commence-t-il plus tôt ou plus tard que ce que j’ai demandé ?

Parce que le mode Fast (stream copy) ne peut commencer que sur une keyframe (I-frame), et la keyframe la plus proche avant votre début demandé peut être jusqu’à un GOP complet plus tôt, n’importe où entre 2 et 10 secondes selon la façon dont la source a été encodée. Si vous avez besoin de la coupe à une image spécifique, passez en mode Précis, qui ré-encode et atterrit exactement sur l’image choisie au prix d’une attente plus longue et d’une petite génération de perte de compression.

Pourquoi l’audio est-il désynchronisé après mon rognage Fast ?

Habituellement parce que le point de coupe a atterri à l’intérieur d’un GOP vidéo et l’image audio à ce timestamp ne s’aligne pas avec une keyframe vidéo. Le mode Fast décale le début vidéo à la keyframe la plus proche mais peut porter les timestamps audio inchangés, produisant un décalage. La correction standard FFmpeg est le drapeau -avoid_negative_ts make_zero, qui re-base tous les timestamps de sorte que le premier soit zéro. Si la synchro est critique, le mode Précis ré-échantillonne l’audio pour s’aligner avec le nouveau début et évite cette classe de problème.

Puis-je exporter dans un format différent de l’entrée ?

Pour la conversion de format, l’outil Video Converter est construit à cet effet et expose plus d’options. Le trimmer est optimisé pour le cas même-codec, même-conteneur (le mode Fast préserve entièrement l’encodage original) ou pour le ré-encodage vers un petit ensemble de sorties web-friendly en mode Précis. Le ré-encodage coûte toujours du temps CPU et une génération de perte de qualité ; si vous avez seulement besoin de changer le conteneur sans ré-encoder l’image, un équivalent ffmpeg -c copy est le bon outil.

Pourquoi l’entrée AVI fonctionne mais la sortie AVI non ?

AVI précède la plupart des fonctionnalités modernes de codec (les B-frames sont maladroits, la synchro audio est fragile au-delà de 4 Go, le format d’index est limité), et l’outillage moderne le traite généralement comme un format d’entrée hérité seulement. Les entrées AVI sont lues correctement ; les sorties par défaut sont MP4 ou WebM, qui sont les familles ISOBMFF/Matroska activement maintenues et se lisent dans chaque navigateur et lecteur moderne.

Outils associés

Convertisseur vidéo Créateur de GIF Vidéo → texte Découpeur audio