Zéro nouveau matériel : une boussole EROOM pour une solution numérique adaptée au besoin

Deux proches utilisent chaque nuit un appareil de traitement de l’apnée du sommeil. Chaque matin, le constat est le même : le portail constructeur est illisible, lent et inadapté à leurs besoins. Une situation d'autant plus critique que ces deux utilisateurs se sentent éloignés du numérique — comme un tiers des Français en 2022 d’après l’Agence nationale de la cohésion des territoires (ANCT) — et que l'une d'entre elles souffre de problèmes de vision basse. Fallait-il pour autant créer un énième service cloud ?

Nous avons choisi l'inverse. Boussole EROOM en main, nous avons appliqué une règle simple : avant de provisionner, inventoriez. Un Mac, un téléphone Android, un compte Google, des enceintes connectées. Tout était déjà là, déjà allumé.

Cet article raconte comment nous avons transformé cet existant en un service de suivi médical utile, fiable et sobre, sans acheter un seul appareil supplémentaire. Que vous soyez praticien du numérique responsable ou curieux, découvrez ce qu'un smartphone classique — déjà en circulation — est réellement capable de faire en tâche de fond.

Plan de l’article :

• Pourquoi cette boussole ?
• Le service imaginé, simple, utile, frugal
• Utilisation du réseau : Web vs API
• Web vs API : sobriété comparée
• Les limites
• EROOM : la contrainte physique comme rempart contre l'effet rebond
• Conclusion
• Pour aller plus loin

Bonne lecture !

Pourquoi cette boussole ?

Avant d’écrire une seule ligne de code, nous avons posé une question simple : avons-nous vraiment besoin de nouveau matériel ?

L’approche EROOM, “Effort Radicalement Organisé d’Optimisation en Masse" (mais c’est aussi Moore à l’envers, pour inverser la Loi de Gordon Moore), initiée par Tristan Nitot dans un post LinkedIn remarqué, répond à cette question par une inversion du raisonnement habituel. Plutôt que de partir du besoin et de dimensionner l’infrastructure en conséquence, elle invite à faire l’inventaire de ce qui existe déjà, et à vérifier si ce n’est pas suffisant. L’écoconception classique est une démarche préventive : elle s’applique au moment de la conception depuis une page blanche, sans nécessairement prendre en compte l'existant. EROOM étend cette logique à l’existant, au logiciel déjà en production, au matériel déjà en circulation.

Les enjeux sont massifs : la fabrication des terminaux représente près de 80 % des émissions de gaz à effet de serre du numérique en France. Pourtant, selon l’ADEME, 88 % des Français remplacent leur téléphone alors qu'il fonctionne encore. Chaque appareil non acheté est une empreinte évitée. Membres du groupe de travail Boavizta sur ce sujet, EROOM était notre réflexe naturel.

Dans notre cas, l’analyse fut rapide : un vieux téléphone Android, un compte Google, une connexion internet et un Google Nest Hub. Aucun achat n'a été nécessaire. Après avoir écarté la Freebox (non adaptée à l'hébergement d'un serveur), nous avons confirmé que ces objets du quotidien suffisaient à automatiser un service complet, sans rien acheter de plus.

Le service imaginé, simple, utile, frugal

La solution retenue transforme ces données techniques en un compte-rendu simple et quotidien. Chaque matin, un programme interroge les serveurs du fabricant, synthétise les indicateurs clés (durée, fuites, apnées) et écrit le résultat dans Google Calendar.

Le but était de rendre l'information accessible sans interaction complexe : une enceinte connectée, posée dans la pièce de vie, lit le résumé à voix haute sur demande orale. L’information est là, sans écran, sans connexion, sans menu à parcourir.

Parallèlement, l’agenda partagé se synchronise nativement sur les smartphones des aidants, offrant un suivi plus détaillé. Contrairement au portail du fabricant et des prestataires, dont le délai de restitution peut atteindre 48 heures, ce flux est quasi immédiat et adapté au besoin de réassurance matinale.

Cette solution repose entièrement sur des outils déjà en place, sans ajouter ni service, ni abonnement.

