Service vidéo P2P sur WebRTC : développement de zéro en 9 mois

# Construire un service vidéo P2P de A à Z : 9 mois de développement sur un VPS mono-cœur

En neuf mois de temps libre, un électricien d'une région isolée a créé un service vidéo P2P entièrement fonctionnel nommé « Vizavi » — sans inscription ni installation d'application requise. Construit de toutes pièces sur un VPS modeste (1 cœur, 512 Mo de RAM), il utilise WebRTC pour des connexions directes peer-to-peer et contourne les blocages. Le résultat : une solution basée sur navigateur avec un domaine russe qui continue de fonctionner même sous restrictions réseau locales.

De l'idée à la réalité : Comment « Vizavi » est né

Le projet a démarré lorsque son créateur s'est heurté à des blocages sur les services vidéo grand public et a dû chercher des alternatives. En expérimentant avec un réseau neuronal, l'idée a surgi : « Peut-on créer un appel vidéo ? » En se plongeant dans les bases de WebRTC, les serveurs STUN/TURN et les candidats ICE, l'auteur s'est immergé dans la technologie. Les premiers appels de test réussis ont lancé le développement. Une fonctionnalité phare : pas d'inscription ni d'applications — les connexions se font directement dans le navigateur via un court code numérique de salle.

L'architecture suit un modèle « salles » : les utilisateurs saisissent un numéro de salle sur https://vizavi.rf/, et le système les connecte automatiquement dès qu'il y a deux participants. Le partage du code de salle dépend des utilisateurs — via des apps de messagerie, un appel téléphonique ou même en personne. Cela maintient les barrières basses : il suffit de cliquer sur le lien et d'autoriser l'accès à la caméra/micro.

Pile technologique : Le minimalisme comme philosophie

Le service tourne sur un VPS loué dans un data center de Moscou aux specs minimales :

• 1 cœur CPU
• 512 Mo RAM
• 10 Go disque SSD (3,3 Go utilisés)
• OS Debian 11

L'infrastructure comprend :

• Coturn — serveur STUN/TURN interne pour traverser les NAT
• Node.js (serveur de signalisation) géré par PM2
• Nginx comme proxy inverse
• SSL de Let’s Encrypt avec renouvellement automatique
• UFW et Fail2Ban pour la sécurité de base
• Logique client et serveur en vanilla JavaScript
• Express pour les fichiers statiques et REST API
• Socket.io pour la signalisation WebRTC en temps réel

Le stockage de données utilise des fichiers JSON au lieu de bases de données traditionnelles. Cela s'adapte aux ressources limitées du serveur et simplifie le déploiement. Un panneau d'administration personnalisé, construit de A à Z, affiche les stats de connexions en direct et surveille l'activité en temps réel.

Types de salles : Du basique au VIP

Le système gère trois types de salles :

• Salles standard — configuration basique pour deux utilisateurs. Saisissez le même numéro, et vous êtes connectés automatiquement. Pas d'enregistrement d'appels, de journalisation d'IP ou de stockage de messages.

• Salles VIP — ajoute une hiérarchie : le propriétaire contrôle le chat, enregistre les réunions et peut expulser les invités. Les invités peuvent partager leur écran et envoyer des fichiers. Inclut une file d'attente pour connexions multiples et un tableau de messages à l'entrée.

• Salles d'observation (en développement) — comme un « babyphone » : un appareil fait office de caméra, l'autre de visionneuse. Projets pour recycler d'anciens smartphones en flux vidéo.

Un atout majeur : pas d'étapes superflues avant connexion. Contrairement aux concurrents qui exigent inscription ou pseudos, « Vizavi » connecte les utilisateurs instantanément après saisie du code de salle.

Sécurité et confidentialité : État des lieux

Le chiffrement de bout en bout est intégré à WebRTC, sécurisant les flux audio et vidéo. Cela dit, certains points restent à améliorer :

• L'historique de chat est stocké en clair dans le localStorage du navigateur
• Les messages d'entrée VIP sont sauvegardés dans des fichiers JSON non chiffrés
• Pas d'authentification pour l'accès aux salles

L'auteur précise que ce n'est pas conçu pour des données sensibles, mais sait qu'il faut renforcer la protection. Sur un VPS aux ressources limitées (512 Mo RAM), ajouter un chiffrement complet implique un équilibre entre sécurité et performances.

Leçons clés pour les développeurs

• Minimalisme architectural — JSON plutôt que bases de données et abandon des dépendances inutiles sont essentiels pour tourner sur VPS low-cost.
• Flexibilité du serveur de signalisation — Socket.io gère les signaux WebRTC sans accroc, même sous trafic intense de bots et scanners.
• Expérience utilisateur — Éviter les étapes comme l'inscription ou la saisie de nom booste l'engagement dès le départ.
• Sécurité comme processus continu — Des bases comme UFW et Fail2Ban sont indispensables pour tout projet, mais auditez régulièrement.

Le système fait face à des sondes constantes de scanners et bots, il les filtre donc : les clients non-navigateurs reçoivent une page HTML allégée sans JavaScript. Cela réduit la charge serveur et aide au SEO.

Le projet prouve que des technologies comme WebRTC sont accessibles aux devs débutants. Le succès vient d'une construction par phases, en se focalisant sur les fonctionnalités cœur, et en exploitant des outils prêts à l'emploi (Coturn, Let’s Encrypt). Prochaines étapes : chiffrement des messages et scalabilité pour plus de connexions simultanées.

— Editorial Team