HackerBooks : les livres recommandés sur Hacker News

3 novembre 2026 jeanmich Laisser un commentaire

Vous cherchez un livre de programmation, de maths ou simplement une idée de lecture qui sort des classements habituels ? HackerBooks rassemble les ouvrages évoqués sur Hacker News depuis 2007. L’intérêt n’est pas seulement de voir quels titres reviennent souvent : le site essaie aussi de distinguer un livre cité au détour d’une discussion d’un livre réellement conseillé. Et cette nuance change pas mal de choses.

HackerBooks transforme les discussions en bibliothèque

Les utilisateurs de Hacker News échangent depuis des années des recommandations dans les commentaires. Le problème, c’est qu’une bonne suggestion peut vite disparaître sous une pile de nouvelles discussions. HackerBooks remet de l’ordre dans tout ça : 15 766 livres ont été recensés à partir de 281 363 mentions publiées depuis 2007.

Pour figurer dans la bibliothèque, un ouvrage doit avoir été cité par au moins deux personnes différentes. Ce seuil ne garantit pas qu’il soit excellent, bien sûr, mais il évite de construire tout un catalogue sur des mentions isolées. On obtient ainsi un point d’entrée pratique pour retrouver des livres dont plusieurs personnes ont parlé.

Les ouvrages sont répartis dans des rubriques comme la programmation, les mathématiques, la philosophie ou la fiction. Chaque fiche permet aussi de revenir aux commentaires associés. C’est à mon avis la partie la plus utile : un titre seul donne une piste, une discussion aide à comprendre pourquoi il mérite votre temps.

Une citation n’est pas une recommandation

C’est le piège classique des classements fondés sur la popularité. Un livre peut être mentionné parce qu’il a marqué un domaine, parce qu’il suscite un désaccord ou simplement parce qu’il répond à une question précise. Compter toutes ces occurrences comme des recommandations donnerait une image trompeuse.

HackerBooks utilise l’IA pour séparer les citations des recommandations. Prenez The Art of Computer Programming, de Donald Knuth : 1 125 personnes l’ont cité, mais 336 l’ont recommandé. Le premier chiffre mesure sa présence dans les conversations ; le second tente de mesurer l’envie de le conseiller. Ce n’est pas du tout la même information.

Différence entre citations et recommandations de livres dans HackerBooks

J’aime bien cette distinction parce qu’elle pousse à regarder derrière les chiffres. Si vous cherchez votre prochaine lecture, un ouvrage très cité n’est pas automatiquement celui par lequel commencer. Il vaut mieux lire quelques commentaires pour voir à qui il s’adresse, ce que les lecteurs en ont retenu et dans quel contexte ils le proposent.

Comment trouver une lecture qui vous correspond ?

Une grosse bibliothèque peut rapidement devenir une nouvelle façon de perdre du temps. Le plus simple est de partir d’un besoin concret, puis de confronter les suggestions aux discussions. Par exemple :

Choisissez une rubrique liée à ce que vous voulez découvrir ou approfondir.
Repérez les livres recommandés, sans vous arrêter au nombre total de citations.
Ouvrez les commentaires pour comprendre les avis et le niveau attendu.
Comparez plusieurs titres avant de décider lequel vous donnera vraiment envie de lire.

Le site propose aussi des suggestions personnalisées en fonction des fiches ouvertes. Cela peut aider à prolonger l’exploration, surtout quand un ouvrage vous intrigue sans être exactement ce que vous cherchiez. Mais je garderais la main sur le choix final : une suggestion automatique connaît vos clics, pas forcément vos objectifs.

Une bonne idée, à utiliser avec un peu de recul

HackerBooks a été codé avec Claude à la demande de Roansh. Dans le même esprit, HackerTube rassemble des vidéos recommandées sur Hacker News. Je trouve ces projets intéressants parce qu’ils donnent une forme utilisable à des années d’échanges dispersés. L’IA sert ici à organiser et à trier, plutôt qu’à inventer une liste de lectures sortie de nulle part.

Il reste une précaution importante : le classement des recommandations repose sur une interprétation automatique. Le contexte d’un commentaire peut être subtil, et un livre peut être confondu avec un autre. Si une fiche vous semble étrange, les discussions restent le meilleur endroit pour vérifier ce que les personnes voulaient dire. Il est également possible de signaler une erreur au créateur du site.

Enfin, HackerBooks n’est pas une bibliothèque de fichiers à télécharger : les fiches orientent vers des vendeurs de livres. Son intérêt est ailleurs, dans la découverte et dans l’accès aux échanges autour des ouvrages. Si vous avez envie d’apprendre quelque chose de nouveau, c’est une bonne porte d’entrée. Reste ensuite le plus difficile : choisir un livre, le commencer et aller jusqu’au bout.

Source : https://korben.info/hackerbooks-hackertube-hacker-news.html

Informatique

Trunk-based development : la fin des pull requests

2 novembre 2026 jeanmich Laisser un commentaire

Le trunk-based development revient dans les discussions dès qu’on parle de code produit avec l’aide de l’IA. Puisque les modifications arrivent plus vite, pourquoi attendre une pull request, une revue et une fusion pour les intégrer ? Mais supprimer une étape ne supprime pas le travail qu’elle accomplissait. Il faut décider où placer ce travail, et comment vérifier qu’il est bien fait.

Je préfère une petite modification intégrée rapidement à une grosse pull request qui attend plusieurs jours. Pour autant, je ne donnerais pas les clés de la branche principale à toute l’équipe au seul motif qu’un assistant IA aide à écrire le code. La vitesse est utile si elle réduit aussi le délai entre une erreur et sa détection.

Trunk-based development : ce qu’on change vraiment

Le principe du trunk-based development consiste à intégrer fréquemment de petites modifications dans une branche principale commune. On évite ainsi que chacun travaille trop longtemps dans son coin, avec une branche qui diverge progressivement du reste du projet. Ce n’est pas forcément « plus de branches du tout » : des branches très courtes peuvent garder leur place.

La différence importante se situe dans la taille et la durée de vie du travail isolé. Une branche ouverte pour quelques heures et une pull request relue rapidement restent compatibles avec cette logique. À l’inverse, une fonctionnalité complète développée pendant des semaines avant fusion rend l’intégration plus risquée, même si elle passe par une revue formelle.

Le débat « pull requests ou trunk » devient trompeur quand il oppose deux boutons dans une interface Git. Une pull request est un moyen de discuter et de contrôler une modification. Le trunk-based development est une manière d’organiser le flux de travail.

Ce que l’IA accélère, et ce qu’elle ne vérifie pas

Un assistant peut proposer du code, des tests ou une première explication d’un changement. C’est pratique pour avancer. Mais une proposition rapide n’est pas automatiquement une modification pertinente. Il reste à vérifier qu’elle répond au besoin, s’intègre au projet et ne dégrade pas un comportement moins visible.

C’est là que je serais prudent avec l’idée de rendre les pull requests obsolètes. Si l’IA augmente le volume de code produit, elle peut aussi augmenter le volume de code à comprendre. Déplacer ce volume directement sur la branche principale, sans ajuster les contrôles, ne me semble pas être un progrès.

