Trois briques, un objectif
Sous le capot, Timmy est conçu de façon plutôt pragmatique : Flutter pour l’application, WebRTC pour l’audio et la vidéo en temps réel, et Firebase pour la coordination. Je ne voulais pas créer une énorme plateforme qui fait tout passer par le cloud. Chaque élément doit en savoir le moins possible tout en fonctionnant de manière fiable avec les autres.
WebRTC : connexion directe, chiffrée par défaut
WebRTC (Web Real-Time Communication) transporte l’audio et la vidéo entre l’appareil bébé et l’appareil parent. Dans le meilleur des cas, les données circulent directement entre les deux appareils, de pair à pair, sans serveur multimédia intermédiaire.
Chaque connexion WebRTC utilise DTLS-SRTP par défaut. Si quelqu’un intercepte des paquets réseau, il n’obtient ni audio ni vidéo lisibles. Ce chiffrement fait partie du protocole et ne peut pas être simplement désactivé dans WebRTC.
C’était le point essentiel pour moi : les flux audio et vidéo de la chambre de bébé n’ont rien à faire sur mon serveur. Ils restent entre vos appareils.
Signalisation via Firebase Firestore
Avant que WebRTC puisse démarrer, les appareils doivent se trouver et négocier la façon dont ils vont se connecter. Cette étape s’appelle la signalisation. Timmy utilise Firebase Firestore, la base de données cloud de Google, pour cela.
Seules des données techniques de connexion sont échangées :
- Offres et réponses SDP : Elles décrivent les capacités des appareils (codecs pris en charge, résolutions, etc.).
- Candidats ICE : Les chemins réseau possibles par lesquels les appareils peuvent se joindre.
L’audio et la vidéo n’arrivent pas dans Firebase. Firestore ne transporte que les données techniques de connexion. Timmy chiffre aussi cette couche de signalisation, afin que Firestore ne devienne pas un point de rencontre en clair pour SDP et ICE.
Serveurs TURN : quand la connexion directe ne fonctionne pas
Certains réseaux bloquent les connexions directes, par exemple les pare-feu stricts ou certains opérateurs mobiles. WebRTC a alors besoin d’un relais TURN (Traversal Using Relays around NAT).
Timmy essaie d’abord le serveur TURN local et utilise Cloudflare comme solution de secours lorsque le relais local n’est pas disponible ou est surchargé. Le relais transmet des paquets chiffrés. Il ne dispose pas des clés permettant de déchiffrer l’audio ou la vidéo ; le chiffrement WebRTC reste intact.
Les identifiants d’accès TURN proviennent d’une fonction Firebase Cloud Function et ne sont valables que 24 heures. Des identifiants d’accès permanents dans une application de babyphone seraient trop risqués à mon goût.
Connexions à proximité : les appareils se trouvent automatiquement
Pour éviter des étapes de configuration pénibles entre l’appareil bébé et l’appareil parent, Timmy utilise Nearby Connections. Google fournit cette couche de découverte via Bluetooth et Wi‑Fi.
L’appairage automatique dans Timmy fonctionne sans saisie manuelle de code : les appareils se détectent et trouvent le même point de rendez-vous pour l’échange de clés. Si cela échoue, vous pouvez saisir un code à 4 caractères. Le code d’appairage ne quitte jamais l’appareil ; Firestore ne voit qu’une empreinte cryptographique (SHA-256) comme identifiant du document.
Authentification anonyme
Timmy utilise l’authentification anonyme de Firebase. Au premier lancement, chaque appareil reçoit un identifiant temporaire et anonyme. Il n’y a pas de compte, pas d’adresse e-mail ni de mot de passe. Cet identifiant sert uniquement à appliquer les règles Firestore : seuls les appareils authentifiés peuvent lire ou écrire les données de session.
L’architecture : qui envoie, qui reçoit
Timmy propose deux modes :
- Mode bébé (émetteur) : L’appareil capte l’audio via le microphone et l’envoie à l’appareil parent via WebRTC. Vous pouvez aussi activer la caméra ; la vidéo est alors elle aussi envoyée directement.
- Mode parent (récepteur) : L’appareil reçoit l’audio et la vidéo, affiche le flux de la caméra et propose une fonction « Appuyer pour parler » permettant d’envoyer de courts messages vocaux à l’appareil bébé.
Les commandes comme « Appuyer pour parler » et l’activation ou la désactivation de la caméra utilisent un DataChannel, un autre canal WebRTC qui envoie directement de petits messages chiffrés entre les appareils.
Pourquoi Flutter ?
Flutter est le framework de Google pour créer des applications sur plusieurs plateformes. Pour Timmy, cela signifie que je peux écrire une grande partie de la logique une seule fois et l’utiliser sur Android et iOS. Timmy est disponible sur Android, et la version iOS est presque prête à sortir. Moins de code dupliqué, c’est moins d’endroits où des bugs peuvent se glisser.
En résumé
La règle technique est simple : Timmy ne doit utiliser que les données dont il a réellement besoin. WebRTC protège les médias, Firebase coordonne la mise en place de la connexion, TURN ne voit que des paquets chiffrés et Nearby Connections simplifie l’appairage.
Une bonne technologie se fait un peu oublier au quotidien. Elle fonctionne sans transformer la chambre de bébé en projet cloud.