Informatique

Claude bouscule les tests de recrutement des développeurs

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
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

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.

  1. 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é ?
  2. 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é.
  3. 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”

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
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
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 :

  1. Repérez les 10 plus gros éléments (treemap + tri par taille). Ne cherchez pas tout : commencez par l’impact.
  2. 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”.
  3. 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

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
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.

  1. Ouvrez Container Manager.
  2. Dans le menu de gauche, allez sur Projets.
  3. Recherchez le projet concerné (ex. votre stack).
  4. Ouvrez le projet, puis allez dans l’onglet Statistiques.
  5. 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.

  1. Dans Container Manager, allez dans Conteneur.
  2. Sélectionnez le conteneur concerné.
  3. 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 :

  1. Allez dans Panneau de configuration > Planificateur de tâche.
  2. Cliquez sur Créer.
  3. Choisissez Tâche planifiée > Script défini par l’utilisateur.
  4. Donnez un nom personnalisé (sans caractères spéciaux ni accent).
  5. Choisissez root comme utilisateur.
  6. Dans l’onglet Programmer, configurez Répéter sur Toutes les semaines.
  7. 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
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 :

  1. Ouvrez Moniteur de ressources > Gestionnaire des tâches > Processus.
  2. Trier par Mémoire privée (ordre décroissant).
  3. Repérez le conteneur ou l’application suspecte.
  4. Confirmez dans Container Manager (Projet > Statistiques sur RAM, ou Conteneur > Statistiques).
  5. 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

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
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
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 :

  1. couverture (avancer en sautant davantage, pour garder une vue d’ensemble),
  2. 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”

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
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 ?

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
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.

  1. Regardez l’activité récente : commits, issues, réponses sur le forum, fréquence des corrections.
  2. Surveillez les releases : des mises à jour régulières indiquent une capacité de maintenance.
  3. Vérifiez la stabilité des clients : web, mobile et TV doivent rester compatibles avec le serveur.
  4. Testez avant de mettre à jour : idéalement sur une instance de préproduction ou un environnement de test.
  5. 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
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)

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
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
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 :

  1. Éviter la fragilité du stockage : si des cartes SD meurent chez vous, passez sur un SSD.
  2. Valider le BIOS : UEFI activé, Secure Boot désactivé.
  3. Gérer le retour après coupure : “Power On” pour éviter une maison muette au prochain incident.
  4. 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.
  5. 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

Informatique

Januscape : comment OVHcloud a patché en urgence

Laisser un commentaire

Januscape OVHcloud a mis en lumière un scénario que tout hébergeur redoute : une faille exploitable pouvant faire planter l’hôte physique. Quand l’attaque vise l’infrastructure elle-même, la question n’est plus “si” on corrige, mais “comment” on corrige vite, à grande échelle, sans multiplier les dégâts. OVHcloud a publié un retour d’expérience détaillé : chronologie, arbitrages et choix opérationnels, jusqu’aux ratés.

Le contexte : une faille qui touche l’hôte physique

La faille Januscape a été révélée comme un problème où une machine virtuelle louée peut provoquer le plantage du serveur physique qui l’héberge. Pour un acteur disposant de dizaines de milliers d’hôtes et d’environ un million de machines virtuelles, cela change la nature de l’urgence : il ne s’agit pas seulement de corriger des services, mais de sécuriser la plateforme d’exécution elle-même.

Dans son billet, OVHcloud explique avoir dû répondre à une double contrainte : agir rapidement, tout en tenant compte du fait que l’impact d’un correctif peut se traduire par des redémarrages et des effets de bord sur certains environnements.

Carte du monde illustrant le déploiement par relais horaire
Carte du monde illustrant le déploiement par relais horaire

11 jours pour patcher : la chronologie d’une réponse

OVHcloud décrit une opération structurée en étapes très courtes, avec des validations internes et des décisions prises au fil de l’eau. L’alerte tombe le 7 juillet en début d’après-midi. Le correctif est adapté aux noyaux Debian maison dans la journée, puis validé en laboratoire le soir.

Le point clé : l’équipe teste le comportement de l’exploit dans un cadre interne, et constate un plantage d’un hôte non corrigé en quelques minutes. Cette validation sert de base au feu vert décisionnel.

