IA et TV connectée : les risques du vibe coding
Une IA peut-elle personnaliser votre téléviseur sans risque ? Retour sur un lancement webOS qui a effacé un jailbreak, et les précautions à prendre.
J'ai confié ma TV à une IA : l'application a fonctionné, mais j'ai perdu mon jailbreak
Le vibe coding promet de transformer une idée en logiciel grâce à une conversation avec une IA. Sur une TV connectée, l'idée est alléchante : remplacer une interface un peu lourde par un lanceur plus rapide, plus simple, et sans recommandations publicitaires. Sauf qu'une commande « inoffensive » peut aussi toucher à un système déjà modifié.
C'est ce qui m'est arrivé lors d'un essai sur un téléviseur LG sous webOS. Claude a d'abord examiné le code du projet, puis a demandé l'activation du mode développeur. Sur le moment, ça semblait cohérent avec l'installation. En pratique, cette étape a reconfiguré une partition et supprimé un environnement rooté qui contenait notamment Homebrew Channel et une version sans publicité de YouTube. L'application s'est bien installée, mais elle n'a pas remplacé l'écran d'accueil.
Au fond, ce cas illustre une limite assez simple des assistants de programmation : comprendre un script ne suffit pas à anticiper toutes les conséquences d'une opération sur un appareil déjà « dans un état spécial ». Voilà ce qui s'est passé, pourquoi l'erreur était évitable, et comment aborder ce genre de projet sans se laisser entraîner par l'automatisation.
Le projet : remplacer le lanceur d'une TV LG
L'objectif était clair : installer Free My TV, un lanceur open source destiné à webOS. L'interface annoncée par le projet vise quelque chose de plus épuré : moins de carrousel, moins de promotion, moins de recommandations « par défaut ». Le dépôt indique aussi qu'un assistant de programmation peut recevoir l'adresse IP du téléviseur, construire l'application et la déployer.
Sur le papier, tout est simple : un projet pensé pour une TV, un assistant qui exécute des commandes, et du temps disponible. Mais sur ce type d'appareil, le contexte matériel compte plus que la procédure « typique ».
Une vérification du code, mais pas de l'historique du téléviseur
Claude n'a pas lancé l'installation tout de suite. Il a commencé par regarder webos/install.py. D'après le compte rendu, le script :
- déverrouille une clé chiffrée avec
ssh-keygen, - se connecte au service développeur SSH de LG sur le port 9922,
- transfère un paquet
.ipk, - puis utilise le mécanisme d'installation d'applications webOS.
C'est utile : au moins, on sait ce que fait le script, et on évite de « croire » sur parole qu'il télécharge n'importe quoi. Mais l'audit du script ne répond pas à une question différente : dans quel état se trouve déjà le téléviseur ?
Lors d'un premier examen réseau, l'assistant avait repéré un service Dropbear SSH sur le port 22. Sur un appareil comme le mien, c'était un signal assez fort : le téléviseur avait déjà été rooté via Homebrew Channel. Cet environnement modifié servait depuis 2023 à installer des applications tierces, dont YouTube sans publicité. Le port avait ensuite été fermé, mais les modifications restaient présentes.
Le signal a été vu. Il n'a pas été traité comme une raison de ralentir, de demander des précisions, ou de vérifier ce que l'activation du mode développeur allait faire à cet état existant. Et c'est là que le sérieux technique ne suffit pas : l'IA a vérifié le chemin qu'elle s'apprêtait à emprunter, sans assez tenir compte des conditions de départ qui rendaient ce chemin potentiellement destructeur.
L'erreur : activer le mode développeur sans vérifier l'existant
Pour déployer Free My TV, Claude a recommandé d'activer le mode développeur officiel de LG afin d'utiliser le service SSH sur le port 9922. J'ai suivi. Le téléviseur a redémarré. Au retour, Homebrew Channel et les autres applications liées au root avaient disparu.
D'après l'analyse faite après coup, l'activation du mode développeur a réinitialisé la partition /media/developer, là où se trouvaient des éléments de l'environnement rooté. Le téléviseur n'était pas « mort » : il restait utilisable. Mais une partie de ce que j'avais mis en place ne l'était plus, et je ne pouvais pas tout remettre comme avant en une seule action.
La bonne question aurait dû venir avant la commande
Face à un indice de modification système, la réponse prudente n'était pas de poursuivre « comme si de rien n'était ». Il fallait suspendre et demander quelque chose de direct :
« Ce téléviseur a-t-il déjà été rooté ou modifié ? L'activation du mode développeur peut-elle réinitialiser des données ou effacer une partition ? »
Je connaissais mon installation, mais l'assistant ne m'a pas laissé relier le port détecté à cette configuration avant de recommander un changement. Au final, c'est une défaillance de dialogue autant qu'une erreur technique. Quand une opération peut supprimer des données, « je ne sais pas » ne doit pas se traduire par « alors on peut continuer ».
La suite a confirmé à quel point la récupération pouvait être pénible. Claude a reconnu sa responsabilité, puis a téléchargé les paquets Homebrew Channel et YouTube AdFree depuis leurs pages de versions, vérifié certains éléments et réinstallé les applications. La restauration a permis de revoir les apps. Mais elle n'a pas rétabli le root ni le mécanisme qui lui permettait de tenir dans le temps.
Le téléviseur tournait aussi sur un micrologiciel où l'exploit utilisé auparavant avait été corrigé par LG. La mise à jour avait donc rendu impossible la reproduction « simple » de l'ancien enracinement. Une fois ça, l'assistant s'est aussi heurté à des restrictions de sécurité quand il a essayé d'autres procédures. Conclusion : retrouver des applications et « revenir exactement à l'état précédent » ne sont pas la même chose.
Installer une application ne remplace pas le système
Free My TV a fini par s'installer, et l'interface affichait bien ce que montraient les démos : quelque chose de plus propre, sans les recommandations habituelles de LG. Mais après avoir appuyé sur le bouton d'accueil de la télécommande, je suis retombé sur le lanceur d'origine.
Ce n'est pas contradictoire : une application installée en mode développeur ne remplace pas forcément l'interface principale. Sans privilèges et sans mécanisme de persistance adapté, elle peut s'ouvrir quand on la lance, tout en restant « hors » de l'écran d'accueil. Dans mon cas, le projet a fonctionné - mais pas dans la direction que j'attendais.
Ça mérite d'être clair avant de commencer : est-ce que vous voulez juste tester une application, ou remplacer durablement l'interface de l'appareil ? Le premier objectif est souvent faisable avec des outils officiels. Le second dépend de privilèges, de versions précises, et donc de risques supplémentaires.
Ce que l'incident révèle sur l'assistance par IA
Ce moment ne prouve pas qu'un assistant IA est incapable d'aider à programmer. Il montre plutôt un problème classique : on mélange plusieurs compétences distinctes dans une seule « promesse ».
Un modèle peut lire un script correctement, comprendre la logique générale, et pourtant ignorer :
- le risque spécifique à l'appareil concerné,
- l'état réel du système (surtout s'il a déjà été modifié),
- l'impact concret d'une action,
- et, surtout, ce qu'on a vraiment compris avant de l'exécuter.
Dans un environnement de développement classique, installer une dépendance ou lancer un script dans un répertoire de test n'a pas forcément d'effets durables. Sur un appareil domestique déjà trafiqué, le même réflexe peut toucher une partition, effacer une config, ou supprimer des applications auxquelles vous tenez.
Une explication convaincante n'est pas une garantie
Les assistants sont très bons pour résumer du code, proposer des commandes, et accélérer des tâches répétitives. Mais leur assurance n'est ni une preuve que toutes les hypothèses sont correctes, ni une garantie que le risque a été correctement mesuré.
Et le plus frustrant, c'est que la commande la plus « coûteuse » n'est pas toujours celle qui ressemble à une bombe. Parfois, c'est une étape propre, prévue, « officielle », qui fait quelque chose de différent sur un appareil déjà personnalisé.
Trois niveaux de confiance, et aucun n'est automatique
Je résume les choses en trois niveaux :
- Le code semble compréhensible : on a examiné ce qui est visible.
- La procédure est adaptée au cas présent : versions, modifications antérieures et dépendances ont été vérifiées.
- L'action est acceptable pour vous : les conséquences possibles ont été expliquées, puis acceptées.
Valider le premier niveau ne valide pas les deux autres. Ici, le script a été examiné, donc une partie de l'incertitude a diminué. Mais la découverte du service SSH aurait dû ouvrir une enquête sur l'état rooté avant toute modification.
La réparation ne supprime pas la responsabilité
Le fait que Claude reconnaisse l'erreur et tente de restaurer des applications est, évidemment, mieux qu'un déni. Et la reconnaissance était claire : l'assistant a admis avoir repéré le port 22 sans s'arrêter pour protéger le root existant.
Mais une excuse et une récupération partielle ne rendent pas l'intervention acceptable « après coup ». Il y a eu des coûts réels : du temps perdu, un environnement fonctionnel effacé, une incertitude sur ce qui serait récupérable, et une vérification manuelle à faire pour les pistes de réparation. Dans un contexte pro, un schéma comme celui-là pourrait tourner à l'arrêt de service, voire à une perte de données plus sérieuse.
En clair : la qualité d'un assistant ne se limite pas à « produire du code » ou à « s'excuser ». Elle devrait aussi inclure la capacité à repérer les opérations réversibles, à s'arrêter quand un risque n'est pas compris, et à demander une confirmation contextualisée.
Une méthode plus sûre pour utiliser une IA sur un appareil connecté
On n'a pas besoin d'abandonner le vibe coding pour éviter ce type de mésaventure. Le but, c'est d'empêcher l'assistant de passer directement d'une demande générale à une commande exécutée sur un appareil réel.
Une approche simple : séparer analyse, plan, validation et exécution.
1. Faire l'inventaire avant de modifier quoi que ce soit
Demandez à l'assistant de démarrer par un diagnostic en lecture seule. Dites clairement que vous ne voulez ni installation, ni redémarrage, ni changements de paramètres pendant cette phase.
L'objectif : identifier le modèle, la version du système, les services actifs, les modifications connues, et les données susceptibles d'être touchées.
Et surtout : ne vous contentez pas d'un « résumé qui a l'air bien ». Si un élément est inconnu (par exemple un service SSH sur un port inhabituel), l'assistant doit expliquer plusieurs hypothèses et vous demander laquelle correspond à votre appareil. Un signal ambigu n'est pas une autorisation implicite : c'est un motif de ralentir.
2. Demander les conséquences précises de chaque étape
Avant toute commande qui modifie l'appareil, demandez une explication structurée :
- Quel composant sera modifié ?
- Quelles données ou applications peuvent être supprimées ?
- L'opération est-elle réversible ?
- Existe-t-il une sauvegarde exploitable ?
- Le résultat dépend-il d'une version du micrologiciel ou d'un accès root ?
- Quel est le scénario d'échec, et comment revenir à l'état précédent ?
Si l'assistant n'arrive pas à répondre de façon claire, le plus pragmatique est de ne pas exécuter tout de suite. Une réponse incomplète ne prouve pas forcément que c'est dangereux, mais elle indique que le risque n'est pas assez caractérisé.
3. Séparer le test de l'installation permanente
Quand c'est possible, testez d'abord sur un environnement de test, un appareil secondaire, ou une procédure qui n'écrase pas la configuration existante. Sur un téléviseur, ce n'est pas toujours évident, mais on peut quand même découper : vérifier le paquet, lire les instructions du projet, valider la compatibilité, puis installer seulement après avoir compris ce que l'application fait réellement au démarrage.
Si l'appareil est déjà modifié, documentez au minimum la version du système et les applications installées. Et une sauvegarde n'est utile que si elle couvre ce qui compte, et si sa restauration est vraiment faisable. Dire « faites une sauvegarde » ne suffit pas si l'appareil ne permet pas d'exporter la partition concernée.
4. Exiger un accord explicite pour les actions irréversibles
Une IA qui modifie un appareil devrait présenter les opérations à risque une par une, avec l'effet attendu et les effets secondaires plausibles. Vous devez pouvoir approuver chaque étape, pas seulement dire « oui » au début du chat.
Règle simple : autorisez l'assistant à lire et à proposer ; gardez la validation humaine pour les suppressions, les réinitialisations, les changements de micrologiciel, les élévations de privilèges, et tout ce qui ressemble à une opération réseau sensible. Ce découpage prend quelques minutes. Il peut aussi éviter de perdre une config construite au fil de plusieurs années.
En entreprise, le principe s'étend naturellement aux postes, aux équipements réseau et aux environnements de production. Les assistants peuvent accélérer le diagnostic, mais les contrôles d'accès, les journaux, les environnements de test et les procédures de retour arrière restent nécessaires. L'automatisation ne supprime pas le coût de l'erreur : elle peut même l'exécuter plus vite.
Conclusion : garder la main sur les opérations sensibles
Cet essai a produit deux résultats très différents : Free My TV a bien fourni un lanceur utilisable, mais j'ai perdu un environnement rooté que j'aurais dû être en mesure de protéger. L'application s'ouvrait, mais elle ne remplaçait pas l'écran d'accueil. Les applications supprimées ont été réinstallées, mais le root n'a pas été restauré.
Ce n'était ni un succès complet, ni une catastrophe totale : c'était une intervention mal cadrée, et surtout une étape sensible lancée trop tôt, sans exposer clairement ses limites avant le redémarrage.
Le vibe coding reste utile quand il accélère la mise en œuvre sans masquer les décisions importantes. Sur un appareil réel, la règle est simple : d'abord diagnostiquer, ensuite exiger une explication précise des changements, puis garder la validation humaine pour tout ce qui est irréversible. Une IA peut vous aider à avancer. Elle ne connaît pas forcément l'histoire de votre matériel - et c'est à vous de vérifier qu'elle ne l'efface pas.