À 25 minutes, le minuteur ne sonne pas.

Un bras tombe sur l’écran du Mac et ferme physiquement l’ordinateur.1

Lewis Menelaws est parti d’un problème très simple : les applications de productivité peuvent être ignorées. Une notification se balaie. Un timer se repousse d’une minute. Une extension qui bloque YouTube finit mystérieusement désactivée par la même personne qui l’avait installée avec beaucoup de conviction.

Lewis, qui dit avoir un TDAH, a donc construit une expérience volontairement absurde : deux systèmes qui rendent la procrastination plus coûteuse.1

Le premier agit sur sa réputation. Le second sur son ordinateur.

La partie intéressante arrive lorsqu’ils commencent à partager le même bouton.

Le premier robot était trop poli

À partir de 4:19 dans sa vidéo, Lewis montre le premier prototype physique.1

Le mécanisme est simple : un servo, un bras imprimé en 3D, un ESP32. Toutes les 25 minutes, le servo fait descendre le bras sur le capot du laptop.1

Ça fonctionne.

Et c’est inutile.

Lewis peut retenir le bras avec un doigt. Le servo applique une poussée programmée, prévisible, facile à contrer. Le robot ressemble moins à une contrainte qu’à quelqu’un qui vous tapote l’épaule en disant « vraiment, tu devrais faire une pause ».1

Le premier prototype finit donc sur l’étagère.

C’est un raté très utile. Le problème n’était pas de savoir fermer un ordinateur. Le problème était de produire un événement que Lewis ne puisse pas négocier mentalement au moment où il arrive.

La deuxième version remplace le moteur par de l’énergie stockée

Vers 5:50, le projet change de logique.1

Le nouveau bras est maintenu en position haute sous tension par un ressort. Un solénoïde 12 V retient le mécanisme. Quand le timer arrive à zéro, le solénoïde libère le verrou et le ressort abat le bras.1

Lewis ajoute de la mousse sur la zone de contact et teste plusieurs ressorts. Trop faible, le geste reste facile à bloquer. Trop fort, il risque surtout de transformer un problème de concentration en facture AppleCare.1

Le choix du ressort devient donc le vrai réglage du système.

Le robot utilise toujours un ESP32, se connecte au Wi-Fi et écoute aussi un webhook. Un autre logiciel peut donc déclencher le mécanisme à distance.1

Et Lewis possède précisément cet autre logiciel.

Le second robot n’a pas de corps

Au début de la vidéo, Lewis décrit un script qui surveille la fenêtre active, le temps d’inactivité et certains domaines pendant une session de travail.1

Lorsqu’il estime que Lewis procrastine suffisamment longtemps, le programme peut publier automatiquement un message pré-écrit sur un vrai compte social, sans boîte de confirmation.1

Le système est volontairement construit autour d’un coût qu’il ne peut pas annuler silencieusement.

C’est également là que le projet prend une dimension beaucoup plus intéressante pour les agents et les automatisations.

Lewis remarque qu’un bug ordinaire produit une page d’erreur. Ici, un faux positif peut publier quelque chose en public et déclencher une machine physique.1

L’erreur logicielle obtient soudain un rayon d’explosion très concret.

Il ajoute donc du logging et de l’observabilité avant de brancher le script sur son vrai compte. La vidéo contient une séquence sponsorisée autour de Sentry, donc il faut garder un peu de distance avec la démonstration commerciale. Mais le principe reste valable indépendamment du produit : plus une automatisation peut agir, plus comprendre pourquoi elle a décidé d’agir devient important.

Puis le système fait exactement ce qu’on lui demande

Lewis utilise l’ensemble pendant une journée.1

Les pauses de 25 minutes deviennent effectivement difficiles à ignorer. Le script et le bras finissent aussi par l’interrompre pendant un appel vidéo.1

Et c’est là que l’expérience devient meilleure que son pitch.

Le système n’avait pas nécessairement « buggué ». Il appliquait simplement une définition trop rigide de ce qui comptait comme travail acceptable.1

Une automatisation peut être parfaitement correcte selon sa règle et complètement stupide selon le contexte humain.

C’est un problème familier dans les agents : le vrai risque n’est pas seulement qu’un modèle échoue à suivre une instruction. C’est aussi qu’il la suive très bien alors que l’instruction était incomplète.

Lewis finit par critiquer l’idée qu’il vient de construire

À partir d’environ 8:28, le ton de la vidéo change.1

Lewis demande si rendre son bureau suffisamment pénible pour qu’il ait peur de procrastiner constitue réellement une bonne manière de devenir productif. Il dit explicitement que le projet est une expérience de divertissement et questionne l’idée que le fonctionnement de son cerveau devrait mériter une punition.1

C’est important de s’arrêter là.

Cette vidéo n’est pas une démonstration qu’un robot à ressort « traite » le TDAH. Ce n’est même pas un test sérieux d’efficacité : une personne, une journée, une machine construite précisément parce que l’idée est drôle à filmer.

Sa valeur est ailleurs.

Lewis matérialise une tension que les applications cachent généralement : toute contrainte efficace possède un coût lorsqu’elle se trompe.

Une notification est facile à ignorer parce qu’elle est sans conséquence. Un bras mécanique est difficile à ignorer précisément parce que sa conséquence existe dans le monde.

Entre les deux, il faut décider quelle quantité de pouvoir on accepte de donner au système.

Le robot le plus utile de l’expérience n’est peut-être donc pas celui qui ferme le Mac.

C’est celui qui rend impossible d’oublier qu’une automatisation, dès qu’elle obtient un corps ou un compte connecté, doit aussi apprendre quand ne rien faire.