Les webhooks dans les workflows vidéo : automatiser votre pipeline

Introduction aux webhooks

Les webhooks permettent à un système d'en notifier un autre lorsqu'un événement survient, en envoyant une requête HTTP vers une URL que vous contrôlez. Au lieu que votre application interroge sans cesse une API pour demander « la vidéo est-elle prête ? », le fournisseur pousse un message dès que l'événement se produit. Dans les workflows vidéo, c'est la colonne vertébrale de l'automatisation : la fin d'un transcodage, les événements du cycle de vie d'un direct, la disponibilité d'un enregistrement et la finalisation d'un import peuvent tous déclencher l'étape suivante de votre pipeline, sans qu'un humain surveille un tableau de bord.

Le fonctionnement est simple et cohérent d'un fournisseur à l'autre. Le serveur récepteur valide la requête (idéalement en vérifiant une signature cryptographique), répond rapidement avec un statut 2xx, puis met en file d'attente toute tâche lourde pour un traitement en arrière-plan. Tout le reste — noms d'événements, forme des payloads, comportement de renvoi — varie selon le fournisseur, raison pour laquelle comprendre le schéma compte davantage que mémoriser les champs d'un fournisseur en particulier.

Où configure-t-on les URL de webhook

La configuration est toujours propre au fournisseur. Vous enregistrez votre point de terminaison HTTPS public dans le tableau de bord ou l'API de ce fournisseur précis — service d'encodage, plateforme de direct, prestataire de paiement, etc. Le déroulé habituel : collez votre URL de rappel, choisissez les types d'événements que vous souhaitez recevoir, puis stockez en lieu sûr le secret de signature qu'ils vous délivrent. Il n'existe pas d'« écran webhooks » universel couvrant tous les fournisseurs ; vous suivez la documentation du produit précis que vous intégrez réellement, car l'emplacement exact et la terminologie diffèrent à chaque fois.

DCAST et les produits destinés aux développeurs

L'expérience créateur publique sur dcast.tv ne comporte pas de page de réglages « Webhooks » générique où ajouter des URL arbitraires pour des événements tels que « transcodage terminé » ou « direct démarré », contrairement à ce que prétendent certaines ébauches SEO obsolètes. Ne suivez pas des instructions demandant de se connecter à un tableau de bord dcast.tv et de cliquer sur une « action webhook manuelle du tableau de bord » — ce n'est pas ainsi que fonctionne le produit grand public, et recopier ces étapes ne mène qu'à la confusion.

Les intégrations partenaires et API — la documentation et l'outillage destinés aux développeurs ou aux surfaces Pro/partenaires — voilà où trouvent leur place les rappels, les événements signés et les éléments de feuille de route associés, décrits dans la documentation officielle Partner API et développeurs plutôt que dans un flux de tableau de bord grand public fictif. La règle pratique : considérez comme obsolète toute rédaction de blog promettant une interface dcast.tv précise, sauf si elle correspond à la documentation produit actuelle. Dans le doute, faites confiance à la documentation officielle plutôt qu'à un tutoriel, y compris celui-ci.

Événements de webhook courants dans les workflows vidéo

Les chaînes exactes varient selon le fournisseur, mais les catégories d'événements sont remarquablement constantes dans tout le secteur :

• Transcodage ou encodage terminé — l'asset est prêt pour la lecture ou l'étape suivante du pipeline (miniatures, sous-titrage, publication).
• Direct démarré / terminé — le cycle de vie du live, utile pour l'analytique, les notifications et le déclenchement de l'enregistrement.
• Enregistrement prêt — la version replay ou VOD d'un direct est désormais disponible.
• Import terminé — l'ingest est achevé et le fichier brut est stocké en sécurité.

Un pipeline bien conçu enchaîne ces événements : `import terminé` lance le transcodage, `transcodage terminé` déclenche la génération de miniatures et marque l'asset comme publiable, et `enregistrement prêt` avertit les abonnés qu'un replay existe. Chaque événement fait une seule chose et passe le relais au suivant.

Comprendre les payloads de webhook

