varlog/_cache/similar/04a3214a-c277-44e5-b4a9-537ae7ec35cd.json

[{"uuid":"4f443bcb-b0d4-47f8-837d-61627e6c94f2","slug":"priorites-et-acces-au-reseau-en-4g-et-5g","title":"Pourquoi le réseau mobile ne s'effondre pas le jour où tout le monde téléphone en même temps","category":"télécom","author":"cedric@abonnel.fr","cover":"cover.jpg","published":true,"published_at":"2026-01-06 22:21","created_at":"2026-01-06 22:21:04","updated_at":"2026-05-11 23:40:18","tags":[],"plain":"Un attentat, un séisme, un match du Stade de France, une grande panne d'électricité. Dans ces moments-là, des centaines de milliers de gens dégainent leur téléphone au même instant. Le réseau mobile est dimensionné pour un usage moyen, pas pour un pic massif simultané, et il devrait théoriquement s'effondrer. La plupart du temps, il tient. Pas parfaitement, pas pour tout le monde, mais il tient — et surtout, les appels d'urgence continuent de passer. C'est le résultat d'une série de mécanismes empilés depuis les années 1990, que la 4G a affinés et que la 5G a élargis. Cet article les passe en revue, et termine sur une question qu'on me pose souvent : est-ce que mon forfait à 50 € me donne une place prioritaire dans cette file d'attente ?\r\n\r\nTrois questions, pas une\r\n\r\nQuand une cellule commence à chauffer, l'opérateur doit répondre à trois questions distinctes. Qui a le droit de se connecter ? Une fois connecté, qui passe en premier ? Et quels services doivent absolument continuer à fonctionner, quoi qu'il arrive ?\r\n\r\nLa 2G ne savait répondre qu'à la première. Elle filtrait à l'entrée et basta. La 4G a ajouté la deuxième : une fois admis sur le réseau, votre trafic est traité différemment selon son importance. La 5G ajoute la troisième : elle peut créer des réseaux virtuels parallèles dont certains sont réservés à des usages critiques, totalement isolés des autres.\r\n\r\nLe filtrage à l'entrée\r\n\r\nChaque carte SIM porte un numéro de classe d'accès, hérité du GSM, entre 0 et 15. Les classes 0 à 9 couvrent le grand public — autrement dit nous tous. Les classes 11 à 15 sont réservées : services de secours, autorités publiques, personnel opérateur, usages militaires selon les pays.\r\n\r\nQuand une cellule est surchargée, l'eNodeB (la station de base 4G) diffuse une consigne aux téléphones du secteur : « les classes 0 à 9, vous attendez ». C'est l'Access Class Barring. Concrètement, votre téléphone reçoit ce message et bloque lui-même votre tentative d'appel ou de connexion data, sans même envoyer la demande à la station. C'est élégant parce que ça soulage la station avant même qu'elle ne soit sollicitée. Les classes prioritaires, elles, passent sans encombre.\r\n\r\nUne variante plus dure, l'Extended Access Barring, vise les objets connectés et les usages non urgents. Quand une vraie crise se déclare, l'opérateur peut couper les compteurs intelligents, les alarmes domestiques et autres équipements bavards pour préserver la bande passante humaine.\r\n\r\nEn 5G, ce mécanisme a été refondu sous le nom d'UAC — Unified Access Control, introduit dans la Release 15 du 3GPP. UAC unifie dans un seul cadre ce qui était auparavant éparpillé entre ACB, EAB et d'autres dispositifs spécifiques. Il repose sur deux notions complémentaires. Les Access Identities identifient qui vous êtes : utilisateur lambda, abonné à un service prioritaire type MPS ou MCS, personnel d'urgence, agent opérateur. Les Access Categories identifient ce que vous essayez de faire : appel d'urgence, connexion data normale, SMS, mise à jour de localisation. La combinaison des deux détermine si votre demande passe ou pas. La granularité gagnée par rapport à la 4G est réelle : on peut bloquer un type d'action précis pour un type d'utilisateur précis, par exemple « les abonnés grand public ne peuvent plus initier de nouveaux appels data, mais les SMS et les appels voix continuent ».\r\n\r\nLa priorité une fois connecté\r\n\r\nLà où la 4G a vraiment innové, c'est en introduisant le QCI — QoS Class Identifier. Chaque flux de données qui transite sur le réseau se voit attribuer un numéro entre 1 et 9 (avec quelques valeurs supplémentaires pour des cas spéciaux) qui dit à l'infrastructure comment le traiter.\r\nUsage | QCI | Traitement |\r\n---|---|---|\r\nAppel VoLTE (voix sur LTE) | 1 | Latence minimale, débit garanti |\r\nVisioconférence | 2 | Débit garanti |\r\nSignalisation réseau | 5 | Très haute priorité |\r\nStreaming vidéo | 6 ou 8 | Best effort prioritaire |\r\nWeb et internet général | 9 | Best effort standard |\r\n\r\nQuand la cellule est encombrée, le routeur sait quoi sacrifier en premier. YouTube va ralentir, les pages web vont mettre du temps à charger, mais l'appel téléphonique de votre voisin reste audible. C'est un compromis assumé : on dégrade volontairement les usages secondaires pour préserver les usages critiques.\r\n\r\nLa 5G a transposé ce mécanisme sous le nom de 5QI (5G QoS Identifier) avec davantage de niveaux et une meilleure prise en compte des cas que la 4G gérait mal — notamment les services à très basse latence pour les usines connectées ou la voiture autonome. La voix d'urgence garde son sommet, les données critiques industrielles s'intercalent juste après, le streaming et le web restent en bas de la pile.\r\n\r\nL'isolation par tranches : le network slicing\r\n\r\nC'est l'apport majeur de la 5G en matière de gestion de crise. Au lieu de partager une seule infrastructure entre tous les usages, on peut maintenant la découper logiciellement en tranches — des slices — qui se comportent comme autant de réseaux indépendants, alors qu'ils tournent sur les mêmes antennes et les mêmes câbles.\r\n\r\nUn opérateur peut par exemple maintenir une tranche pour le grand public avec ses millions d'abonnés et son trafic massif, une autre pour les services d'urgence dimensionnée pour rester fluide même quand le reste sature, une troisième pour les objets connectés industriels avec des garanties de latence, et une quatrième pour des opérateurs critiques type SNCF, EDF ou hôpitaux. Chaque tranche a ses propres règles d'admission, ses propres priorités, ses propres garanties de performance. Si la tranche grand public est totalement saturée, celle des secours ne le sait même pas.\r\n\r\nCette isolation est ce qui distingue le plus fondamentalement la 5G des générations précédentes. Avant, tout le monde se battait pour les mêmes ressources, avec juste des priorités différentes pour départager. Maintenant, certaines ressources sont retirées du combat dès le départ.\r\n\r\nRécapitulatif\r\nGénération | Ce qui est contrôlé | Comment |\r\n---|---|---|\r\n2G | L'accès au réseau | Classes d'accès 0-15 |\r\n4G | L'accès + la priorité du trafic | ACB / EAB + QCI |\r\n5G | L'accès + la priorité + l'isolation des services | UAC + 5QI + network slicing |\r\n\r\nTous ces mécanismes restent invisibles tant que tout va bien. Vous ne savez pas qu'ils existent. Vous découvrez leur existence le jour où votre voisin n'arrive plus à charger ses mails alors que les pompiers, eux, continuent de communiquer normalement. Ce jour-là, ce n'est pas de la magie. C'est trente ans d'ingénierie radio qui ont anticipé que ça arriverait.\r\n--\r\n\r\nEt mon forfait premium, alors ?\r\n\r\nQuestion logique à ce stade. Si le réseau sait techniquement prioriser certains flux par rapport à d'autres, qu'est-ce qui empêche un opérateur de faire passer ses abonnés à 50 € devant ceux à 10 € quand les antennes saturent ? La réponse honnête commence par un aveu : techniquement, rien. L'outil existe, il s'appelle Quality of Service (QoS), c'est exactement le mécanisme qu'on vient de décrire. Si demain Orange ou SFR voulaient créer une voie rapide pour leurs abonnés haut de gamme, ils auraient les outils dans la boîte. Pourtant, ils ne le font pas. Pour quatre raisons.\r\n\r\nLa loi européenne l'interdit\r\n\r\nLe règlement (UE) 2015/2120, dit « règlement internet ouvert », oblige les opérateurs à traiter tout le trafic de la même façon, sans discrimination liée à l'expéditeur, au destinataire, au contenu ou à l'application. Il a fêté ses dix ans en novembre 2025, et l'ARCEP a profité de l'anniversaire pour rappeler que c'est l'un des piliers du modèle numérique européen. Les sanctions sont sérieuses : jusqu'à 3 % du chiffre d'affaires de l'opérateur fautif. Un opérateur français qui annoncerait demain « avec notre forfait Premium, vous passez devant les autres » se retrouverait devant l'ARCEP dans la semaine.\r\n\r\nLe règlement laisse quelques portes ouvertes pour les services dits « spécialisés » qui ont besoin d'une qualité garantie — téléchirurgie, voiture connectée. Mais ces exceptions sont étroitement encadrées et ne couvrent absolument pas le confort d'un client haut de gamme qui voudrait charger son Instagram plus vite à 19h.\r\n\r\nAux États-Unis, l'histoire est différente. La FCC a tenté de restaurer la neutralité du net en 2024, mais en janvier 2025 la cour d'appel du sixième circuit a invalidé la décision, jugeant que la FCC n'avait pas l'autorité légale pour reclasser le haut débit comme service public. Avec l'arrivée de Brendan Carr à la tête de la FCC, ouvertement opposé à la neutralité du net, il n'y a aujourd'hui plus de règle fédérale outre-Atlantique. Quelques États (Californie, Washington, New York, Oregon) ont leurs propres lois qui maintiennent le principe, mais à l'échelle du pays, les opérateurs américains pourraient légalement faire ce que leurs homologues européens n'ont pas le droit de faire. Pourtant, ils ne le font pas ouvertement non plus, et la raison renvoie aux trois points suivants.\r\n\r\nC'est commercialement intenable\r\n\r\nImagine la publicité : « Forfait Premium à 50 € — passez devant les pauvres pendant les heures de pointe ». Le slogan ne se vend pas. Les directions marketing savent que dire à la moitié de leurs clients qu'ils sont des citoyens de seconde zone du réseau est le plus court chemin vers une crise de réputation. C'est pour ça qu'on vous vend « plus de Go », « 5G ultra rapide », « roaming inclus dans 110 pays » — des promesses qui sonnent positivement sans jamais dire à personne qu'il est désavantagé.\r\n\r\nL'effet boule de neige serait toxique\r\n\r\nImagine que ça se mette quand même en place. Les riches passent devant. Les antennes restent saturées pour les autres, qui se mettent à payer plus pour échapper à la saturation, ce qui sature encore plus les bas forfaits, ce qui pousse encore plus de gens à monter en gamme. Au bout de cinq ans, on a un réseau à deux vitesses où les forfaits modestes deviennent quasi inutilisables aux heures critiques, et où la connexion mobile correcte devient un service de luxe. Ce n'est plus un service de télécommunications, c'est un système de classes.\r\n\r\nC'est exactement ce que la neutralité du net cherche à empêcher. Pas par idéologie, mais parce qu'on a déjà vu où mène ce genre de spirale dans les pays où elle n'est pas protégée. Certains opérateurs proposent par exemple des forfaits où Facebook et WhatsApp sont gratuits mais où le reste est payant, ce qui revient à dire que le bon internet est celui que l'opérateur a choisi pour vous. Ce n'est plus tout à fait le même service.\r\n\r\nÇa ne résoudrait rien\r\n\r\nQuand un réseau sature, ce n'est pas un problème de répartition entre utilisateurs, c'est un problème de capacité totale. Faire passer Pierre avant Paul ne crée pas un seul bit de bande passante supplémentaire. Ça déplace juste le problème de l'un vers l'autre. La vraie solution, quand une cellule sature trop souvent, c'est d'installer plus d'antennes, de densifier le réseau, de basculer sur une fréquence plus performante ou de passer à la génération suivante. C'est cher, c'est long, ça implique des autorisations administratives et des négociations foncières, mais c'est la seule réponse qui tient la route. Prioriser, c'est rapide, mais ça repousse le mur, ça ne le déplace pas.\r\n\r\nC'est comme si on proposait une voie réservée aux Mercedes sur l'A7 un samedi de chassé-croisé. Techniquement, on peut peindre la ligne au sol et installer les panneaux dans la matinée. Mais cette voie ne réduit pas le bouchon, elle le concentre sur les voies restantes ; elle écorne le principe d'égalité d'accès à l'infrastructure publique ; et elle ne change rien au problème de fond, qui est qu'il y a trop de voitures pour la route disponible. La vraie solution reste la même qu'avant : élargir l'autoroute, ou convaincre une partie des gens de prendre le train.\r\n\r\nLe caveat 5G\r\n\r\nUne nuance honnête pour finir. Le network slicing complique le débat juridique. Un opérateur peut créer des tranches de réseau avec des qualités différenciées en toute légalité quand il s'agit d'usages spécialisés — santé, industrie, transports. La question qui agite régulateurs et juristes depuis plusieurs années est de savoir où finit le service spécialisé légitime et où commence le contournement déguisé de la neutralité du net. L'ARCEP a ouvert ce chantier, et c'est probablement là, plus que dans une revanche commerciale brutale sur les forfaits premium, que se jouera la prochaine bataille.\r\n\r\nMais pour répondre simplement à la question : non, votre forfait à 50 € ne vous donne pas la priorité réseau sur celui de votre voisin à 10 €. Il vous donne plus de data, parfois un meilleur débit théorique, des options en plus. Pas une place dans la file."},{"uuid":"0297ae4d-23ba-44cc-ba52-ec6ed48a4cbc","slug":"20230527-etude-d-une-configuration-docker-compose","title":"Étude d'une configuration docker compose","category":"Journal geek","author":"cedric@abonnel.fr","cover":"","published":true,"published_at":"2023-05-27 05:56:44","created_at":"2023-05-27 05:56:44","updated_at":"2023-05-27 05:56:44","tags":[],"plain":"Docker Compose est un outil qui permet de décrire et de gérer des applications multi-conteneurs. Le fichier docker-compose.yml est utilisé pour définir la configuration des services d'une application et les paramètres nécessaires à son exécution. Le fichier docker-compose.yml est généralement écrit en format YAML (Yet Another Markup Language) et il contient les informations suivantes :\nServices : Il s'agit des différents conteneurs qui composent votre application. Chaque service est défini avec un nom et peut spécifier l'image Docker à utiliser, les volumes à monter, les ports à exposer, les variables d'environnement, etc.\nRéseaux : Vous pouvez spécifier les réseaux auxquels les conteneurs doivent être connectés, ainsi que les paramètres réseau spécifiques à chaque service.\nVolumes : Vous pouvez définir des volumes pour partager des données entre les conteneurs ou pour stocker des données persistantes.\nVariables d'environnement : Vous pouvez définir des variables d'environnement spécifiques à chaque service, qui seront accessibles depuis les conteneurs.\nDépendances : Vous pouvez spécifier des dépendances entre les services, ce qui permet de contrôler l'ordre de démarrage et de garantir que les services dépendants sont prêts avant que d'autres services ne démarrent. Une fois que vous avez défini votre configuration dans le fichier docker-compose.yml, vous pouvez utiliser la commande docker-compose up pour démarrer tous les conteneurs et les services correspondants en fonction de cette configuration. Voir l'étude d'un exemple : https://www.abonnel.fr/informatique/serveur/castopod/docker-compose"},{"uuid":"f853ad20-c0b4-4dad-9315-f7226da26393","slug":"docker-compose","title":"docker-compose.yml","category":"Informatique","author":"cedric@abonnel.fr","cover":"","published":true,"published_at":"2023-05-26 18:28:17","created_at":"2023-05-26 18:28:17","updated_at":"2023-05-26 18:28:17","tags":[],"plain":"Cette configuration définit un ensemble de services Docker qui sont utilisés pour déployer l'application Castopod, une plateforme de gestion de podcasts. Les services déclarés sont les suivants : 1. Le service \"app\" :\nUtilise l'image Docker \"castopod/app:latest\" pour exécuter l'application Castopod.\nLe nom du conteneur est défini comme \"castopod-app\".\nMontre un volume nommé \"castopod-media\" dans le répertoire \"/opt/castopod/public/media\" du conteneur, qui est utilisé pour stocker les fichiers médias des podcasts.\nDéfinit plusieurs variables d'environnement liées à la base de données MySQL utilisée par Castopod, y compris le nom de la base de données, l'utilisateur et le mot de passe.\nDéfinit également d'autres variables d'environnement, telles que l'URL de base de Castopod, le sel pour les analyses, le gestionnaire de cache utilisé (Redis), et l'hôte Redis.\nAppartient au réseau \"castopod-app\".\nLe redémarrage du conteneur est défini sur \"unless-stopped\", ce qui signifie qu'il sera redémarré automatiquement sauf s'il est arrêté explicitement. 2. Le service \"redis\" :\nUtilise l'image Docker \"redis:7.0-alpine\" pour exécuter une instance Redis, qui est utilisée par Castopod comme gestionnaire de cache.\nLe nom du conteneur est défini comme \"castopod-redis\".\nMontre un volume nommé \"castopod-cache\" dans le répertoire \"/data\" du conteneur, qui est utilisé pour stocker les données de cache de Redis.\nAppartient également au réseau \"castopod-app\". 3. Le service \"video-clipper\" (optionnel) :\nUtilise l'image Docker \"castopod/video-clipper:latest\" pour exécuter un conteneur dédié à la fonctionnalité de découpage vidéo de Castopod.\nLe nom du conteneur est défini comme \"castopod-video-clipper\".\nMontre le même volume \"castopod-media\" que le service \"app\", ce qui permet au conteneur d'accéder aux fichiers médias des podcasts.\nDéfinit les mêmes variables d'environnement pour la base de données MySQL que le service \"app\".\nLe redémarrage du conteneur est également défini sur \"unless-stopped\". En outre, la configuration définit deux volumes Docker nommés \"castopod-media\" et \"castopod-cache\", qui sont utilisés pour stocker respectivement les fichiers médias des podcasts et les données de cache de Redis. De plus, un réseau nommé \"castopod-app\" est créé pour permettre la communication entre les services. Cette configuration permet donc de déployer l'application Castopod avec une base de données MySQL et une instance Redis pour la gestion du cache. Concernant les variables à modifier\nVoici les variables modifiables présentes dans la section   de chaque service : Pour le service \"app\" :\n: Nom de la base de données MySQL utilisée par Castopod.\n: Nom d'utilisateur MySQL pour Castopod.\n: Mot de passe MySQL pour Castopod.\n: URL de base pour Castopod.\n: Sel utilisé pour les analyses. Pour le service \"video-clipper\" (optionnel) :\n: Nom de la base de données MySQL utilisée par Castopod.\n: Nom d'utilisateur MySQL pour Castopod.\n: Mot de passe MySQL pour Castopod. Vous pouvez modifier ces variables en fonction de vos besoins spécifiques en leur attribuant les valeurs souhaitées. Par exemple, vous pouvez changer le nom de la base de données, l'utilisateur et le mot de passe MySQL, ainsi que l'URL de base pour Castopod, le sel pour les analyses. Assurez-vous de respecter les contraintes et les configurations requises par l'application Castopod lors de la modification de ces variables. Concernant les volumes\nPour définir les volumes dans la configuration Docker Compose, vous utilisez la section  du fichier YAML. Voici comment faire : Dans cet exemple, nous avons ajouté la section  à la fin du fichier YAML. À l'intérieur de cette section, vous déclarez vos volumes en utilisant un nom de volume suivi des deux-points . Les noms de volume ici sont \"castopod-media\" et \"castopod-cache\". Ensuite, vous pouvez référencer ces volumes dans la section  des services concernés en utilisant la syntaxe . Dans l'exemple ci-dessus, le volume \"castopod-media\" est monté dans le répertoire  du conteneur du service \"app\", et le volume \"castopod-cache\" est monté dans le répertoire  du conteneur du service \"redis\". En définissant les volumes de cette manière, Docker va créer les volumes persistants nécessaires pour les conteneurs et les associer à leurs répertoires respectifs à chaque exécution. N'oubliez pas que si vous avez plusieurs services utilisant les mêmes volumes, ils auront accès aux mêmes données persistantes, ce qui peut être utile pour le partage de données entre les conteneurs. Voici un exemple de configurations que vous pouvez utiliser pour les volumes  \"castopod-media\" et  \"castopod-cache\" dans votre fichier Docker Compose : 1. Utilisation d'un chemin local sur la machine hôte : Dans cet exemple, nous utilisons des volumes de type  \"local\" pour lier des dossiers locaux sur la machine hôte aux conteneurs. Vous devez remplacer  \"/chemin/vers/le/dossier/media\" et  \"/chemin/vers/le/dossier/cache\" par les chemins réels vers les dossiers que vous souhaitez utiliser pour stocker les données du volume. 2. Utilisation de volumes nommés : Dans cet exemple, nous déclarons simplement les volumes  \"castopod-media\" et  \"castopod-cache\" sans spécifier de configuration supplémentaire. Dans ce cas, Docker va créer et gérer les volumes automatiquement dans un emplacement par défaut sur le système de fichiers du système d'hébergement Docker. Concernant l'option restart\nDans le contexte de la configuration Docker Compose, la ligne  est spécifiée pour les services \"app\" et \"video-clipper\". Lorsque vous utilisez , cela signifie que Docker va automatiquement redémarrer le conteneur en cas d'arrêt, sauf si vous arrêtez explicitement le conteneur manuellement en utilisant une commande Docker, par exemple . Cela garantit que le conteneur est toujours en cours d'exécution, sauf si vous décidez de l'arrêter de manière explicite. Cela peut être utile pour s'assurer que les services sont toujours disponibles et fonctionnent de manière continue, même après un redémarrage du système ou un arrêt inattendu. Cette option de redémarrage automatique peut être configurée avec d'autres valeurs, telles que , , ."},{"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."},{"uuid":"586c5ab7-e960-465b-b499-83e0209890fe","slug":"quand-alt-ne-repond-plus-anatomie-d-un-bug-clavier-sous-gnome-wayland","title":"Quand Alt ne répond plus : anatomie d'un bug clavier sous GNOME/Wayland","category":"informatique","author":"cedric@abonnel.fr","cover":"cover.png","published":true,"published_at":"2026-05-25 07:27","created_at":"2026-05-12 13:35:47","updated_at":"2026-05-12 13:40:34","tags":[],"plain":"Comment une option de clavier a priori anodine peut désactiver Alt+Tab, Alt+F4 et tous les raccourcis Alt — et comment diagnostiquer ce genre de problème de façon méthodique.\r\n\r\nLe symptôme\r\n\r\nUn beau matin, les raccourcis clavier ne répondent plus. Pas tous : seulement ceux qui utilisent la touche Alt gauche.\r\nne change plus de fenêtre\r\nne ferme plus l'application active\r\nDans un terminal, les raccourcis  (édition de ligne readline, raccourcis dans une applicaiton, navigation tmux…) restent sans effet\r\nLa touche AltGr (Alt droite), elle, fonctionne toujours : on peut taper , , , les caractères normalement obtenus via Alt droite sur un clavier français azerty\r\n\r\nPremier réflexe naturel : « Le clavier est cassé ». Sauf que la touche physique répond bien — elle ne déclenche simplement plus ce qu'on attend d'elle.\r\n\r\nComprendre ce qui se passe (sans connaître Linux par cœur)\r\n\r\nPour saisir le bug, il faut comprendre un détail qu'on ignore généralement : une touche physique du clavier et la fonction qu'elle déclenche sont deux choses différentes.\r\n\r\nQuand on appuie sur la touche marquée « Alt » à gauche du clavier, le système reçoit d'abord un signal matériel — un code brut,  sous Linux. Ce signal est ensuite traduit en une fonction logique par une couche logicielle appelée xkb (X Keyboard Extension). C'est xkb qui décide que  signifie « modificateur Alt gauche » (le fameux ).\r\n\r\nMais xkb peut être configuré pour faire autre chose de ce même signal. Et c'est exactement ce qui s'était passé ici. Une option xkb nommée  indiquait à la couche de traduction :\r\n« Quand tu reçois , ne génère pas . Génère  à la place. »\r\n\r\n, c'est le nom technique de AltGr : la touche modificatrice qui permet d'accéder au « troisième niveau » d'une touche (le  au-dessus du , le  au-dessus du , etc.). En clair, l'option transformait Alt gauche en un deuxième AltGr.\r\n\r\nConséquence : du point de vue des applications, personne n'appuie jamais sur Alt. Le gestionnaire de fenêtres (mutter, dans GNOME) attend un événement  qui ne vient jamais ; le terminal attend un préfixe Alt qui ne vient jamais non plus ; AltGr fonctionne toujours parce que c'est lui le « vrai » Level 3 Shift sur azerty, par défaut.\r\n\r\nC'est l'analogie d'un interrupteur dont on aurait inversé deux fils dans le mur : l'interrupteur marche, mais il commande une autre lampe.\r\n\r\nLa cause exacte\r\n\r\nSous GNOME, les options xkb sont stockées dans la base de configuration dconf, accessible via la commande . La clé concernée :\r\n\r\n\r\n\r\nSur le système concerné, la commande retournait :\r\n\r\n\r\n\r\nD'où venait cette option ? Plusieurs hypothèses plausibles :\r\nSélectionnée par erreur dans Paramètres → Clavier → Options de disposition lors d'une configuration ancienne\r\nImportée depuis une ancienne machine via la synchronisation du profil\r\nActivée par un script ou un outil de personnalisation (GNOME Tweaks, dconf-editor)\r\nHéritée d'une habitude QWERTY où certains préfèrent un second AltGr à gauche\r\n\r\nSur un clavier français azerty, cette option n'a aucun intérêt pratique : AltGr est déjà sur la touche Alt droite, là où l'index droit peut l'atteindre naturellement. Ajouter un second AltGr sur la touche Alt gauche revient à perdre Alt sans gagner quoi que ce soit.\r\n\r\nLe diagnostic, étape par étape\r\n\r\nVoici la séquence de commandes pour confirmer le problème — utile à mémoriser parce qu'elle s'applique à tout symptôme similaire sur GNOME/Wayland.\r\n\r\n1. Confirmer l'environnement de session. Les commandes qui suivent supposent GNOME sous Wayland ; sous X11 ou KDE, le diagnostic diffère.\r\n\r\n\r\n\r\n2. Inspecter les options xkb. C'est le test diagnostic principal pour ce genre de panne.\r\n\r\n\r\n\r\nSi la sortie n'est pas  (liste vide) ou une option clairement intentionnelle, on tient probablement le coupable. Les options les plus susceptibles de casser des raccourcis :\r\n— transforme Alt gauche en AltGr (le cas présent)\r\n— échange Alt et Super (la touche Windows)\r\n— échange Caps Lock et Échap (anodin pour Alt, mais peut surprendre)\r\n,  — transforment Caps Lock en Ctrl\r\n\r\n3. Vérifier que les raccourcis WM sont bien définis. Cela permet d'éliminer une mauvaise piste : si  ne marchait pas parce que le raccourci avait été effacé, ce serait visible ici.\r\n\r\n\r\n\r\nLa sortie attendue est  ou équivalent. Si  y figure, le gestionnaire de fenêtres est correctement configuré — la panne est ailleurs.\r\n\r\n4. Vérifier les options d'accessibilité. Les touches rémanentes (StickyKeys), touches lentes (SlowKeys) ou touches rebonds (BounceKeys) peuvent provoquer des comportements clavier surprenants quand elles sont activées par erreur.\r\n\r\n\r\n\r\nToutes les trois doivent normalement renvoyer  sauf besoin spécifique.\r\n\r\n5. Tester au niveau matériel si rien d'autre n'explique. Si toutes les vérifications logicielles sont propres, on vérifie que la touche envoie bien un signal au noyau :\r\n\r\n\r\n\r\nL'outil demande de choisir un périphérique (le clavier), puis affiche en direct chaque événement reçu. En appuyant sur Alt gauche, une ligne contenant  doit apparaître. Si rien ne s'affiche, le problème est matériel ou dans le pilote — ce qui sort du cadre de cette fiche.\r\n\r\nLa correction\r\n\r\nUne seule commande suffit dans le cas présent :\r\n\r\n\r\n\r\nL'effet est immédiat : mutter recharge la configuration clavier à la volée, sans qu'on ait besoin de fermer sa session. Si pour une raison ou une autre l'effet ne se voit pas (vieux processus qui a mis en cache la configuration, terminal récalcitrant…), une déconnexion/reconnexion de la session GNOME suffit à tout réinitialiser.\r\n\r\nPour vérifier que la valeur est bien revenue à vide :\r\n\r\n\r\n\r\nEt si on voulait vraiment garder l'option ?\r\n\r\nPour information, la commande inverse est :\r\n\r\n\r\n\r\nÀ réserver aux cas où l'on tape énormément de caractères de troisième niveau de la main gauche et où on accepte de perdre Alt+Tab.\r\n\r\nLa méthode à retenir, au-delà de ce bug précis\r\n\r\nL'intérêt de cette fiche n'est pas tant la solution — une ligne de commande — que la logique de diagnostic. Quand une touche cesse de fonctionner sous Linux, on remonte la chaîne des responsabilités, du plus haut niveau au plus bas :\r\n\r\n1. Le gestionnaire de fenêtres a-t-il bien le raccourci ? ()\r\n2. Les options d'accessibilité ne brouillent-elles pas la frappe ? ()\r\n3. La couche xkb traduit-elle correctement la touche en modificateur ? ()\r\n4. Le noyau reçoit-il un signal matériel quand on appuie ? ()\r\n\r\nÀ chaque étage, une commande, une sortie attendue, et un verdict clair. La grande force de Linux dans ce genre de situation, c'est que chaque couche est inspectable séparément. Le réflexe à acquérir n'est pas « ça ne marche pas, je redémarre » mais « ça ne marche pas, je trouve quelle couche ment ».\r\n\r\nChecklist mémo\r\n\r\nModificateur (Alt / Super / Ctrl) qui ne répond plus sous GNOME/Wayland :\r\n\r\n1.  — surveiller , , , \r\n2.  — confirmer que le raccourci existe\r\n3.  (puis , )\r\n4.  → choisir le clavier → presser la touche → doit afficher le bon code (, , etc.)\r\n\r\nQuatre commandes, quatre couches, et 95 % des bugs clavier de session graphique sont localisés."}]