L’architecture et fonctionnement

Le service repose sur l'existant : un Mac, un smartphone, les machines PPC , infrastructure de leur constructeur et Google Calendar.

Voilà un diagramme de composants qui représente l'architecture statique du système : les modules logiciels, leurs interfaces et leurs dépendances.

Le Mac sert d'atelier de développement et de coffre-fort pour les identifiants, tandis que le téléphone (via Termux) orchestre les tâches en arrière-plan. L'information, une fois traitée, est synchronisée dans Google Calendar, puis lue vocalement par des enceintes connectées (Un vieux modèle de Google Home mini et un Google Nest Hub Max).

Chaque nuit et chaque sieste génèrent un événement avec un titre court et explicite du style : “😴PPC <émoji #1><Prénom dormeur #1>:<état du sommeil #1>, <émoji #2><Prénom dormeur #2>:<état du sommeil #2>” avec des émojis explicites ( ✅,💛, 🟠et 🟥) restitué à voix haute sur demande orale. Comme vous avez pu le comprendre avec la première image de l’article, cette interface est entièrement vocale, sans écran à manipuler ni menu à parcourir : elle est pensée pour un public pour qui le numérique reste souvent perçu comme une contrainte.

Les trois diagrammes de séquence ci-dessous décrivent le fonctionnement du service selon trois angles : la mise en place, le quotidien automatisé, et les opérations de maintenance.

Développement et configuration

Le programme est développé et testé sur le Mac. La première étape consiste à configurer les accès : authentification auprès des serveurs de ResMed, fabricant des appareils PPC, avec une étape de vérification par code reçu par email, puis autorisation d'accès à Google Calendar. Les identifiants de génération des tokens temporaires associés au terminal de consultation d'accès sont stockés dans le trousseau système de macOS : ils ne transitent jamais en clair sur le disque et restent protégés par les mécanismes de sécurité du système.

Une fois ces accès validés, le programme et les données de configuration sont packagés puis transférés sur le téléphone Android, et une commande à coller dans l'application de terminal (ici Termux) réalise le déploiement.

Sur le téléphone, deux déclenchements automatiques sont configurés : un à partir de 8h pour les données de nuit, un dès 17h30 pour les données de sieste.

Le quotidien automatisé

Chaque nuit, les deux appareils transmettent automatiquement leurs données aux serveurs de ResMed. Le matin, le programme se déclenche sans intervention humaine. Il charge les identifiants depuis le trousseau système, vérifie la disponibilité du réseau, interroge les serveurs pour chacun des deux utilisateurs, calcule les indicateurs clés (durée, fuites, nombre d’apnées) et met à jour l’événement du jour dans Google Calendar. En cas d’absence de réseau, il réessaie toutes les quinze minutes. Le soir, le même cycle se répète pour la sieste. Sur demande orale, le Nest Hub lit le résumé à voix haute.

Les fonctions de maintenance

Deux opérations sont disponibles pour l’administrateur du service. La première permet de consulter les statistiques sur une période donnée : quelques jours, plusieurs semaines, un mois entier, ou une plage de dates précise. Le programme récupère les événements Calendar correspondants et produit un tableau récapitulatif avec des indicateurs colorés pour chaque nuit. La seconde permet de remettre à zéro l’agenda en effaçant les anciens événements du calendrier, par exemple en cas d’erreur ou de reprise depuis une date antérieure.

À noter : lors de son exécution quotidienne, le programme écrase automatiquement l’événement du jour s’il existe déjà. Il n’y a donc jamais de doublon : relancer le programme deux fois de suite produit le même résultat qu’une seule exécution.

Utilisation du réseau : Web vs API

Pour récupérer les données des deux dormeurs, on aurait pu ouvrir le portail deux fois par jour dans un navigateur. En pratique, chaque consultation charge bien plus que les données utiles : la page embarque automatiquement un lecteur vidéo, Google Analytics et un bandeau de gestion des cookies. Des services que personne n'a demandés, et qui représentent 42 % du volume total téléchargé.

