[{"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":"da406813-bf15-4f4e-a700-2752550224bb","slug":"quand-la-3g-suffisait-et-qu-on-vous-fait-basculer","title":"Quand la 3G suffisait… et qu’on vous fait basculer","category":"télécom","author":"cedric@abonnel.fr","cover":"","published":true,"published_at":"2025-11-05 08:38:25","created_at":"2025-11-05 08:38:25","updated_at":"2025-11-05 08:38:25","tags":[],"plain":"Une plongée scientifique et technologique dans l’évolution des réseaux mobiles et la stratégie des opérateurs.\r\n--\r\n\r\nIntroduction\r\nEn 2015, votre 3G suffisait pour le télétravail, la visioconférence et le streaming léger. Aujourd’hui, même pour un simple email, certaines zones semblent plus lentes qu’avant.\r\n\r\nL’histoire des télécommunications mobiles est jalonnée de révolutions techniques. Chaque génération de réseau – de la 2G à la 5G – a apporté des débits supérieurs, des latences réduites et de nouveaux usages. Pourtant, derrière la façade technologique, une stratégie commerciale se dessine : la migration forcée des utilisateurs vers les nouvelles générations. Ce dossier examine comment la 3G, la 4G et la 5G se succèdent, comment les opérateurs orchestrent le passage d’une technologie à l’autre, et quels impacts cela a sur l’expérience utilisateur.\r\n--\r\n\r\nLa 3G : une technologie encore performante… bridée par les opérateurs\r\n\r\nDéfinition et usages\r\n\r\nLa 3G (UMTS/HSPA) a marqué un saut qualitatif par rapport à la 2G. Développée à la fin des années 1990 et déployée massivement à partir de 2004, elle permettait :\r\n\r\n des débits théoriques de 384 kbit/s jusqu’à 42 Mbit/s pour les variantes HSPA+ ;\r\n des applications comme le surf web, la messagerie instantanée, les appels VoIP et la visioconférence légère ;\r\n une latence moyenne de 150–200 ms, suffisante pour la plupart des usages bureautiques.\r\n\r\nPour l’utilisateur lambda, la 3G suffisait amplement. Pourtant, à partir de 2016–2017, certains opérateurs ont commencé à réduire volontairement les performances.\r\n\r\nExemple concret : Free Mobile\r\n\r\nFree Mobile, en itinérance sur le réseau Orange, a progressivement bridé les débits 3G :\r\nAnnée | Débit descendant | Débit montant |\r\n----- | ---------------- | ------------- |\r\n2016  | 5 Mbit/s        | 0,5–1 Mbit/s  |\r\n2017  | 1 Mbit/s        | 0,5 Mbit/s    |\r\n2019  | 768 kbit/s       | 384 kbit/s    |\r\n2020  | 384 kbit/s       | 384 kbit/s    |\r\nSource : 01net – Free Mobile et bridage 3G\r\n\r\nLes utilisateurs constatent alors que leur expérience, auparavant fluide, devient frustrante : ralentissement du web, vidéos qui ne se chargent pas correctement, visioconférences de qualité médiocre.\r\n\r\nPourquoi un bridage ?\r\n\r\nLe bridage de la 3G s’explique par plusieurs facteurs :\r\n\r\n1. Refarming du spectre : libérer les fréquences 900/1800/2100 MHz pour la 4G et la 5G ;\r\n2. Coût d’entretien : maintenir un réseau 3G coûteux pour des utilisateurs minoritaires n’est plus rentable ;\r\n3. Incitation à migrer : les abonnés passent naturellement aux nouvelles technologies pour profiter de meilleurs débits.\r\n\r\nSchéma suggéré : flux de données et coût par bit en 3G vs 4G.\r\n--\r\n\r\nLa 4G : la révolution nécessaire\r\n\r\nDéfinition technique\r\n\r\nLa 4G, ou LTE (Long Term Evolution), est une avancée majeure :\r\n\r\n Débits théoriques : 100 Mbit/s → 1 Gbit/s ;\r\n Latence : 30–50 ms ;\r\n Architecture optimisée : eNodeB remplace le contrôleur RNC de la 3G pour réduire les goulots d’étranglement ;\r\n Utilisations : streaming HD, cloud computing, jeux en ligne, IoT.\r\nLa 4G a donc transformé l’expérience mobile et a rendu certaines limitations 3G plus visibles que jamais.\r\n\r\nStratégies de migration\r\n\r\nLes opérateurs incitent à la migration par :\r\n\r\n le bridage des anciennes générations ;\r\n la publicité sur les débits 4G/5G ;\r\n le lancement de forfaits “4G-only”.\r\nOpérateur | 3G moyen (Mbit/s) | 4G moyen (Mbit/s) |\r\n--------- | ----------------- | ----------------- |\r\nFree      | 0,384             | 50–150            |\r\nOrange    | 0,5–1             | 60–200            |\r\nSFR       | 0,5               | 50–150            |\r\nBouygues  | 0,5               | 50–150            |\r\nGraphique suggéré : part des abonnés 4G vs 3G (2015–2025).\r\n--\r\n\r\nLa 5G : promesse et réalité\r\n\r\nLes promesses\r\n\r\n Débits : 100 Mbit/s → 10 Gbit/s selon fréquence et densité d’antennes ;\r\n Latence ultra faible : 1–10 ms ;\r\n Fréquences : 700 MHz → 26 GHz (mmWave) ;\r\n Usages : cloud gaming, véhicules autonomes, IoT à grande échelle.\r\n\r\nL’expérience utilisateur\r\n\r\nMême scénario qu’avec la 3G : certaines zones restent en 4G bridée, incitant les utilisateurs à passer à la 5G. La promesse de la 5G ne se réalise pleinement que dans les zones très denses ou les zones pilotes.\r\n\r\nSchéma suggéré : architecture 4G vs 5G.\r\n--\r\n\r\nConséquences pour l’utilisateur\r\n\r\n Scénarios pratiques : visioconférence, streaming, cloud computing, IoT ;\r\n Expérience variable selon réseau : frustration sur 3G bridée, fluidité sur 4G/5G ;\r\n Témoignages utilisateurs : Reddit, forums français, témoignages directs.\r\n“Dès qu’on tombe en 3G, rien ne charge correctement… le réseau est volontairement dégradé.” – Reddit\r\n--\r\n\r\nSynthèse scientifique\r\nGénération | Débit théorique        | Latence    | Couverture | Usages possibles                       | Coût par bit | Bridage existant       |\r\n---------- | ---------------------- | ---------- | ---------- | -------------------------------------- | ------------ | ---------------------- |\r\n3G         | 384 kbit/s → 42 Mbit/s | 150–200 ms | Très large | Email, surf, visio légère              | Élevé        | Itinérance bridée Free |\r\n4G         | 100 Mbit/s → 1 Gbit/s  | 30–50 ms   | Large      | Streaming HD, jeux, cloud              | Moyen        | Bridage minoritaire    |\r\n5G         | 100 Mbit/s → 10 Gbit/s | 1–10 ms    | Variable   | IoT, cloud gaming, véhicules autonomes | Faible       | Pas encore             |\r\nLe bridage apparaît comme une stratégie commerciale autant qu’une conséquence technique, visant à préparer l’utilisateur à migrer vers de nouvelles technologies.\r\n--\r\n\r\nPerspectives et conseils\r\n\r\n Vérifier la couverture et la technologie disponible selon votre zone ;\r\n Questionner son opérateur :\r\n\r\n  1. Suis-je sur le réseau propre ou en itinérance ?\r\n  2. Quels sont les débits effectifs en 3G et 4G ?\r\n  3. Quand la 3G sera-t-elle désactivée ?\r\n Anticiper le passage à la 5G pour certains usages exigeants (IoT, cloud gaming, télétravail intensif).\r\nVous pouvez encore profiter de votre 3G… mais à quel prix ?\r\n--\r\n\r\nRéférences principales\r\n\r\n1. 01net – Free Mobile et bridage 3G\r\n2. Univers Freebox – Bridage 3G\r\n3. ARCEP – Gestion spectre et couverture\r\n4. Free Mobile – Fiche information standardisée 2020 (PDF)"},{"uuid":"8236d5a4-be51-4cca-a0db-1647307bc43b","slug":"dhcp","title":"DHCP et DNS","category":"Informatique","author":"cedric@abonnel.fr","cover":"","published":true,"published_at":"2021-02-21 19:46:14","created_at":"2021-02-21 19:46:14","updated_at":"2021-02-21 19:46:14","tags":[],"plain":"En solution de DNS, j'en connais deux : Bind9 et dnsmasq. Bind9 (appelé également bind ou named) est mondialement connu et utilisé, mais il demande une gymnastique intellectuelle assez avancée pour le maîtriser. Quant à dnsmasq, plus rapide de configuration, il permet également de configurer un service DHCP. Il a également l'avantage de s'appuyer sur le fichier  pour déclarer des adresses locales. Configuration testée sous Debian et Raspbian.\nConfigurer l'adresse IP du serveur\nIl faut fixer l'adresse IP de l'ordinateur. Il est impératif de ne pas être en DHCP pour cet ordinateur. Le fichier  doit être modifié afin de faire apparaître les options suivantes. Les lignes suivantes ont été décommentées (suppression du symbole #) et les paramètres modifiés.\nDéfinir le nom du serveur\nL'ordinateur s'appellera rpinas. A adapter avec votre configuration   sudo hostnamectl set-hostname rpinas\nInstallation\nConfigurer dnsmasq\nDécommenter la ligne suivante dans le fichier  avec les droits  : Ajouter ça propre configuration dans un nouveau fichier de configuration avec les droits . Par exemple  : Modifier le fichier  Il faut redémarrer l'appareil :\n  sudo reboot Gérer le service dnsmasq\nDémarrer le service :   $ sudo systemctl restart dnsmasq\n  \nConfigurer le service en démarrage automatique   $ sudo systemctl enable dnsmasq Vérifier le fonctionnement du service \n  sudo systemctl enable dnsmasq\nAlias DNS\nLe fichier  est lu par DNSmasq afin d'établir un référentiel . Il convient de déclarer son ordinateur tel quel et d'autres références :\nDNS menteur\nVous pouvez répondre une bêtise à la place de la réponse DNS mondial. Créer un fichier  pour de fausses résolutions : Il faudra redémarrer dnsmasq :\n  sudo systemctl restart dnsmasq Bilbiographie\nQuad9, un résolveur DNS public, et avec sécurité\nChoisir son résolveur DNS, pas si facile\nhttps:www.bortzmeyer.org/google-dns.html\n<https:www.bortzmeyer.org/son-propre-resolveur-dns.html|>\nChanger de serveur résolveur DNS facilement\ndnssec-trigger, un outil pour mettre DNSSEC à la disposition de M. Toutlemonde\nRPZ, un moyen simple de configurer un résolveur DNS BIND pour qu'il mente\nUtiliser un résolveur DNS public ?"},{"uuid":"0bba1ad7-e4cb-49a6-9467-fcfac2e09a93","slug":"deuxiemes-pas-devops-durcir-et-fiabiliser-un-serveur-debian","title":"Deuxièmes pas DevOps : durcir et fiabiliser un serveur Debian","category":"informatique","author":"cedric@abonnel.fr","cover":"cover.jpg","published":true,"published_at":"2026-06-08 07:00","created_at":"2026-05-12 23:01:34","updated_at":"2026-05-13 22:53:46","tags":{"logiciels":["Fail2ban","Debian"]},"plain":"Une fois le système de base configuré (dépôts, mises à jour, , identification — sujets traités dans l'article précédent), la machine est fonctionnelle mais encore vulnérable et un peu fragile pour un usage sérieux. Ce deuxième article s'attaque aux gestes qui transforment un serveur « qui marche » en un serveur sur lequel on peut raisonnablement faire tourner quelque chose : sécuriser l'accès SSH, mettre en place un pare-feu, automatiser les correctifs de sécurité et soigner quelques détails opérationnels.\r\n\r\nSécuriser l'accès SSH\r\n\r\nSSH est la porte d'entrée principale d'un serveur Linux. C'est aussi, statistiquement, la cible la plus attaquée : n'importe quelle IP publique reçoit en permanence des tentatives de connexion automatisées. Deux gestes simples changent radicalement la donne.\r\n\r\nPasser à l'authentification par clé\r\n\r\nLes mots de passe, même longs, restent vulnérables aux attaques par force brute et au phishing. Une paire de clés cryptographiques est à la fois plus sûre et plus pratique au quotidien.\r\n\r\nCôté poste de travail, on génère une paire de clés modernes :\r\n\r\n\r\n\r\nL'algorithme  est aujourd'hui le choix par défaut recommandé : clés courtes, signatures rapides, sécurité solide. Le commentaire () facilite l'identification de la clé quand on en gère plusieurs.\r\n\r\nOn copie ensuite la clé publique sur le serveur :\r\n\r\n\r\n\r\nCette commande dépose la clé publique dans  côté serveur avec les bonnes permissions. À partir de là, la connexion se fait sans saisir de mot de passe — il faut tester depuis une nouvelle session avant de passer à l'étape suivante, sous peine de risquer de se retrouver enfermé dehors.\r\n\r\nDésactiver la connexion root et les mots de passe\r\n\r\nUne fois la connexion par clé validée, on durcit la configuration SSH. Le fichier à modifier est  :\r\n\r\n\r\n\r\nLes directives importantes à positionner (ou décommenter) sont :\r\n\r\n\r\n\r\nLa première interdit toute connexion directe en  via SSH : on devra obligatoirement se connecter avec un utilisateur normal puis élever ses droits via . La deuxième supprime complètement l'authentification par mot de passe, ne laissant plus que les clés. La troisième confirme explicitement que l'authentification par clé est active.\r\n\r\nOn recharge ensuite le service pour appliquer les changements :\r\n\r\n\r\n\r\nImportant : garder la session SSH actuelle ouverte et tester la nouvelle configuration depuis un autre terminal avant de fermer la première. En cas de problème, on peut encore corriger le tir.\r\n\r\nPour aller un cran plus loin, changer le port SSH par défaut (22) vers un port moins évident réduit considérablement le bruit dans les logs. Ce n'est pas de la sécurité au sens strict (un scan le retrouvera), mais c'est un filtre efficace contre les attaques automatisées.\r\n\r\nMettre en place un pare-feu\r\n\r\nPar défaut, Debian n'a aucun pare-feu actif. Tout port ouvert par un service installé sera donc directement exposé. Deux outils standards existent :  (le successeur officiel d', bas niveau et puissant) et  (une surcouche pensée pour la simplicité). Pour démarrer,  est le bon compromis.\r\n\r\n\r\n\r\nLa logique consiste à tout bloquer en entrée par défaut, puis à n'ouvrir explicitement que ce qui doit l'être :\r\n\r\n\r\n\r\nSi SSH écoute sur un port non standard, remplacer  par  (ou le port choisi). Oublier cette étape avant un  est un grand classique du verrouillage involontaire.\r\n\r\nPour les services web, on ouvrira typiquement les ports 80 et 443 :\r\n\r\n\r\n\r\nL'état du pare-feu se vérifie avec :\r\n\r\n\r\n\r\nSur une architecture où la machine est derrière un reverse proxy (cas fréquent quand on expose plusieurs services sur un même domaine), seuls les ports utiles côté proxy doivent être ouverts au monde extérieur. Les services applicatifs eux-mêmes restent accessibles uniquement depuis le réseau interne.\r\n\r\nAutomatiser les correctifs de sécurité\r\n\r\nLes failles de sécurité ne préviennent pas, et personne n'a envie de lancer manuellement  chaque matin sur dix machines. Le paquet  applique automatiquement les mises à jour du dépôt .\r\n\r\n\r\n\r\nLa configuration se trouve ensuite dans . Par défaut, seuls les correctifs de sécurité sont appliqués automatiquement, ce qui est généralement le bon compromis : on profite des patches critiques sans risquer qu'une mise à jour fonctionnelle introduise une régression sur un service en production.\r\n\r\nQuelques options qui méritent l'attention dans ce fichier :\r\n: à régler sur  si l'on accepte les redémarrages automatiques après une mise à jour de noyau, ou  si l'on préfère les piloter à la main. La directive  permet alors de choisir l'horaire.\r\n: pour recevoir un rapport par mail des mises à jour appliquées, à condition d'avoir un MTA configuré sur la machine.\r\n\r\nLe bon réflexe consiste à vérifier de temps en temps les logs dans  pour s'assurer que tout se déroule sans heurts.\r\n\r\nSoigner les détails opérationnels\r\n\r\nQuelques outils complémentaires améliorent significativement le confort et la résilience d'un serveur.\r\n\r\nFail2ban surveille les logs d'authentification et bannit temporairement les IP qui tentent trop de connexions échouées. Même avec SSH par clé uniquement, le service réduit considérablement le bruit dans les journaux :\r\n\r\n\r\n\r\nLa configuration par défaut surveille déjà SSH ; elle peut être étendue à d'autres services (nginx, Postfix, etc.) via des fichiers dans .\r\n\r\nLogwatch ou journalctl méritent qu'on s'y attarde. Sur une Debian récente,  est l'outil central pour consulter les logs systemd :\r\n\r\n\r\n\r\nPrendre l'habitude de jeter un œil aux logs régulièrement — ou de mettre en place une remontée centralisée si l'on gère plusieurs machines — change beaucoup de choses en exploitation.\r\n\r\nUn swap raisonnable, sur une VM ou un serveur dédié, évite que la machine ne devienne complètement injoignable en cas de pic de consommation mémoire. Sur un conteneur LXC en revanche, c'est généralement géré au niveau de l'hyperviseur.\r\n\r\nEt après ?\r\n\r\nAvec ces réglages, le serveur est dans un état correct pour accueillir des services réels : la surface d'attaque est réduite, les correctifs s'appliquent tout seuls, et les logs racontent ce qui se passe. La suite logique est l'installation de la pile applicative proprement dite (serveur web, base de données, runtime) et la mise en place d'un reverse proxy pour exposer plusieurs services derrière un même point d'entrée.\r\n\r\nComme évoqué dans le premier article, le moment où l'on commence à enchaîner ces étapes sur plusieurs machines est exactement celui où il faut basculer vers de l'automatisation : un script shell bien rangé pour commencer, puis Ansible ou un équivalent quand le parc grossit. Une bonne pratique consiste à versionner ces scripts dans un dépôt Git dédié à l'infrastructure, au même titre que le code applicatif."},{"uuid":"e1e8a0c1-6971-4357-9aaa-7e7a748922f3","slug":"quand-systemd-remplace-cron-pourquoi-et-comment-migrer-ses-taches-planifiees","title":"Quand systemd remplace cron : pourquoi (et comment) migrer ses tâches planifiées","category":"informatique","author":"cedric@abonnel.fr","cover":"","published":true,"published_at":"2026-06-01 07:56","created_at":"2026-05-12 13:57:29","updated_at":"2026-05-12 13:58:58","tags":[],"plain":"Cron tourne sur Linux depuis 1975. Il a fait son temps pour beaucoup d'usages : voici ce que les timers systemd apportent, et comment basculer sans tout casser.\r\n\r\nPourquoi cron reste partout\r\n\r\n est l'un des plus anciens outils Unix encore en service. Son principe tient en deux idées : un démon qui se réveille toutes les minutes, et un fichier texte — la crontab — où chaque ligne décrit une commande et son moment d'exécution avec cinq champs (minute, heure, jour du mois, mois, jour de la semaine).\r\n\r\n\r\n\r\nCinquante ans plus tard, ça marche. C'est installé partout, c'est documenté à mort, ça tient sur une ligne, et n'importe quel administrateur sait lire . Pour beaucoup de besoins simples — « lancer ce script tous les jours à 2h du matin » — cron reste le bon choix.\r\n\r\nLe problème est que les besoins ont rarement été aussi simples depuis longtemps.\r\n\r\nLes limites de cron qu'on finit toujours par rencontrer\r\n\r\nÀ chaque administration de serveur sérieuse, on retombe sur les mêmes frustrations.\r\n\r\nLa machine était éteinte au moment du job. Cron saute purement et simplement l'occurrence ratée. Si le portable de l'utilisateur dormait à 2h, la sauvegarde quotidienne n'aura pas lieu — point. Le job s'exécutera de nouveau le lendemain à 2h, sans rattrapage, sans alerte.\r\n\r\nLes logs sont dispersés ou perdus. Par défaut, la sortie standard du job est envoyée par mail à l'utilisateur (si  est défini et qu'un MTA tourne) ou simplement perdue. Le démon lui-même logue dans syslog quand il démarre un job, mais pas son contenu. Diagnostiquer pourquoi un job a échoué la semaine dernière relève souvent de l'archéologie.\r\n\r\nPas de dépendances. Un job qui doit attendre que le réseau soit monté, qu'un point de montage soit présent, qu'un autre service ait fini son démarrage : cron ne sait pas exprimer ça. La parade habituelle — un  ou un  suivi d'une boucle d'attente — fonctionne mais reste un bricolage.\r\n\r\nPas de recouvrement entre exécutions. Si un job de 5 minutes en prend 7 ce jour-là, cron lance la prochaine occurrence pile au moment où la précédente tourne encore. Deux instances simultanées d'un script de synchronisation, c'est rarement ce qu'on veut.\r\n\r\nPas de jitter, pas de randomisation. Quand cinquante VMs lancent leur  toutes en même temps à 6h25 (l'heure d'anacron par défaut sur Debian), le pic de charge sur l'hyperviseur est garanti. Cron n'offre aucune primitive pour étaler les exécutions.\r\n\r\nPas de visibilité globale. Pour répondre à « quels jobs vont tourner aujourd'hui sur cette machine ? », il faut lire la crontab système, les crontabs utilisateur (), le contenu de , , , etc. Aucune commande ne donne la vue consolidée.\r\n\r\nPas d'isolation, pas de quota. Le job s'exécute avec les privilèges et les ressources du shell qui l'a lancé. Aucune façon native de limiter à 50 % de CPU, à 1 Go de RAM, ou de couper si ça dépasse 10 minutes.\r\n\r\nAucun de ces points ne rend cron inutilisable. Mais accumulés sur une dizaine de jobs critiques, ils transforment l'administration en travail de surveillance permanente.\r\n\r\nCe qu'apporte un timer systemd\r\n\r\nSur toute distribution Linux moderne basée sur systemd (la quasi-totalité, hors BSD, Alpine, Gentoo et quelques cas particuliers), une alternative native existe : les timers. Le principe est différent dès le départ.\r\n\r\nUn timer systemd, c'est deux fichiers au lieu d'une ligne :\r\nUn fichier  qui décrit ce qu'il faut faire — exactement comme on décrit un service classique, en mode  pour un job ponctuel\r\nUn fichier  qui décrit quand le faire — ce sont les règles de déclenchement\r\n\r\nCette séparation entre le « quoi » et le « quand » est plus verbeuse au départ, mais elle débloque tout le reste.\r\n\r\nUne syntaxe d'horaire lisible\r\n\r\nLà où cron oblige à mentaliser , systemd écrit :\r\n\r\n\r\n\r\nEt la commande  valide l'expression en montrant la prochaine exécution prévue. Une erreur de jour-de-semaine ou un décalage horaire ne plante pas en silence : on le voit avant de déployer.\r\n\r\nD'autres formes utiles que cron ne sait pas exprimer :\r\n\r\n\r\n\r\nLe support natif des fuseaux horaires est une avancée significative pour qui gère des serveurs distribués géographiquement — cron ignore tout du concept et tourne sur le fuseau du système.\r\n\r\nDu temps relatif, pas seulement du temps absolu\r\n\r\nCron raisonne uniquement en horloge murale (« tel jour, à telle heure »). systemd ajoute le temps monotone, relatif à un événement :\r\n\r\n\r\n\r\n règle proprement le problème des exécutions qui se chevauchent : la prochaine instance se déclenche 6 heures après la fin de la précédente, pas 6 heures après son démarrage. Aucune équivalence simple en cron.\r\n\r\nLe rattrapage des exécutions ratées\r\n\r\nUne seule ligne change tout :\r\n\r\n\r\n\r\nAvec cette option, systemd mémorise la dernière exécution réussie. Si la machine était éteinte au moment prévu, le job se déclenche dès le démarrage suivant (après le  éventuel, voir plus bas). Pour un portable, un poste de développement, ou n'importe quelle machine qui n'est pas en service 24/7, c'est une différence majeure de fiabilité.\r\n\r\nDu jitter intégré\r\n\r\n\r\n\r\nLe déclenchement se fait à un instant aléatoire dans la fenêtre . Quand cinquante machines lancent leur mise à jour quotidienne, le pic de charge se lisse au lieu de tomber au même instant. C'est la fonctionnalité que tous les administrateurs de flottes finissent par re-bricoler en cron avec un  peu élégant.\r\n\r\nLe logging gratuit dans journald\r\n\r\nTout ce que le service écrit sur stdout et stderr est capturé automatiquement par journald. Une seule commande pour tout consulter :\r\n\r\n\r\n\r\nPas de configuration, pas de redirection à la main, pas de  à coller à chaque ligne de crontab. Et accessoirement, journald gère la rotation, la compression et la rétention.\r\n\r\nLes dépendances déclaratives\r\n\r\nDans le fichier , on peut dire au planificateur qu'un job nécessite que le réseau soit prêt, qu'un point de montage soit présent, qu'un autre service ait démarré :\r\n\r\n\r\n\r\nsystemd attend que ces conditions soient remplies avant de déclencher le service. Le job ne tente plus de s'exécuter sur un montage absent ou avant que la résolution DNS soit fonctionnelle.\r\n\r\nLe contrôle des ressources via cgroups\r\n\r\nPuisque chaque exécution passe par un service, on bénéficie de tout l'arsenal cgroups de systemd :\r\n\r\n\r\n\r\nUn job de sauvegarde qui pourrait saturer le disque ne sortira pas de son enveloppe. Cron n'offre rien d'équivalent — au mieux on enrobe la commande dans  et , ce qui reste primitif.\r\n\r\nLa vue consolidée\r\n\r\n\r\n\r\nUne seule commande, toutes les exécutions planifiées du système, classées par prochaine échéance, avec date de dernière exécution. La question « qu'est-ce qui tourne automatiquement sur cette machine ? » trouve enfin une réponse en une ligne.\r\n\r\nUn exemple complet, pas-à-pas\r\n\r\nReprenons le job de sauvegarde initial —  — et traduisons-le.\r\n\r\n :\r\n\r\n\r\n\r\n :\r\n\r\n\r\n\r\nActivation :\r\n\r\n\r\n\r\nVérifications :\r\n\r\n\r\n\r\nComparé à la ligne de crontab originale, c'est plus verbeux. Mais on a, sans rien ajouter : le rattrapage en cas d'arrêt machine, du jitter pour éviter les pics, l'attente du réseau, des limites de ressources, du logging structuré, et une commande pour tout inspecter.\r\n\r\nQuelques recettes utiles\r\n\r\nTous les jours à 3h sauf le dimanche :\r\n\r\n\r\n\r\nToutes les 15 minutes pendant les heures de bureau :\r\n\r\n\r\n\r\nLe premier lundi de chaque mois à 5h : pas faisable en une seule expression, mais combinable avec une condition  qui vérifie la date et sort si ce n'est pas le bon jour. C'est l'une des rares zones où cron reste plus naturel ( +  dans le script).\r\n\r\nToutes les six heures à partir du dernier passage (jamais de chevauchement) :\r\n\r\n\r\n\r\nTimer utilisateur, sans  : dans , puis :\r\n\r\n\r\n\r\nQuand garder cron\r\n\r\nTout n'est pas à migrer. Cron reste le bon choix dans plusieurs cas :\r\nScripts portables vers BSD, macOS, ou des conteneurs minimaux. systemd n'existe pas dans Alpine Linux, sur les BSD, ni dans la plupart des images Docker légères.\r\nTâches utilisateur très simples sur un serveur partagé, où chaque utilisateur gère sa propre crontab sans privilèges admin.\r\nNotification par mail intégrée : si  suivi d'une sortie sur stderr couvre déjà le besoin de monitoring, repasser par journald + un exporter Prometheus est de la sur-ingénierie.\r\nUn job de trente secondes à ajouter sur un serveur existant déjà couvert par cron. Mélanger les deux outils est sans risque — ils coexistent sans interférence — et créer deux fichiers pour un alias unique d'une ligne reste excessif.\r\n\r\nLa meilleure stratégie est rarement migratoire au pas de charge. Elle consiste à utiliser systemd pour toute nouvelle tâche planifiée, et à ne migrer les jobs cron existants que quand ils posent un problème concret : un job raté qu'il fallait rattraper, un log perdu qu'il fallait retrouver, un chevauchement qui a corrompu des données.\r\n\r\nEn résumé\r\n\r\nCron n'est pas obsolète, il est sous-dimensionné pour des besoins modernes. Les timers systemd ne remplacent pas la simplicité d'une ligne de crontab pour un job trivial, mais ils apportent à peu près tout ce qui manque dès qu'une tâche planifiée devient critique : rattrapage, logging, dépendances, isolation, observabilité.\r\n\r\nPour un DevOps qui construit aujourd'hui un nouveau service, le choix par défaut a basculé : commencer en systemd, et n'utiliser cron que par exception justifiée. La verbosité initiale des deux fichiers se rentabilise au premier incident de production qu'on diagnostique en  au lieu de fouiller dans des logs disparates.\r\n\r\nEt même sans migrer quoi que ce soit, la commande  mérite d'entrer dans le réflexe de tout audit de machine Linux. C'est là que se cache la moitié des tâches planifiées qu'on croit avoir comprises."}]