Les payloads sont presque toujours au format JSON. Lisez toujours le schéma réel de votre fournisseur, car les noms de champs et l'imbrication diffèrent — l'exemple ci-dessous est générique et purement illustratif :

```json

{

"event": "transcoding_finished",

"video_id": "12345",

"status": "success",

"filename": "example_video.mp4",

"timestamp": "2023-10-05T12:00:00Z"

}

```

Deux habitudes vous épargneront de vraies déconvenues. D'abord, ne présumez jamais qu'un champ existe — vérifiez-le de manière défensive avant de l'utiliser, car les fournisseurs ajoutent et renomment des champs au fil du temps. Ensuite, traitez le payload comme une notification, pas comme la source de vérité. Pour tout élément important, servez-vous de l'ID contenu dans le payload pour récupérer l'enregistrement faisant autorité via l'API du fournisseur, plutôt que de faire aveuglément confiance au corps du webhook, car les payloads peuvent être falsifiés ou rejoués.

Traiter les webhooks avec Node.js

Mettre en place un listener simple

```javascript

const express = require('express');

const bodyParser = require('body-parser');

const app = express();

const port = 3000;

app.use(bodyParser.json());

app.post('/webhook', (req, res) => {

const payload = req.body;

console.log('Received webhook event: ' + payload.event);

res.status(200).send('Webhook received');

});

app.listen(port, () => {

console.log('Webhook server listening on port ' + port);

});

```

Exemple : aiguiller selon le type d'événement

```javascript

app.post('/webhook', (req, res) => {

const payload = req.body;

if (payload.event === 'transcoding_finished') {

console.log('Transcoding finished for video ' + payload.video_id);

}

res.status(200).send('Webhook received');

});

```

Vérifier les signatures

L'étape de sécurité la plus importante consiste à vérifier qu'une requête provient bien de votre fournisseur et n'a pas été forgée. La plupart des fournisseurs signent chaque requête avec un HMAC du corps brut de la requête à l'aide de votre secret partagé, et transmettent le résultat dans un en-tête. Votre rôle est de recalculer cette signature et de la comparer en temps constant :

```javascript

const crypto = require('crypto');

function verifySignature(rawBody, signatureHeader, secret) {

const expected = crypto

.createHmac('sha256', secret)

.update(rawBody)

.digest('hex');

// constant-time compare avoids leaking timing information

return crypto.timingSafeEqual(

Buffer.from(expected),

Buffer.from(signatureHeader)

);

}

```

Notez que la vérification de signature exige généralement le corps brut de la requête, exactement tel qu'il a été reçu. Si votre analyseur JSON a déjà re-sérialisé le corps, les octets peuvent différer et la signature ne correspondra jamais — capturez donc le corps brut avant l'analyse lorsqu'un fournisseur l'exige.

Gestion des erreurs et renvois

Implémentez l'idempotence en stockant l'ID de chaque événement traité et en ignorant les doublons, car les fournisseurs délivreront le même événement plusieurs fois lors d'incidents réseau. Ne renvoyez un statut 2xx qu'après avoir accepté l'événement en toute sécurité — généralement après l'avoir écrit dans une file d'attente durable, et non après avoir terminé le travail réel. Traitez ensuite les tâches longues de façon asynchrone afin que l'expéditeur n'expire pas. Si vous effectuez un traitement lourd en ligne et tardez trop à répondre, le fournisseur suppose un échec, renvoie l'événement, et vous finissez par traiter le même événement à répétition.

Bonnes pratiques

1. Sécurité : utilisez toujours HTTPS, vérifiez les signatures à chaque requête, et rejetez tout ce qui échoue à la validation avec un 401 ou un 403.

2. Idempotence : partez du principe que des livraisons en double surviendront et dédupliquez par ID d'événement, pour qu'un renvoi ne facture, ne publie ou ne notifie jamais deux fois.

3. Accusé de réception rapide : répondez vite avec un 2xx, puis effectuez le vrai travail dans une file d'attente en arrière-plan.

4. Supervision : journalisez chaque livraison et chaque échec, alertez en cas de pic de réponses non-2xx, et conservez une file de lettres mortes (dead-letter queue) pour les événements que vous n'avez pas pu traiter.

