Baby Monitor Timmy est né d’une idée simple : un babyphone qui respecte la vie privée à la maison. Pas d’enregistrements dans le cloud, pas de circulation inutile de données hors de la chambre de bébé. Ce que beaucoup de gens ne voient pas : je développe Timmy seul, à Zurich, et GitHub Copilot est mon binôme de programmation, particulièrement rapide.
Le travail entre l’humain et l’IA
La répartition est claire : je définis les fonctionnalités, fixe les priorités et prends les décisions d’architecture. Copilot m’aide à les mettre en œuvre : écrire du code, ajouter des tests, cerner les bugs et préparer les étapes de publication.
Voici à quoi ressemble en gros un sprint type pour moi :
- Description de la fonctionnalité : Je décris ce que doit faire la fonctionnalité, y compris les cas limites et les contraintes.
- Mise en œuvre : Copilot propose du code et suit les conventions déjà en place dans le projet.
- Tests : Des tests automatisés de bout en bout s’exécutent sur deux émulateurs et vérifient la connexion réelle entre l’appareil bébé et l’appareil parent.
- Distribution : Une fois les tests réussis, les versions Android et iOS sont préparées pour les boutiques d’applications et les canaux de test appropriés.
Ce cycle se répète pour les fonctionnalités et les corrections de bugs. Je n’écris pas chaque ligne moi-même, mais je décide de ce qui est développé, pourquoi c’est développé, et si une suggestion convient à Timmy.
Du concept à WebRTC
Dès le départ, la tâche technique centrale était claire : transmettre de l’audio et de la vidéo en temps réel entre deux téléphones. WebRTC était le choix évident, mais son intégration à Flutter n’est pas simple : les candidats ICE, la négociation SDP, le relais TURN et les DataChannels doivent fonctionner ensemble dans le bon ordre.
Copilot m’a aidé à assembler ces éléments étape par étape : configurer la connexion pair à pair, respecter l’ordre critique (DataChannel avant l’offre, onTrack avant setRemoteDescription), et utiliser Firebase Firestore pour la signalisation. Chaque élément devait fonctionner sur deux émulateurs avant que je passe au suivant.
Appairage sécurisé avec ECDH
L’une des fonctionnalités les plus critiques était le système d’appairage sécurisé. Deux appareils doivent établir une confiance mutuelle sans dépendre d’un serveur central pour garantir leur identité. La solution : un échange de clés ECDH P-256 via Firebase, associé à un numéro de vérification visuel (SAS) qui détecte les attaques de l’homme du milieu.
Copilot a aidé à mettre en œuvre la chaîne cryptographique : génération des clés, échange des clés publiques, dérivation du secret partagé, calcul du SAS et chiffrement AES-256-GCM de toutes les données de signalisation ultérieures. Je n’envoie pas la clé d’appairage au backend ; seul son hachage SHA-256 sert d’identifiant de document Firestore.
Audit de sécurité : trouver et corriger les vulnérabilités
Pour moi, le développement assisté par l’IA ne consiste pas seulement à taper plus vite. Il aide aussi à traquer les bugs de façon systématique. Lors d’un sprint d’audit de sécurité ciblé, Copilot a analysé la base de code et trouvé six problèmes que je devais corriger :
- Validation des entrées manquante pour les données de signalisation
- Risque de conditions de concurrence dans la gestion des candidats ICE
- Données de session obsolètes qui n’étaient pas correctement nettoyées
- Règles de sécurité Firestore trop permissives
- Absence de prise en compte de l’épinglage de certificats
- Gestion des erreurs insuffisante dans le flux d’identifiants TURN
Les six problèmes ont été corrigés pendant le même sprint. C’est là que Copilot est efficace : lire de nombreux fichiers, comparer les schémas et signaler les endroits que je dois examiner de plus près.
Sprints itératifs : comment l’application a évolué
Timmy a grandi grâce à des sprints rapides, mais clairement cadrés. Quelques jalons :
- v1.8 : Refonte complète de l’appairage — l’association d’un code à 4 caractères et d’un échange ECDH P-256 via Firebase a remplacé l’ancienne approche par clé directe.
- v1.10 : Sprint de renforcement de la sécurité — cycle d’audit et de correction des six vulnérabilités.
- v1.11 : Mode sombre sur tous les écrans, ainsi que la page d’accueil et le blog que vous lisez en ce moment.
- v1.12 : Grande refonte de l’écran parent, mode vision nocturne et détection des mouvements par analyse des images de la caméra.
Chaque sprint suit le même schéma de base : décrire l’objectif, examiner les suggestions, tester automatiquement, puis envoyer aux testeurs.
Tests E2E sur plusieurs appareils
On ne peut pas tester correctement un babyphone sur un seul appareil. Il me faut un appareil bébé et un appareil parent. Le projet a commencé avec deux émulateurs Android exécutés simultanément et complète désormais cette boucle par des vérifications sur simulateur iOS local et sur appareils réels. Le script de test Android automatisé continue de :
- Installer l’application sur les deux émulateurs
- Effectuer l’appairage sur les deux appareils
- Vérifier que les connexions audio et vidéo sont établies
- Tester la fonction « appuyer pour parler », le contrôle de la caméra et d’autres fonctionnalités
Comme les deux émulateurs partagent la même adresse IP (10.0.2.15), une connexion directe de pair à pair via STUN est impossible. Chaque exécution de test doit passer par le relais Cloudflare TURN. C’est contraignant, mais utile : le chemin de connexion le plus complexe est testé à chaque fois.
Ce que j’ai appris
Créer une application complète avec un copilote IA m’a appris plusieurs choses :
- L’architecture compte plus que jamais. Des conventions claires et une base de code bien documentée aident l’IA à proposer un code cohérent. Les ambiguïtés deviennent vite coûteuses.
- Les tests ne sont pas négociables. Le code généré par l’IA exige la même rigueur de test que le code écrit par des humains. Les tests E2E automatisés ont détecté des problèmes faciles à manquer manuellement.
- L’humain garde la main. Chaque décision d’architecture, chaque compromis de sécurité et chaque limite du produit restent de mon ressort. L’IA accélère la mise en œuvre, mais ne remplace pas le jugement.
- La rapidité favorise la qualité. Comme les fonctionnalités sont livrées en quelques heures plutôt qu’en plusieurs jours, il reste davantage de temps pour peaufiner le produit et corriger les bugs. La rapidité n’est pas automatiquement synonyme de qualité.
La suite
Baby Monitor Timmy continue d’évoluer. La sortie de la version iOS approche ; viendront ensuite de nouvelles fonctionnalités reposant sur les capteurs et un renforcement continu de la sécurité. Le processus reste similaire : je fixe la direction et les limites, tandis que Copilot aide à mettre en œuvre et à vérifier rapidement.
Les composants importants pour la sécurité sont désormais regroupés dans des périmètres clairement définis dans le dépôt public baby-monitor-timmy-core. C’est également là que sont documentées les décisions d’architecture relatives à l’appairage, à la signalisation et aux interfaces du backend.