Le “follow the sun” pour enchaîner les régions

Le déploiement démarre depuis Sydney, un choix présenté comme moins “exotique” qu’il n’y paraît : la région est petite et sa nuit locale correspond aux heures de travail des équipes européennes. Une fois la procédure validée en conditions réelles, OVHcloud enclenche une logique de relais : chaque région prend le relais sur sa matinée locale, en continu.

Des seuils d’arrêt pour éviter l’emballement

Pour piloter le rythme, l’entreprise encadre l’opération avec des seuils. Par exemple, si le nombre d’hôtes en panne simultanée dépasse un certain niveau dans les régions les plus denses (et un niveau différent ailleurs), la vague est suspendue le temps que les techniciens de datacenter interviennent.

Sur la première nuit, OVHcloud indique que 20 à 30 hôtes sur 6 000 ne sont pas revenus seuls, avec des causes évoquées comme des barrettes mémoire ou des problèmes de configuration.

Le choix le plus lourd : corriger puis redémarrer

OVHcloud explique qu’il existait plusieurs options sur la table : attendre un correctif “officiel” via des noyaux, passer par un correctif à chaud, ou encore migrer massivement les machines virtuelles. Toutes sont écartées au profit d’une approche jugée la plus radicale : corriger puis redémarrer l’intégralité des hôtes.

Cette stratégie repose sur une idée simple : si la faille peut conduire à des plantages, alors la correction doit atteindre le niveau le plus fondamental de l’infrastructure, même si cela implique un impact opérationnel.

Orchestration de correctifs et redémarrages sur des hôtes de datacenter
Orchestration de correctifs et redémarrages sur des hôtes de datacenter

“Patching unilatéral à impact contrôlé” : sans fenêtre de maintenance client

Le billet assume un point sensible : pas de fenêtre de maintenance négociée client par client. OVHcloud parle d’un patching unilatéral à impact contrôlé : les redémarrages sont appliqués sans accord individuel, et l’impact est considéré comme inévitable, à condition d’être maîtrisé.

Pour limiter la casse, l’entreprise met en place une logique d’orchestration basée sur un graphe de colocalisation. L’objectif est de ne pas redémarrer en même temps deux hôtes portant des instances d’un même projet client.

Anti-affinité “best effort” : pas de garantie absolue

OVHcloud revendique une anti-affinité en “best effort”, c’est-à-dire une approche qui réduit le risque sans pouvoir garantir un résultat parfait dans tous les cas. Concrètement, cela signifie que l’orchestration cherche à éviter les situations les plus dommageables, mais qu’elle ne peut pas éliminer toute possibilité de collision.

Les charges critiques : migration à chaud au cas par cas

Les charges les plus sensibles, notamment des machines virtuelles de bases de données managées, sont traitées autrement : OVHcloud indique avoir migré ces éléments à chaud, une par une. L’idée est de préserver la continuité là où elle est la plus difficile à obtenir via un simple redémarrage.

La communication : assumer, documenter… et gérer le silence initial

Dans son retour d’expérience, OVHcloud aborde aussi la dimension communication. L’entreprise explique avoir choisi de ne pas publier immédiatement une page d’état publique, afin de ne pas exposer certains détails susceptibles d’être utilisés.

Ce choix illustre un dilemme classique en cybersécurité : informer tôt peut aider les clients à se préparer, mais cela peut aussi fournir des repères à des acteurs malveillants. OVHcloud semble avoir privilégié la réduction du risque pendant la phase la plus critique.

Ce qu’on peut retenir : une méthode réplicable pour les crises de patch

Au-delà du cas Januscape, le retour d’expérience met en avant des principes opérationnels utiles quand une faille touche l’infrastructure :

  • Valider vite : adapter le correctif et tester l’impact en laboratoire avant d’industrialiser.
  • Choisir une stratégie “niveau infrastructure” quand la faille est structurelle (ici, redémarrer après correction).
  • Orchestrer le risque : anti-affinité et logique de colocalisation pour limiter les effets simultanés.
  • Rythmer avec des garde-fous : seuils d’arrêt et interventions datacenter planifiées.
  • Traiter les charges critiques différemment : migration à chaud quand c’est nécessaire.

Conclusion : la sécurité, c’est aussi de la décision sous contrainte