Le cas nominal (6 requêtes, 12 KB) correspond à la grande majorité des matins : le programme réutilise un jeton de reconnexion, récupère les données, écrit dans Calendar. Le pire cas (10 requêtes, 19 KB) se produit au premier lancement ou quand tous les jetons ont expiré. Dans les deux situations, l'écart avec la version Web dépasse 99,8 % de données en moins, soit environ 500 à 780 fois moins de données reçues. Ces volumes sont mesurés en octets réseau réels, déjà compressés, côté navigateur comme côté programme : la comparaison est loyale. La sieste suit le même principe et n'est pas comptée ici pour ne pas alourdir.

Mais la différence ne se limite pas au réseau. La version navigateur suppose que l'un ou l'autre des dormeurs aille chaque matin sur le portail, se connecte, navigue jusqu'aux données. Pour des personnes dont l'autonomie numérique est réduite, c'est une contrainte réelle, quotidienne. Ce nouveau service tourne seul, dépose les résultats dans Calendar, et n'attend rien de personne.

C'est ce que l'on entend par « efficient par construction » : non pas un service qui optimise sa consommation à la marge, mais un service dont la structure même évite la création de ressources supplémentaires.

Les limites

Ce projet fonctionne, avec ses limites.

Il s'agit d'un service domestique, taillé pour un usage familial. Il repose sur deux appareils personnels, une connexion internet domestique, et deux services tiers dont nous ne maîtrisons ni les conditions d'utilisation ni la pérennité. Si ResMed décide de fermer ou de modifier son API, le programme cesse de fonctionner. Si Google modifie son API Calendar, idem. Ce sont des dépendances réelles, acceptées en connaissance de cause, mais qui excluraient ce modèle d'un déploiement à plus grande échelle. Il faut également être lucide sur un autre point : en stockant des données de santé dans Google Calendar, on les confie à Google, qui en sait déjà beaucoup sur nous. Et même si le compte utilisé n'est pas nominatif, il est tout à fait géolocalisé : Google Home, notamment, sait précisément où se trouve le Nest Hub et qui vit dans ce foyer.

La résilience est moindre qu'un vrai serveur. Un téléphone Android peut redémarrer, perdre sa connexion, voir sa batterie se décharger. Le programme intègre des mécanismes de retry, mais il n'offre pas les garanties de disponibilité d'une infrastructure professionnelle. Pour un suivi quotidien à usage familial, c'est acceptable ; un service médical critique appellerait d'autres choix d'architecture.

La sécurité est celle d'un projet domestique. Les identifiants sont protégés sur le Mac ; sur le téléphone, les données étant moins sensibles, elles sont moins sécurisées et peuvent rarement demander l'intervention d'un humain lors de problèmes type déconnexion. Les données de santé transitent par des services tiers. Ce sont des compromis conscients, adaptés au contexte, mais à ne pas reproduire sans réflexion dans un cadre professionnel ou réglementé.

Ce service a été construit avec un objectif clair : être utile rapidement, sans sur-ingénierie. Des raccourcis ont été faits, consciemment. Sécuriser davantage ou rendre le programme plus robuste était possible ; ce n'était simplement pas le sujet. L'enjeu était de trouver le bon équilibre entre le service rendu et le coût de développement : un service qui fonctionne vraiment, pour de vraies personnes, sans prétendre à une industrialisation qui n'aurait aucun sens ici.