Avant d’intégrer une modification, je garderais au minimum quelques questions en tête :

Le changement est-il assez petit pour être compris et annulé facilement ?
Les tests vérifient-ils le comportement qui compte, et pas seulement le chemin le plus évident ?
Une personne connaît-elle la raison du changement, même si l’IA a participé à son écriture ?
Que se passe-t-il si cette modification casse quelque chose après l’intégration ?

Ces questions ne réclament pas nécessairement une longue revue asynchrone. Elles réclament en revanche une réponse. Selon les équipes, elle peut prendre la forme d’une revue courte, d’un échange en binôme, de contrôles automatisés ou d’une combinaison des trois.

Comparaison visuelle entre branche longue et intégrations fréquentes sur le trunk

Des petits changements, pas des contrôles en moins

À mes yeux, le principal intérêt du trunk-based development n’est pas de gagner quelques clics dans Git. C’est de rendre chaque changement assez limité pour qu’on puisse le comprendre, le tester et, si besoin, revenir en arrière. La taille des modifications devient alors un outil de maîtrise du risque.

Prenons une fonctionnalité qui touche à la base de données, au traitement métier et à l’interface. Tout livrer d’un coup complique la revue comme le diagnostic en cas de problème. La découper en étapes cohérentes permet de vérifier chaque partie plus tôt. Mais il faut préparer ces étapes : un changement intermédiaire ne doit pas casser le fonctionnement existant.

Les feature flags peuvent aider à séparer l’intégration du code de l’activation d’une fonctionnalité. Le code rejoint la branche principale, tandis que la nouveauté reste désactivée pour les utilisateurs concernés jusqu’à ce qu’elle soit prête. Ce n’est pas une solution magique : les états activé et désactivé doivent être testés, et les flags devenus inutiles doivent être retirés.

Je retiens surtout une règle pratique : si une modification paraît impossible à intégrer sans tout terminer auparavant, il faut regarder si on peut la découper autrement. Ce n’est pas toujours facile, notamment lorsqu’une migration touche plusieurs composants. Mais cette difficulté mérite d’être traitée comme un problème de conception, pas cachée dans une branche de longue durée.

Ce qu’il faut préparer avant de changer de méthode

Intégrer plusieurs fois par jour suppose une branche principale sur laquelle l’équipe peut travailler sans appréhension. Pour y parvenir, il faut plus qu’une consigne du type « faites des petits commits ». Les tests doivent être utiles, leur résultat doit arriver assez vite, et un échec doit être pris en charge rapidement.

Je commencerais par observer le fonctionnement actuel plutôt que par interdire les pull requests. Combien de temps une modification attend-elle une revue ? Quelle taille font les changements difficiles à relire ? Quels tests échouent régulièrement sans signaler un vrai problème ? Ces questions montrent où le travail ralentit et où la confiance manque.

Ensuite, je ferais évoluer les habitudes progressivement :

Découper une tâche en changements plus petits, chacun avec un objectif compréhensible.
Automatiser les vérifications que l’équipe répète déjà à chaque revue.
Conserver une intervention humaine ciblée sur les choix de conception, les cas sensibles et les risques métier.
Prévoir comment désactiver une fonctionnalité ou revenir sur un changement problématique.
Vérifier régulièrement si le délai d’intégration baisse sans multiplier les incidents.

Ce dernier point est important. Une équipe peut fusionner beaucoup plus vite tout en passant davantage de temps à réparer. Elle n’a alors fait que déplacer l’attente : elle n’est plus devant la pull request, elle se retrouve après la mise en production.

Flux de vérification et d’intégration de petits changements de code

Faut-il vraiment supprimer les pull requests ?

Je ne le ferais pas par principe. Dans une petite équipe qui échange souvent, une revue rapide avant fusion peut rester légère et utile. Dans un projet ouvert aux contributions extérieures, la pull request offre aussi un espace clair pour expliquer le changement et en discuter. Et certains changements sensibles justifient un contrôle explicite avant d’atteindre la branche principale.

En revanche, une pull request qui reste ouverte longtemps parce que personne n’a le temps de la lire ne protège pas grand-chose. Elle accumule les conflits, retarde les retours et finit parfois par être validée dans l’urgence. Dans ce cas, la bonne réponse n’est pas nécessairement de supprimer les revues : c’est de réduire leur taille et de leur réserver une vraie place dans le travail de l’équipe.

L’IA rend cette discipline encore plus importante. Si produire une modification prend moins de temps, comprendre pourquoi elle existe et vérifier ses effets ne doit pas devenir une formalité. La responsabilité du code reste humaine, qu’il ait été écrit à la main ou suggéré par un outil.

Au fond, je ne choisirais pas entre « tout passe par une pull request » et « tout part directement sur le trunk ». Je chercherais le circuit le plus court qui permette encore de comprendre, tester et corriger chaque changement. C’est moins spectaculaire qu’une révolution des méthodes de développement, mais probablement plus utile au quotidien.

Source : https://alm.developpez.com/actu/388617/Des-developpeurs-estiment-que-les-Pull-Requests-sont-obsoletes-a-l-ere-de-l-IA-et-proposent-d-aller-au-Trunk-Based-Development-Tout-le-monde-integre-son-travail-sur-une-seule-branche-plusieurs-fois-par-jour/

Informatique

Claude bouscule les tests de recrutement des développeurs

31 octobre 2026 jeanmich Laisser un commentaire

Le recrutement des développeurs repose souvent sur un exercice bien connu : résoudre un problème de programmation sous les yeux d’un recruteur. Mais que mesure encore ce test lorsqu’une IA peut le réussir mieux que la plupart des candidats ? Chez Anthropic, un responsable a choisi de le retirer des entretiens de son équipe. Ce n’est pas la fin des évaluations techniques, mais c’est un signal intéressant sur ce qu’elles doivent désormais vérifier.

Pourquoi Claude change le recrutement des développeurs

Felix Rieseberg, qui a dirigé le développement technique de Claude.ai et de l’application de bureau Claude Code, a supprimé un entretien de code du processus de recrutement de son équipe. Son raisonnement est simple : Claude réussit désormais si bien ce type d’exercice que le résultat ne lui apporte plus assez d’informations utiles sur les candidats.

Un test de programmation avait pourtant un intérêt. Il permettait d’observer comment une personne comprenait une consigne, décomposait un problème et avançait vers une solution. Ce n’était pas une mesure parfaite de ses capacités, mais cela donnait un aperçu de sa manière de travailler. Si l’exercice ressemble surtout à un défi court et prévisible, sa réussite devient moins révélatrice.

Attention à la portée de cette décision : un responsable retire un test pour son équipe. Anthropic n’a pas annoncé la disparition de toutes ses évaluations techniques. La question n’est pas de savoir s’il faut encore tester les développeurs, mais comment le faire utilement.

Un test de code confronté aux capacités de Claude pour le recrutement des développeurs

Des exercices de plus en plus difficiles à calibrer