Januscape OVHcloud n’est pas seulement une histoire de correctif. C’est une histoire de décisions : quand corriger, comment redémarrer, comment limiter l’impact, et comment communiquer sans augmenter le risque. Le message implicite est clair : en cybersécurité, la vitesse compte, mais la méthode compte tout autant.

La prochaine question, pour les équipes techniques comme pour les clients, est simple : comment préparer à l’avance des plans de patch “à grande échelle” pour que l’urgence ne devienne pas une improvisation ?

Source : https://www.clubic.com/actualite-622141-januscape-ovhcloud-raconte-11-jours-de-crise-pour-patcher-son-parc-mondial.html

Informatique

Clés SSH : arrête de les générer n’importe comment

Laisser un commentaire

Quand on se lance dans le self-hosting, on finit toujours par taper la même commande : ssh-keygen, Entrée trois fois, et hop… ça marche. Sauf que tes clés SSH ne sont pas un détail : ce sont littéralement les clés d’accès à tes serveurs. Et si tu les fabriques ou les organises mal, tu passes très vite de « un fichier volé » à « un accès permanent à tout ton parc ».

Dans ce guide, je te donne la méthode que j’applique sur mon homelab : bon format, bonne commande, passphrase obligatoire, organisation par usages, et ssh-agent bien configuré. Pas de théorie inutile : juste des décisions concrètes qui réduisent le risque.

1) Le bon format en 2026 : Ed25519, point

Si tu ne dois retenir qu’une chose : génère tes clés en Ed25519. La commande minimale est :

ssh-keygen -t ed25519

Pourquoi je pousse Ed25519 ? Parce que c’est un choix moderne, efficace et robuste dans l’écosystème OpenSSH. Et surtout : c’est le format que tu veux standardiser dans ton homelab, pour éviter les exceptions et les “ça marche chez moi” qui finissent par coûter cher.

Ce que tu évites

  • DSA : obsolète, à oublier.
  • ECDSA : acceptable en théorie, mais je préfère éviter les compromis et rester sur Ed25519.
  • RSA : utile uniquement pour l’interop avec un vieux système. Sinon, tu perds du temps à gérer un héritage.
Commande ssh-keygen en Ed25519 avec indicateurs de sécurité
Commande ssh-keygen en Ed25519 avec indicateurs de sécurité

2) La commande idéale, décortiquée

Voici la ligne que j’utilise et que je te recommande d’adopter comme standard :

ssh-keygen -t ed25519 -a 100 -C "moi@mon-pc" -f ~/.ssh/id_ed25519_mon_pc

Chaque option a un rôle. Et c’est précisément là que beaucoup de gens “génèrent n’importe comment” : ils laissent des valeurs par défaut sans comprendre ce qu’elles protègent.

-t ed25519 : le type de clé

On l’a vu : c’est ton standard. Pas de débat.

-a 100 : le blindage du fichier au repos

Ta clé privée n’est pas stockée en clair si tu mets une passphrase. Elle est chiffrée, et -a règle le coût de dérivation de la clé de chiffrement (KDF). Plus tu augmentes ce coût, plus un attaquant qui vole le fichier doit “payer” du temps pour tester des passphrases.

En pratique, 100 est un bon compromis : tu ne le sens presque pas à l’usage (une fois au déverrouillage), mais tu rends les essais beaucoup plus coûteux pour un attaquant.

Point important : -a ne sert à rien si tu ne mets pas de passphrase. Donc on enchaîne.

-C : un commentaire utile

Le commentaire (moi@mon-pc) n’ajoute pas de sécurité cryptographique. Mais il te sauve la vie quand tu retrouves une clé dans un authorized_keys six mois plus tard : tu sais à quoi elle correspond.

-f : le nom explicite qui évite le chaos

Le chemin de sortie (~/.ssh/id_ed25519_mon_pc) n’est pas qu’un détail. C’est l’organisation qui te permet de savoir quelle clé est où, et de révoquer vite quand une machine change.

Ce que je ne fais jamais : -N

Je ne passe jamais la passphrase en argument avec -N. Elle finirait dans l’historique de ton shell ou dans des logs. Tu la tapes au prompt, c’est plus sûr.

3) Passphrase obligatoire (et comment ne pas la rendre pénible)

