Cédrix
1 line
32 KiB
JSON
1 line
32 KiB
JSON
[{"uuid":"6a70fb79-9cd0-42a5-ae17-f7e30875f32f","slug":"7245","title":"7245 - Le transport des prisonniers","category":"Loisirs","author":"cedric@abonnel.fr","cover":"","published":true,"published_at":"2020-04-17 18:07:14","created_at":"2020-04-17 18:07:14","updated_at":"2020-04-17 18:07:14","tags":[],"plain":"Article: 7245 Âges: 5-8 ans Année : 2005 Nb de Pièces: 98 Conduis le méchant en prison ! Pas moyen de s'échapper du fourgon de police ! Une fois que le policier capture le bandit, il le met derrière les barreaux de son fourgon blindé et l'amène à la prison. La sécurité règne de nouveau dans la ville LEGO® ! Comprend un policier et un bandit. Ouvre la porte arrière du fourgon pour mettre le prisonnier à l'intérieur. <http://www.peeron.com/inv/sets/7245-1>"},{"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":"5a0cced3-40d0-46bf-8501-b533f3c2608e","slug":"reparer-une-instance-uptime-kuma-installee-via-le-script-proxmox","title":"Réparer une instance Uptime Kuma installée via le script Proxmox","category":"informatique","author":"cedric@abonnel.fr","cover":"cover.svg","published":true,"published_at":"2025-11-26 08:33","created_at":"2025-11-26 08:33:49","updated_at":"2026-05-12 09:16:00","tags":[],"plain":"Méthode basée sur l'installation via le script communautaire :\r\ncommunity-scripts.github.io/ProxmoxVE/scripts?id=uptimekuma\r\n\r\nSi tu utilises Uptime Kuma pour monitorer ton infra, tu finiras tôt ou tard par tomber sur un de ces grands classiques : le service qui refuse de démarrer après une mise à jour, des erreurs SQLite louches dans , ou pire — l'interface qui tourne mais ne remonte plus aucun heartbeat. Dans 90 % des cas, c'est la base SQLite qui a pris cher, souvent à cause d'un arrêt brutal du conteneur LXC ou d'une migration qui s'est mal passée.\r\n\r\nAvant de paniquer et de tout réinstaller, il y a une série d'étapes à dérouler. Je les mets ici dans l'ordre, parce que l'ordre compte : on commence toujours par le moins destructif.\r\n\r\nPourquoi SQLite et pas un vrai SGBD ?\r\n\r\nPetite parenthèse pour les juniors qui se demanderaient. Uptime Kuma embarque SQLite parce que c'est une appli pensée pour être facile à déployer : pas de serveur de base à installer à côté, pas de credentials à gérer, juste un fichier sur le disque. C'est génial pour démarrer, mais ça a un défaut majeur — SQLite n'aime pas du tout être coupé en plein milieu d'une écriture. Si ton LXC tombe pendant que Kuma écrit un heartbeat, tu peux te retrouver avec un fichier corrompu. D'où l'importance de toujours arrêter proprement le service avant de toucher au fichier.\r\n\r\n1. Arrêter le service proprement\r\n\r\n\r\n\r\nC'est la première chose à faire, toujours. Tant que le service tourne, il a un verrou sur et il continue d'y écrire. Tu peux ouvrir le fichier en lecture avec malgré ce verrou, mais dès que tu veux faire un ou un , tu vas soit avoir une erreur , soit — pire — corrompre encore plus la base si tu forces.\r\n\r\nVérifie que c'est bien arrêté avant de continuer :\r\n\r\n\r\n\r\nTu dois voir . Pas , pas , pas avec un process encore en l'air.\r\n\r\n2. Aller dans le dossier de l'app\r\n\r\nLe script communautaire installe Kuma dans :\r\n\r\n\r\n\r\nDans ce dossier, ce qui nous intéresse c'est le sous-dossier . C'est là que vit tout ce qui compte : le fichier (la base), les uploads, et quelques fichiers de config. Le reste (, , etc.) c'est le code de l'application — tu peux le casser, un ou une réinstallation le remettra en place. Mais , si tu le perds, tu perds toute ta config de monitoring.\r\n\r\n3. Sauvegarder avant de toucher à quoi que ce soit\r\n\r\nRègle d'or de l'ops : on ne touche jamais à une base de données sans avoir une copie au chaud. Jamais.\r\n\r\n\r\n\r\nLe te génère un suffixe du genre . Comme ça si tu fais plusieurs interventions dans la même semaine, tu sais laquelle date de quand, et tu ne risques pas d'écraser une sauvegarde par une autre.\r\n\r\nCette copie embarque :\r\nla base elle-même\r\nles fichiers WAL (, ) si SQLite est en mode Write-Ahead Logging — c'est important de les prendre avec, sinon ta sauvegarde est incomplète\r\nles uploads et certificats si tu en as\r\n\r\nSi tu sautes cette étape et que tu te plantes à l'étape 5 ou 6, tu n'auras aucun moyen de revenir en arrière. Sérieusement, fais-le.\r\n\r\n4. Vérifier l'intégrité de la base\r\n\r\n\r\n\r\n, c'est la commande de diagnostic native de SQLite. Elle parcourt toute la base, vérifie que les index pointent bien sur les bonnes lignes, que les pages ne sont pas corrompues, que les contraintes sont respectées. Deux issues possibles :\r\n* : la base est saine sur le plan structurel. Si Kuma ne démarre toujours pas, le problème vient probablement d'une migration coincée (voir étape 5) ou du code de l'app, pas du fichier.\r\nUne liste d'erreurs : il y a de la corruption. Selon ce qui est touché, on passera à l'étape 5 ou 6.\r\n\r\nPour les juniors qui découvrent SQLite : , c'est le mot-clé que SQLite utilise pour les commandes qui ne sont pas du SQL standard — c'est spécifique à SQLite, tu ne le verras pas dans PostgreSQL ou MySQL.\r\n\r\n5. Supprimer un paramètre de migration corrompu\r\n\r\nSur certaines versions de Kuma (notamment autour des montées de version qui touchent à l'agrégation des heartbeats), il y a un bug connu : l'entrée dans la table se retrouve dans un état incohérent, et le service refuse de démarrer parce qu'il pense être au milieu d'une migration qui n'avance plus.\r\n\r\nLa fix :\r\n\r\n\r\n\r\nCe qu'on fait, c'est qu'on dit à Kuma : \"oublie où tu en étais, repars de zéro sur ce point\". Au redémarrage, il va recréer la clé proprement et relancer la migration depuis le début. C'est non destructif pour tes données de monitoring — on ne touche qu'à un drapeau d'état interne.\r\n\r\nSi ce n'est pas ton problème (clé absente ou suppression sans effet), passe à la suite.\r\n\r\n6. Solution radicale : vider la table \r\n\r\nSi la corruption est concentrée sur l'historique de monitoring (et c'est souvent le cas, parce que c'est la table où Kuma écrit le plus souvent — un INSERT toutes les 20-60 secondes par sonde, ça finit par faire du volume), tu peux la vider :\r\n\r\n\r\n\r\nÀ lire attentivement : cette commande supprime tout l'historique des sondes. Tu perds les graphes de uptime, les SLA calculés sur les 30/90/365 derniers jours, tout. En revanche :\r\ntes sondes sont conservées (table )\r\ntes utilisateurs aussi (table )\r\ntes notifications également (table )\r\nta config générale est intacte (table )\r\n\r\nC'est à utiliser uniquement quand :\r\npointe vers des problèmes sur ou ses index\r\nKuma refuse de démarrer et l'étape 5 n'a rien donné\r\nou plus simplement, ta base a tellement grossi que Kuma rame et que tu acceptes de perdre l'historique pour repartir propre\r\n\r\nTant qu'à faire, profites-en pour faire un derrière, qui va vraiment libérer l'espace disque (un seul ne récupère pas la place sur le disque, il marque juste les pages comme libres pour réutilisation) :\r\n\r\n\r\n\r\n7. Redémarrer le service\r\n\r\n\r\n\r\nEt vérifie qu'il a bien démarré :\r\n\r\n\r\n\r\nTu dois voir . Si tu vois ou si le service redémarre en boucle, ne le laisse pas dans cet état — passe directement à l'étape 8 pour comprendre pourquoi.\r\n\r\n8. Lire les logs\r\n\r\n\r\n\r\nLe cible le service, le fait du (équivalent de ) — les nouvelles lignes s'affichent en temps réel. Laisse tourner pendant deux ou trois minutes, le temps que Kuma rejoue ses migrations, recharge ses sondes, et envoie les premiers heartbeats.\r\n\r\nCe qu'il faut chercher dans les logs :\r\nerreurs SQLite : , , — ça veut dire que t'as encore un problème de fichier, voire de permissions\r\nmigrations bloquées : des messages du genre qui ne sont jamais suivis d'un \r\npermissions : , — typiquement après une intervention faite en root sur des fichiers qui doivent appartenir à un autre utilisateur. Vérifie avec que les fichiers sont bien possédés par l'user qui fait tourner le service\r\nmodules Node manquants : — ça arrive après une mise à jour qui s'est mal passée. La fix, c'est généralement de relancer dans \r\nport déjà utilisé : — tu as un autre process qui squatte le port 3001 (ou celui que tu as configuré)\r\n\r\nPour sortir du , c'est .\r\n\r\nEt après ?\r\n\r\nUne fois que Kuma tourne propre, prends cinq minutes pour mettre en place ce qui t'aurait évité d'arriver ici :\r\n\r\n1. Une sauvegarde régulière de . Un simple cron qui fait du dossier vers un autre serveur, ça suffit largement pour un Kuma perso. Pense à arrêter le service avant le tar, ou utilise qui fait un snapshot cohérent sans devoir couper Kuma.\r\n2. Un monitoring du monitoring. Oui, c'est méta. Mais si Kuma tombe, c'est lui qui t'aurait alerté de la chute de tes autres services — donc personne ne te prévient. Un check externe (UptimeRobot gratuit, healthchecks.io, ou un autre Kuma sur une autre machine) qui ping ton instance, c'est cinq minutes à mettre en place.\r\n3. Garder ta sauvegarde au moins une semaine** avant de la supprimer. Au cas où un effet de bord apparaîtrait quelques jours plus tard.\r\n\r\nEt voilà. Avec ces huit étapes, tu couvres 95 % des cas de Kuma cassé. Pour les 5 % restants — typiquement quand le LXC lui-même a un souci de filesystem — c'est une autre histoire, et il faudra sortir l'artillerie côté Proxmox."},{"uuid":"ad1fe29b-d77c-48c5-b0b1-d950244a4ca8","slug":"test-de-debit-de-disques-dur","title":"Tester le débit des disques dur avec dd","category":"Informatique","author":"cedric@abonnel.fr","cover":"","published":true,"published_at":"2022-12-07 20:42:37","created_at":"2022-12-07 20:42:37","updated_at":"2022-12-07 20:42:37","tags":[],"plain":"Sous Linux, la commande peut être utilisée pour une mesure de performance en lecture et écriture séquentielle. Un test de lecture et écriture. Pour se concentrer sur l'écriture des données sur un disque, la source des informations sera une suite de zero disponible depuis le chemin . Si nous voulions mesurer la performance du disque, il aurait fallu écrire directement sur le chemin du disque (par exemple of=/dev/sda), mais cela effacerait le contenu du disque. En indiquant le chemin d'un fichier , nous devons passer par le systèmes de gestion de fichiers, qui peut nous ralentir. Mais cela n’enlèvera pas les conditions réelles que nous pouvons avoir avec un disque. En utilisant , Linux aura besoin de 1GB d'espace disponible dans la RAM. Si vous n'avez pas suffisamment d'espace disponible, pensez à réduire cette valeur, par exemple à 512MB. J'ai effectué des tests avec des disques dur externes branchés sur un Raspberry Pi 3. Les disques se trouvent dans deux baies 4 disques branchées sur les ports USB3, sauf le disk51 qui était branché sur un port USB 2.0. Ensuite J'ai effectué un second test avec tous les disques branchés derrière un HUB USB 3.\nDisk | Branché en direct | Branché via un hub |\n--- | --- | --- |\ndisk14 | 76,2 MB/s | 76,2 MB/s |\ndisk20 | 89,6 MB/s | 90,2 MB/s |\ndisk21 | 99,0 MB/s | 91,9 MB/s |\ndisk23 | 108 MB/s | 97,3 MB/s |\ndisk24 | 101 MB/s | 95,0 MB/s |\ndisk25 | 97,3 MB/s | 93,5 MB/s |\ndisk51 | 24,6 MB/s | 68,0 MB/s |"},{"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."}] |