Une autre équipe d’Anthropic a rencontré le même problème avec un test à réaliser à domicile. Son responsable, Tristan Hume, a constaté que Claude Opus 4 obtenait de meilleurs résultats que la majorité des candidats dans le temps prévu. Il a d’abord augmenté la difficulté de l’épreuve.

Puis Opus 4.5 a atteint le niveau des meilleurs candidats sur cette nouvelle version. Une troisième mouture a donc été conçue autour de problèmes plus inhabituels, proches de jeux de réflexion, que le modèle n’est pas parvenu à résoudre. Cette succession de changements montre à quel point un test peut perdre rapidement sa valeur si les outils disponibles progressent plus vite que l’exercice lui-même.

Rendre une épreuve toujours plus difficile n’est toutefois pas forcément la meilleure réponse. Un problème très éloigné du travail quotidien peut départager des candidats sans aider à savoir qui saura maintenir une application, comprendre un besoin ou collaborer avec une équipe. Le bon test doit rester lié au poste, pas devenir une compétition de casse-têtes.

Que faut-il vraiment évaluer chez un développeur ?

Écrire du code n’est qu’une partie du métier. Dans un projet réel, il faut aussi choisir entre plusieurs solutions, lire l’existant, repérer les risques et expliquer ses décisions. L’arrivée d’assistants capables de produire rapidement une première réponse donne davantage de poids à ces compétences.

Une évaluation technique peut, par exemple, chercher à observer :

la façon dont le candidat clarifie un besoin avant de développer ;
sa capacité à relire, tester et corriger une solution ;
les compromis qu’il fait entre simplicité, performance et maintenance ;
sa manière d’expliquer ce qu’il comprend et ce qu’il vérifierait.

Ces pistes ne rendent pas les tests infaillibles. Elles déplacent simplement l’attention du résultat brut vers le raisonnement et les choix. Un programme qui fonctionne ne suffit pas toujours à montrer comment il se comportera une fois intégré à un produit utilisé et maintenu par d’autres.

Évaluation des compétences d'un développeur lors d'une discussion technique — Évaluation des compétences d’un développeur lors d’une discussion technique

Interdire l’IA ou adapter les entretiens ?

Anthropic interdit aux candidats d’utiliser Claude pendant les entretiens et les tests à domicile, sauf indication contraire. Cette règle vise à savoir ce qu’une personne peut faire elle-même. Elle ne résout pourtant qu’une partie du problème : même sans aide pendant l’épreuve, un exercice devenu trop facile pour l’IA peut ne plus distinguer efficacement les candidats.

Les entreprises cherchent aussi à encadrer davantage leurs évaluations. Dans une enquête menée auprès de 1 500 employeurs, 62,5 % des entreprises du secteur de l’information déclaraient demander des tests formels de compétences dès la candidature initiale. Environ 70 % avaient modifié leurs modalités, notamment avec des sessions surveillées ou en présentiel, pour limiter l’usage de l’IA.

La surveillance permet de fixer une règle claire, mais elle ne dispense pas de se demander ce que le test mesure réellement. À l’inverse, autoriser l’IA peut avoir du sens si l’objectif est d’observer comment un candidat utilise un outil, contrôle ses réponses et garde la maîtrise du résultat. Les deux approches répondent à des questions différentes.

Le test de code n’est pas mort, son objectif doit être clair

Claude ne rend pas les compétences des développeurs inutiles. Il remet en cause certains raccourcis utilisés pour les évaluer. Un petit exercice réussi rapidement ne dit pas nécessairement qui saura résoudre les problèmes d’une équipe sur la durée.

Pour les recruteurs, l’enjeu est de concevoir des épreuves proches du travail attendu et d’expliquer la place autorisée à l’IA. Pour les candidats, il reste essentiel de pratiquer, de comprendre leur code et de pouvoir défendre leurs choix. Les outils évoluent ; la capacité à bien poser un problème et à juger une solution reste, elle, au cœur du métier.

Source : https://www.tomshardware.fr/claude-est-devenu-trop-fort-anthropic-supprime-un-test-de-recrutement-pour-ses-developpeurs/

Informatique, Sécurité

Sécuriser le Wi‑Fi au boulot : le guide ANSSI

6 septembre 2026 jeanmich Laisser un commentaire

Sécuriser le Wi‑Fi en entreprise, ce n’est pas “juste” changer un mot de passe. C’est un ensemble de réflexes côté utilisateurs, de réglages côté infrastructure et de choix techniques cohérents. L’ANSSI vient de publier un guide pratique pour réduire les risques de piratage sur les réseaux sans fil professionnels.

Trois volets : salariés, réseau maîtrisé, administration des points d’accès

Le document de l’ANSSI s’organise autour de trois axes. D’abord, les habitudes des salariés : ce sont souvent elles qui ouvrent la porte aux incidents. Ensuite, le principe de base : ne se connecter qu’à des réseaux maîtrisés par l’entreprise. Enfin, l’administration sécurisée des points d’accès, avec des réglages précis.

L’idée est simple : si vous sécurisez le Wi‑Fi “sur le papier” mais que les usages réels contournent les règles, le risque reste entier. Le guide insiste donc sur l’alignement entre politique interne et configuration technique.

Les bons réflexes côté utilisateurs (ce qui évite la majorité des galères)

Pour les usages quotidiens, l’ANSSI recommande plusieurs actions concrètes. L’objectif : limiter l’exposition quand un employé est en mobilité ou utilise son ordinateur portable en dehors du périmètre habituel.

Couper l’interface Wi‑Fi et le partage de connexion quand ils ne servent pas.
Désactiver la connexion automatique aux réseaux déjà mémorisés.
Ne se brancher que sur des réseaux réellement maîtrisés (ceux que l’entreprise contrôle).
Si vous ne pouvez pas éviter un hotspot public : utiliser le VPN de l’entreprise.

Autre point très pragmatique : configurer le pare-feu local des ordinateurs portables pour bloquer les connexions entrantes, notamment via le Wi‑Fi. Enfin, avant de reconditionner, céder ou mettre au rebut

un appareil professionnel, il faut effacer les réseaux enregistrés et les mots de passe associés. Sinon, vous laissez des accès réutilisables “hors contrôle”.

Changements indispensables sur l’infrastructure : WPS, UPnP et réseaux invités

Sur le plan infrastructure, l’ANSSI est claire : certains mécanismes doivent être désactivés par défaut, car ils augmentent la surface d’attaque.

Désactiver WPS sur les points d’accès.
Désactiver UPnP si personne ne l’utilise.
Interdire l’usage d’un hotspot personnel au bureau.
Bloquer par défaut les terminaux non maîtrisés (ex. téléphones personnels), et n’ouvrir qu’un réseau Wi‑Fi invité dédié et cloisonné.

Le cloisonnement n’est pas un détail : il sert à empêcher qu’un appareil “invité” ou moins contrôlé puisse interagir avec le reste du système d’information. En pratique, vous séparez les chemins de communication et vous réduisez les conséquences d’un incident.

Le chiffrement : WPA3 en priorité, et des conditions strictes pour WPA2

