IA locale : un bloqueur d’écran qui vous fait sortir
Découvrez comment une IA locale transforme une limite d’écran en pause dehors, sans cloud ni API payante. Analyse du fonctionnement, des choix et des limites.
Une limite d'écran sans bouton « ignorer » : quand l'IA locale vous pousse à sortir
Les applis de contrôle du temps d'écran ont souvent un talon d'Achille : elles finissent par vous laisser un bouton pour repousser la limite. Et une fois que l'habitude est prise, ce bouton devient la sortie de secours par défaut. La règle est là... mais elle se défait en un clic.
Le projet Outside Leash attaque le problème à l'envers. Après environ 20 minutes passées sur YouTube, Reddit ou d'autres réseaux sociaux, une extension Chrome bloque l'onglet et affiche une petite mission à accomplir dehors. Pour retrouver l'accès, il faut envoyer depuis son téléphone une photo correspondant à la mission. Ensuite, Gemma 4 E2B vérifie l'image sur l'ordinateur, sans transmettre les photos à un service cloud.
Le but n'est pas de « soigner » une dépendance, ni de rendre le contournement impossible à quelqu'un de déterminé. C'est plus simple, et plus ciblé : créer une friction, forcer une pause réelle, et rendre le retour aux sites moins automatique. Voici comment le système marche, les choix techniques qui le rendent possible, et ce qu'il ne peut pas garantir.
Pourquoi supprimer le bouton de report change le mécanisme
Une limite de temps repose toujours sur deux choses : une règle et la capacité (ou l'envie) de s'y tenir. Quand l'interface propose « ignorer pour aujourd'hui », la règle se retrouve en concurrence directe avec la routine que l'on essaie justement de casser. Ce n'est pas forcément un mauvais design : certaines personnes ont besoin de flexibilité. Mais pour celles qui repoussent systématiquement, la flexibilité finit par vider la règle de son intérêt.
Le créateur d'Outside Leash part d'un constat personnel : les applications qu'il avait testées lui permettaient de contourner la restriction en un geste. Il a donc construit un système sans option de report immédiat : après un quota quotidien, l'onglet bascule vers une page de mission. Pour récupérer l'accès, il faut faire quelque chose d'autre.
La mission reste volontairement simple. Par exemple : repérer un objet d'une couleur inhabituelle dehors et le photographier. Une fois la photo envoyée depuis le téléphone, le modèle vérifie si elle correspond à la consigne. Si c'est validé, l'accès revient pour 30 minutes, et l'ordinateur renvoie l'onglet à la page précédente.
La friction est le cœur du mécanisme
Le projet n'est pas là pour prouver que l'IA est « meilleure » ou plus sophistiquée. Il vise surtout à casser une boucle très automatique : consultation, dépassement du temps prévu, puis clic sur « encore cinq minutes ». À la place, l'utilisateur doit s'arrêter, prendre son téléphone et changer d'environnement.
Cette friction n'a pas besoin d'être infaillible. Elle doit juste être assez pénible pour casser l'automatisme. C'est un choix pragmatique : l'idée n'est pas de rendre l'accès impossible, mais de rendre le contournement moins immédiat.
À ce stade, il faut séparer trois objectifs qu'on confond souvent : mesurer le temps d'usage, limiter l'accès techniquement, et aider à modifier une habitude. Outside Leash s'occupe du premier (au moins en partie) et rend le deuxième moins fluide. Il ne fait pas (à lui seul) le troisième. D'ailleurs, l'utilisateur peut désactiver l'extension, arrêter le serveur, ou choisir de ne pas suivre la mission.
Un outil personnel, pas un produit de contrôle parental
Cette nuance compte. Le projet se présente comme un outil personnel, construit pour son auteur dans le cadre du défi Open Source AI de Hacktoberfest, sur le thème « Touch Grass ». Rien dans la façon dont le projet est présenté ne le met clairement du côté d'une solution validée pour des familles, des entreprises, ou des personnes confrontées à un trouble lié aux écrans.
Dans un contexte pro, la même logique poserait d'autres questions : qui décide des sites bloqués, qui contrôle les données, que faire si un site est nécessaire au travail, et comment récupérer l'accès en cas d'urgence. Une contrainte pensée pour un usage volontaire sur son propre ordinateur ne se transpose pas automatiquement à un dispositif imposé.
Comment fonctionne le système, de l'onglet à la photo
L'ensemble est volontairement simple côté architecture : une extension Chrome, un petit serveur Python lancé sur l'ordinateur, et Gemma 4 E2B exécuté localement avec Ollama. Le téléphone sert à prendre (ou sélectionner) la photo et à l'envoyer au serveur via le réseau Wi‑Fi local.
Le flux se résume à quelques étapes :
- L'extension surveille l'onglet actif et comptabilise le temps passé sur un site concerné.
- Une fois le quota quotidien atteint, elle redirige l'onglet vers la page de mission servie par l'ordinateur.
- L'utilisateur ouvre l'adresse affichée sur son téléphone et envoie une photo récente.
- Le serveur interroge le modèle local : l'image correspond-elle à la consigne ?
- Si c'est validé, le serveur autorise 30 minutes de plus et l'onglet revient à sa page précédente.
Le temps est compté sur l'onglet consulté
L'extension vérifie son état toutes les 30 secondes. Elle n'ajoute du temps que lorsque l'onglet ouvert correspond à un site bloqué, et elle conserve un total quotidien. Ce détail évite de compter indistinctement tout le temps pendant lequel Chrome reste ouvert.
Cette vérification « toutes les 30 secondes » est un compromis facile à mettre en œuvre. Le système n'a pas besoin d'une précision au seconde près : il s'agit de plafonner l'usage, pas de produire un relevé certifié. Le projet ne liste pas tous les cas particuliers possibles (plusieurs fenêtres, changement de jour, synchronisation entre appareils, etc.), et il serait faux de supposer que tout est parfaitement géré.
Quand le quota est dépassé, l'extension demande au serveur local si une mission a déjà été validée récemment. Sinon, elle envoie l'onglet vers la page de mission tout en conservant l'adresse de départ. Après validation, le retour à la page précédente rend l'expérience moins « punitive » : on retrouve son contexte.
Téléphone séparé de l'ordinateur
La mission demande une photo faite avec le téléphone, mais l'image est ensuite envoyée à un serveur qui tourne sur l'ordinateur. Téléphone et ordinateur communiquent sur le réseau local. Le créateur indique qu'il n'y a pas d'appel vers un service externe, pas de clé d'API, pas d'infrastructure cloud.
Le serveur refuse aussi les téléversements provenant de l'ordinateur lui-même. L'idée est d'empêcher de finir la mission directement depuis la même machine (dans le fonctionnement prévu). Ce n'est pas une barrière magique contre un utilisateur qui modifierait le code ou contournerait la logique : c'est surtout un garde-fou cohérent avec l'objectif d'introduire une action « physique ».
Autre point : la photo doit être récente. L'interface rejette les fichiers dont la date de modification dépasse dix minutes. C'est une façon simple de décourager l'envoi d'une ancienne image, mais ce contrôle s'appuie sur une métadonnée de fichier. Ce n'est pas une preuve robuste de lieu ou de moment de prise de vue.
Les choix d'IA : local, rapide et volontairement limité
Côté IA, la tâche est très cadrée : regarder une image et dire si le contenu correspond à une consigne courte. Le modèle ne gère pas le quota, ne décide pas quels sites sont bloqués, et ne contrôle pas le comportement de la personne. En séparant ces rôles, le système réduit aussi le nombre de décisions confiées au modèle, et il devient plus facile d'expliquer le fonctionnement.
Le créateur a d'abord testé Qwen3‑VL 2B. D'après ses mesures, l'analyse prenait environ 47 secondes par photo. Avec Gemma 4 E2B, il observait plutôt ~31 secondes au départ, notamment parce que le modèle produisait son raisonnement avant de répondre. En désactivant ce mode et en limitant la sortie à dix jetons, le temps de vérification est tombé à environ 3,4 secondes sur sa configuration.
Ces chiffres reflètent ses essais, pas une garantie de performance sur n'importe quelle machine. Il a testé sur un ordinateur portable avec 16 Go de RAM et sans carte graphique dédiée. Les résultats varient selon le matériel, les versions des modèles, et les paramètres. Mais l'idée générale reste la même : le réglage d'inférence peut compter autant que le modèle choisi, dès qu'on veut une réponse rapide.
Mission séparée de sa vérification
Au début, le projet demandait au modèle d'inventer la mission et de formuler la question de vérification. Les résultats étaient inégaux : parfois, le modèle proposait des variantes autour des feuilles, ou une vérification trop vague (par exemple demander si l'image était « claire »).
Par la suite, le projet a séparé clairement les rôles. Le code choisit un thème et prépare la question de vérification à l'avance ; le modèle reformule seulement la mission pour lui donner un ton plus naturel. Résultat : la consigne peut rester engageante, sans changer en même temps que le critère de validation.
C'est une décision assez simple, mais elle change vraiment la donne. Si un modèle génère à la fois la mission et son barème, il peut produire une mission difficile avec une validation permissive, ou l'inverse. En gardant la règle de validation dans le code, le concepteur réduit cette variabilité : la mission reste la même jusqu'à sa réussite, et on évite aussi qu'un simple rafraîchissement de page rende la mission plus facile.
Pourquoi exécuter localement
Dans ce cas précis, traiter localement apporte trois avantages assez concrets :
- Confidentialité maîtrisée : les photos restent, d'après l'architecture décrite, sur l'ordinateur.
- Coût prévisible : pas de facturation « par image ». Si la vérification se déclenche souvent, c'est un point non négligeable.
- Facilité de test : changer de modèle revient surtout à modifier la configuration, plutôt qu'à reconstruire toute l'application.
Cela dit, le local n'est pas automatiquement le meilleur choix. Il faut une machine assez puissante, installer et maintenir le modèle, et accepter des performances parfois moins bonnes qu'un service distant. Le créateur n'a pas comparé explicitement le projet à un modèle de vision hébergé : il ne prétend donc pas que le distant serait inférieur. Un service distant pourrait, par exemple, mieux repérer certaines tentatives de fraude, au prix de transferts de données et de coûts d'exploitation.
Pour explorer le projet, le code est disponible dans le dépôt Outside Leash sur GitHub. Les infos sur le modèle et son exécution locale se trouvent aussi dans la documentation actuelle d'Ollama, car les versions et la disponibilité des modèles évoluent.
Les limites à connaître avant de reproduire l'approche
Le projet est assez clair sur un point : il ne prétend pas avoir une mesure d'exactitude « établie ». Les essais reposent sur un petit nombre de photos, et aucun taux de réussite chiffré n'est publié. Sans corpus de test représentatif, annoncer une précision serait une promesse non vérifiable.
Le modèle peut aussi se tromper, dans les deux sens : refuser une photo qui devrait passer, ou accepter une image qui ne satisfait pas vraiment la consigne. Le créateur a notamment observé qu'une fleur rose pouvait être validée alors que la formulation parlait d'un objet ancien. Il a donc réécrit certaines questions pour qu'elles portent davantage sur le sujet principal de l'image.
Faux positifs et faux négatifs : pas le même impact
Dans ce type de dispositif, toutes les erreurs n'ont pas le même coût. Si le modèle accepte une image qui ne correspond pas, la barrière devient moins efficace. S'il refuse une photo correcte, il bloque l'utilisateur alors qu'il a fait ce qui était demandé.
Le créateur a aussi testé une vérification supplémentaire visant à repérer les captures d'écran. Problème : la question sur l'écran perturbait aussi l'acceptation de photos légitimes, et un contrôle séparé rejetait parfois de vraies photos tout en laissant passer une tentative de fraude. Il a finalement décidé de ne pas ajouter ce contrôle : dans son usage personnel, exclure une photo réelle lui semblait pire que laisser passer occasionnellement une image détournée.
C'est une bonne illustration : « ajouter un contrôle » ne rend pas automatiquement un système meilleur. Une nouvelle règle peut réduire un type de fraude, tout en augmentant les refus injustifiés. Il faut donc décider, selon le contexte, quel type d'erreur est le plus coûteux... puis tester l'hypothèse avec plus que quelques exemples.
Une mission dehors, que le logiciel ne peut pas garantir
Le système vérifie le contenu visible sur la photo, pas l'endroit exact où elle a été prise. Le créateur a pu valider une mission de couleur avec un tissu rose photographié chez lui : la sortie dehors fait partie de l'intention de la mission, mais la localisation n'est pas réellement contrôlée.
Une photographie d'écran peut aussi tromper le modèle. Et si l'utilisateur désactive l'extension ou arrête le serveur, la limite s'arrête. Le dispositif dépend donc de plusieurs éléments actifs... et d'une certaine coopération volontaire.
Pour tout ça, Outside Leash ressemble davantage à un ralentisseur qu'à un verrou. Ce n'est pas un défaut à masquer : c'est une façon fidèle de décrire le niveau de menace réel. Si l'objectif est de protéger un service sensible, d'appliquer une politique à des employés, ou de contrôler un appareil qui appartient à un tiers, ce mécanisme est inadapté. En revanche, pour créer une pause personnelle, la contrainte peut suffire.
La vie privée dépend aussi du contexte. Le traitement local réduit les transmissions décrites, mais ce n'est pas une certification RGPD à elle seule. Une organisation qui reprendrait l'approche devrait documenter les données traitées, les accès, les durées de conservation et les usages prévus, puis vérifier ses obligations avec des personnes compétentes.
Conclusion : une friction utile, pas une sécurité absolue
Outside Leash est intéressant moins parce qu'il « résout » le temps d'écran, que parce qu'il fait correspondre son interface avec le problème visé : si le bouton d'exception est utilisé en permanence, supprimer l'option et ajouter une action physique peut rendre la pause plus probable. L'IA locale n'intervient que sur un point étroit : vérifier une photo. Le reste reste explicite dans les règles du système.
Les compromis sont, eux aussi, plutôt clairs : configuration locale, pas de coût par image, et meilleure maîtrise des données - contre une installation à maintenir, des performances variables selon la machine, et un contournement toujours possible. Le modèle ne vérifie pas le lieu de prise de vue, ni la « vérité » complète d'une scène.
Si vous voulez reprendre l'idée, commencez par définir ce que vous essayez vraiment d'empêcher, et ce que vous pouvez tolérer comme erreurs. Pour un usage personnel, un ralentisseur volontaire peut suffire. Pour une contrainte imposée ou un enjeu de sécurité, il faut une architecture différente et des contrôles à un autre niveau. Vous pouvez consulter le dépôt du projet, puis tester la mécanique sur votre matériel avant d'aller plus loin.