Ajouter de la vidéo à son application : construire ou acheter ?

Vous avez un produit, un intranet ou un outil métier, et la vidéo doit y entrer. Un tutoriel dans l'application, les rediffusions d'un séminaire interne, les démonstrations dans un espace client. La demande arrive rarement comme un projet : elle arrive comme une ligne de plus dans une liste.

Puis quelqu'un ouvre le sujet, et la ligne devient un chantier. Parce qu'entre un fichier vidéo et une vidéo qui se lit correctement chez tout le monde, il y a une chaîne technique entière que personne n'avait chiffrée.

Cet article détaille cette chaîne, brique par brique, dit ce que chacune coûte à maintenir, et donne les trois options possibles avec le profil auquel elles conviennent. Il est écrit pour les responsables techniques et les équipes produit qui doivent arbitrer entre construire et acheter.

Ce que « ajouter de la vidéo » veut vraiment dire

La vidéo en ligne ne repose pas sur des balises <video> pointant vers des fichiers posés sur un serveur. Elle repose sur une infrastructure spécialisée, et voici ce qu'elle contient.

Un fichier source n'est pas lisible tel quel

Le fichier qui sort d'une caméra ou d'un logiciel de montage pèse lourd et n'a qu'une seule qualité. Servi à un spectateur en 4G, il se met en pause toutes les dix secondes. Servi à un spectateur en fibre, il se lit très bien, mais vous avez payé le transfert d'un fichier surdimensionné.

La réponse du métier est l'encodage adaptatif : le fichier est réencodé en plusieurs résolutions, découpé en segments de quelques secondes, et le lecteur change de qualité en cours de route selon la connexion. Chez Streamfizz, cela donne quatre résolutions générées automatiquement, du 360p au 1080p, des segments de 3 secondes et deux pistes audio.

Construire cette étape, c'est faire tourner une flotte de machines d'encodage, gérer une file d'attente, définir les paramètres de chaque résolution, et surveiller les échecs. C'est aussi le poste le plus coûteux en calcul : notre orchestrateur utilise des GPU pour cette raison, avec un gain de 10 à 50 fois sur le temps d'encodage par rapport au processeur.

Servir un fichier n'est pas le diffuser

Une fois la vidéo encodée, il faut la livrer. Depuis un seul serveur, la lecture est correcte pour les personnes qui en sont géographiquement proches, et médiocre pour les autres. Un réseau de distribution rapproche les segments du spectateur, et c'est ce qui fait la différence entre une vidéo qui démarre en une seconde et une vidéo qu'on abandonne.

C'est aussi une décision de souveraineté, souvent prise sans être vue. Le réseau de distribution que vous choisissez détermine où transitent vos contenus et à quelle juridiction ils sont soumis. Nos vidéos sont servies en CMAF et HLS par un réseau de distribution européen, et hébergées en France.

Un lecteur n'est pas une balise vidéo

Le lecteur natif du navigateur ne sait pas lire un flux adaptatif sans aide. Il faut une bibliothèque de lecture, et ensuite tout ce qu'un spectateur considère comme normal : reprise de lecture, sous-titres, chapitres, miniatures au survol de la barre de progression, mode théâtre, image dans l'image, reconnexion automatique en direct.

Nous avons fait le choix de développer le nôtre, sur Media Chrome et hls.js. Ce n'est pas un choix évident et il a un coût, que nous avons raconté en détail. Il se justifie quand le lecteur est le point de contact principal avec vos utilisateurs.

Et le reste, qui n'est pas optionnel

Trois briques passent souvent à la trappe dans les estimations initiales.

• Le contrôle des accès. Qui a le droit de voir cette vidéo, et comment on l'empêche d'être rejouée ailleurs. Cela va du mot de passe au verrouillage par domaine, en passant par la restriction par adresse IP.
• L'accessibilité. Les sous-titres ne sont plus un supplément. Les produire, les corriger, les convertir entre SRT et VTT, les traduire : c'est une chaîne à part entière. La nôtre transcrit dans plus de 100 langues et traduit les sous-titres en 27.
• La mesure. Savoir combien de personnes ont regardé, combien de temps, et à quel moment elles décrochent. Sans cela, vous ne saurez jamais si la vidéo sert à quelque chose.