Le guide rappelle que le chiffrement reste un pilier. L’ANSSI pousse vers des protocoles robustes, en particulier WPA3‑Enterprise, WPA2‑Enterprise sous conditions, ou WPA3‑Personal.

En WPA3‑Enterprise, l’ANSSI recommande des suites EAP compatibles avec une authentification par certificats. Et surtout : il faut vérifier la validité des certificats avant chaque connexion.

En WPA2‑Enterprise, le choix dépend de conditions précises. L’important, c’est la logique : plus l’authentification est forte et contrôlée, moins le réseau est vulnérable aux contournements.

Un plan d’action simple pour sécuriser le Wi‑Fi en entreprise

Si vous devez passer à l’action, vous pouvez structurer votre démarche en trois étapes. L’objectif n’est pas de tout faire d’un coup, mais de traiter les points qui réduisent le risque le plus vite.

Cartographier les usages : où les salariés se connectent-ils réellement ? Quels réseaux sont “mémorisés” ? Qui utilise le Wi‑Fi invité ?
Durcir la configuration : désactiver WPS, désactiver UPnP si inutile, bloquer les terminaux non maîtrisés, mettre en place un Wi‑Fi invité cloisonné.
Renforcer l’authentification et le chiffrement : viser WPA3‑Enterprise, et encadrer strictement les déploiements WPA2‑Enterprise.

Ajoutez à cela une règle d’hygiène : quand un poste change de propriétaire ou de statut, on efface les réseaux et identifiants enregistrés. Ce point est souvent oublié, alors qu’il est directement lié à la prévention des réutilisations non autorisées.

Pourquoi ces recommandations sont “plus que jamais utiles”

Le Wi‑Fi est devenu un point d’entrée naturel : il est pratique, omniprésent, et parfois utilisé sans réfléchir aux conséquences. Le guide de l’ANSSI remet les priorités au bon endroit : réduire les connexions non maîtrisées, durcir l’infrastructure et choisir des mécanismes de chiffrement et d’authentification solides.

En bref : sécuriser le Wi‑Fi en entreprise, c’est aligner les comportements et les paramètres techniques. Et c’est précisément ce que ce type de recommandations rend possible.

Prochaine étape : faites un audit rapide de vos points d’accès (WPS/UPnP, segmentation invité) puis vérifiez vos règles d’usage (VPN, désactivation de la connexion automatique, pare-feu). Vous gagnerez en sécurité sans complexifier inutilement le quotidien.

Source : https://www.clubic.com/actualite-627604-wi-fi-au-boulot-l-anssi-rappelle-son-mode-d-emploi-anti-piratage-plus-que-jamais-utile.html

Informatique

WizTree : le logiciel qui révèle enfin “Autres”

5 septembre 2026 jeanmich Laisser un commentaire

WizTree répond enfin à la question que Windows esquive quand votre disque se remplit : “qu’est-ce qui prend toute la place ?”. Là où l’outil de stockage de Windows vous laisse face à une catégorie fourre-tout, WizTree pointe les coupables avec une rapidité impressionnante.

Concrètement, si vous avez déjà vu votre espace disparaître au fil des caches, des vidéos oubliées et des dossiers de projets jamais purgés, vous allez comprendre pourquoi “Autres” devient vite frustrant. WizTree, lui, vous montre le fichier précis et vous permet d’agir.

Pourquoi Windows vous cache la vérité (“Autres”)

Sur un PC Windows, l’espace disque ne s’évapore pas “magiquement”. Il se déplace : fichiers temporaires, téléchargements qui s’accumulent, rushs vidéo, archives, doublons… Le problème, c’est que Windows regroupe souvent ces éléments dans une catégorie vague, “Autres”. Résultat : vous savez que ça prend de la place, mais vous ne savez pas quoi supprimer.

WizTree change la donne. Il lit directement l’index central du système de fichiers, ce qui lui permet de cartographier le disque sans passer par une longue tournée dossier par dossier.

Le principe de WizTree : lire l’index NTFS, pas parcourir tout

Sur un volume NTFS, chaque fichier est référencé dans la Master File Table (MFT), l’index que Windows maintient en continu. La plupart des analyseurs classiques explorent l’arborescence en parcourant les dossiers. WizTree, lui, exploite la MFT : il “lit l’inventaire” au lieu de faire le tour des pièces.

Le résultat se ressent immédiatement : sur des disques de plusieurs téraoctets, l’analyse peut arriver très vite, là où un scan classique peut prendre des minutes.

Schéma pédagogique de la lecture de l’index NTFS (MFT) vers la liste des fichiers lourds

Ce que WizTree affiche vraiment (et pourquoi c’est utile)

WizTree ne se contente pas de dire “ça fait X Go”. Son interface vous aide à diagnostiquer et prioriser.

Arborescence par taille : vous descendez du gros au détail, jusqu’au fichier individuel.
Treemap : chaque fichier devient un rectangle proportionnel à son poids. Les gros éléments ressortent visuellement, sans effort.
Vue par extensions : pratique pour repérer rapidement des masses entières (par exemple des images ISO, des archives, des vidéos, etc.).
Recherche et tri : pour retrouver un nom, classer par taille, et accélérer le ménage.
Détection de doublons : WizTree repère les fichiers en double, ce qui évite de supprimer “à l’aveugle”.

Autre point pratique : vous pouvez relancer l’analyse sur un dossier précis, un disque entier ou l’ensemble des volumes montés. Et il existe aussi une version portable, utile quand vous dépannez un PC familial sans vouloir installer quoi que ce soit.

Treemap, doublons et gros fichiers : la différence avec les outils classiques

Les outils historiques du genre (comme WinDirStat ou TreeSize) restent utiles, mais leur méthode de parcours dossier par dossier peut pénaliser sur les gros volumes. WizTree adopte une approche plus directe et, surtout, rend l’information plus actionnable.

Quand vous cherchez “ce qui remplit”, vous n’avez pas besoin d’un rapport abstrait. Vous avez besoin de chemins, de tailles, et d’une vue qui vous fait comprendre en quelques secondes où agir. La treemap et la liste des fichiers lourds font exactement ce travail.

Et si votre problème vient de doublons, WizTree vous donne un levier immédiat : vous identifiez les répétitions, puis vous passez à l’étape suivante (par exemple avec un outil dédié au ménage de doublons).

Treemap WizTree mettant en évidence les gros fichiers responsables de l’espace disque manquant

Les limites à connaître avant de lancer WizTree

WizTree est particulièrement efficace sur les volumes NTFS, car son approche repose sur la lecture de l’index associé. Si vous utilisez un support en exFAT ou un lecteur réseau, WizTree repasse par un scan plus “classique”, donc potentiellement plus lent.

Autre réflexe utile : avant d’acheter un SSD plus grand, vérifiez si la place existe déjà… mais qu’elle est simplement mal rangée. Dans beaucoup de cas, le “manque” vient d’un stockage dispersé : des archives, des caches, des médias et des projets qui n’ont jamais été consolidés.

Mon conseil : une méthode simple pour reprendre la main

Pour que WizTree serve vraiment à quelque chose, je vous recommande une démarche en trois temps :