Enfin, ce projet ne se généralise pas tel quel. Il a été taillé pour un besoin précis, avec un matériel précis, pour une famille précise. La loi de Goodhart (“quand une mesure devient un objectif, elle cesse d'être une bonne mesure”) s'applique ici comme ailleurs : si l'on commençait à optimiser excessivement ce service numérique pour en faire un produit au standard de la haute disponibilité, on recréerait exactement l'infrastructure que l'on a voulu éviter.

EROOM : la contrainte physique comme rempart contre l'effet rebond

Une question revient souvent dès qu'on parle de numérique sobre : et si l'efficacité gagnée était finalement consommée ailleurs, voire amplifiée ? C'est le paradoxe de Jevons, ou effet rebond. Avec notre service, ce risque est écarté par la nature même de l'approche EROOM : elle place le service dans un étau.

Ici, le matériel existant définit les bornes. Une fois la phase de développement terminée, le programme tourne sur des ressources qui existaient déjà. Pas de nouveau serveur à allumer, pas d'infrastructure qui s'étoffe au fil des usages. Cette structure interdit la dérive : les empreintes matérielles étaient déjà amorties avant le projet, et la charge énergétique additionnelle est marginale.

C’est ce que l’on entend par « efficient par construction » : la sobriété ne vient pas d’une optimisation à la marge, mais d'une structure qui, par définition, ne peut pas « grossir ». Pas de fonctionnalité superflue ajoutée "parce qu'on pourrait", pas de tableau de bord enrichi "parce que ce serait pratique". Dès qu'on s'éloigne du besoin réel, les limites du téléphone ou du service tiers rappellent à l'ordre.

Cette méthode offre une sécurité que les projets écoconçus classiques n'ont pas. Dans ces derniers, les cibles de consommation restent souvent abstraites et peuvent dériver — une dépendance par-ci, une bibliothèque par-là — sans que personne n'ait eu l'impression de franchir une ligne. Avec EROOM, les bornes sont physiques. La contrainte est intégrée dès le départ, non pas comme un idéal à atteindre, mais comme une réalité matérielle immédiate. En veillant à ce que le service reste simplement utile, utilisable et utilisé, nous évitons l'inflation numérique.

Conclusion

Ce service illustre que le raisonnement compte autant que la technique. Avant de provisionner une infrastructure cloud ou d’acheter un nouveau serveur, une question mérite d'être posée : qu'est-ce que le matériel déjà là est capable de faire ? Dans notre cas, la réponse a suffi à construire un service utile, robuste et profondément sobre.

EROOM n'est pas une simple méthode d'optimisation : c'est un changement de regard. En refusant de céder à la facilité de la sur-ingénierie, nous avons prouvé que l'existant suffit souvent à créer des solutions adaptées. Le vrai défi du numérique responsable ne se joue plus dans les serveurs, mais dans notre capacité à redéfinir la notion de "besoin". Avant d'acheter ou de déployer, demandez-vous ce que votre matériel actuel est déjà capable de faire.

Avec moins de matériel que la configuration standard, il est même parfois possible de réaliser des services et applications web sans serveur, comme le rappelle très bien Aleth Gueguen dans son excellent talk de 37 minutes "Développer des applications résistantes à des conditions dégradées", présenté lors de l'édition 2026 de la Journée Écoconception des Designers Éthiques.

Le prochain service numérique sobre ne sera peut-être pas une nouvelle ligne de code, mais une nouvelle manière d'utiliser ce que vous possédez déjà. Et si ce réflexe devenait systématique avant chaque nouveau projet ?

Pour aller plus loin

⚠️ Attention toutefois, ce retour d'expérience n'illustre qu'une partie de l'approche EROOM. Bien plus vaste, cette méthodologie propose un état des lieux à 360 degrés structuré autour de cinq dimensions d'analyse : le produit, l'architecture logicielle, l'infrastructure, le stockage et les données, et enfin les algorithmes / le code (avec une sixième dimension sur l'IA générative en préparation).

Pour explorer la méthode en profondeur, voici les ressources essentielles :

• La démarche EROOM / Boavizta, commun numérique open source sous licence CC BY-SA 4.0
• Diagnostic rapide EROOM / évaluer en quelques minutes le potentiel d’optimisation d’un service existant
• La genèse d’EROOM / comprendre l’origine de la démarche
• Vidéo explicative EROOM, 30 minutes / présentation complète de la méthode
• Retour d’expérience chez Décathlon, 40 minutes / exemple concret pour mesurer les dérives à grande échelle
• Vidéo : “Développer des applications résistantes à des conditions dégradées” 37 minutes / Aleth Gueguen, Journée Écoconception 2026
• academy.lotincorp.biz / Utile, utilisable et utilisé : pourquoi ça compte pour les designers