Cédrix
1 line
26 KiB
JSON
1 line
26 KiB
JSON
[{"uuid":"acb314e7-f467-42ed-99e2-6ab5a7dfa87c","slug":"66-20220829-radio-et-tele-regionnale-connectee","title":"Radio et télé régionnale connectée, c'est ici","category":"Podcasts","author":"cedric@abonnel.fr","cover":"","published":true,"published_at":"2022-08-29 21:49:12","created_at":"2022-08-29 21:49:12","updated_at":"2022-08-29 21:49:12","tags":[],"plain":"Voici le 66ème épisode : Radio et télé régionnale connectée, c'est ici\nCette page est amenée à évoluer. Réagissez à cet épisode dans la partie [Épisode disponible sur https://info.mindcast.fr/]\n--"},{"uuid":"4f193d70-d236-42d7-aedb-58631cd15002","slug":"la-6g-au-dela-de-la-5g-promesses-et-interrogations","title":"La 6G : au-delà de la 5G, promesses et interrogations","category":"télécom","author":"cedric@abonnel.fr","cover":"","published":true,"published_at":"2025-11-05 08:46:51","created_at":"2025-11-05 08:46:51","updated_at":"2025-11-05 08:46:51","tags":[],"plain":"Alors que la 5G peine encore à s’imposer partout, la recherche sur la 6G est déjà bien avancée. Les laboratoires, opérateurs et gouvernements annoncent des innovations spectaculaires : débits colossaux, latence quasi nulle et intégration massive de l’intelligence artificielle dans le réseau. Mais derrière le buzz médiatique se cachent de grandes incertitudes techniques et économiques.\r\n--\r\n\r\nPromesses technologiques\r\n\r\n Débits théoriques : jusqu’à 1 Tbit/s dans des conditions expérimentales (vs 10 Gbit/s max pour la 5G).\r\n Latence ultra-faible : <1 ms, visant les applications critiques comme chirurgie à distance, véhicules autonomes coordonnés en temps réel et réalité immersive totale.\r\n Fréquences : exploitation des ondes térahertz (THz), beaucoup plus hautes que les mmWave 5G, offrant un spectre presque illimité mais avec des contraintes sévères de portée et pénétration.\r\n Intelligence embarquée : réseaux capables d’auto-optimisation grâce à l’IA et au machine learning pour gérer la congestion, l’énergie et les allocations de spectre en temps réel.\r\n Intégration multi-domaines : fusion des communications terrestres, satellites, drones et IoT pour créer un réseau ubiquitaire.\r\n--\r\n\r\nDéfis techniques\r\n\r\n1. Propagation et portée : les ondes THz sont extrêmement sensibles aux obstacles et à l’humidité, nécessitant une densité d’antennes inimaginable à l’échelle mondiale.\r\n2. Consommation énergétique : déployer des antennes THz ultra-puissantes et gérer des réseaux IA en temps réel risque d’augmenter considérablement la consommation électrique.\r\n3. Standardisation complexe : contrairement à la 5G qui a hérité d’une partie de l’infrastructure 4G, la 6G nécessitera des investissements massifs et de nouveaux protocoles.\r\n4. Coût et adoption : le coût pour les opérateurs et la nécessité de renouveler les équipements pour les utilisateurs seront un frein majeur, comme ce fut le cas pour la 3G et la 5G.\r\n--\r\n\r\nUsages envisagés\r\n\r\n Réalité mixte et immersive : AR/VR ultra-réaliste, métavers en temps réel, téléprésence totale.\r\n Téléchirurgie et véhicules autonomes coordonnés : applications critiques nécessitant une latence quasi nulle.\r\n IoT massif : milliards d’objets connectés, capteurs intelligents, villes et infrastructures “autonomes”.\r\n Communication spatiale et aérienne : drones, satellites et aéronefs connectés en temps réel.\r\n--\r\n\r\nCritique et perspective\r\n\r\nMême si les promesses de la 6G sont spectaculaires, plusieurs points restent préoccupants :\r\n\r\n La 6G est encore largement théorique : aucune application grand public n’est prévue avant 2030.\r\n Comme pour la 5G, les opérateurs pourraient utiliser la 6G pour inciter la migration depuis la 5G, en bridant certaines fonctionnalités sur la génération précédente.\r\n Le discours marketing risque de créer une confusion encore plus grande pour les utilisateurs : débits maximaux, latence minimale et réseaux intelligents seront très localisés et expérimentaux, bien loin d’une couverture nationale.\r\n--\r\n\r\nSchéma suggéré : évolution 3G → 4G → 5G → 6G\r\n--\r\n\r\nLa 6G s’annonce comme l’avenir des réseaux mobiles, mais elle illustre encore la stratégie récurrente des opérateurs :\r\n\r\n1. Créer une promesse technologique spectaculaire.\r\n2. Déployer progressivement pour ne pas perturber l’infrastructure existante.\r\n3. Inciter subtilement les utilisateurs à migrer vers la nouvelle génération, souvent via des limitations sur les générations précédentes.\r\nComme pour la 3G bridée puis la 4G et la 5G, la 6G risque d’être autant un outil de marketing et de stratégie économique qu’une véritable révolution immédiate pour le consommateur."},{"uuid":"663b0638-10fd-4549-8ff5-aebb3285388f","slug":"la-5g-promesse-derives-et-realite","title":"La 5G : promesse, dérivés et réalité","category":"télécom","author":"cedric@abonnel.fr","cover":"","published":true,"published_at":"2025-11-05 08:45:44","created_at":"2025-11-05 08:45:44","updated_at":"2025-11-05 08:45:44","tags":[],"plain":"Technologie et promesse\r\n\r\nLa 5G est présentée comme la révolution ultime des réseaux mobiles. Débits massifs, latence ultra-faible, support d’un nombre astronomique d’objets connectés… mais derrière le discours marketing se cache une réalité plus nuancée :\r\n\r\n Débits théoriques : 100 Mbit/s en usage réel, jusqu’à 10 Gbit/s sur bandes millimétriques (mmWave) et zones ultra-denses.\r\n Latence : 1–10 ms, permettant cloud gaming, véhicules autonomes et IoT industriel.\r\n Architecture :\r\n\r\n NSA (Non Standalone) : la 5G repose sur la 4G pour le contrôle, 5G uniquement pour les débits.\r\n SA (Standalone) : réseau 5G indépendant avec cœur 5GC, latence minimale et optimisation maximale.\r\n Fréquences : de 700 MHz (longue portée) à 26 GHz (mmWave, très haut débit mais faible portée).\r\n--\r\n\r\n5G+ : le “plus” marketing\r\n\r\n La 5G+ n’est pas une nouvelle génération mais une dénomination commerciale pour la 5G sur fréquences millimétriques ou avec agrégation de bandes.\r\n Objectif : mettre en avant des débits spectaculaires (souvent >1 Gbit/s) sur des zones très localisées.\r\n Limitation : portée extrêmement courte et sensibilité aux obstacles. Les débits annoncés ne sont atteints que pour une minorité d’abonnés.\r\n--\r\n\r\nVoLTE : la voix sur LTE\r\n\r\n VoLTE (Voice over LTE) permet de passer les appels vocaux via le réseau 4G au lieu de basculer sur la 2G/3G.\r\n Avantages : meilleure qualité sonore, connexion plus rapide, possibilité de passer simultanément un appel et utiliser Internet.\r\n Limitation : nécessite un smartphone compatible et un réseau correctement configuré. Dans certaines zones, les abonnés passent encore par la 3G pour la voix, même avec un smartphone récent.\r\n--\r\n\r\nDSS : Dynamic Spectrum Sharing\r\n\r\n DSS permet de partager dynamiquement le spectre entre 4G et 5G sur les mêmes fréquences.\r\n Avantages pour l’opérateur : déploiement rapide de la 5G sans attendre la libération complète du spectre.\r\n Limitation : la 4G existante peut être légèrement dégradée, ce qui reproduit l’effet déjà observé avec la 3G bridée pour forcer la migration.\r\n--\r\n\r\nSchéma suggéré : architecture 4G vs 5G\r\n\r\n\r\n\r\n La 5G remplace eNodeB/EPC par gNodeB/5GC, réduisant la latence et augmentant l’efficacité, mais l’accès réel à ces débits reste limité selon la fréquence et la zone.\r\n--\r\n\r\nLa 5G, avec ses variantes 5G+, VoLTE, DSS, illustre la complexité croissante du paysage mobile :\r\n\r\n1. Multiplicité des normes et labels : 4G, 4G+, VoLTE, 5G, 5G+, DSS… pour l’utilisateur, il devient presque impossible de savoir ce qu’il utilise réellement.\r\n2. Marketing vs réalité : les débits annoncés sont rarement atteints, et certaines zones restent sur une 4G bridée pour préparer la migration.\r\n3. Stratégie opérateur : comme pour la 3G et la 4G, la pression sur l’utilisateur est subtile : dégrader légèrement les anciens réseaux, mettre en avant les nouvelles performances, et pousser à migrer progressivement.\r\nLa “révolution 5G” existe techniquement, mais pour le consommateur moyen, elle se traduit souvent par une interface confuse et des débits très variables. Les promesses marketing et la réalité économique du déploiement ne coïncident pas toujours."},{"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."}] |