Repérez les 10 plus gros éléments (treemap + tri par taille). Ne cherchez pas tout : commencez par l’impact.
Contrôlez les doublons avant de supprimer. Si vous supprimez sans vérifier, vous risquez de casser un projet ou de perdre un fichier “utile”.
Nettoyez par catégories : archives, médias, caches, téléchargements. Une fois le gros fait, le reste devient facile.

Vous verrez alors disparaître la frustration du “Autres” : vous saurez enfin ce qui prend la place, et vous pourrez décider quoi garder, quoi déplacer, et quoi supprimer.

Conclusion : WizTree rend l’espace disque compréhensible

WizTree ne fait pas que “montrer” : il explique et oriente. En affichant rapidement les fichiers responsables, il transforme un problème flou (“mon disque est plein”) en actions concrètes (où regarder, quoi trier, quoi supprimer).

Et si vous avez déjà vécu cette scène où Windows vous répond “Autres”, vous savez : la meilleure victoire, c’est de retrouver de la clarté. La prochaine étape, c’est d’instaurer un petit rituel de ménage pour éviter que “Autres” ne revienne trop vite.

Source : https://www.clubic.com/actualite-627415-microsoft-n-a-jamais-su-dire-ce-qui-remplit-votre-disque-un-logiciel-gratuit-le-fait-en-un-clic.html

NAS & Stockage

Synology : redémarrer un conteneur Docker gourmand en RAM

5 septembre 2026 jeanmich Laisser un commentaire

Quand la RAM de votre NAS Synology baisse jour après jour, la cause n’est pas toujours évidente. Dans beaucoup de cas, ce sont des conteneurs Docker qui finissent par devenir plus gourmands avec le temps. La bonne nouvelle : un redémarrage un conteneur Docker peut remettre d’aplomb votre système, et vous pouvez même automatiser l’opération.

Dans ce guide, je vous montre une méthode simple : repérer ce qui consomme le plus, confirmer au niveau projet/containeur, puis redémarrer manuellement ou planifier le redémarrage pour éviter la dérive.

1) Commencez par identifier le plus gros consommateur de RAM

Avant de redémarrer quoi que ce soit, il faut savoir qui consomme. Sur DSM, le point de départ le plus efficace reste le Moniteur de ressources.

Procédez ainsi :

Ouvrez Moniteur de ressources depuis le menu principal.
Allez dans Performances.
Dans le menu de gauche, sélectionnez Gestionnaire des tâches.
Ouvrez l’onglet Processus.
Cliquez deux fois sur la colonne Mémoire privée pour trier par ordre décroissant.

Vous obtenez alors une vue claire : application native, paquet installé… ou conteneur Docker.

Moniteur de ressources DSM triant les processus par mémoire privée

2) Confirmez au niveau Projet / Conteneur (Docker)

Une fois que vous avez repéré un acteur “suspect” dans le Moniteur de ressources, l’étape suivante consiste à confirmer précisément le conteneur responsable.

Tout dépend de votre déploiement :

Cas A : votre conteneur fait partie d’un projet

Si votre application Docker est organisée en projet (par exemple via Container Manager), vous pouvez vérifier la consommation directement au bon niveau.

Ouvrez Container Manager.
Dans le menu de gauche, allez sur Projets.
Recherchez le projet concerné (ex. votre stack).
Ouvrez le projet, puis allez dans l’onglet Statistiques.
Par défaut, l’affichage est souvent sur CPU. Basculez sur RAM pour voir la consommation mémoire des conteneurs du projet.

Cas B : votre conteneur tourne “tout seul”

Si vous n’avez pas de notion de projet (conteneur isolé), le contrôle se fait directement sur l’objet conteneur.

Dans Container Manager, allez dans Conteneur.
Sélectionnez le conteneur concerné.
Ouvrez l’onglet Statistiques pour vérifier la consommation mémoire.

À ce stade, vous savez exactement quel conteneur redémarrer.

3) Redémarrer un conteneur Docker manuellement (le plus simple)

Quand un conteneur devient trop gourmand, le redémarrage manuel est souvent la solution la plus rapide. Sur DSM, l’interface Container Manager permet de le faire en quelques clics.

Procédure :

Dans Container Manager, ouvrez le menu Conteneur.
Sélectionnez le conteneur concerné (ou faites un clic droit).
Cliquez sur le bouton Action (en haut à droite).
Choisissez Redémarrer.

Si vous préférez repartir sur l’ensemble d’une stack, vous pouvez aussi redémarrer un projet complet : ouvrez le projet, puis Action > Redémarrer.

Astuce : observez ensuite la RAM dans le Moniteur de ressources pour vérifier que le “pic” retombe.

4) Automatiser : planifier un redémarrage hebdomadaire

Si vous constatez une dérive régulière (par exemple “après quelques jours”), l’automatisation peut vous faire gagner du temps. L’idée : redémarrer un conteneur Docker une fois par semaine, à un moment où l’impact est minimal.

Mais il faut être prudent : un redémarrage peut interrompre un service (envoi de documents, lecture vidéo, etc.). Choisissez donc un horaire “creux”. L’exemple classique est 5h du matin.

Le chemin dans DSM

Pour créer la tâche planifiée :

Allez dans Panneau de configuration > Planificateur de tâche.
Cliquez sur Créer.
Choisissez Tâche planifiée > Script défini par l’utilisateur.
Donnez un nom personnalisé (sans caractères spéciaux ni accent).
Choisissez root comme utilisateur.
Dans l’onglet Programmer, configurez Répéter sur Toutes les semaines.
Sélectionnez le jour souhaité.

Ensuite, vous ajoutez le script qui déclenche le redémarrage.

Anticipez les notifications

Un redémarrage programmé peut générer une notification d’arrêt dans DSM. Selon vos réglages, cela peut aussi déclencher des notifications par e-mail ou via l’application mobile. Autrement dit : vérifiez vos paramètres pour éviter d’être noyé de messages.

5) Bonnes pratiques pour éviter de “masquer” un vrai problème

Redémarrer un conteneur est une mesure de stabilisation. C’est utile, mais ça ne remplace pas une analyse si la RAM continue de grimper rapidement.

Voici comment garder une approche saine :

Surveillez : observez la RAM après redémarrage et notez la durée avant la prochaine dérive.
Vérifiez la stack : si votre application est composée de plusieurs conteneurs, identifiez celui qui “prend” la mémoire.
Planifiez intelligemment : un redémarrage hebdomadaire à heure fixe limite l’impact utilisateur.
Évitez de redémarrer “au hasard” : commencez toujours par trier par Mémoire privée dans le Moniteur de ressources.

Graphique RAM qui se stabilise après redémarrage d’un conteneur Docker

Checklist rapide : la méthode en 5 minutes

Si vous voulez une procédure “terrain”, gardez cette checklist sous la main :

Ouvrez Moniteur de ressources > Gestionnaire des tâches > Processus.
Trier par Mémoire privée (ordre décroissant).
Repérez le conteneur ou l’application suspecte.
Confirmez dans Container Manager (Projet > Statistiques sur RAM, ou Conteneur > Statistiques).
Redémarrez manuellement, puis observez l’effet. Si c’est récurrent, planifiez un redémarrage hebdomadaire.