Ce que ça coûte, une fois que c'est construit

Chacune de ces briques se construit. Une équipe compétente assemble un premier pipeline de transcodage en quelques semaines, et il fonctionnera.

Le coût réel n'est pas là. Il est dans ce qui vient après :

• Les formats d'entrée changent. Un fichier issu d'un téléphone récent, un codec inattendu, une piste audio absente : chaque cas casse le pipeline une première fois.
• Les navigateurs évoluent. Une politique de lecture automatique qui change, un comportement différent sur iOS, une régression sur une version majeure.
• Le volume monte. Ce qui marchait pour 50 vidéos par mois se comporte différemment à 500, et la file d'attente devient un sujet.
• Personne ne veut en hériter. C'est le point le plus sous-estimé : une brique vidéo interne finit par n'être comprise que par la personne qui l'a écrite.

Aucun de ces points n'est un argument contre la construction. Ce sont des arguments pour la chiffrer honnêtement, y compris sur trois ans.

Trois options, trois profils

Tout construire. Vous prenez le stockage objet, un encodeur, une bibliothèque de lecture open source, et vous assemblez. C'est le bon choix quand la vidéo est le produit lui-même et que la maîtrise de chaque étape est un avantage concurrentiel.

Assembler des briques cloud. Vous prenez un service d'encodage, un service de distribution, un lecteur du marché, et vous gérez la couture entre les trois. C'est souple, et c'est là que la facture surprend le plus souvent, parce qu'elle se compose de trois lignes qui grossissent séparément.

Une plateforme avec une API. Vous appelez un service qui a déjà fait ces choix, et vous gardez votre temps d'équipe pour ce qui vous distingue. C'est le bon choix quand la vidéo est un moyen et non le produit.

Ce qui change quand la vidéo s'appelle depuis vos outils

Une plateforme vidéo pilotée à la main a une limite pratique : quelqu'un doit ouvrir une interface. Or les gestes de la vidéo ont presque toujours déjà eu lieu ailleurs. La session de formation existe dans votre outil de formation. Le webinaire est déjà dans votre agenda. Le nouveau collaborateur est déjà dans votre système de gestion.

C'est ce que change une API : ces gestes se déclenchent depuis vos propres applications. Envoyer un fichier, créer un direct, publier, ouvrir un accès à un groupe. La vidéo cesse d'être un projet à côté et devient une fonctionnalité de vos outils.

Le mouvement inverse compte tout autant. Les chiffres d'audience d'une vidéo, d'un direct, d'une playlist ou d'une WebTV se récupèrent par une requête et alimentent vos propres tableaux de bord : lectures, spectateurs uniques, répartition par pays et par type d'appareil, sur une fenêtre allant jusqu'à 24 mois. Vous n'avez plus à ouvrir une interface pour savoir si un contenu a été vu, ni à recoller un export à la main.

Notre API GraphQL est celle qui fait tourner la plateforme au quotidien : chaque action de notre back-office passe par ces méthodes. Vous ne construisez pas sur une façade créée pour l'occasion. Nous avons raconté ce chantier, ses arbitrages et ce qu'il a coûté dans un article dédié.

Les tâches ingrates suivent le même chemin. Lancer la transcription d'une vidéo, demander la traduction de ses sous-titres, importer une liste de chapitres depuis un fichier CSV, ou pointer un chapitre en direct pendant qu'on diffuse : ce sont des appels, pas des allers-retours dans une interface.

Une précision utile, parce qu'elle revient souvent en discussion : il n'existe pas de connecteur prêt à l'emploi ni de plugin à installer. L'intégration s'écrit, en appels à l'API depuis votre application, et le lecteur s'embarque en iframe sur votre site à vos couleurs. C'est plus de travail qu'un plugin, et beaucoup moins qu'une chaîne vidéo complète.

