- ▸ Un week-end pour comprendre un réveil
- ▸ La thèse en une ligne
- ▸ D'où vient cette idée d'instrumenter son sommeil
- ▸ Anatomie du système construit en un week-end
Un développeur a confié à une IA la conception d’un système maison pour comprendre pourquoi il se réveillait chaque nuit. Le récit, publié le 11 mai 2026 sur martin.sh, déplace la frontière entre bricolage logiciel et instrumentation de soi. Trois enseignements, trois angles morts, une méthode reproductible.
Points clés 1. Un développeur a documenté la construction d’un outil de détection des réveils nocturnes confié à une IA générative, sur un week-end de travail. 2. La démarche illustre un glissement : du « probablement pas la peine » au « pourquoi pas, donnons-y un week-end » dès que le coût marginal de prototypage tend vers zéro. 3. La méthode repose sur une boucle d’introspection : repérer un moment précis (« ce moment mérite d’être analysé »), l’instrumenter, recouper. 4. Le projet expose aussi les limites du quantified self piloté par IA : friction d’usage, fiabilité des capteurs, interprétation des corrélations. 5. L’enjeu dépasse le sommeil : il pose la question du seuil à partir duquel un problème personnel devient « buildable » par un particulier seul.
Un week-end pour comprendre un réveil
L’auteur du billet décrit un déclic banal. Réveillé sans raison apparente, il bascule dans une réflexion familière à quiconque a déjà perdu une heure à scruter son plafond. Pourquoi maintenant ? Pourquoi cette nuit-là plutôt qu’une autre ? La question s’arrête souvent là, faute d’outil pour y répondre. Ce matin-là, elle franchit un seuil. « Et si je construisais quelque chose pour comprendre ? » se demande-t-il, formule devenue rituelle chez les développeurs habitués à coder leurs propres outils.
Le récit, publié sur son blog personnel le 11 mai 2026, raconte la suite : le passage de l’idée à un prototype fonctionnel, l’arbitrage permanent entre l’effort consenti et le bénéfice attendu, et surtout le rôle de l’assistant IA comme catalyseur. L’auteur insiste sur une formule décisive : « sure, why not, let’s give it a weekend ». Ce basculement mental — du « probablement pas la peine » au « donnons-y un week-end » — constitue le vrai sujet de l’article. Et il dit quelque chose de plus large sur ce que change la génération de code assistée pour les projets dits « personnels ».
La thèse en une ligne
L’IA générative ne crée pas de nouveaux besoins logiciels. Elle abaisse le seuil de rentabilité subjective d’un projet personnel au point où des micro-outils, jadis abandonnés au stade de l’intuition, deviennent réalisables en un week-end. Le sommeil n’est ici qu’un terrain d’étude : ce qui se joue, c’est l’arbitrage cognitif entre « would be nice, not worth building » et « probablement pas la peine », dont l’équilibre vient de se déplacer.
D’où vient cette idée d’instrumenter son sommeil
Le geste n’est pas nouveau. Depuis le milieu des années 2000, le mouvement quantified self a popularisé l’idée que mesurer ses propres données — sommeil, pas, fréquence cardiaque, glycémie — permettait de mieux se comprendre. Les pionniers Gary Wolf et Kevin Kelly, fondateurs du courant au sein du magazine Wired, en ont théorisé les contours dès 2007. À l’époque, instrumenter son sommeil supposait un investissement matériel et logiciel significatif : capteurs spécialisés, scripts maison, agrégateurs de données.
La décennie suivante a vu l’industrialisation de cette pratique. Les bracelets Fitbit, Oura, puis l’Apple Watch ont démocratisé le suivi du sommeil au point de le rendre quasi-passif. Mais ces dispositifs partagent un trait commun : ils mesurent le sommeil dans son ensemble, sans tenter d’isoler la cause précise d’un réveil. Ils livrent un score, une qualité estimée, parfois une fenêtre de stade REM, mais s’arrêtent là.
Le récit publié sur martin.sh prend le contrepied de cette approche industrielle. L’auteur ne cherche pas à mesurer la qualité globale de son sommeil — il dispose déjà, comme beaucoup, de cette information via un appareil grand public. Il veut isoler un événement précis : pourquoi ce réveil-là, à cette heure-là. Le geste est analytique avant d’être quantitatif. C’est en cela qu’il rejoint la tradition du débogage informatique appliqué au soi : poser un point d’arrêt sur un événement, examiner l’état du système au moment de l’incident, formuler une hypothèse.
Cette transposition du débogage à la vie quotidienne est elle-même une tendance ancienne. Dès les années 2010, des développeurs comme Nicholas Felton — célèbre pour ses rapports annuels personnels — ou Stephen Wolfram avaient documenté leur quotidien avec une rigueur de chercheur. Wolfram lui-même publie depuis 2012 des analyses détaillées de ses propres données de frappe clavier, de courriels et de sommeil. Mais ces démarches restaient artisanales, lentes, et largement réservées à des profils techniques exceptionnellement motivés.
Ce qui change en 2026, et que le billet de martin.sh illustre, c’est le rapport entre l’envie ponctuelle et la mise en œuvre. La friction n’est plus dans le code. Elle est dans la décision.
Anatomie du système construit en un week-end
Le récit ne livre pas l’intégralité du code, mais expose la logique de construction. L’auteur commence par un constat : son appareil de suivi lui indique régulièrement, au réveil, que « votre sommeil a été difficile » — formule fidèlement rapportée dans l’article (« your sleep was rough »). Cette information arrive trop tard, et surtout trop vague. Elle ne dit ni quand, ni pourquoi.
La question initiale qu’il pose à l’assistant IA est formulée avec une retenue méthodique : « is there a small system I could build to understand this better? ». La nuance importe. Il ne demande pas une application complète, ni une solution clé en main. Il interroge la faisabilité d’un petit système. C’est précisément cette modestie d’échelle qui rend le projet réalisable dans le temps imparti.
| Critère | Approche grand public (montre, bracelet) | Approche du projet martin.sh |
|---|---|---|
| Granularité | Score global de nuit | Événement de réveil isolé |
| Hypothèse | Le score résume la qualité | La cause précise est identifiable |
| Effort initial | Achat de l’appareil | Un week-end de prototypage |
| Personnalisation | Algorithme fermé du fabricant | Logique sur-mesure |
| Données croisées | Limité à l’écosystème du fabricant | Capteurs et signaux libres |
| Maintenance | Mise à jour automatique | À la charge de l’utilisateur |
Le système combine plusieurs sources de signal. L’auteur ne détaille pas exhaustivement leur intégration, mais évoque l’idée d’instrumenter l’environnement nocturne pour détecter ce qui pourrait avoir provoqué un réveil. Bruit, mouvement, variations d’environnement : autant de candidats. L’objectif est de figer un instantané au moment où l’événement se produit, afin de pouvoir le rejouer ou l’analyser après coup. La métaphore — implicite dans le ton du billet — est celle du stack trace logiciel : capturer l’état du système au moment du crash pour comprendre l’enchaînement causal.
C’est ici que l’IA générative joue un rôle particulier. Elle n’apporte ni capteur ni donnée nouvelle. Elle réduit le coût cognitif et temporel du collage entre composants. Configurer un flux de données, parser un format obscur, écrire un script de visualisation : autant de tâches qui, prises individuellement, restaient triviales pour un développeur expérimenté, mais dont l’accumulation suffisait à dissuader le projet. L’auteur l’exprime sans détour : auparavant, c’était « too much effort for the payoff ». Le rapport effort/bénéfice basculait du mauvais côté.
L’autre élément central du récit est ce que l’on pourrait appeler la méthode du « ce moment mérite d’être étudié ». L’auteur le formule comme suit : « this moment is worth investigating ». La phrase est plus profonde qu’elle n’y paraît. Elle décrit un protocole : identifier un instant précis, le marquer comme digne d’analyse, puis instrumenter rétroactivement ou prospectivement. Ce protocole est applicable à de nombreux domaines au-delà du sommeil : pics de stress, baisses d’énergie, moments de distraction au travail. Il préfigure une logique d’introspection assistée où l’IA tient le rôle du débogueur.
Ce que ça change concrètement
L’enseignement le plus immédiat tient au déplacement du seuil de rentabilité subjective. Avant l’arrivée des assistants de codage capables de produire du code fonctionnel à partir d’une description en langage naturel, le calcul mental d’un développeur face à une idée d’outil personnel suivait une logique connue. L’auteur la résume en deux verdicts opposés : « would be nice, not worth building » d’un côté, « sure, why not, let’s give it a weekend » de l’autre. Entre les deux, une marge où l’envie existe mais où le coût décourage.
Cette marge s’est rétrécie. Pour un développeur disposant d’un assistant IA performant, le coût d’un prototype basique tombe à quelques heures. La conséquence directe : davantage de problèmes personnels franchissent le seuil du « ça vaut le coup d’essayer ». Le sommeil n’est qu’une illustration. On peut imaginer la même mécanique appliquée à la gestion d’un budget, au suivi d’une consommation énergétique, à la détection d’usages numériques compulsifs.
Pour le secteur des objets connectés grand public, l’observation est moins anodine qu’il n’y paraît. Les fabricants ont construit leur proposition de valeur sur une asymétrie : eux disposent du capteur, de l’algorithme, et du verrou logiciel. L’utilisateur consomme un score sans pouvoir creuser. Si une fraction croissante d’utilisateurs techniques se met à reconstruire des couches d’analyse personnalisées par-dessus — ou à côté — de ces écosystèmes, la pression sur l’ouverture des données ne pourra que croître.
Le secteur de la santé connectée fait face à une dynamique analogue. Les applications de suivi de sommeil grand public ont longtemps fonctionné sur un modèle prescriptif : voici ton score, voici nos recommandations. Le mouvement esquissé par le billet de martin.sh suggère un modèle complémentaire, plus exploratoire, où l’utilisateur formule ses propres hypothèses et construit ses propres outils d’investigation. La frontière entre l’utilisateur passif et l’utilisateur instrumentateur s’estompe.
Pour les développeurs eux-mêmes, l’expérience décrite illustre un changement de rapport au temps libre. Le projet du week-end, autrefois souvent abandonné en route, devient un format viable. C’est une bonne nouvelle pour la créativité technique. C’est aussi un test pour la capacité à doser : tous les problèmes ne méritent pas un outil, et la tentation de tout instrumenter peut elle-même devenir un piège.
Les contre-arguments à considérer
Le récit publié sur martin.sh est volontairement modeste sur les conclusions. L’auteur évite l’enthousiasme béat, et son ton — fait de petites phrases d’hésitation comme « probably not worth it » — traduit une lucidité utile. Il n’en demeure pas moins que plusieurs critiques peuvent être adressées à la démarche.
La première porte sur la fiabilité des inférences tirées de capteurs domestiques. Un microphone d’environnement détecte un bruit, mais ne prouve pas que ce bruit soit la cause du réveil. Un accéléromètre mesure un mouvement, mais ne distingue pas un réveil spontané d’un réveil provoqué. La corrélation temporelle entre un événement environnemental et un événement physiologique n’établit pas la causalité. C’est un travers connu de l’épidémiologie personnelle : la tentation de raconter une histoire cohérente à partir de données fragmentaires.
La deuxième critique tient au biais d’observation. À partir du moment où l’on instrumente son sommeil, on modifie potentiellement son sommeil. Le simple fait de savoir qu’un système enregistre l’environnement peut introduire une anxiété de fond, ou au contraire un faux sentiment de contrôle. Les chercheurs en sciences comportementales documentent depuis longtemps cet effet, sous le nom d’effet Hawthorne. Aucune méthode personnelle d’instrumentation n’y échappe entièrement.
La troisième critique est plus profonde. Construire un outil personnalisé répond à un besoin individuel, mais ne produit pas de connaissance partageable. À la différence d’un protocole de recherche en laboratoire du sommeil, dont les conclusions peuvent être confrontées à une cohorte, le bricolage personnel reste idiosyncrasique. Cela ne le disqualifie pas — l’auteur ne prétend pas faire de la science — mais cela invite à mesurer la valeur épistémique du résultat. Comprendre son sommeil n’équivaut pas à comprendre le sommeil.
Enfin, certains observateurs pointent un risque plus diffus : celui de la médicalisation rampante du quotidien. À mesure que chaque dimension de la vie devient instrumentable, la tentation s’accroît de tout transformer en problème à résoudre. Or beaucoup de variations — un réveil isolé, une nuit moyenne — relèvent simplement du bruit statistique inhérent à la physiologie humaine. La sur-instrumentation peut produire un excès d’interprétation, et nourrir une vigilance contre-productive.
À ces critiques, les défenseurs de l’approche répondent que l’enjeu n’est pas de remplacer la médecine du sommeil, mais de combler un angle mort. Entre l’absence totale d’information et la consultation d’un spécialiste — démarche lourde, coûteuse, souvent réservée aux cas chroniques — il existe une zone intermédiaire où l’auto-observation outillée peut générer des hypothèses utiles. Le système construit en un week-end ne remplace pas une polysomnographie. Il sert d’antichambre.
Et maintenant : trois directions pour les prochains mois
Le récit de martin.sh n’est pas un cas isolé. Il s’inscrit dans une tendance plus large, qu’il convient de baliser. Trois directions méritent un suivi attentif sur les douze prochains mois.
La première concerne l’émergence de bibliothèques et de modèles spécifiquement pensés pour le bricolage de données personnelles. À mesure que les développeurs accumulent des récits similaires, des composants réutilisables vont se sédimenter. Les frameworks d’observabilité applicative — Prometheus, Grafana — ont déjà inspiré des transpositions à des usages personnels. La fenêtre de standardisation est ouverte.
La deuxième direction touche à la position des grandes plateformes. Apple, Google, Fitbit et Oura ont jusqu’à présent verrouillé l’accès aux données brutes derrière des couches d’agrégation. Si la communauté des utilisateurs-bidouilleurs grossit, la pression pour des API plus ouvertes va s’intensifier. Le précédent du right to repair, qui a contraint plusieurs fabricants à céder du terrain, pourrait trouver son équivalent dans le domaine des données personnelles de santé.
La troisième direction est plus conceptuelle. Elle concerne la place que prendra l’IA générative dans la médiation entre un individu et ses propres données. Le rôle d’assistant à la construction d’outils est aujourd’hui le plus visible. Mais on peut anticiper un glissement vers un rôle d’interprète : poser des questions à ses propres flux de données en langage naturel, sans construire d’outil dédié. La frontière entre l’outil et la conversation s’estompe.
Reste une question ouverte, que le billet de martin.sh laisse en suspens : à partir de quel seuil l’instrumentation de soi devient-elle contre-productive ? L’épisode du sommeil illustre un bénéfice net dans un cas circonscrit. Généralisé à toutes les dimensions de la vie quotidienne, le même geste pourrait produire un effet inverse. La sobriété instrumentale est probablement la prochaine vertu à inventer.
FAQ
Faut-il être développeur pour construire ce type d’outil maison ?
À ce jour, la réponse reste positive pour les versions les plus personnalisées. L’assistance IA réduit le coût du code, mais elle suppose toujours de savoir formuler une demande technique précise, de débugger les sorties, et de comprendre les flux de données. L’évolution attendue dans les prochains mois est l’arrivée d’interfaces conversationnelles plus tolérantes, capables d’accompagner un utilisateur non-développeur. Mais la frontière n’est pas encore tombée.
Quelles données peut-on raisonnablement utiliser à domicile ?
Les sources disponibles évoquent le bruit ambiant, le mouvement, et les données déjà collectées par les appareils de suivi du sommeil. Le facteur limitant n’est pas le capteur — leur coût est faible — mais la qualité de l’interprétation. Les données brutes sont accessibles ; leur signification l’est moins. C’est précisément là que les assistants IA peuvent jouer un rôle, sans toutefois lever toutes les ambiguïtés.
Ce type de démarche peut-il remplacer un médecin du sommeil ?
Non, et l’auteur du billet ne le revendique pas. La démarche relève de l’auto-observation outillée. Elle peut aider à formuler des hypothèses, à documenter des épisodes, et à préparer une éventuelle consultation. Mais elle ne saurait se substituer à un diagnostic clinique, ni à une polysomnographie en laboratoire pour les cas où un trouble du sommeil est suspecté.
Quel est le principal risque de cette approche ?
Le risque dominant tient à la sur-interprétation. Une corrélation entre un bruit nocturne et un réveil ne prouve pas une causalité. Un week-end de prototypage peut produire un outil qui semble convaincant sans avoir la robustesse statistique nécessaire. La discipline à acquérir, en parallèle de l’outil, est celle de la modestie épistémique : se rappeler que le bruit est partout, et que les conclusions personnelles ont une portée personnelle.
Encadré sources
- Martin, I Let AI Build a Tool to Help Me Figure Out What Was Waking Me Up at Night, 11 mai 2026, https://martin.sh/i-let-ai-build-a-tool-to-help-me-figure-out-what-was-waking-me-up-at-night/
Pour aller plus loin sur les sujets connexes : le quantified self à l’ère des assistants IA, débogage personnel et observabilité domestique, API ouvertes pour les données de santé connectée, sobriété instrumentale et hygiène numérique.