Conclusion : stabiliser, puis comprendre

Quand un conteneur Docker devient gourmand en RAM sur Synology, redémarrer un conteneur Docker est souvent la solution la plus rapide pour retrouver de la marge. En combinant tri des processus, vérification dans Container Manager et planification, vous reprenez le contrôle sans subir la dérive.

Et si la consommation revient trop vite, utilisez ces mêmes étapes pour affiner : vous saurez exactement quel composant surveiller en priorité.

Source : https://www.cachem.fr/synology-redemarre-conteneur/

Divers, Uncategorized

Pourquoi nos yeux sautent des mots en lisant

30 août 2026 jeanmich Laisser un commentaire

Quand on lit, nos yeux ne “balayent” pas le texte de façon continue. Ils saccadent, se fixent brièvement… puis sautent certains mots. Et ce n’est pas un hasard : une équipe de chercheurs a entraîné un modèle d’IA pour reproduire ces mouvements et surtout expliquer pourquoi les yeux sautent des mots.

Lire, ce n’est pas regarder tout le texte

Le point de départ est simple : lors de la lecture, l’œil avance par fixations courtes, séparées par des saccades. Entre ces moments, une partie des mots n’est jamais fixée directement. Autrement dit, on ne “lit” pas chaque mot au sens visuel du terme : on sélectionne.

Jusqu’ici, plusieurs explications reposaient sur des règles assez fixes (par exemple liées à la longueur ou à la fréquence des mots). Le modèle présenté ici propose une approche plus souple : chaque décision de regard serait traitée comme un choix pris sous contrainte.

Fixations et saccades : certains mots ne sont pas fixés directement

Le modèle d’IA : décider quoi fixer, sous incertitude

Le cœur de la démarche consiste à traiter la lecture comme une suite de décisions. À chaque étape, le modèle évalue l’intérêt d’ajouter une fixation supplémentaire, en tenant compte du temps que cela coûte.

Concrètement, l’IA raisonne à trois niveaux :

le mot (ce qui est probable à venir),
la phrase (le contexte syntaxique),
le texte (la structure globale et l’orientation du sens).

Cette logique s’appuie sur une idée issue de la théorie de la décision : si le gain d’information attendu ne compense pas le coût temporel, l’œil a plus de chances de ne pas s’attarder sur certains mots.

Pourquoi les mots “faciles” sont plus souvent sautés

Le résultat le plus parlant concerne les mots qui semblent “prévisibles” pour le lecteur. Plus la confiance du modèle envers un mot à venir est élevée, plus ce mot risque d’être sauté.

Dans les données, ce sont surtout :

les mots courts,
les mots fréquents,
les mots prévisibles dans le contexte.

La tendance suit une logique intuitive : la probabilité de saut diminue quand le mot est plus long, et augmente quand il est plus fréquent. Autrement dit, si le cerveau (et ici le modèle) anticipe déjà ce mot, il n’a pas forcément besoin de le “vérifier” par une fixation directe.

Le rôle de la longueur et de la fréquence sur la fixation

Les modèles cognitifs plus anciens reliaient souvent fréquence et prévisibilité à des mouvements oculaires via des règles déterministes. Ici, l’idée est différente : la durée de fixation sur un mot augmente avec sa longueur, et diminue avec sa fréquence ou sa prévisibilité.

On observe aussi des régularités dans la manière dont l’œil se pose : il revient généralement entre le début et le milieu du mot, une constante appelée position de lecture préférée. Et quand la phrase comporte une ambiguïté syntaxique, le regard a davantage tendance à faire des retours en arrière.

Quand le temps manque, les mots sont davantage sautés et les retours en arrière changent

Lecture sous contrainte : quand le temps manque, on optimise

Un autre apport important est la prise en compte du temps. Les chercheurs ont testé le mécanisme dans des conditions où la lecture doit se faire vite : des participants lisent des textes avec des limites de temps, puis répondent à des questions de compréhension.

Quand le temps augmente, on observe chez les humains une baisse de la vitesse de lecture. En parallèle, le taux de mots sautés recule et les retours en arrière (les régressions) augmentent. La compréhension progresse aussi.

Le modèle reproduit ces tendances : il “apprend” à adapter ses décisions quand la contrainte temporelle change. L’idée générale est que la lecture devient un arbitrage entre :

couverture (avancer en sautant davantage, pour garder une vue d’ensemble),
précision (investir plus de fixations et de retours quand on a le temps).

En situation de temps limité, l’œil privilégie la compréhension globale plutôt que le détail mot à mot.

Ce que ça change (vraiment) pour comprendre la lecture

Ce travail ne dit pas “les yeux sautent des mots parce que…”, comme une règle unique. Il montre plutôt une mécanique : la lecture ressemble à une gestion rationnelle des ressources sous incertitude.

On peut en tirer une lecture pratique : si un texte contient des mots très prévisibles, le lecteur peut les traiter sans fixation directe. À l’inverse, quand le contexte est ambigu ou que l’information est moins anticipable, l’œil revient, vérifie, et investit davantage.

Conclusion : des sauts qui servent la compréhension

Les yeux sautent des mots parce que lire, c’est décider quoi vérifier et quoi laisser passer, selon ce qui est probable et selon le temps disponible. L’IA met en lumière un principe : la lecture n’est pas une capture exhaustive du texte, mais une stratégie d’optimisation.

Et si vous voulez améliorer votre compréhension (ou concevoir des contenus plus lisibles), la question n’est peut-être pas “comment faire lire chaque mot”, mais plutôt “comment réduire l’ambiguïté et guider l’anticipation”.

Source : https://www.clubic.com/actualite-626332-une-ia-apprend-pourquoi-nos-yeux-sautent-des-mots-quand-nous-lisons.html

Intelligence artificielle

IA pirate “anonyme”

29 août 2026 jeanmich Laisser un commentaire

La promesse d’une IA pirate anonyme “sans compte, sans JavaScript, sans traces” peut sembler séduisante. Mais quand on regarde de près ce que le service permet réellement de produire, la confidentialité devient surtout un accélérateur de risque.

Une IA présentée comme “privée” et sans garde-fous

Le service testé par ZATAZ, baptisé DONG (pseudonyme), revendique une utilisation sans informations personnelles. Il ne demande pas de compte classique et annonce que les requêtes seraient exécutées hors ligne, directement sur le matériel de l’opérateur. L’identification reposerait sur un jeton, au format “DONGxxxxxx”, à conserver pour retrouver ses conversations.

Sur le papier, l’idée est claire : réduire les données persistantes et limiter les liens directs entre une identité civile et l’usage. L’historique pourrait aussi être effacé à tout moment, et les comptes supprimés après trois mois d’inactivité.

Jeton stylisé et bouclier barré pour illustrer l’absence de garde-fous d’une IA pirate anonyme

Le vrai sujet : ce que l’IA laisse faire

