Le 1er août, Matt Webb n’a pas annoncé une nouvelle horloge. Il a demandé aux propriétaires d’un Poem/1 de prendre un ordinateur, de suivre une procédure et d’installer manuellement un firmware.1 La mise à jour devait corriger des cas où la connexion Wi-Fi ou le backend laissaient l’objet bloqué; elle ajoutait aussi les mises à jour automatiques et une troisième police, Shantell.

Ce n’est pas le genre d’annonce qui fait une belle fiche produit. C’est précisément pour cela qu’elle mérite un article. Une horloge connectée n’est pas terminée lorsqu’elle arrive dans une boîte. Elle continue à révéler son architecture dans des routeurs imprévisibles, des serveurs modifiés, des écrans qui vieillissent et des propriétaires qui ne pensent pas spontanément à flasher un appareil décoratif.

Une horloge qui dépend de plusieurs endroits

Le Poem/1 affiche un nouveau poème chaque minute. Le manuel explique que les textes sont composés sur le site poem.town puis récupérés par Wi-Fi; l’horloge doit donc rester connectée à Internet pour fonctionner comme prévu.2 Le matériel est volontairement simple à regarder : un écran e-paper de 4,7 pouces, un bouton supérieur, un câble USB-C et du Wi-Fi 2,4 GHz, sans Bluetooth.2

Cette simplicité visuelle cache une chaîne distribuée. L’électricité arrive par le câble. Le réseau passe par la box du propriétaire. L’horloge obtient l’heure, contacte un service, reçoit un contenu et l’affiche. Une panne peut venir du signal radio, de l’authentification, d’un changement d’API, d’un serveur indisponible ou d’une logique locale qui ne sait pas récupérer après l’échec.

Le billet de Webb décrit un bug rare qui pouvait affecter certaines horloges pendant une semaine avant de disparaître.1 Le détail est plus instructif que le mot « bug ». Dans un prototype, on peut redémarrer l’objet, regarder les logs ou modifier le code immédiatement. Dans une maison, le même état devient une relation de support : quelqu’un doit savoir que le problème existe, comprendre ce que l’appareil peut encore faire et obtenir une manière de le réparer sans ouvrir le boîtier.

Le premier firmware est une conversation

Le manuel actuel formalise cette conversation. La première mise à jour doit être installée manuellement depuis un navigateur sur ordinateur; les suivantes pourront être installées automatiquement par Wi-Fi.2 L’outil guide l’utilisateur, valide le fichier et demande de ne pas débrancher l’horloge pendant l’écriture. Une procédure de secours existe aussi via le mode de configuration Wi-Fi et l’adresse locale 192.168.4.1.2

Cette séquence ne ressemble pas à l’App Store, et c’est une bonne chose de ne pas prétendre le contraire. Le propriétaire doit comprendre qu’il possède un objet qui a une version logicielle. Il doit mettre l’horloge en mode configuration, rejoindre son réseau temporaire, ouvrir une page et attendre le redémarrage. Pour un maker, la procédure est raisonnable. Pour une personne qui voulait seulement accrocher une horloge au mur, elle représente déjà une dette de conception.

Le passage vers l’OTA réduit cette dette pour les prochaines corrections. Mais il ne peut pas effacer la dette initiale : le premier mécanisme automatique doit être livré par un mécanisme manuel ou par une version installée en usine. La mise à jour automatique n’est donc pas une fonction isolée. Elle est le dernier maillon d’une chaîne de récupération qui doit prévoir ce qui se passe lorsque la mise à jour échoue, que le réseau disparaît ou que l’alimentation est retirée trop tôt.

La documentation insiste sur ce dernier risque pour l’écran e-paper : ne jamais débrancher pendant une mise à jour d’affichage, sous peine de dommage permanent.2 Un détail comme celui-ci change le ton de l’interface. Le logiciel ne peut pas seulement afficher « update available ». Il doit protéger le geste physique autour de l’appareil.

Fabriquer un objet, c’est fabriquer sa deuxième version

Un an avant la mise à jour, Webb racontait depuis Shenzhen la fabrication du Poem/1.3 Le billet ne décrit pas une chaîne abstraite de sous-traitance : il parle d’itérations de boîtiers, de pièces sorties d’une ligne d’assemblage pilote, de tests de vieillissement et d’un risque de dommage de l’écran à corriger. La production de cent unités pilotes devait servir à la certification et aux tests de bout en bout.

Ce récit donne un contexte matériel à l’update. Le firmware n’est pas un fichier qui flotte indépendamment du produit. Il doit correspondre à une carte, une alimentation, une procédure d’assemblage et une situation de récupération. Une modification du code peut rendre une étape d’usine plus fiable; un défaut découvert en usine peut exiger un changement de firmware. Le logiciel et le plastique apprennent ensemble.

Le billet de lancement Kickstarter montre l’autre côté du problème.4 Webb y décrit un prototype devenu projet financé, puis la nécessité de trouver une route de fabrication et de faire entrer l’objet dans une vraie production. Il annonce aussi l’idée d’un serveur qui compose les poèmes et d’un produit sans abonnement, financé par une part du prix initial pour couvrir les coûts de génération et de serveur pendant plusieurs années.4

Cette promesse économique n’est pas une garantie éternelle. Elle est un choix de design. Le fabricant doit estimer le coût d’un service qui continue après la vente, puis décider ce que l’appareil fera si les coûts changent. Le support firmware appartient à la même économie invisible : chaque correction demande du temps de diagnostic, un outil, une version testée et une explication compréhensible.