Une clé SSH sans passphrase, c’est une clé privée qui peut ouvrir tes serveurs et qui traîne sur ton disque. Si un jour ta machine est compromise, la “sécurité au repos” disparaît.

Ma règle : toujours une passphrase forte. Et ensuite, on gère le confort avec ssh-agent.

Une clé SSH ne s’expire pas : attention aux clés oubliées dans authorized_keys
Une clé SSH ne s’expire pas : attention aux clés oubliées dans authorized_keys

4) Le piège : une clé SSH n’expire jamais

Contrairement à un certificat TLS, une paire de clés SSH “classique” n’a pas de date de validité. Une fois que ta clé publique est dans authorized_keys, elle fonctionne indéfiniment jusqu’à ce que tu la retires.

Le vrai danger en homelab, ce n’est pas “la clé trop vieille”. C’est la clé oubliée : un ancien laptop revendu, une VM réinstallée, un téléphone perdu… et pourtant l’accès reste valide parce que personne n’a fait le ménage.

Deux solutions réalistes

  1. Rotation manuelle : tu régénères tes paires périodiquement (par exemple une fois par an) et tu remplaces les clés publiques sur tes serveurs.
  2. Certificats SSH : tu utilises une CA et des certificats avec une fenêtre de validité. Quand ça expire, le serveur refuse automatiquement.

Mon avis : pour un petit parc (un VPS + un NAS), monter une PKI complète peut être disproportionné. Mais dès que tu passes à plusieurs machines, l’approche certificats devient intéressante. Dans tous les cas, garde en tête une règle : audit régulier de qui a accès à quoi.

5) Combien de clés ? et combien de passphrases ?

On confond souvent deux décisions différentes : le nombre de clés et le nombre de passphrases. Elles ne répondent pas aux mêmes objectifs.

“Une clé par usage” ≠ “une clé par serveur”

Le bon découpage, ce n’est pas la destination (VPS, NAS, etc.). C’est le point de départ : quelle machine cliente et quel contexte.

Exemple de découpage sain :

PC       → id_ed25519_pc       (ouvre VPS, NAS, etc.)
Laptop   → id_ed25519_laptop   (ouvre VPS, NAS, etc.)
PC       → id_ed25519_github   (dédiée aux services tiers)

Pourquoi une clé dédiée pour GitHub / services tiers ? Parce que tu confies la clé publique à un tiers. Autant qu’elle ne soit pas réutilisée pour tes accès “maison”.

Une passphrase par machine (pas par clé)

La passphrase sert à protéger un fichier de clé privée volé. Si plusieurs clés vivent sur la même machine et partagent la même passphrase, un attaquant qui accède au disque pourra tenter cette passphrase pour toutes.

Mon conseil pragmatique : une passphrase forte et unique par machine cliente. Toutes les clés générées sur ce poste peuvent partager cette passphrase.

Deux exceptions où tu cloisonnes plus

  • Clé tierce (GitHub / services) : passphrase distincte si tu veux renforcer l’isolation.
  • Clé matérielle (ex. ed25519-sk) pour ton accès le plus sensible : la partie secrète ne peut pas être copiée depuis le disque. Là, la passphrase devient presque secondaire, parce que voler le fichier ne suffit plus.

6) ssh-agent : le confort sans sacrifier la sécurité

“Taper une passphrase à chaque connexion, c’est infernal.” Oui. Mais justement : on ne le fait pas. ssh-agent garde tes clés déchiffrées en mémoire le temps de la session.

Le but : tu tapes la passphrase une fois, puis tu enchaînes tes connexions sans friction.

ssh-agent garde les clés en mémoire pour éviter de retaper la passphrase
ssh-agent garde les clés en mémoire pour éviter de retaper la passphrase

Le réflexe qui change tout : AddKeysToAgent yes

Dans ~/.ssh/config, je mets :

Host *
  AddKeysToAgent yes
  IdentityFile ~/.ssh/id_ed25519_mon_pc

Résultat : à la première utilisation, SSH charge la clé dans l’agent. Ensuite, tu ne retapes pas la passphrase tant que l’agent vit.

Évite les mauvaises surprises : IdentitiesOnly yes

Quand tu as plusieurs clés, SSH peut essayer “trop de choses” et provoquer des refus côté serveur. Pour forcer la clé attendue, je recommande :

