Cédrix
1 line
51 KiB
JSON
1 line
51 KiB
JSON
[{"uuid":"4cf880e6-e4e0-42dd-aae2-675837850b83","slug":"compromission-de-jdownloader-6-7-mai-2026-analyse-indicateurs-et-procedure-de-detection","title":"JDownloader : quand le CMS devient la faille","category":"informatique","author":"cedric@abonnel.fr","cover":"cover.webp","published":true,"published_at":"2026-05-12 17:09","created_at":"2026-05-12 17:10:36","updated_at":"2026-05-12 17:21:01","tags":[],"plain":"À propos de l'incident de sécurité affectant le site officiel jdownloader.org les 6 et 7 mai 2026.\r\n\r\nJDownloader expliqué simplement\r\n\r\nJDownloader est un gestionnaire de téléchargements écrit en Java, distribué gratuitement par l'éditeur allemand AppWork GmbH depuis plus de quinze ans. Il sert essentiellement à automatiser la récupération de fichiers depuis des hébergeurs (Mega, Uptobox, Rapidgator…), des plateformes vidéo et des services de liens premium. Côté utilisateur, c'est l'outil qu'on lance pour récupérer une série de fichiers en une opération, plutôt que cliquer sur cent liens un par un. L'application est multiplateforme — Windows, Linux, macOS — et tourne sur quelques millions de postes dans le monde.\r\n\r\nLe projet est distribué de plusieurs façons : un JAR principal (le binaire Java pur), des installateurs natifs par OS depuis le site officiel, et des paquets passant par des canaux distribués comme Flatpak, Snap ou Winget. C'est cette diversité de canaux qui va jouer un rôle central dans ce qui suit.\r\n\r\nL'incident : ce qui s'est passé\r\n\r\nEntre le 6 mai 2026 à 00 h 01 UTC et le 7 mai 2026 à 17 h 06 UTC, le site officiel a distribué des installateurs piégés à la place des binaires légitimes. La fenêtre n'a duré qu'environ 48 heures, et seuls deux liens ont été affectés. Mais pendant cette fenêtre, tout utilisateur qui passait par le bon parcours téléchargeait un cheval de Troie au lieu d'un gestionnaire de téléchargements.\r\n\r\nLe scénario reconstitué par l'équipe d'AppWork et les chercheurs en sécurité (BleepingComputer, Thomas Klemenc, équipe Rescana) se déroule en quatre temps.\r\n\r\n1. Compromission du CMS du site. Les attaquants ont exploité une vulnérabilité non corrigée dans le système de gestion de contenu de , qui permettait de modifier les listes de contrôle d'accès et le contenu publié sans authentification. Point crucial : ils n'ont pas eu accès au serveur sous-jacent, ni au système de fichiers, ni à l'infrastructure de build. Juste au contenu web — et ça a suffi.\r\n\r\n2. Réécriture de deux liens. Plutôt que de tenter de modifier les binaires originaux (qui étaient hors de leur portée), les attaquants ont fait beaucoup plus simple : ils ont changé l'URL cible de deux liens publics sur la page de téléchargement. Le lien « Download Alternative Installer » pour Windows et le script shell pour Linux pointaient désormais vers des fichiers malveillants hébergés sur une infrastructure tierce. Le HTML autour, lui, restait identique. Visuellement, rien ne distinguait la page propre de la page piégée.\r\n\r\n3. Charges utiles différenciées par plateforme. Sur Windows, l'installateur piégé agit comme un loader qui déploie un RAT (Remote Access Trojan) écrit en Python, fortement obfusqué, communiquant avec deux serveurs de commande et contrôle ( et ). Le RAT est modulaire : il reçoit du code Python depuis le C2 et l'exécute, ce qui donne aux attaquants une porte ouverte indéfiniment extensible. Sur Linux, le script shell modifié télécharge une archive depuis , déguisée en fichier SVG, dont il extrait deux binaires ELF — et . Le second est installé en SUID-root dans , le premier est copié dans , et la persistance est assurée par un script déposé dans . Le malware se lance ensuite déguisé en , un nom de processus qui existe légitimement sur la plupart des distributions.\r\n\r\n4. Détection par la communauté. L'alerte n'est pas venue d'un système de surveillance, mais d'un utilisateur Reddit (PrinceOfNightSky) qui a remarqué que Microsoft Defender bloquait son installateur fraîchement téléchargé. La signature numérique indiquait « Zipline LLC » au lieu de « AppWork GmbH ». L'équipe AppWork a confirmé, mis le site hors ligne pour investigation dans les heures qui ont suivi, puis publié un rapport d'incident détaillé. Le site est revenu en ligne dans la nuit du 8 au 9 mai avec des liens vérifiés.\r\n\r\nPourquoi c'est systémique\r\n\r\nÀ première vue, c'est un incident isolé : une faille CMS, une équipe qui patche, le service revient. Vu de loin, ça ressemble à un mauvais quart d'heure. Mais en prenant un peu de recul, le schéma est troublant.\r\n\r\nCPUID, début avril 2026. Le site officiel de l'éditeur de CPU-Z est compromis, des installateurs piégés sont distribués pendant plusieurs jours.\r\n\r\nDAEMON Tools, début mai 2026. Même schéma : compromission du site officiel, substitution d'installateurs, plusieurs versions infectées (12.5.0.2421 à 12.5.0.2434) distribuées avant détection.\r\n\r\nJDownloader, 6–7 mai 2026. Toujours le même schéma.\r\n\r\nTrois compromissions d'éditeurs logiciels en cinq semaines, exactement sur le même schéma : pas d'intrusion dans l'infrastructure de build, pas de modification du code source, pas de vol de certificat de signature de l'éditeur. À chaque fois, le maillon faible est le CMS qui sert la page de téléchargement. Ce qu'on attaque, ce n'est pas le logiciel ; c'est le panneau publicitaire qui pointe vers le logiciel.\r\n\r\nCette mécanique est intéressante parce qu'elle déjoue à peu près toutes les défenses « modernes » de la chaîne d'approvisionnement.\r\n\r\nLa signature de code ne protège pas. Le binaire légitime de JDownloader est toujours signé proprement par AppWork GmbH. Mais le binaire malveillant servi à sa place est signé, lui aussi — par un autre éditeur (Zipline LLC, The Water Team), avec des certificats vraisemblablement volés ou achetés au marché noir. La signature certifie que le fichier vient bien de celui qui l'a signé ; elle ne certifie pas que c'est le bon fichier.\r\n\r\nLe HTTPS ne protège pas. La page de téléchargement est servie en HTTPS valide, depuis le bon domaine, avec le bon certificat. Le navigateur n'a aucune raison de tiquer.\r\n\r\nLes mises à jour in-app sont, elles, protégées. AppWork le souligne : chaque mise à jour livrée par le mécanisme intégré de JDownloader est signée RSA et vérifiée cryptographiquement, indépendamment du site web. Ce canal n'a pas été touché. C'est tout le paradoxe : les utilisateurs qui mettaient à jour JDownloader depuis l'application elle-même n'ont rien risqué ; ceux qui sont allés sur le site officiel pour le télécharger « proprement » sont les seuls exposés.\r\n\r\nLes paquets distribués sont protégés. Flatpak, Snap, Winget, le JAR principal — tout ce qui passe par une chaîne d'approvisionnement où l'intégrité est vérifiée par checksum hors site est resté propre. AppWork le résume sans détour : « Winget/Flatpak/Snap infra is outside of our reach — files downloaded by those are hosted on other infra and secured by sha256 checksums that are unchanged. »\r\n\r\nAutrement dit, plus le canal est court et naïf, plus il est vulnérable. Le téléchargement direct depuis un site web est le canal le plus naïf qui soit : on fait confiance au CMS, point. Tout l'effort de sécurisation de l'écosystème logiciel — signatures, builds reproductibles, SBOMs, attestations de provenance — porte sur la chaîne de production et la chaîne de distribution centralisée. Le maillon « page HTML qui dit clique ici », lui, est resté tel qu'il était en 2005.\r\n\r\nComment vérifier si on est touché\r\n\r\nLa fenêtre est étroite, donc le filtrage est simple. Trois questions, dans l'ordre :\r\n\r\n1. L'installateur a-t-il été récupéré entre le 6 mai 2026 (00 h 01 UTC) et le 7 mai 2026 (17 h 06 UTC) ?\r\n2. S'agit-il du lien « Download Alternative Installer » Windows ou du script shell Linux depuis ?\r\n3. Le fichier a-t-il été exécuté ?\r\n\r\nTrois oui → traiter la machine comme compromise. N'importe quel non dans la liste → aucun risque lié à cet incident. Une installation pré-existante mise à jour automatiquement, un paquet Flatpak/Snap/Winget, le JAR, la version macOS : rien à craindre.\r\n\r\nSous Windows\r\n\r\nLe contrôle de référence, c'est la signature numérique. Clic droit sur l'installateur → Propriétés → onglet Signatures numériques. La valeur attendue est . Toute autre signature (notamment Zipline LLC ou The Water Team), ou l'absence de signature, désigne un fichier malveillant.\r\n\r\nEn PowerShell :\r\n\r\n\r\n\r\nSi n'est pas ou si le certificat ne contient pas , ne pas exécuter.\r\n\r\nSous Linux\r\n\r\nTrois artefacts sont à chercher en post-exécution :\r\n\r\n\r\n\r\nL'apparition de l'un de ces trois éléments suffit à confirmer l'infection. Pour aller plus loin, un coup d'œil au trafic sortant vers les trois domaines C2 (, , ) dans les logs DNS ou via permet de confirmer l'activité du malware.\r\n\r\nSi le script installateur traîne encore quelque part, sa signature est sans ambiguïté : taille de 7 934 496 octets, SHA-256 commençant par .\r\n\r\nEn cas de compromission confirmée\r\n\r\nLa position officielle d'AppWork est sans nuance : réinstallation complète du système. Un RAT modulaire avec persistance SUID-root et exécution arbitraire de code Python depuis un C2 n'est pas quelque chose qu'on retire avec un antivirus. Il faut considérer que tout secret qui a transité sur la machine est compromis — mots de passe saisis au clavier, clés SSH, jetons API, cookies de session, configurations cloud — et les faire tous tourner après réinstallation, depuis une autre machine saine.\r\n\r\nCe que ça change pour qui s'auto-héberge\r\n\r\nL'incident JDownloader est un exemple éclairant pour qui exploite ses propres services exposés sur Internet — un Forgejo, un reverse proxy, un site personnel. La leçon n'est pas vraiment côté utilisateur (la procédure de détection plus haut suffit), elle est côté opérateur.\r\n\r\nLe CMS de JDownloader n'a probablement pas été ciblé pour ses qualités intrinsèques. C'est un dommage collatéral d'un schéma plus large : tout site qui distribue un binaire avec un nombre significatif d'utilisateurs devient une cible rentable, et le CMS public est souvent la pièce la moins surveillée du dispositif. On sécurise le serveur Git, le pipeline de build, la signature des paquets — et on laisse tourner un CMS qui n'a pas été patché depuis huit mois parce qu'il « ne sert qu'à afficher la page d'accueil ».\r\n\r\nQuelques principes opérationnels qui en découlent.\r\n\r\nSéparer le canal de publication du canal de vérification. AppWork a eu raison sur un point essentiel : leurs mises à jour in-app passent par une infrastructure indépendante du site web, avec signature RSA vérifiée côté client. Quand on auto-héberge, ça se traduit par : ne jamais utiliser le même serveur pour distribuer un binaire et publier son empreinte. Le checksum doit vivre ailleurs — dans un dépôt Git séparé, sur un domaine différent, idéalement sur une infrastructure qu'on n'administre pas soi-même.\r\n\r\nSurveiller la dérive du contenu publié. Une simple vérification quotidienne du hash des pages publiques (un cron qui calcule le SHA-256 des URL critiques et alerte en cas de changement non planifié) aurait détecté la compromission de JDownloader en moins d'une heure. C'est le genre de surveillance qu'aucune solution commerciale ne propose nativement, et qui s'écrit en quinze lignes de bash.\r\n\r\nPatcher le CMS avec la même rigueur que l'OS. L'automatisation des mises à jour applicatives reste sous-investie, surtout pour les outils « périphériques » (CMS, wiki, formulaire de contact). Une mise à jour automatique de niveau correctif n'est pas plus risquée qu'une mise à jour du noyau, et elle évite ce type de scénario.\r\n\r\nAuditer les ACL régulièrement. La faille exploitée ici permettait de modifier les ACL sans authentification. C'est l'équivalent CMS d'un répertoire dans un coin du système. Un audit périodique des permissions sur les pages publiques fait partie du minimum syndical pour un service exposé.\r\n\r\nEn résumé\r\n\r\nJDownloader n'a pas été cassé. Son code source est intact, son infrastructure de build est intacte, ses paquets officiels distribués via Flatpak ou Snap sont intacts, ses mises à jour internes sont intactes. Ce qui a été cassé, c'est le panneau qui dit où aller chercher le binaire.\r\n\r\nC'est une mécanique élégante du point de vue de l'attaquant, et inquiétante du point de vue de l'opérateur. Elle illustre quelque chose que l'incident NPM avait déjà mis en lumière dans un autre registre : la chaîne d'approvisionnement logicielle n'est pas une chaîne, c'est un réseau, et les points faibles ne sont jamais là où on les attend. On peut investir massivement dans la sécurité du code, du build et de la signature ; si la page web qui sert le lien reste un Wordpress non patché derrière un nom de domaine prestigieux, tout cet investissement passe à côté.\r\n\r\nLe rôle de l'opérateur en 2026, ce n'est plus de protéger le code. C'est de protéger chaque maillon qui sert à dire au monde où trouver le code — et de partir du principe que ce maillon-là sera le prochain à céder.\r\n\r\nLiens & sources\r\n\r\nJDownloader site hacked to replace installers with Python RAT malware | BleepingComputer\r\n\r\nRapport d'incident officiel | jdownloader.org\r\n\r\nJDownloader Website Supply Chain Attack | Rescana\r\n\r\nLe site officiel de JDownloader compromis | IT-Connect"},{"uuid":"093711bf-4e60-4ea8-ba73-928d2d67776c","slug":"certificats-let-s-encrypt-a-6-jours-faut-il-sauter-le-pas","title":"Certificats Let's Encrypt à 6 jours : faut-il sauter le pas ?","category":"actualité","author":"cedric@abonnel.fr","cover":"cover.svg","published":true,"published_at":"2026-05-07 22:46","created_at":"2026-05-12 08:47:27","updated_at":"2026-05-12 08:59:58","tags":[],"plain":"Guide DevOps / WebOps pour comprendre les certificats à durée de vie courte () et décider si vous devez migrer.\r\n--\r\n\r\nTL;DR\r\n\r\nLet's Encrypt propose désormais au grand public des certificats valides 6 jours (profil ), en plus du classique 90 jours. Pour les certificats sur adresse IP, c'est même obligatoire. La question n'est pas \"est-ce que c'est bien ?\" — techniquement oui — mais \"est-ce que mon infra est prête ?\". Si votre renouvellement automatique fonctionne sans accroc depuis 6 mois, foncez. Sinon, fiabilisez d'abord, migrez ensuite.\r\n--\r\n\r\n1. De quoi on parle\r\n\r\nDepuis janvier 2026, Let's Encrypt émet en disponibilité générale deux nouveautés couplées : les certificats pour adresses IP, et les certificats à durée de vie de 6 jours via un nouveau profil ACME nommé . Certbot 4.0 a introduit le flag pour les sélectionner, et Certbot 5.3 a ajouté pour demander un cert sur IP.\r\n\r\nConcrètement, un certificat a une validité de 6 jours au lieu de 90. Tout le reste — chaîne de confiance, algorithmes, format — est identique. Pour le navigateur, c'est un certificat Let's Encrypt standard.\r\n\r\nLes profils disponibles\r\nProfil | Durée | Usage |\r\n---|---|---|\r\n(défaut) | 90 jours | Tout le monde, par défaut |\r\n| 6 jours | Adopters précoces, certs sur IP (obligatoire) |\r\n| 90 jours | Variante optimisée serveur web (sans clientAuth) |\r\n--\r\n\r\n2. Pourquoi Let's Encrypt pousse vers le court\r\n\r\nQuatre raisons techniques, par ordre d'importance.\r\n\r\n2.1 La révocation TLS est cassée — autant l'éviter\r\n\r\nC'est le vrai sujet. Le mécanisme de révocation des certificats (CRL, OCSP) n'a jamais fonctionné correctement à grande échelle :\r\nOCSP soft-fail : si le serveur OCSP est injoignable, la plupart des navigateurs acceptent quand même le certificat. Un attaquant qui contrôle le réseau bloque l'OCSP et le cert révoqué passe.\r\nOCSP stapling mal configuré sur beaucoup de serveurs.\r\nCRLite, OneCRL : couvertures partielles, déploiement client incohérent.\r\nOCSP retiré : Let's Encrypt a arrêté OCSP en 2025, justement parce que ça ne servait quasiment à rien tout en posant des problèmes de vie privée.\r\n\r\nAvec un cert à 6 jours, la révocation devient cosmétique : on attend l'expiration. La fenêtre d'exploitation d'une clé compromise passe de plusieurs semaines (cert 90 jours, OCSP douteux) à quelques jours maximum.\r\n\r\n2.2 Réduire la fenêtre de compromission\r\n\r\nSi votre clé privée fuite (backup mal protégé, faille serveur, employé qui part avec une copie, vulnérabilité type Heartbleed), l'attaquant peut usurper votre site tant que le cert est valide. À 90 jours, c'est trois mois d'exposition dans le pire cas. À 6 jours, c'est une semaine.\r\n\r\nC'est encore plus critique pour les certs sur IP : une IP peut changer de propriétaire (cloud, VPS recyclé, réattribution FAI). Un cert long pour une IP qui ne vous appartient plus, c'est un risque que LE refuse de prendre — d'où l'obligation du profil court pour cet usage.\r\n\r\n2.3 Forcer une automatisation propre\r\n\r\nPersonne ne renouvelle un cert à la main tous les 6 jours. C'est mécaniquement infaisable. Le profil est donc un filtre qualité : si votre renouvellement n'est pas blindé, vous le saurez vite.\r\n\r\nL'effet de bord positif : ça élimine les pannes classiques type \"le cert a expiré parce que le cron était cassé depuis trois mois et personne ne s'en est rendu compte\". À 6 jours, un cron cassé devient visible immédiatement.\r\n\r\n2.4 Agilité cryptographique\r\n\r\nSi une vulnérabilité majeure impose de déprécier un algorithme en urgence (RSA, transition post-quantique, faille découverte sur SHA-256), un parc avec des certs à 6 jours bascule en une semaine. Un parc 90 jours met trois mois. C'est la raison qui motive aussi le CA/Browser Forum à pousser globalement vers des durées plus courtes (45 jours d'ici 2029 dans la baseline).\r\n--\r\n\r\n3. Pourquoi vous pourriez ne pas migrer\r\n\r\nSoyons honnêtes : pour la plupart des infras web classiques, le 90 jours suffit largement. Le 6 jours a des coûts réels.\r\n\r\n3.1 Pression sur le rate limiting\r\n\r\nLet's Encrypt limite à 300 nouveaux certificats par compte par 3 heures et 5 duplicatas de cert par semaine. Avec des certs 90 jours, vous renouvelez 4 fois par an. Avec des 6 jours, c'est 60 fois par an et par cert. Si vous avez 50 services derrière 50 certs distincts, vous explosez votre budget de requêtes ACME.\r\n\r\nMitigation : regrouper les domaines dans des certs SAN (un seul cert pour , , plutôt que trois certs).\r\n\r\n3.2 Dépendance critique au CA et au réseau\r\n\r\nÀ 90 jours, si Let's Encrypt est down 48h, vous ne le remarquez même pas. À 6 jours, une panne de 48h sur LE et votre fenêtre de renouvellement (typiquement à 1/3 de la durée restante, soit 2 jours), et votre cert expire. Vos services tombent.\r\n\r\nConséquences concrètes :\r\nIl faut un monitoring sérieux de l'expiration des certs (Prometheus blackbox exporter, , etc.).\r\nIl faut un fallback : second client ACME, second account, ou cert de secours d'une autre CA.\r\nIl faut absolument que la résolution DNS et le port 80/443 sortants depuis votre serveur soient fiables.\r\n\r\n3.3 Charge sur les systèmes de déploiement\r\n\r\nChaque renouvellement déclenche : appel ACME, validation HTTP-01 ou DNS-01, écriture des fichiers, rechargement du serveur web (Nginx, Apache, HAProxy, etc.). À 60 fois par an au lieu de 4, ça multiplie par 15 le nombre de reloads.\r\n\r\nSur un serveur web basique, un est gratuit. Sur des architectures plus complexes (load balancers stateful, terminations TLS distribuées, certs poussés vers un CDN, configs multi-nœuds avec Ansible/Salt), chaque renouvellement déclenche une cascade. À évaluer.\r\n\r\n3.4 Logs, audit, conformité\r\n\r\nCertains contextes réglementaires demandent une traçabilité des certificats (PCI-DSS, ISO 27001, HDS). Multiplier par 15 le volume d'événements de renouvellement à archiver et auditer, ça représente du stockage et du tooling à adapter.\r\n\r\n3.5 Le cas \"monitoring TLS externe\"\r\n\r\nSi vous avez des outils tiers (uptime monitors, scanners de conformité) qui vérifient l'expiration de vos certs, ils risquent de hurler en permanence : un cert qui montre toujours \"expire dans 6 jours\" déclenche les alertes \"cert expirant bientôt\" sur la plupart des outils mal configurés. Il faut soit ajuster les seuils, soit changer d'outil.\r\n--\r\n\r\n4. Décision : grille de lecture\r\nSituation | Recommandation |\r\n---|---|\r\nServeurs web classiques, renouvellement Certbot qui marche, < 20 certs | Restez en 90 jours. Le bénéfice marginal ne justifie pas le risque. |\r\nVous gérez des certs sur IP | Pas le choix : est obligatoire. |\r\nArchitecture critique avec rotation de clés agressive (banque, santé, infra publique) | Migrez. Le 6 jours est aligné avec vos exigences de sécurité. |\r\nInfra dev/staging interne | Excellent terrain de test. Migrez d'abord ici pour valider votre pipeline. |\r\nVous avez déjà eu une expiration cert non détectée en prod | Ne migrez pas tout de suite. Fiabilisez d'abord le monitoring et le renouvellement, puis migrez. Sinon vous transformez un incident annuel en incident hebdomadaire. |\r\nVous publiez via reverse proxy unique (un seul cert SAN pour plusieurs services) | Bon candidat. Un seul renouvellement à fiabiliser. |\r\nVous avez un parc hétérogène (Apache + Nginx + HAProxy + Traefik...) avec hooks custom | Auditez chaque hook avant de migrer. C'est là que ça casse. |\r\n--\r\n\r\n5. Comment migrer concrètement (Certbot)\r\n\r\n5.1 Pré-requis\r\n\r\nAvant tout :\r\n\r\n1. Certbot 4.0+ pour , 5.3+ pour , 5.4+ pour avec IP.\r\n2. Un renouvellement automatique opérationnel et vérifié (timer systemd ou cron actif, testé avec ).\r\n3. Un monitoring d'expiration des certs en place. Si vous n'en avez pas, installez-le avant de migrer.\r\n4. Un hook de reload du serveur web qui fonctionne ().\r\n\r\n5.2 Test sur le staging Let's Encrypt\r\n\r\n\r\n\r\nVérifier que le cert obtenu a bien une durée de 6 jours :\r\n\r\n\r\n\r\n5.3 Renouvellement plus fréquent\r\n\r\nPar défaut, Certbot renouvelle quand il reste 1/3 de la durée. Pour un cert 6 jours, ça veut dire renouveler à 2 jours restants. Ça laisse peu de marge en cas de panne. Vous pouvez forcer un renouvellement plus tôt :\r\n\r\n\r\n\r\nLe timer Certbot tourne deux fois par jour par défaut, ce qui est suffisant. Pas besoin de l'accélérer.\r\n\r\n5.4 Cas d'un certificat sur IP\r\n\r\n\r\n\r\nNote importante : Certbot ne sait pas encore installer automatiquement les certs IP dans Nginx ou Apache. Il faut éditer la config manuellement pour pointer vers et , et configurer un pour le reload.\r\n\r\n5.5 Plan de bascule recommandé\r\n\r\n1. Semaine 1-2 : un domaine non critique (un sous-domaine de test, un service interne) en . Surveillez les renouvellements.\r\n2. Semaine 3-4 : étendez à la moitié de votre dev/staging.\r\n3. Semaine 5-6 : migration progressive en prod, en commençant par les services les moins critiques.\r\n4. À tout moment : possibilité de retour arrière en supprimant du fichier de config Certbot dans .\r\n--\r\n\r\n6. Pièges à éviter\r\nNe migrez pas tout en même temps. Si votre hook de reload a un bug, vous le découvrez sur un seul service, pas sur 50.\r\nNe désactivez pas le monitoring d'expiration sous prétexte que c'est automatisé. L'automatisation peut casser silencieusement. Un check externe qui hurle à J-2 reste indispensable.\r\nAttention aux secrets stockés dans des configs autres que Certbot. Si vous avez des certs poussés manuellement vers un CDN, un load balancer cloud ou un firewall TLS-inspectant, le passage à 6 jours impose d'automatiser cette propagation aussi.\r\nPas de cert IP pour un service exposé publiquement à long terme. Si l'IP change, le cert devient inutilisable instantanément. Préférez le DNS quand c'est possible.\r\nVérifiez votre client ACME. Tous les clients ACME ne supportent pas encore les profils. acme.sh, Caddy, lego, Traefik : checkez la version. Certbot 4.0 minimum.\r\n--\r\n\r\n7. Verdict\r\n\r\nLe profil est techniquement supérieur au 90 jours sur le plan sécuritaire. Mais il déplace le coût : moins de risques liés aux clés compromises et à la révocation cassée, plus de risques liés à la chaîne de renouvellement.\r\n\r\nLa règle simple : si votre renouvellement automatique est fiable, migrez. Sinon, fiabilisez-le d'abord — la migration n'en sera que la conséquence naturelle.\r\n\r\nPour la majorité des infras web auto-hébergées (typiquement, un Proxmox + reverse proxy + une dizaine de services derrière), le 90 jours reste un excellent compromis. Le devient pertinent quand :\r\nVous avez besoin de certs sur IP (obligatoire).\r\nVous exploitez des services à forte exigence de sécurité (clés très sensibles).\r\nVous voulez tester votre résilience opérationnelle (le 6 jours est un excellent test de fiabilité de votre stack).\r\n\r\nLe reste du temps, gardez le 90 jours, dormez tranquille, et ressortez ce document quand le CA/Browser Forum imposera 45 jours par défaut (vers 2027-2028).\r\n--\r\n\r\nSources\r\nLet's Encrypt — Six-Day and IP Address Certificates Available in Certbot (mars 2026)\r\nLet's Encrypt — 6-day and IP address certs in general availability (janvier 2026)\r\nDocumentation Certbot — Hooks\r\nCA/Browser Forum Baseline Requirements"},{"uuid":"4f443bcb-b0d4-47f8-837d-61627e6c94f2","slug":"priorites-et-acces-au-reseau-en-4g-et-5g","title":"Pourquoi le réseau mobile ne s'effondre pas le jour où tout le monde téléphone en même temps","category":"télécom","author":"cedric@abonnel.fr","cover":"cover.jpg","published":true,"published_at":"2026-01-06 22:21","created_at":"2026-01-06 22:21:04","updated_at":"2026-05-11 23:40:18","tags":[],"plain":"Un attentat, un séisme, un match du Stade de France, une grande panne d'électricité. Dans ces moments-là, des centaines de milliers de gens dégainent leur téléphone au même instant. Le réseau mobile est dimensionné pour un usage moyen, pas pour un pic massif simultané, et il devrait théoriquement s'effondrer. La plupart du temps, il tient. Pas parfaitement, pas pour tout le monde, mais il tient — et surtout, les appels d'urgence continuent de passer. C'est le résultat d'une série de mécanismes empilés depuis les années 1990, que la 4G a affinés et que la 5G a élargis. Cet article les passe en revue, et termine sur une question qu'on me pose souvent : est-ce que mon forfait à 50 € me donne une place prioritaire dans cette file d'attente ?\r\n\r\nTrois questions, pas une\r\n\r\nQuand une cellule commence à chauffer, l'opérateur doit répondre à trois questions distinctes. Qui a le droit de se connecter ? Une fois connecté, qui passe en premier ? Et quels services doivent absolument continuer à fonctionner, quoi qu'il arrive ?\r\n\r\nLa 2G ne savait répondre qu'à la première. Elle filtrait à l'entrée et basta. La 4G a ajouté la deuxième : une fois admis sur le réseau, votre trafic est traité différemment selon son importance. La 5G ajoute la troisième : elle peut créer des réseaux virtuels parallèles dont certains sont réservés à des usages critiques, totalement isolés des autres.\r\n\r\nLe filtrage à l'entrée\r\n\r\nChaque carte SIM porte un numéro de classe d'accès, hérité du GSM, entre 0 et 15. Les classes 0 à 9 couvrent le grand public — autrement dit nous tous. Les classes 11 à 15 sont réservées : services de secours, autorités publiques, personnel opérateur, usages militaires selon les pays.\r\n\r\nQuand une cellule est surchargée, l'eNodeB (la station de base 4G) diffuse une consigne aux téléphones du secteur : « les classes 0 à 9, vous attendez ». C'est l'Access Class Barring. Concrètement, votre téléphone reçoit ce message et bloque lui-même votre tentative d'appel ou de connexion data, sans même envoyer la demande à la station. C'est élégant parce que ça soulage la station avant même qu'elle ne soit sollicitée. Les classes prioritaires, elles, passent sans encombre.\r\n\r\nUne variante plus dure, l'Extended Access Barring, vise les objets connectés et les usages non urgents. Quand une vraie crise se déclare, l'opérateur peut couper les compteurs intelligents, les alarmes domestiques et autres équipements bavards pour préserver la bande passante humaine.\r\n\r\nEn 5G, ce mécanisme a été refondu sous le nom d'UAC — Unified Access Control, introduit dans la Release 15 du 3GPP. UAC unifie dans un seul cadre ce qui était auparavant éparpillé entre ACB, EAB et d'autres dispositifs spécifiques. Il repose sur deux notions complémentaires. Les Access Identities identifient qui vous êtes : utilisateur lambda, abonné à un service prioritaire type MPS ou MCS, personnel d'urgence, agent opérateur. Les Access Categories identifient ce que vous essayez de faire : appel d'urgence, connexion data normale, SMS, mise à jour de localisation. La combinaison des deux détermine si votre demande passe ou pas. La granularité gagnée par rapport à la 4G est réelle : on peut bloquer un type d'action précis pour un type d'utilisateur précis, par exemple « les abonnés grand public ne peuvent plus initier de nouveaux appels data, mais les SMS et les appels voix continuent ».\r\n\r\nLa priorité une fois connecté\r\n\r\nLà où la 4G a vraiment innové, c'est en introduisant le QCI — QoS Class Identifier. Chaque flux de données qui transite sur le réseau se voit attribuer un numéro entre 1 et 9 (avec quelques valeurs supplémentaires pour des cas spéciaux) qui dit à l'infrastructure comment le traiter.\r\nUsage | QCI | Traitement |\r\n---|---|---|\r\nAppel VoLTE (voix sur LTE) | 1 | Latence minimale, débit garanti |\r\nVisioconférence | 2 | Débit garanti |\r\nSignalisation réseau | 5 | Très haute priorité |\r\nStreaming vidéo | 6 ou 8 | Best effort prioritaire |\r\nWeb et internet général | 9 | Best effort standard |\r\n\r\nQuand la cellule est encombrée, le routeur sait quoi sacrifier en premier. YouTube va ralentir, les pages web vont mettre du temps à charger, mais l'appel téléphonique de votre voisin reste audible. C'est un compromis assumé : on dégrade volontairement les usages secondaires pour préserver les usages critiques.\r\n\r\nLa 5G a transposé ce mécanisme sous le nom de 5QI (5G QoS Identifier) avec davantage de niveaux et une meilleure prise en compte des cas que la 4G gérait mal — notamment les services à très basse latence pour les usines connectées ou la voiture autonome. La voix d'urgence garde son sommet, les données critiques industrielles s'intercalent juste après, le streaming et le web restent en bas de la pile.\r\n\r\nL'isolation par tranches : le network slicing\r\n\r\nC'est l'apport majeur de la 5G en matière de gestion de crise. Au lieu de partager une seule infrastructure entre tous les usages, on peut maintenant la découper logiciellement en tranches — des slices — qui se comportent comme autant de réseaux indépendants, alors qu'ils tournent sur les mêmes antennes et les mêmes câbles.\r\n\r\nUn opérateur peut par exemple maintenir une tranche pour le grand public avec ses millions d'abonnés et son trafic massif, une autre pour les services d'urgence dimensionnée pour rester fluide même quand le reste sature, une troisième pour les objets connectés industriels avec des garanties de latence, et une quatrième pour des opérateurs critiques type SNCF, EDF ou hôpitaux. Chaque tranche a ses propres règles d'admission, ses propres priorités, ses propres garanties de performance. Si la tranche grand public est totalement saturée, celle des secours ne le sait même pas.\r\n\r\nCette isolation est ce qui distingue le plus fondamentalement la 5G des générations précédentes. Avant, tout le monde se battait pour les mêmes ressources, avec juste des priorités différentes pour départager. Maintenant, certaines ressources sont retirées du combat dès le départ.\r\n\r\nRécapitulatif\r\nGénération | Ce qui est contrôlé | Comment |\r\n---|---|---|\r\n2G | L'accès au réseau | Classes d'accès 0-15 |\r\n4G | L'accès + la priorité du trafic | ACB / EAB + QCI |\r\n5G | L'accès + la priorité + l'isolation des services | UAC + 5QI + network slicing |\r\n\r\nTous ces mécanismes restent invisibles tant que tout va bien. Vous ne savez pas qu'ils existent. Vous découvrez leur existence le jour où votre voisin n'arrive plus à charger ses mails alors que les pompiers, eux, continuent de communiquer normalement. Ce jour-là, ce n'est pas de la magie. C'est trente ans d'ingénierie radio qui ont anticipé que ça arriverait.\r\n--\r\n\r\nEt mon forfait premium, alors ?\r\n\r\nQuestion logique à ce stade. Si le réseau sait techniquement prioriser certains flux par rapport à d'autres, qu'est-ce qui empêche un opérateur de faire passer ses abonnés à 50 € devant ceux à 10 € quand les antennes saturent ? La réponse honnête commence par un aveu : techniquement, rien. L'outil existe, il s'appelle Quality of Service (QoS), c'est exactement le mécanisme qu'on vient de décrire. Si demain Orange ou SFR voulaient créer une voie rapide pour leurs abonnés haut de gamme, ils auraient les outils dans la boîte. Pourtant, ils ne le font pas. Pour quatre raisons.\r\n\r\nLa loi européenne l'interdit\r\n\r\nLe règlement (UE) 2015/2120, dit « règlement internet ouvert », oblige les opérateurs à traiter tout le trafic de la même façon, sans discrimination liée à l'expéditeur, au destinataire, au contenu ou à l'application. Il a fêté ses dix ans en novembre 2025, et l'ARCEP a profité de l'anniversaire pour rappeler que c'est l'un des piliers du modèle numérique européen. Les sanctions sont sérieuses : jusqu'à 3 % du chiffre d'affaires de l'opérateur fautif. Un opérateur français qui annoncerait demain « avec notre forfait Premium, vous passez devant les autres » se retrouverait devant l'ARCEP dans la semaine.\r\n\r\nLe règlement laisse quelques portes ouvertes pour les services dits « spécialisés » qui ont besoin d'une qualité garantie — téléchirurgie, voiture connectée. Mais ces exceptions sont étroitement encadrées et ne couvrent absolument pas le confort d'un client haut de gamme qui voudrait charger son Instagram plus vite à 19h.\r\n\r\nAux États-Unis, l'histoire est différente. La FCC a tenté de restaurer la neutralité du net en 2024, mais en janvier 2025 la cour d'appel du sixième circuit a invalidé la décision, jugeant que la FCC n'avait pas l'autorité légale pour reclasser le haut débit comme service public. Avec l'arrivée de Brendan Carr à la tête de la FCC, ouvertement opposé à la neutralité du net, il n'y a aujourd'hui plus de règle fédérale outre-Atlantique. Quelques États (Californie, Washington, New York, Oregon) ont leurs propres lois qui maintiennent le principe, mais à l'échelle du pays, les opérateurs américains pourraient légalement faire ce que leurs homologues européens n'ont pas le droit de faire. Pourtant, ils ne le font pas ouvertement non plus, et la raison renvoie aux trois points suivants.\r\n\r\nC'est commercialement intenable\r\n\r\nImagine la publicité : « Forfait Premium à 50 € — passez devant les pauvres pendant les heures de pointe ». Le slogan ne se vend pas. Les directions marketing savent que dire à la moitié de leurs clients qu'ils sont des citoyens de seconde zone du réseau est le plus court chemin vers une crise de réputation. C'est pour ça qu'on vous vend « plus de Go », « 5G ultra rapide », « roaming inclus dans 110 pays » — des promesses qui sonnent positivement sans jamais dire à personne qu'il est désavantagé.\r\n\r\nL'effet boule de neige serait toxique\r\n\r\nImagine que ça se mette quand même en place. Les riches passent devant. Les antennes restent saturées pour les autres, qui se mettent à payer plus pour échapper à la saturation, ce qui sature encore plus les bas forfaits, ce qui pousse encore plus de gens à monter en gamme. Au bout de cinq ans, on a un réseau à deux vitesses où les forfaits modestes deviennent quasi inutilisables aux heures critiques, et où la connexion mobile correcte devient un service de luxe. Ce n'est plus un service de télécommunications, c'est un système de classes.\r\n\r\nC'est exactement ce que la neutralité du net cherche à empêcher. Pas par idéologie, mais parce qu'on a déjà vu où mène ce genre de spirale dans les pays où elle n'est pas protégée. Certains opérateurs proposent par exemple des forfaits où Facebook et WhatsApp sont gratuits mais où le reste est payant, ce qui revient à dire que le bon internet est celui que l'opérateur a choisi pour vous. Ce n'est plus tout à fait le même service.\r\n\r\nÇa ne résoudrait rien\r\n\r\nQuand un réseau sature, ce n'est pas un problème de répartition entre utilisateurs, c'est un problème de capacité totale. Faire passer Pierre avant Paul ne crée pas un seul bit de bande passante supplémentaire. Ça déplace juste le problème de l'un vers l'autre. La vraie solution, quand une cellule sature trop souvent, c'est d'installer plus d'antennes, de densifier le réseau, de basculer sur une fréquence plus performante ou de passer à la génération suivante. C'est cher, c'est long, ça implique des autorisations administratives et des négociations foncières, mais c'est la seule réponse qui tient la route. Prioriser, c'est rapide, mais ça repousse le mur, ça ne le déplace pas.\r\n\r\nC'est comme si on proposait une voie réservée aux Mercedes sur l'A7 un samedi de chassé-croisé. Techniquement, on peut peindre la ligne au sol et installer les panneaux dans la matinée. Mais cette voie ne réduit pas le bouchon, elle le concentre sur les voies restantes ; elle écorne le principe d'égalité d'accès à l'infrastructure publique ; et elle ne change rien au problème de fond, qui est qu'il y a trop de voitures pour la route disponible. La vraie solution reste la même qu'avant : élargir l'autoroute, ou convaincre une partie des gens de prendre le train.\r\n\r\nLe caveat 5G\r\n\r\nUne nuance honnête pour finir. Le network slicing complique le débat juridique. Un opérateur peut créer des tranches de réseau avec des qualités différenciées en toute légalité quand il s'agit d'usages spécialisés — santé, industrie, transports. La question qui agite régulateurs et juristes depuis plusieurs années est de savoir où finit le service spécialisé légitime et où commence le contournement déguisé de la neutralité du net. L'ARCEP a ouvert ce chantier, et c'est probablement là, plus que dans une revanche commerciale brutale sur les forfaits premium, que se jouera la prochaine bataille.\r\n\r\nMais pour répondre simplement à la question : non, votre forfait à 50 € ne vous donne pas la priorité réseau sur celui de votre voisin à 10 €. Il vous donne plus de data, parfois un meilleur débit théorique, des options en plus. Pas une place dans la file."},{"uuid":"ddb53aae-7214-4e3c-8af5-e42da60d8429","slug":"kobo-elipsa-2e-le-cahier-a4-numerique-qu-on-attendait-a-quelques-details-pres","title":"Kobo Elipsa 2E : le cahier A4 numérique qu'on attendait, à quelques détails près","category":"loisirs","author":"cedric@abonnel.fr","cover":"cover.jpg","published":true,"published_at":"2025-11-09 12:07","created_at":"2025-11-09 12:07:00","updated_at":"2026-05-12 01:43:39","tags":[],"plain":"Une liseuse qui n'en est plus tout à fait une\r\n\r\nPendant longtemps, le marché des liseuses s'est tenu à une règle non écrite : une liseuse, c'est petit, c'est noir et blanc, c'est fait pour lire des romans dans le métro. Les tentatives de sortir de ce cadre — Sony DPT-RP1, Onyx Boox, ReMarkable — restaient soit confidentielles, soit positionnées comme des outils de prise de notes pure, sans véritable identité de liseuse. Avec l'Elipsa 2E, Kobo assume frontalement l'hybridation. Ce n'est pas une liseuse à laquelle on a ajouté un stylet ; c'est un objet pensé dès le départ comme un cahier numérique qui sait aussi lire des livres.\r\n\r\nL'engin est imposant. Écran E-Ink Carta 1200 de 10,3 pouces, résolution 1404 × 1872 pour 227 ppi, processeur dual-core 2 GHz et 32 Go de stockage. Côté tarif, TechRadar la situe autour de 399 dollars ou 349 livres, ce qui la place dans une catégorie où on n'achète plus sur un coup de tête : à ce prix, on attend un usage précis, pas un gadget de chevet.\r\n\r\nLe format change tout\r\n\r\nTenir l'Elipsa 2E pour la première fois, c'est comprendre instantanément à qui elle parle. À 10,3 pouces, on est très proche d'une feuille A5, voire d'un cahier d'étudiant — un format qui colle naturellement aux PDF et aux documents grand format. Et c'est là que tout se joue.\r\n\r\nQuiconque a déjà tenté de lire un PDF technique sur une liseuse 6 ou 7 pouces sait à quel point l'exercice est frustrant : on zoome, on déplace, on perd la mise en page, les schémas explosent en morceaux. Avec l'Elipsa 2E, un PDF A4 passe à l'écran à une taille parfaitement lisible, sans gymnastique. Les manuels techniques, les articles scientifiques, les supports de cours, les rapports d'entreprise : tout ce qui était pénible devient confortable. C'est moins spectaculaire que la couleur d'une Libra Colour, mais sur un usage professionnel ou étudiant intensif, le format change littéralement la nature de l'objet.\r\n\r\nLe stylet, atout central — mais imparfait\r\n\r\nLe stylet est inclus dans la boîte. Détail qui n'a l'air de rien mais qui mérite d'être souligné, parce que l'usage prévu est clairement l'annotation directe sur les e-books et la prise de notes manuscrites. Pas de Kobo Stylus 2 à racheter en option, pas de configuration séparée : on déballe, on écrit.\r\n\r\nL'utilisation est exactement ce qu'on en attend. On peut surligner dans n'importe quel ePub, écrire dans la marge, créer des carnets vierges pour des notes manuscrites, dessiner des schémas à main levée. Tout ce qu'on griffonne reste dans le fichier, et — point essentiel — peut être ressorti ensuite. Le système prend en charge ePub, PDF, et accepte sans broncher les fichiers déposés par USB-C, Wi-Fi ou Bluetooth.\r\n\r\nMais il faut être honnête : la sensation d'écriture n'est pas au niveau de ce que proposent les meilleurs concurrents. eWritable est même cinglant, qualifiant l'expérience tactile d'« horrible » et pointant le choix par Kobo du protocole Microsoft Pen Protocol (MPP 2.0) plutôt que la technologie Wacom qui équipe le ReMarkable 2 et reste la référence du secteur. Concrètement, qu'est-ce que ça veut dire ? Que la pointe glisse un peu trop sur le verre, qu'il manque cette résistance subtile qui fait penser au crayon sur papier, et qu'à très haute vitesse d'écriture la latence devient perceptible. Pour quelqu'un qui annote ses lectures, surligne, prend des notes ponctuelles, c'est largement suffisant. Pour quelqu'un qui veut remplacer son carnet Moleskine en cours magistral et écrire trois pages d'affilée à vitesse normale, ce sera frustrant.\r\n\r\nC'est une différence de positionnement, pas un défaut technique grave : l'Elipsa 2E est d'abord une liseuse qui annote, pas un cahier qui sait aussi lire.\r\n\r\nL'export des annotations, ce qui fait vraiment la différence\r\n\r\nC'est probablement le point sur lequel Kobo creuse l'écart avec ses concurrents, et notamment avec le Kindle Scribe. Le manuel officiel explique qu'on peut exporter ses annotations sous forme de fichier .txt et le récupérer sur son ordinateur, mais en réalité l'écosystème va plus loin : les PDF annotés ressortent avec les annotations intégrées à la page, prêts à être imprimés ou partagés.\r\n\r\nCe flux, en apparence banal, change tout pour qui travaille sérieusement avec ses lectures. Un étudiant peut annoter ses cours et imprimer la version surlignée pour les révisions. Un enseignant peut corriger des copies en PDF et renvoyer le fichier annoté à l'élève. Un consultant peut lire un rapport, le commenter en marge, le réintégrer dans sa documentation projet. Aucune annotation perdue, aucune resaisie. Là où Kindle Scribe limite encore largement l'export de ses annotations, Kobo joue le jeu de l'ouverture.\r\n\r\nLe talon d'Achille : l'entrée des fichiers\r\n\r\nC'est ici que l'Elipsa 2E montre ses limites les plus tangibles, et il faut le savoir avant d'acheter. Contrairement à Kindle, il n'existe pas d'adresse e-mail officielle « envoyer à ma liseuse » : il faut transférer les fichiers manuellement, par USB ou via un service tiers comme Dropbox. Pour qui s'envoie régulièrement des articles ou des e-books depuis son ordinateur ou son téléphone, ce manque crée une vraie friction quotidienne.\r\n\r\nLes workarounds existent, à condition d'accepter de mettre un peu les mains dans le moteur. Un projet open source baptisé KoboMail propose un système d'envoi par e-mail pour certaines Kobo, et plus intéressant encore, un daemon Nextcloud-Kobo permet de synchroniser automatiquement un dossier Nextcloud via WebDAV vers la liseuse. C'est ouvert, c'est élégant, ça respecte le principe d'auto-hébergement — mais ce n'est pas du plug and play. Il faut un serveur Nextcloud opérationnel, savoir configurer une connexion WebDAV, et accepter que l'installation se fasse dans le dossier du système Kobo. Bref, c'est superbe pour qui maîtrise déjà son infrastructure ; c'est rédhibitoire pour qui veut juste une solution clé en main.\r\n\r\nSur ce point précis, Kobo et Amazon proposent deux philosophies opposées : le confort immédiat d'un écosystème fermé contre la liberté d'un écosystème ouvert mais exigeant. À vous de voir où vous vous situez.\r\n\r\nPour qui ce produit a-t-il du sens ?\r\n\r\nL'Elipsa 2E est faite pour vous si vous lisez beaucoup de documents grand format — PDF techniques, cours universitaires, rapports professionnels, partitions — et si l'idée d'annoter ces documents fait partie intégrante de votre flux de travail. Elle est faite pour vous si vous voulez un objet unique au lieu de jongler entre une liseuse classique et un cahier papier. Elle est faite pour vous, aussi, si vous avez déjà (ou êtes prêt à monter) un Nextcloud ou un Dropbox pour synchroniser vos fichiers proprement.\r\n\r\nElle ne l'est pas si votre priorité est la prise de notes manuscrite intensive et fluide : sur ce terrain, un ReMarkable 2 ou un Supernote restent supérieurs. Elle ne l'est pas non plus si vous attendez le confort de l'envoi par e-mail à la Kindle, ou si l'idée d'installer un plugin communautaire pour combler un manque officiel vous donne de l'urticaire. Et elle est sans doute disproportionnée si vous lisez essentiellement des romans : à ce moment-là, une Clara BW à 150 € vous donnera plus de plaisir, dans un format de poche.\r\n\r\nMon avis\r\n\r\nL'Elipsa 2E est un produit ambitieux qui réussit l'essentiel et trébuche sur quelques détails finalement révélateurs. L'essentiel, c'est le format, la qualité de l'écran, l'export des annotations, l'ouverture du système et l'autonomie typique d'une liseuse — autant de raisons qui en font la meilleure proposition du marché pour un usage documentaire sérieux à ce niveau de prix.\r\n\r\nLes détails, ce sont le ressenti perfectible du stylet et l'absence d'un système d'entrée des fichiers digne de 2026. Kobo aurait pu intégrer nativement WebDAV — ça lui coûterait à peu près rien — et opter pour une dalle Wacom — ça lui coûterait plus cher mais lui ferait gagner une catégorie entière d'utilisateurs. À la place, on hérite d'un produit excellent à 80 %, et qui demande qu'on accepte ses zones grises sur les 20 % restants.\r\n\r\nPour qui cherche un véritable cahier A4 numérique sans basculer dans une tablette Android Onyx — plus chère, plus complexe, et au confort de lecture moindre — l'Elipsa 2E reste, à mes yeux, le meilleur compromis du moment. Pas le produit parfait. Le meilleur compromis. Ce n'est pas la même chose, et c'est très bien aussi."},{"uuid":"593c8ceb-9071-4db8-85a4-2bca8a98774f","slug":"40-20200601-ssd-sur-raspberry-pi","title":"SSD sur Raspberry Pi / Passerelle, DNS et DHCP : le réseau à la maison","category":"Podcasts","author":"cedric@abonnel.fr","cover":"","published":true,"published_at":"2020-06-01 09:13:29","created_at":"2020-06-01 09:13:29","updated_at":"2020-06-01 09:13:29","tags":[],"plain":"Voici un rapide tour des informations que je traite dans ce 40ème épisode : SSD sur Raspberry Pi / Passerelle, DNS et DHCP : le réseau à la maison Je vous parle de deux sujets : le branchement d'un SSD sur Rasbperry Pi et le fonctionnement du réseau IP à la maison. Cette page est amenée à évoluer. Réagissez à cet épisode dans la partie [Épisode disponible sur https:info.mindcast.fr/]\n-- Est-ce qu'un disque dur branché sur un Raspberry Pi 2 est vraiment utile ? Evidemment, je pose la question d'un point de vue de performance, car le RPI est limité par la présente de ports USB 2.\nJe vous présente comment j'ai préparé mon disque dur et je réalise les tests de performances. Les commandes utilisées dans cette vidéo sont :\nlsblk - lister les périphériques de type bloc\nblkid - lister les id des périphériques de type bloc\nrsync - copier et synchroniser les fichiers\ndd - copier en bloc, me permet de faire des tests de performance d'écriture\niostat - statistique sur les périphériques Les fichiers modifiés dans cette vidéo sont :\ncmdline.txt dans la partition '/boot' de la carte SD\n/etc/fstab dans la partition '/' du disques dur externe La première partie de la vidéo indique comment j'ai préparé le disque dur.\nCette étape est interessante car je vous indique comment copier les données de la carte S vers le disque dur externe sans casser toutes les permissions et propriétaires des différents fichiers.\nLa méthode utilisée permet de toujours conserver le moyen de démarrer la carte SD en cas de défaillance du disque (mauvais branchement USB, mauvaise alimentation électrique, defaillance mécanique...). Le secondes partie, vous dévoile les moyens logiciels pour évaluer les performances d'écriture sur un périphérique. Ces moyens sollicitent énormément la RAM, donc il faut les utiliser avec précaution. En conclusion, même pour une carte comme le Raspberry Pi 2 qui ne possède qu'un Port USB, avoir un disque dur externe branché en autoalimentation sur USB, ça vaut franchement le coup pour des questions de débit d'écriture sur le disque. Vidéo disponible sur la chaine Youtube 'S'informer sur la Tech' https:youtu.be/MDzLiVKCeXE\n-- Comment fonctionne le réseau à la maison ? Pourquoi avons-nous besoin de routeur ? Pourquoi un DHCP est utile ou inutile ? Comment mettre en place un filtrage Internet ? Première vidéo incontournable, d'une longue série, très instructive et qui permettra de poser de bonnes bases pour la suite. Je vous recommande de passer un moment dessus pour enfin assurer la maitrise de votre réseau domestique. Les commandes utilisées sont , et . Vidéo disponible sur la chaine Youtube 'S'informer sur la Tech' https://youtu.be/qs-J9oXkUEA"}] |