Un appareil local-first fait son travail principal sur son propre matériel et sur le réseau local, et considère internet comme un bonus plutôt qu'une nécessité. Quand le cloud est facultatif, une connexion coupée ou un créneau de délestage n'est qu'un bref désagrément, pas un appareil mort. Cet article explique pourquoi les gadgets dépendants du cloud se transforment en presse-papiers, quels schémas de conception continuent de fonctionner hors ligne, et propose un test simple à mener avant d'acheter.

Pourquoi les appareils dépendants du cloud finissent en presse-papiers

Beaucoup de produits connectés placent l'intelligence ailleurs. Le bouton au mur ne décide rien : il envoie un message à un serveur, le serveur décide, et la réponse revient par internet. Cet aller-retour est invisible tant que tout marche. Il saute aux yeux dès que le lien se rompt.

En Afrique du Sud, le lien se rompt souvent. Le délestage fait tomber ensemble le routeur et le boîtier fibre. Les données mobiles s'épuisent ou ralentissent jusqu'à l'immobilité. Le serveur d'un fournisseur sature, ou l'entreprise abandonne discrètement la gamme et coupe le service qui l'alimentait. Dans tous ces cas, un interrupteur qui a besoin du cloud pour allumer une ampoule située sur le même mur cesse de fonctionner. Le matériel va très bien. C'est son cerveau qui habite trop loin.

Le pire scénario est le plus lent. Un appareil peut fonctionner parfaitement pendant deux ans, puis devenir un déchet électronique le jour où son fabricant décide que le service cloud ne vaut plus la peine d'être maintenu. Vous croyiez acheter un produit ; vous louiez une dépendance.

Ce que veut dire local-first, concrètement

Le local-first n'est pas anti-internet. La question est de savoir où se prennent les décisions importantes. Dans une conception local-first, la boucle de contrôle principale s'exécute sur l'appareil lui-même, ou sur un petit concentrateur posé sur votre propre réseau. Le cloud est réservé aux tâches qui ont réellement besoin du monde extérieur : joindre l'appareil quand on n'est pas chez soi, conserver un historique de longue durée, distribuer les mises à jour logicielles et partager l'accès avec d'autres personnes.

Voyez cela comme trois couches. La logique embarquée traite la tâche immédiate. La coordination sur le réseau local permet à votre téléphone de parler à l'appareil en Wi-Fi sans sortir de la maison. La synchronisation cloud facultative s'occupe du reste, uniquement lorsqu'une connexion est disponible. Retirez la couche du haut : les deux autres continuent.

Les schémas qui continuent de fonctionner hors ligne

Nul besoin de concevoir du matériel pour reconnaître les bonnes habitudes. Quelques schémas séparent les appareils qui survivent à une panne de ceux qui n'y survivent pas.

• Boucle de contrôle locale. Les relevés de capteurs et les décisions qu'ils déclenchent se font sur le microcontrôleur, pas sur un serveur. Un thermostat conserve sa programmation ; un interrupteur interrompt le courant.
• Concentrateur sur le réseau local. Un petit appareil toujours allumé coordonne les autres sur votre LAN, si bien que les commandes du téléphone vers l'appareil n'ont jamais à quitter les lieux.
• Synchronisation différée, plutôt que données perdues. Hors ligne, l'appareil stocke ses relevés et les téléverse dès que la connexion revient, au lieu de les jeter.
• Dégradation maîtrisée. L'appareil a un comportement défini pour les périodes hors ligne : conserver le dernier état connu, appliquer une programmation par défaut sûre, ou basculer vers la position la plus sûre. Il ne se contente pas d'afficher une erreur clignotante et d'abandonner.
• Identifiants locaux. Vous pouvez toujours vous connecter et configurer l'appareil sur votre propre réseau sans que le serveur de comptes du fournisseur soit joignable.

Le test du fonctionnement hors ligne

On peut juger l'essentiel dès la première soirée, avant la fin du délai de rétractation. Installez l'appareil, puis mettez-le délibérément à l'épreuve avec un internet mort.

1. Éteignez le routeur, ou désactivez les données mobiles, et utilisez la fonction principale. L'interrupteur commute-t-il encore, le capteur réagit-il toujours ?
2. Redémarrez l'appareil, internet toujours coupé. Revient-il seul à un état fonctionnel, ou reste-t-il bloqué à attendre de joindre son serveur ?
3. Ouvrez l'application sur le même Wi-Fi, sans aucune connexion internet. Parvient-elle à trouver et à piloter l'appareil en local ?
4. Posez au fournisseur une question franche : qu'advient-il de ce matériel si vous arrêtez le service ? Une réponse assurée signale en général l'existence d'un repli local.
5. Cherchez des protocoles ouverts comme Matter, Zigbee ou MQTT vers votre propre broker. Les standards que vous maîtrisez font la différence entre changer d'application plus tard et tout racheter.

Si un appareil échoue aux deux premières étapes, ce n'est pas un appareil intelligent. C'est une télécommande pour le serveur de quelqu'un d'autre.

Enseigner l'état d'esprit local-first

Ce réflexe s'acquiert plus facilement jeune. Les enfants qui apprennent à programmer sur du matériel exécutant le programme sur la carte elle-même grandissent en attendant d'un appareil qu'il possède sa propre logique. Quand le code réside sur la puce, un projet à base de lumière et de capteur continue de tourner qu'il y ait ou non du Wi-Fi dans la pièce, et l'apprenant voit exactement où la décision se prend.

C'est le modèle qu'emploie notre carte sheenbot∞ : le programme s'exécute sur le microcontrôleur, si bien qu'un projet se comporte de la même façon sur un réseau domestique, à l'école ou sur une table sans la moindre connexion. C'est une manière concrète de montrer que « intelligent » n'est pas obligé de vouloir dire « en ligne ». Pour voir comment nous l'enseignons, notre academy construit ces projets pas à pas, vous pouvez réserver un cours d'essai, et les cartes et kits se trouvent dans la boutique.

À retenir

Le cloud est utile pour l'accès à distance, l'historique et les mises à jour. C'est un mauvais endroit où loger la capacité de base d'un appareil à fonctionner. Privilégiez les produits dont la boucle principale s'exécute localement, où les données sont stockées et synchronisées plutôt que jetées, et où des protocoles ouverts vous évitent d'être enfermé chez un seul fabricant. Puis consacrez une soirée au test du fonctionnement hors ligne. Les appareils qui le réussissent sont ceux qui marcheront encore à la prochaine coupure de courant.

FAQ

Le local-first signifie-t-il que je perds l'accès à distance ?

Non. Le local-first préserve le fonctionnement de la fonction principale sans internet, mais un appareil peut tout à fait proposer l'accès à distance en supplément facultatif. La différence, c'est que perdre ce supplément n'empêche pas l'appareil de faire son travail principal.

Le cloud est-il toujours le mauvais choix ?

Non. Les services cloud sont l'outil adapté pour l'historique de longue durée, les mises à jour à distance et l'accès à un appareil quand on est absent. La règle est d'utiliser le cloud pour ce qui a besoin du monde extérieur, pas pour des décisions que l'appareil pourrait prendre seul.

Comment se passent les mises à jour logicielles si l'appareil est hors ligne ?

Les bonnes conceptions téléchargent une mise à jour lorsqu'une connexion est disponible et l'appliquent localement, au lieu d'exiger d'être en ligne au moment de l'exécution. Les périodes hors ligne retardent les mises à jour ; elles ne devraient pas désactiver l'appareil.