Quand construire reste le bon choix

Il y a des cas où externaliser serait une erreur, et il vaut mieux les nommer.

Si la vidéo est votre produit, si votre valeur tient à un traitement d'image, à une latence particulière ou à un format que personne ne propose, alors la chaîne technique n'est pas un coût : c'est votre métier. La sous-traiter revient à sous-traiter ce qui vous distingue.

Si vos volumes sont très faibles et vos besoins simples, une poignée de vidéos publiques déposées chez un hébergeur généraliste peut suffire longtemps. Vous n'avez pas besoin d'une plateforme pour cela.

Enfin, si vous avez déjà construit et que cela fonctionne, la question n'est pas de tout refaire. Elle est de savoir laquelle de vos briques vous coûte le plus cher à maintenir, et si celle-là mérite d'être remplacée.

FAQ

Combien de temps faut-il pour intégrer une plateforme vidéo par API ?

Cela dépend du périmètre. Un premier envoi de fichier depuis votre application se fait en quelques heures. Un parcours complet, avec création de direct, gestion des accès et affichage du lecteur dans votre interface, se compte plutôt en jours de développement. La documentation générée depuis le schéma GraphQL réduit fortement le temps d'exploration, puisqu'elle décrit exactement ce que l'API accepte et renvoie.

Peut-on envoyer de gros fichiers directement depuis son application ?

Oui. L'envoi simple couvre les fichiers courants, et l'envoi en plusieurs parties permet de monter jusqu'à 100 Go par fichier. C'est le mode à utiliser dès que vos sources sont des masters de captation ou des enregistrements longs.

Faut-il un plugin pour brancher la vidéo sur son CMS ou son intranet ?

Non, et il n'en existe pas chez nous. L'intégration passe par des appels à l'API depuis votre application, quel que soit le langage, et par l'intégration iframe du lecteur pour la diffusion. Cette intégration fonctionne sur n'importe quel site, intranet ou système de gestion de contenu, puisqu'elle ne dépend d'aucun module à installer.

Peut-on récupérer les statistiques d'audience automatiquement ?

Oui. Une requête par objet renvoie les statistiques d'un média, d'un direct, d'une playlist ou d'une WebTV : impressions, lectures, spectateurs uniques, répartition géographique, navigateurs et types d'appareils. La fenêtre interrogée peut aller jusqu'à 24 mois. C'est ce qui permet d'afficher l'audience d'une vidéo directement dans votre application, plutôt que de demander un export à quelqu'un.

Que se passe-t-il si l'on veut partir plus tard ?

C'est une question à poser avant de choisir, pas après. Vos fichiers sources restent les vôtres et sont récupérables, et vos contenus sont portables. C'est aussi pour cela que l'hébergement compte : des vidéos stockées en France, hors du champ du Cloud Act, ne posent pas les mêmes questions juridiques que des vidéos hébergées ailleurs.

Et pour la diffusion en direct ?

Le direct suit la même logique, avec deux différences. Il se prépare à l'avance, puisqu'il faut récupérer les coordonnées d'ingestion et les renseigner dans votre encodeur, en RTMP ou en SRT. Et il n'a pas droit à l'erreur, puisqu'il n'y a pas de reprise possible. Notre moteur, construit en interne sur nos serveurs en France, diffuse avec une latence moyenne de 6 à 8 secondes.

Conclusion

La bonne question n'est pas « sait-on faire ». Une équipe compétente sait faire. La question est de savoir combien de briques vous voulez porter dans la durée, et si ces briques vous distinguent.

Quand la vidéo est un moyen au service de votre produit, l'assembler soi-même revient à investir du temps d'équipe dans un problème déjà résolu ailleurs. Quand elle est le produit, c'est exactement l'inverse.

Pour voir ce que couvre l'API et ce qu'elle permet de piloter, la page API et développeurs en donne le détail, et l'hébergement vidéo décrit ce qui tourne derrière.