Si vous avez lu mon article sur Meshtastic , vous savez déjà que les réseaux mesh LoRa, c'est le genre de truc qui fait rêver tous les geeks en manque de hors-piste numérique. Mais y'a un cran au-dessus, et ça s'appelle Reticulum .

En gros, c'est une stack réseau chiffré de bout en bout qui fonctionne sur n'importe quel support physique : LoRa, WiFi, Ethernet, liaison série, radio amateur en packet... TOUT y passe. Du coup, là où Meshtastic reste avant tout taillé pour les messages texte sur LoRa, ici vous pouvez faire transiter des fichiers, des appels vocaux, des pages web et même un shell distant à travers votre mesh. En fait au début je pensais que c'était juste un Meshtastic sous stéroïdes, mais non... c'est carrément une couche réseau complète.

Comments

WorldMonitor , c'est un dashboard open source qui agrège en temps réel à peu près TOUT ce qui se passe sur la planète. Géopolitique, conflits armés, marchés financiers, menaces cyber, catastrophes naturelles, trafic maritime... le tout sur une carte interactive avec 35 couches de données superposables !

Le truc, c'est que c'est pas juste un agrégateur de news. Là-dedans y'a 150+ flux RSS, du tracking de 220+ bases militaires, du suivi de vols militaires en direct via ADS-B, de la surveillance des câbles sous-marins, et même de la détection de feux de forêt par satellite via NASA FIRMS.

C'est fou ce qu'on peut faire avec trois bouts de ficelle et un peu de jugeote. Ou plutôt, avec 140 caractères de JavaScript et un élément . Si vous ne connaissez pas encore Dwitter , c'est le moment de sortir de votre grotte les amis... surtout si vous aimez les challenges et le code !

Le concept c'est que vous avez une fonction u(t) où t est le temps qui passe, et vous devez pondre un truc visuellement bluffant sans dépasser la taille d'un tweet (époque pré-Elon, le fameux 140 caractères). Et là, c'est la claque car les mecs qui participent à ce défi arrivent à caser des univers entiers, des forêts en parallaxe ou des simulations de colonies de fourmis dans un mouchoir de poche.

Comments

Aujourd'hui j'aimerais vous parler un peu de bidouille et plus particulièrement de domotique. Hé oui, si comme moi, vous en avez marre que tous vos objets connectés passent par des serveurs chinois (souvent à la sécurité douteuse) ou américains (souvent directement connecté à la NSA) pour vous dire qu'il fait 22°C dans votre salon, on va voir comment ensemble créer ses propres capteurs 100% locaux avec ESPHome .

ESPHome, c'est un framework open source qui transforme n'importe quel ESP32 ou ESP8266 en appareil connecté intelligent sans vous prendre la tête. Vous écrivez un petit fichier YAML, vous flashez la puce, et hop, vous avez un capteur qui cause directement avec Home Assistant. Comme ça y'a pas de cloud et encore moins de données qui partent on ne sait où.

Un panneau stop, on se dit que c'est juste un bout de métal avec un peu de peinture rouge. On s'arrête, on repart, et puis voilà. Sauf que pour une IA qui pilote un gros engin à 4 roues, ce simple panneau peut devenir un véritable vecteur de tromperie visuelle !

Car oui je vous avais déjà parlé d'attaques de ce type par le passé, mais là, ça va encore plus loin. En effet, je suis tombé sur une étude des chercheurs de l'UCSC (University of California, Santa Cruz) qui en gros, ont trouvé un moyen d'induire en erreur des voitures autonomes et des drones en collant simplement des instructions sur des panneaux de signalisation customisés. Ils ont baptisé cette classe d'attaque CHAI pour Command Hijacking Against Embodied AI .

On nous parle d'agents IA à toutes les sauces depuis deeeees mois mais au final, on se retrouve la plupart du temps avec des outils "stateless" qui perdent le fil dès qu'une session se termine. Heureusement, le projet Personal AI Infrastructure (ou PAI pour les intimes) de Daniel Miessler propose justement de régler ce problème en classant les systèmes IA en 3 niveaux.

Le niveau 1, c'est le chatbot de base type ChatGPT... vous posez une question, il répond, il oublie tout. Le niveau 2, c'est l'agent (genre Claude Code ou Cursor) qui peut exécuter des trucs mais qui ne vous connait pas vraiment. Et le niveau 3, c'est PAI, une infrastructure complète qui observe, planifie, exécute et surtout... apprend de vous.

Rappel assez terrifiant que la plupart de nos normes, y compris les lois, sont là parce qu’elles sont nécessaires. En particulier pour ce qui est des normes de sécurité.

C’est bien parce qu’il y a eu des morts par le passé qu’il y en a beaucoup moins aujourd’hui, et ça c’est grâce aux règles de sécurité qu’on a mis en place.

Ces règles ne sont pas là juste pour emmerder le monde.

Je parle ici spécifiquement des règles de sécurité.
Tout ce qui est de règles sociales, économiques, esthétiques, fonctionnelles, culturelles… c’est autre chose. La société, les cultures, et les usages, par exemple, changent au fil du temps, et les règles devraient le faire avec (mais c’est rarement le cas). Le fait qu’il soit nécessaire de protéger les vies humaines, par contre, ça, ça ne devrait pas changer.

Dans certains cas, comme lors du Covid, il fut par exemple décidé de réduire les test sur les vaccins. En particulier pour une question d’urgence. Ce n’est pas forcément mal, du moment qu’on est sûr que le rapport bénéfice/risque reste sur-unitaire (ce qui a été très largement le cas).