Le point le plus préoccupant concerne les capacités de génération observées pendant les tests. Là où une IA “grand public” applique généralement des garde-fous, DONG semble au contraire laisser passer des usages manifestement problématiques (ZATAZ cite notamment la génération de contenus sexuels extrêmes et la création d’un outil de type “info-stealer”).

Monétisation et orientation “blackmarket”

Autre signal : un modèle commercial avec des bandeaux publicitaires, facturés 1 000 $ par mois, qui renverraient vers des services pirates et des offres de blackmarket. Autrement dit, la confidentialité revendiquée ne sert pas seulement à “protéger l’utilisateur” : elle peut aussi faciliter l’écosystème.

Ce qu’on doit retenir (et surveiller)

Moins de traces ≠ moins de risques.
“Zéro filtre” est un drapeau rouge, surtout pour la génération de contenus.
La monétisation via la publicité peut indiquer une finalité d’audience.

Dans la veille cyber, ce type d’outil mérite une attention particulière : la promesse d’anonymat ne remplace pas l’évaluation des garde-fous et des usages réels. Prochaine étape : vérifier comment ces services évoluent et quels nouveaux mécanismes de contrôle (ou d’absence de contrôle) apparaissent.

Source : https://www.zataz.com/lia-pirate-qui-promet-anonymat-et-zero-filtre/

Informatique

Jellyfin perd ses figures historiques : que faire ?

18 août 2026 jeanmich Laisser un commentaire

Jellyfin est un pilier de l’auto-hébergement multimédia : gratuit, libre, et porté par une communauté. Mais en juillet 2026, le projet a perdu trois de ses visages les plus anciens en seulement quatre jours. Pour les utilisateurs, ce n’est pas un simple fait divers : c’est un signal à prendre au sérieux, sans paniquer.

Ce qui s’est passé, concrètement

D’après les informations disponibles, deux cofondateurs et un chef de projet ont annoncé leur départ sur le forum officiel, avec des dates rapprochées. Le premier départ remonte au 17 juillet, puis deux autres annonces suivent trois jours plus tard. Les raisons évoquées ne sont pas identiques : épuisement, priorités personnelles, et une friction liée à la manière de travailler.

Ce point est important : quand plusieurs personnes clés quittent un projet, ce n’est pas forcément un “drame technique”. Cela peut aussi refléter une fatigue humaine, un changement de cap, ou des désaccords de méthode. Dans tous les cas, l’utilisateur doit regarder au-delà de l’événement et évaluer la continuité.

Départs de mainteneurs et continuité d’un projet libre

Pourquoi ces départs comptent pour les utilisateurs

Un serveur multimédia comme Jellyfin dépend de plusieurs couches : le code, la maintenance, la documentation, et l’écosystème des clients (web, mobile, TV). Quand des profils historiques partent, la question devient : qui assure le quotidien et la trajectoire du projet ?

Trois impacts potentiels reviennent souvent dans ce type de situation :

Rythme de développement : moins de contributions sur certaines fonctionnalités, le temps que la coordination se stabilise.
Priorités : certaines améliorations peuvent être replanifiées, d’autres accélérées selon les nouveaux contributeurs.
Risque de fragmentation : même si ce risque n’est pas automatique, il existe toujours quand la gouvernance change.

À ce stade, l’élément rassurant est que la passation est présentée comme amicale et que l’équipe en place continue d’assurer l’essentiel. Mais “rassurant” ne veut pas dire “inutile de se préparer”.

Le contexte : l’auto-hébergement multimédia n’est pas figé

Le duel Plex/Jellyfin a longtemps structuré le paysage : Plex s’appuie sur une logique d’abonnement, tandis que Jellyfin revendique une approche libre et communautaire. Historiquement, ce modèle attire des contributeurs… mais il expose aussi le projet à une réalité : la disponibilité des bénévoles n’est pas garantie dans le temps.

Le texte source évoque aussi un précédent marquant dans le monde des serveurs multimédia : des bascules de code vers du fermé peuvent survenir, et elles changent la confiance des utilisateurs. Autrement dit, la meilleure stratégie n’est pas d’espérer que “ça ira toujours”, mais de réduire sa dépendance à un seul point de fragilité.

Comment évaluer le risque pour votre installation Jellyfin

Si vous utilisez Jellyfin en production personnelle (famille, maison, ou usage régulier), vous pouvez adopter une grille simple. L’idée : repérer tôt si la maintenance se dégrade.

Regardez l’activité récente : commits, issues, réponses sur le forum, fréquence des corrections.
Surveillez les releases : des mises à jour régulières indiquent une capacité de maintenance.
Vérifiez la stabilité des clients : web, mobile et TV doivent rester compatibles avec le serveur.
Testez avant de mettre à jour : idéalement sur une instance de préproduction ou un environnement de test.
Gardez une stratégie de repli : sauvegardes, export de configuration, et connaissance des alternatives.

Ces actions ne demandent pas d’être développeur. Elles demandent surtout de la méthode.

Checklist de bonnes pratiques pour sécuriser un serveur multimédia

Bonnes pratiques pour sécuriser votre auto-hébergement

Au-delà de Jellyfin lui-même, l’enjeu est votre continuité de service. Voici des pratiques qui réduisent l’impact d’un changement de mainteneur, d’une rupture de rythme ou d’un bug :

Sauvegardez : configuration, base de données si applicable, et fichiers de médias (au moins via une stratégie de copie).
Documentez : comment vous déployez Jellyfin, vos paramètres réseau, vos intégrations (reverse proxy, authentification, etc.).
Isoler les dépendances : reverse proxy et certificats gérés proprement, pour éviter que tout casse en cascade.
Planifiez les mises à jour : une fenêtre de maintenance, même courte, vaut mieux qu’une mise à jour “au fil de l’eau”.
Gardez un œil sur la communauté : forums, discussions, et retours d’utilisateurs donnent souvent une image plus fiable que les annonces seules.

Le but n’est pas de “se préparer au pire”. Le but est de rester maître de votre installation.

Faut-il quitter Jellyfin ?

À mon avis, non : quitter un outil ne se décide pas sur un épisode de départs, mais sur une observation de la trajectoire. Les annonces évoquent une passation et une continuité, ce qui est déjà un signal positif.

En revanche, je recommande de passer en mode “gestion du risque” : vérifiez l’activité, gardez vos sauvegardes, et testez vos mises à jour. Si vous constatez une baisse durable de maintenance ou des signaux de fragmentation, alors seulement il faudra envisager une alternative.

Conclusion : continuité d’abord, vigilance ensuite

La perte de figures historiques de Jellyfin rappelle une évidence : un projet libre vit au rythme des personnes qui le portent. Pour les utilisateurs, la bonne réponse n’est ni la panique ni l’indifférence, mais une vigilance structurée.

La suite dira si la communauté absorbe bien ces départs et maintient la dynamique. En attendant, gardez votre installation sous contrôle : sauvegardes, tests, et suivi de l’activité.

Source : https://www.clubic.com/actualite-622858-jellyfin-perd-ses-trois-figures-historiques-l-alternative-libre-a-plex-vacille.html

Informatique