Tester les webhooks en local

Comme un webhook a besoin d'une URL accessible publiquement, le tester sur votre poste requiert un tunnel. Des outils comme ngrok exposent votre serveur local sur une adresse HTTPS publique temporaire, afin qu'un fournisseur puisse joindre `http://localhost:3000` en phase de développement. De nombreux fournisseurs proposent aussi un bouton « envoyer un événement de test » et un journal de livraison indiquant chaque tentative et le code de réponse que vous avez retourné — servez-vous des deux pour confirmer que votre point de terminaison valide les signatures, renvoie un 2xx rapidement et traite correctement le payload avant de vous y fier en production.

Foire aux questions

Que sont les webhooks et comment fonctionnent-ils dans les workflows vidéo ?

Les webhooks sont des rappels HTTP qu'un fournisseur envoie vers une URL que vous contrôlez lorsqu'un événement précis survient. Dans les workflows vidéo, ils notifient votre application en temps réel d'événements tels que la fin d'un transcodage, le démarrage et l'arrêt d'un direct, la finalisation d'un import et la disponibilité d'un enregistrement — vous permettant de déclencher l'étape automatisée suivante sans interrogation répétée.

Comment configurer des webhooks pour un fournisseur vidéo ?

Le processus est toujours propre au fournisseur. Vous enregistrez votre point de terminaison HTTPS public dans le tableau de bord ou l'API du fournisseur, sélectionnez les types d'événements qui vous intéressent, et stockez le secret de signature qu'il délivre. Il n'existe pas de flux universel : suivez donc la documentation du produit précis que vous intégrez. Pour dcast.tv en particulier, appuyez-vous sur les supports officiels Partner API et développeurs plutôt que de supposer l'existence d'un écran webhooks dans le tableau de bord grand public.

Quels sont les événements types qui déclenchent des webhooks dans les workflows vidéo ?

Les événements courants incluent « transcodage terminé », « direct démarré », « direct terminé », « enregistrement prêt » et « import terminé ». Les chaînes exactes varient selon le fournisseur, mais ces catégories couvrent la plupart des besoins d'automatisation.

Comment sécuriser et vérifier les payloads de webhook ?

Servez votre point de terminaison en HTTPS et vérifiez la signature cryptographique que le fournisseur envoie à chaque requête, à l'aide de votre secret partagé et d'une comparaison en temps constant. Traitez le payload comme une notification plutôt que comme la source de vérité : servez-vous des ID qu'il contient pour récupérer l'enregistrement faisant autorité via l'API du fournisseur avant d'entreprendre toute action conséquente.

Comment gérer les livraisons de webhook en double ou en échec ?

Rendez votre gestionnaire idempotent en enregistrant chaque ID d'événement traité et en ignorant les répétitions, puisque les fournisseurs renvoient l'événement à chaque réponse non-2xx ou expiration. Accusez réception rapidement avec un 2xx après avoir mis l'événement en file en toute sécurité, traitez la charge lourde de façon asynchrone, et conservez une file de lettres mortes assortie d'une supervision, afin que les livraisons en échec soient visibles et récupérables.

Conclusion

Les webhooks sont un moyen standard et fiable d'automatiser les pipelines vidéo — mais uniquement lorsque la plateforme que vous utilisez les expose réellement, et uniquement si vous les traitez de manière sécurisée et idempotente. Vérifiez le comportement par rapport à la documentation produit à jour, vérifiez les signatures à chaque requête, et ne vous fiez jamais à des étapes de tableau de bord fictives qui n'existent pas sur un produit donné. Bâtissez le schéma correctement une bonne fois, et la même rigueur se transposera à chaque fournisseur que vous intégrerez.

Étapes suivantes et ressources

• Appuyez-vous sur la documentation officielle de votre fournisseur d'encodage ou de streaming pour les types d'événements, le format des payloads et les spécificités de la vérification de signature.
• Pour DCAST, appuyez-vous sur les supports Partner API / développeurs publiés pour comprendre le périmètre d'intégration ; évitez de présumer l'existence d'une interface webhooks dans le tableau de bord grand public de dcast.tv.