Cela reste une exception : dans la vaste majorité des cas, il est largement préférable de suivre les règles de sécurité.

Salut les amis ! Aujourd'hui, je voulais vous partager une petite pépite qu'un lecteur, Stanislas, m'a envoyée. Si vous bossez dans la cyber ou que vous passez votre temps à analyser des trucs bizarres qui trainent sur vos serveurs, vous allez adorer Cyberbro.

Cyberbro c'est une plateforme d'analyse d'IoC (Indicators of Compromise) en open source. Grâce à ça, au lieu de vous paluchez 15 sites différents pour vérifier une IP ou un hash, vous balancez tout dans Cyberbro. L'outil va alors extraire automatiquement les infos de vos logs et interroger une vingtaine de services comme VirusTotal, MISP, Shodan, AbuseIPDB ou même Microsoft Defender pour vous dire si c'est dangereux.

GitHub vient peut-être de trouver une piste sérieuse pour sauver la santé mentale des mainteneurs de projets open source. Parce que je sais pas si vous le savez mais gérer un projet populaire sur GitHub, c'est un peu comme essayer de vider l'océan avec une petite cuillère, surtout avec la montée en puissance des contributions de faible qualité, dont une bonne partie est désormais générée par IA ...

Le problème, c'est que la quantité ne veut pas dire la qualité... Entre les Pull Requests (PR) qui ne respectent pas les guidelines du "README.md" et celles qui sont abandonnées en cours de route, les mecs derrière les gros dépôts commencent à fatiguer. Du coup, un représentant de GitHub explique dans une discussion avec la communauté explorer très sérieusement plusieurs options, dont la possibilité de désactiver purement et simplement les Pull Requests sur un dépôt.

Vous devez tester un service en ligne et là, PAF 🥲 formulaire d'inscription 🥲 Ouiiiin !!!

Et bien sûr, même si vous pouvez remplir tous les champs avec un tas de conneries, forcement à un moment, ça vous demande votre email. Et là, impossible d'y échapper... Heureusement pour éviter ça, il existe des services d'emails jetables et je vous propose qu'ensemble qu'on fasse un petit point dessus parce que ça a beaucoup bougé ces dernières années..

Je suis un peu con, et flemmard. C’est pour ça que je crée mes outils pour me simplifier le travail (ça me libère du temps pour réfléchir à le simplifier encore plus).

Quand on me dit qu’on peut faire quelque chose, je comprends « tu n’es pas obligé de le faire ».

Si c’est obligatoire, il fallait me dire « tu dois ».

C’est à ça que servent les mots avec un sens précis.
Les incompréhension et malentendus sont la raison pour laquelle un quart du monde est en ruine et en guerre (un autre quart pour le pétrole, un quart pour une question d’amis imaginaire, et le reste parce qu’un peuple brillamment décérébré a élu un psychopathe comme son président).

J’avais parlé de l’importance de l’insistance sur le choix des termes dans mon article expliquant comment écrire des tutos et des instructions : https://lehollandaisvolant.net/?d=2025/10/03/18/54/57-mes-astuces-pour-realiser-de-bons-tutoriels

Le tout en citant la RFC 2119 qui défini, pour les normes et recommandations de l’Internet, quand employer les termes doit / peut / obligatoirement / optionnel / …

Je remarque que certaines normes ISO / EN / NF ont parfois un paragraphe similaire. Je n’ai pas connaissance d’une norme dédiée, mais je copie ça là :

L’attention du lecteur est attirée sur les points suivants :

Seules les formes verbales doit et doivent sont utilisées pour exprimer une ou des exigences qui doivent être respectées pour se conformer au présent document.

Ces exigences peuvent se trouver dans le corps de la norme ou en annexe qualifiée de «normative». Pour les méthodes d’essai, l’utilisation de l’infinitif correspond à une exigence.

Les expressions telles que, il convient et il est recommandé sont utilisées pour exprimer une possibilité préférée mais non exigée pour se conformer au présent
document. Les formes verbales peut et peuvent sont utilisées pour exprimer une suggestion ou un conseil utiles mais non obligatoires, ou une autorisation.

En outre, le présent document peut fournir des renseignements supplémentaires destinés à faciliter la compréhension ou l'utilisation de certains éléments ou à en clarifier l'application, sans énoncer d'exigence à respecter. Ces éléments sont présentés sous forme de notes ou d'annexes informatives

Oui, il faudrait une norme globale pour ça (un calque de la RFC).
Quand quelque chose est obligatoire pour être valide, il faut que ça soit mis.
Quand quelque chose est recommandé (utile sans être obligatoire) ou non-recommandé (inutile voire dangereux sans être interdit), ça doit être dit aussi.

C’est con qu’il faille préciser ça, mais première nouvelle : les gens SONT cons.

En tant que rédacteur d’instruction de travail (une partie de mon travail), il est de ma responsabilité de faire en sorte que les gens comprennent et travaillent correctement. Dans certains cas, des vies sont en jeu (dans l’aérien, une défaillance c’est souvent synonyme d’accident et de morts).

En mettant « doit » au lieu de « peut », on se couvre. Si la personne comprend mal, c’est un accident.
En insistant sur la différence de doit et peut, si la personne commet encore l’erreur, c’est de l’incompétence ou du sabotage. Pas un accident.

Les normes, les lois, les instructions, devraient insister sur ça. Et choisir leur vocabulaire soigneusement.

Aucune interprétation ne doit être possible.