Home Assistant : retour domotique (mini PC + IA)

17 août 2026 jeanmich Laisser un commentaire

Le Home Assistant de Korben a connu un cycle classique : ça marche, puis ça se dégrade, puis ça finit par lasser. Cette fois, il a changé deux choses clés : la machine (mini PC sur SSD au lieu de Raspberry Pi sur carte SD) et la façon de créer les automatisations (avec une IA qui parle en français). Résultat : moins de pannes, plus de scénarios, et surtout un système qui tient mieux dans la durée.

Pourquoi Korben a décroché (et ce qui l’a relancé)

Dans son retour, Korben explique qu’il aime l’idée des automatisations, mais que l’expérience précédente était frustrante. Les Raspberry Pi finissaient par corrompre les cartes SD, ce qui entraînait des arrêts et des redémarrages à répétition. À cela s’ajoutait un autre frein : le temps nécessaire pour régler des scénarios “au poil de cul”.

Le déclic arrive avec un contexte favorable : déménagement, cartons à vider, réinstallation du matériel, et surtout un mini PC disponible. Korben a aussi un angle “nouveautés” : l’arrivée de l’IA dans son quotidien et l’usage d’Alexa, qui rendent la domotique plus facile à intégrer dans ses habitudes.

Mini PC dédié pour faire tourner Home Assistant de façon fiable

Étape 1 : le mini PC sur SSD, le vrai changement de fond

Le point de départ, c’est un mini PC NiPoGi Pinova P1 (Ryzen 3 4300U, 16 Go de RAM, 1 To de SSD) que Korben avait acheté en 2023. Il le décrit comme surdimensionné pour la domotique… et c’est justement pour ça que c’est un bon choix : la domotique n’a pas besoin de puissance, elle a besoin de fiabilité.

Le problème historique de ses installations, c’était le stockage : une carte SD qui “rend l’âme” après quelques mois d’écritures permanentes. En passant sur un SSD, Korben supprime la cause la plus fréquente de ses arrêts. Ce n’est pas spectaculaire, mais c’est exactement le genre de détail qui change tout.

Home Assistant OS : moins d’administration, plus de sérénité

Korben installe Home Assistant OS sur la machine. Son intérêt est clair : HAOS agit comme un système dédié, sans Linux à administrer en dessous et sans Docker à maintenir. Il y retrouve aussi le magasin d’add-ons et les sauvegardes automatiques, ce qui réduit la charge mentale.

Pour lui, sur une machine dédiée, c’est “le mode le plus tranquille”. Et quand on a déjà vécu des pannes, la tranquillité devient une fonctionnalité à part entière.

Les deux pièges à connaître avant de démarrer

Dans son retour, Korben insiste sur des points qui peuvent faire perdre du temps :

BIOS/boot : HAOS exige le mode UEFI activé et le Secure Boot désactivé. Sinon, la clé USB ne boote pas.
Redémarrage après coupure : il faut régler “Restore on AC Power Loss / After Power Failure / AC Back Function” sur Power On. Sinon, une micro-coupure peut laisser la maison sans domotique jusqu’à une action manuelle.

Ce deuxième point est particulièrement parlant : Korben explique qu’en vacances, on n’a pas envie de dépendre d’un bouton à distance.

Étape 2 : brancher l’IA pour créer des automatisations sans YAML

Une fois le socle stable, Korben s’attaque au sujet qui le freinait : créer des scénarios rapidement, sans passer des heures à écrire et ajuster du YAML. Son approche repose sur Claude Code connecté à Home Assistant via un serveur MCP.

Le résultat qu’il décrit est concret : il crée 21 automatisations en quelques jours en décrivant ses besoins en français, sans écrire de YAML. L’objectif n’est pas de “remplacer” la domotique, mais de réduire le coût d’entrée pour produire des scénarios fonctionnels.

Ce que Korben gagne avec cette méthode

Vitesse : passer de l’idée au scénario sans friction technique.
Itération : ajuster plus facilement quand un comportement ne correspond pas exactement à l’attendu.
Focus : moins de temps sur la syntaxe, plus de temps sur la logique métier (présence, sécurité, confort).

Dans son retour, on sent surtout un changement d’énergie : la domotique redevient un projet “plaisir” plutôt qu’un chantier de correction permanent.

Capteur mmWave de présence et logique de garde-fou pour éviter les faux positifs

Étape 3 : capteur mmWave et garde-fous contre les faux positifs

Korben ajoute un capteur mmWave (Moes) pour détecter la présence. Son point de vue est nuancé : il détecte une présence statique, contrairement à des PIR classiques qui réagissent surtout au mouvement.

Mais il ne vend pas ça comme une baguette magique. Il explique que le capteur peut se “verrouiller” sur des échos fantômes, ce qui peut provoquer des faux positifs. Et c’est là que son approche devient intéressante : il ne cherche pas à “forcer” le capteur, il cherche à sécuriser le système autour de lui.

Le principe : automatisation de garde-fou

Son retour insiste sur une idée simple : quand un capteur peut se tromper, il faut prévoir un comportement de secours. Autrement dit, une logique de garde-fou évite qu’une détection erronée déclenche des actions indésirables.

Ce point est typique des installations qui tiennent dans le temps : on ne supprime pas l’imperfection du monde réel, on la contient.

Ce que Korben retient : fiabilité d’abord, puis productivité

En filigrane, le retour de Korben raconte une progression. D’abord, il remet la domotique sur des bases fiables (SSD + HAOS + redémarrage après coupure). Ensuite, il accélère la création de scénarios avec l’IA, pour ne plus subir la partie la plus pénible. Enfin, il traite les capteurs “imparfaits” avec des garde-fous, au lieu de chercher la perfection.

Checklist “retour d’expérience” (pratique)

Pour résumer son approche, voici les points qui ressortent le plus :

Éviter la fragilité du stockage : si des cartes SD meurent chez vous, passez sur un SSD.
Valider le BIOS : UEFI activé, Secure Boot désactivé.
Gérer le retour après coupure : “Power On” pour éviter une maison muette au prochain incident.
Accélérer les scénarios : utilisez l’IA pour décrire vos besoins en langage naturel et réduire le coût de production.
Prévoir des garde-fous : surtout avec des capteurs capables d’erreurs (échos, verrouillages, etc.).

Conclusion : une domotique qui tient, parce qu’elle est pensée comme un système

Le retour de Korben n’est pas une promesse “magique” : c’est une méthode. Il repart d’un constat (pannes et lenteur), puis il corrige les causes (stockage, démarrage, automatisations), et enfin il accepte la réalité des capteurs en ajoutant des protections.

Si vous voulez relancer votre Home Assistant sans retomber dans le même cycle d’abandon, la leçon la plus forte est peut-être celle-ci : la domotique n’est pas un gadget, c’est une infrastructure. Et une infrastructure se conçoit pour durer.

Ouverture : Une fois le socle stable, le prochain gain vient souvent de la qualité des scénarios (et de la manière de les itérer), plus que de l’ajout de matériel.

Source : https://korben.info/retour-domotique-home-assistant-mini-pc.html