Les 700 horloges deviennent une flotte

Dans son appel d’août, Webb indique avoir expédié plus de 700 horloges et observe que seulement 26 % des horloges actives utilisent la dernière version au moment du billet.1 Ces chiffres ne mesurent pas la qualité d’un produit à eux seuls. Ils donnent néanmoins une information que l’on ne peut pas obtenir sur un objet purement hors ligne : une fois vendu, le matériel devient une flotte avec une distribution de versions.

Le taux de 26 % ne signifie pas que les autres propriétaires négligent leur appareil. La procédure était manuelle. Pour une horloge qui fonctionne la plupart du temps, l’incitation à interrompre le quotidien est faible. L’absence de mise à jour peut être le résultat rationnel d’une friction conçue par le fabricant.

La télémétrie change cette relation, mais elle pose d’autres questions. Savoir quelle version est installée permet de prioriser un correctif, sans forcément collecter le contenu des poèmes ou l’identité du propriétaire. Le manuel explique que chaque horloge possède un code à quatre caractères et une page pour la réclamer et la personnaliser.2 Ce lien entre objet et compte est pratique; il doit aussi être documenté avec la même attention que le firmware.

Le produit est donc un petit système d’administration : versions, identifiants, appareil réclamé, réseau, backend, procédure de récupération. Un objet poétique n’échappe pas à l’infrastructure. Il la rend simplement visible quand il s’arrête.

Le service peut-il survivre à son auteur ?

La documentation développe une idée plus rare : un Device API pour créer d’autres horloges ou remplacer le backend poem.town.5 Elle décrit aussi des usages qui permettent de poster des notes depuis un script ou une application tierce. Un appareil fermé aurait pu garder le contenu, l’identité et le serveur dans un seul silo. L’API ouvre une petite porte vers une autre architecture.

Cette possibilité a déjà été explorée par Jay Goldman avec Home/1, un serveur compatible présenté comme un projet open source sous licence MIT.6 Il explique que l’objectif est de faire fonctionner un service local et de laisser les propriétaires configurer leur appareil sans dépendre entièrement du serveur original. C’est un projet communautaire, pas une promesse de support de Matt Webb; il ne faut pas l’utiliser pour déclarer le Poem/1 « décentralisé ». Mais il fournit une preuve concrète qu’un protocole documenté peut prolonger la vie d’un appareil au-delà de son premier service.

Le choix d’une API ne résout pas tout. Il faut connaître le format attendu, la procédure de configuration, les mises à jour et les limites de la licence. Il faut aussi accepter que remplacer le backend change l’expérience : les poèmes, le rythme et les données peuvent ne plus être ceux imaginés par l’auteur. L’interopérabilité conserve la possibilité; elle ne conserve pas automatiquement l’intention.

Corriger un objet que l’on ne voit pas

Le problème central d’un hardware indépendant est la distance. Au moment du prototype, le créateur a l’objet sur sa table. Après l’expédition, il existe dans des centaines de maisons, derrière des routeurs différents, avec des habitudes différentes. Un bug rare peut être impossible à reproduire localement. Le support devient une méthode d’enquête : demander une version, un message affiché, un état réseau, un redémarrage, puis traduire ces observations en code et en instructions.

La mise à jour OTA est une réponse logistique autant que technique. Elle ne rend pas le logiciel plus intelligent; elle réduit la distance entre le diagnostic et la correction. Elle permet à l’auteur de livrer un correctif sans demander à chaque propriétaire de devenir installateur.

Mais elle impose une discipline. Il faut signer ou valider les fichiers, gérer les versions, prévoir une reprise, protéger l’écriture, conserver un mode de secours et décider ce qui se passe si le backend est hors service. Un appareil qui se met à jour automatiquement est aussi un appareil qui reçoit une autorité à distance. La confiance ne vient pas du mot « automatique »; elle vient de la procédure qui encadre ce pouvoir.

La maintenance est une fonction créative

On pourrait résumer Poem/1 à une nouvelle police, Shantell, ajoutée pour remercier les propriétaires qui mettent à jour leur horloge.1 Ce serait passer à côté de la partie la plus créative. Le travail consiste à maintenir une relation entre un petit écran, une connexion intermittente, un service distant, une batterie d’attentes économiques et des personnes qui n’ont pas acheté un kit de développement.

Le billet de fabrication de Webb insiste sur la capacité à faire des objets, à comprendre les itérations et à montrer les étapes plutôt qu’à présenter la production comme un miracle.3 La mise à jour prolonge exactement cette pédagogie, mais auprès des propriétaires : l’objet n’est pas seulement livré, il peut être repris, corrigé et documenté.

Poem/1 ne prouve pas que tous les objets connectés devraient être des services ouverts, ni qu’une mise à jour automatique rend un produit durable. Il montre un cas plus précis. Une personne qui fabrique un objet en petite série doit concevoir l’après-livraison dès qu’elle ajoute un réseau. Le choix du serveur, du mode de récupération, du format d’update et de l’API devient une partie du design, au même titre que le boîtier et la police.

Le vrai produit commence alors après la première horloge expédiée. Il commence quand une machine cesse de se comporter comme le prototype et devient une collection de situations réelles. La qualité du maker ne se voit plus seulement dans l’idée initiale. Elle se voit dans la manière dont il revient vers l’objet, écoute ce qui s’est passé et donne à la prochaine correction une chance d’arriver.