Host mon_serveur
  HostName ton.ip.ou.domaine
  User user_distant
  IdentityFile ~/.ssh/id_ed25519_mon_pc
  IdentitiesOnly yes

7) Bien gérer ssh-agent selon ton OS

Le problème n’est pas ssh-agent. Le problème, c’est le démarrage. Beaucoup de gens lancent ssh-add alors qu’aucun agent ne tourne, ou alors ils démarrent un agent sans appliquer les variables d’environnement.

Windows : l’agent persiste (souvent le plus simple)

Sur Windows, le service OpenSSH agent peut être configuré pour démarrer automatiquement. Ensuite, tu charges tes clés une fois, et elles reviennent après reboot.

Set-Service ssh-agent -StartupType Automatic Start-Service ssh-agent

Attention : l’agent garde les clés déchiffrées en mémoire via le service. Si ton accès est critique, la clé matérielle reste la meilleure option.

Linux : keychain ou systemd user

Sur Linux, une approche simple consiste à utiliser keychain pour réutiliser un agent existant et éviter de re-taper la passphrase à chaque session.

sudo apt install keychain
# dans ~/.bashrc :
eval "$(keychain --eval --quiet id_ed25519_pc id_ed25519_github)"

Sur certaines configurations desktop, d’autres composants peuvent aussi gérer un agent. L’idée est de garder un contrôle clair sur “qui lance quoi”.

Mode ponctuel : le eval est obligatoire

Pour une tâche isolée, tu peux lancer un agent “jetable” dans ton terminal. Mais fais-le correctement :

eval "$(ssh-agent -s)"

Le eval applique les variables d’environnement dans ton shell courant. Sans ça, ton shell ne sait pas où joindre l’agent, et ssh-add échoue.

Arrêter proprement

Si tu as lancé l’agent proprement, tu peux le tuer avec :

ssh-agent -k

Si tu as lancé sans eval, tu peux te retrouver avec un agent qui tourne “dans le flou”. Dans ce cas, un nettoyage global peut être nécessaire :

pkill -u "$USER" ssh-agent

8) Sécurité ssh-agent : les deux réglages que je fais toujours

ssh-agent est pratique, mais il garde des clés déchiffrées en mémoire. Donc je limite l’exposition.

Timeout sur les clés sensibles

Tu peux demander à l’agent de purger une clé après un délai :

ssh-add -t 8h ~/.ssh/id_ed25519_mon_pc

Tu peux aussi mettre un comportement par défaut dans la config pour éviter les oublis.

Forwarding d’agent : prudence

Le forwarding d’agent (ForwardAgent yes ou ssh -A) permet au serveur distant d’utiliser ton agent pour rebondir ailleurs. C’est pratique, mais si le serveur est compromis, l’attaquant profite de ton agent tant que tu es connecté.

Je préfère une approche plus maîtrisée : ProxyJump pour le rebond, plutôt que le forwarding d’agent.

Checklist : la méthode à appliquer dès maintenant

  • Format : Ed25519 partout.
  • Commande : ssh-keygen -t ed25519 -a 100 -C "..." -f ~/.ssh/nom_explicite.
  • Passphrase : obligatoire, forte, jamais via -N.
  • Nombre de clés : peu. Une par machine cliente, plus une dédiée aux services tiers.
  • Passphrases : une par machine (et éventuellement une distincte pour la clé tierce).
  • Confort : AddKeysToAgent yes + IdentitiesOnly yes quand nécessaire.
  • Rotation / nettoyage : les clés n’expirent pas, donc tu fais un audit et tu révoques vite.
  • Accès sensible : clé matérielle si tu veux le cran au-dessus.

Conclusion : reprendre le contrôle de tes accès

Les clés SSH ne sont pas un “détail de configuration”. Ce sont tes serrures. Et une serrure mal gérée, c’est un accès facile à long terme.

Si tu appliques cette méthode—Ed25519, passphrase, organisation claire, ssh-agent propre et audit régulier—tu réduis drastiquement le risque, tout en gardant un homelab fluide. La prochaine étape logique ? Faire l’inventaire de tes authorized_keys et vérifier que chaque clé correspond encore à une machine que tu contrôles.