Comment fonctionnent les bloqueurs d'applications ?

Un bloqueur d'applications fonctionne en se plaçant entre vous et l'application que vous essayez d'ouvrir, en utilisant l'accès que le système d'exploitation lui accorde pour soit empêcher cette application de se lancer, soit lui faire coûter quelque chose avant qu'elle ne le fasse. Sur iOS, cet accès passe presque entièrement par le framework Screen Time d'Apple lui-même — les applications tierces n'ont pas le droit de tuer silencieusement d'autres processus, donc tout ce qui se présente comme un bloqueur sur iPhone n'est en réalité qu'une interface pour les mêmes App Limits et Communication Limits qu'Apple propose déjà. Sur Android, le système d'exploitation est plus permissif : une application peut demander les autorisations Accessibility Service ou Usage Access et les utiliser pour détecter quand une application bloquée passe au premier plan, puis la recouvrir immédiatement de son propre écran. Le mécanisme diffère selon la plateforme, mais l'objectif est identique — intercepter l'ouverture, et décider de ce qui se passe ensuite.

Les deux mécanismes, et pourquoi ils se comportent différemment

Sur iOS, un bloqueur tiers fonctionne généralement en demandant l'autorisation Family Controls / Screen Time, ce qui lui permet d'enregistrer une liste d'applications comme « restreintes » via le framework ManagedSettings d'Apple. Quand vous appuyez sur une application restreinte, c'est iOS lui-même — pas l'application tierce — qui intercepte le lancement et affiche un écran de blocage Screen Time, car le développeur tiers n'a en réalité jamais accès aux données ou aux processus de vos autres applications ; il peut seulement demander au système de les signaler. C'est aussi pourquoi les bloqueurs iOS se ressemblent relativement les uns aux autres dans leur comportement : ce sont tous des habillages autour du même système sous-jacent. Sur Android, un bloqueur utilise généralement l'API Accessibility Service (conçue pour les lecteurs d'écran) ou l'API Usage Stats pour surveiller quelle application est au premier plan, et lorsqu'il détecte un nom de paquet bloqué, il dessine une superposition par-dessus avant que vous puissiez interagir avec l'application en dessous. Cela donne aux bloqueurs Android plus de flexibilité — des superpositions plus riches, des parcours de déverrouillage personnalisés comme un quiz — mais aussi plus de fragilité, puisque les autorisations d'accessibilité peuvent être révoquées dans les Paramètres par la personne même que le bloqueur est censé arrêter. Cette division explique aussi une plainte fréquente concernant spécifiquement les bloqueurs iOS — le fait que beaucoup se ressemblent malgré des éditeurs différents — puisqu'ils sont tous contraints par le même ensemble limité de points d'accès qu'Apple expose, plutôt que de construire chacun un véritable mécanisme de blocage indépendant depuis zéro.

Ce qui détermine réellement si un blocage tient

La solidité de tout bloqueur d'applications se résume à une seule question : qui contrôle l'interrupteur ? Un bloqueur qui vit entièrement dans le même compte que la personne qu'il bloque — pas de code séparé, pas de second appareil, pas d'autre personne détenant la clé — est, mécaniquement, toujours réversible par cette même personne, car le système d'exploitation doit laisser les réglages propres d'une application être modifiés par quiconque utilise le téléphone. Screen Time d'Apple en est l'illustration la plus claire : configuré sans code Screen Time séparé, les App Limits peuvent être désactivées dans les Paramètres en moins de trente secondes par la personne même qu'elles sont censées restreindre. Ajoutez un code détenu par une autre personne — la configuration parent/enfant du partage familial autour de laquelle Screen Time est construit — et la mécanique ne change pas, mais la partie capable d'annuler le blocage, si, et c'est là toute la différence entre une restriction et une simple suggestion. C'est aussi pourquoi « quelle est la solidité de ce bloqueur » est une question légèrement trompeuse ; le framework sous-jacent à la plupart des bloqueurs sur une plateforme donnée est en grande partie le même. Ce qui varie, c'est ce qui se dresse entre le blocage et le tapotement qui le lèverait — rien, un compte à rebours, un code saisi, ou quelque chose qui exige un effort réel. Il faut préciser que ce n'est pas un défaut propre à une application en particulier ; c'est une propriété structurelle de tout outil conçu pour tourner sur un appareil que la même personne possède et cherche à restreindre, ce qui est vrai pour à peu près tous les bloqueurs d'applications grand public du marché, pas seulement les plus faibles.

Où la friction s'intègre dans le mécanisme

Comme le mécanisme sous-jacent de blocage ou non-blocage est largement fixé par le système d'exploitation, le choix de conception significatif que font la plupart des bloqueurs porte sur ce qui se passe au moment du déverrouillage. Un déverrouillage basé sur un minuteur (attendre cinq minutes) ajoute un délai mais aucun effort. Un déverrouillage par code saisi (récupérer un code sur un autre appareil) ajoute un petit obstacle logistique. Un déverrouillage à effort cognitif — répondre à une vraie question, faire une série de pompes vérifiées par le capteur de mouvement du téléphone — ajoute quelque chose de plus proche de l'inconfort de la tâche que l'on évite au départ, ce qui constitue un type de friction sensiblement différent de la simple attente. Aucun de ces choix ne change le fait que l'autorisation système sous-jacente puisse techniquement être révoquée ; ils changent à quel point la personne qui révoque doit le vouloir à ce moment précis, ce que les chercheurs en comportement étudiant l'usage compulsif du téléphone (parfois appelé « usage problématique du smartphone » dans la littérature académique, car il n'existe aucun diagnostic formel du DSM-5 pour l'« addiction au téléphone ») considèrent généralement comme le levier le plus pertinent plutôt que la seule solidité technique de la restriction, puisque la volonté fluctue mais qu'un coût constant, lui, ne varie pas. Il faut aussi noter que friction et restriction technique stricte ne sont pas des approches concurrentes mais se situent plutôt sur un même spectre — un Downtime programmé sans code est faible sur les deux axes, une limite protégée par un code est forte sur l'axe technique mais n'offre aucune friction si le code est connu, et un déverrouillage par quiz est relativement faible sur l'axe technique (rien n'empêche de désinstaller complètement l'application) mais fort pour exiger un engagement actif et coûteux au moment précis qui compte.

Où Mr. Grummel s'inscrit

Mr. Grummel utilise la version de ce mécanisme fondée sur l'effort : au lieu d'un minuteur ou d'un code saisi, franchir un blocage signifie répondre correctement à une vraie question de quiz. Il ne cherche pas à être un verrou technique plus solide que ce que le système d'exploitation permet — aucune application ne l'est vraiment, sans une seconde personne détenant un code — il est conçu pour élever le coût cognitif du moment où vous auriez sinon tapé directement à travers. Ce choix de conception reflète un pari précis : que pour la plupart des gens, la plupart du temps, le problème n'est pas le besoin d'un verrou techniquement infranchissable, mais le fait qu'un contournement sans coût soit trop facile à saisir.