varlog/_cache/similar/93ebccb3-aef4-40f6-acfa-eaaa4ba7fae7.json

[{"uuid":"37463f14-b96a-4d3d-bed8-14173e668cd0","slug":"activer-line-in","title":"Activer Line In","category":"Informatique","author":"cedric@abonnel.fr","cover":"","published":true,"published_at":"2021-01-16 04:01:46","created_at":"2021-01-16 04:01:46","updated_at":"2021-01-16 04:01:46","tags":[],"plain":"> Activer\n> Désactiver ou xx est le numéro du module renvoyé lors de l'activation."},{"uuid":"9710aeae-eadf-4f2e-b776-c6e1c2f10d33","slug":"l-assurance-maladie-me-doit-l-argent","title":"L'Assurance Maladie me doit de l'argent » : anatomie d'une arnaque par hameçonnage","category":"Informatique","author":"cedric@abonnel.fr","cover":"","published":true,"published_at":"2020-04-17 18:05","created_at":"2020-04-17 18:05:20","updated_at":"2026-05-12 20:26:45","tags":[],"plain":"Un beau matin, un courriel atterrit dans la boîte de réception. L'expéditeur affiche fièrement « Assurance Maladie », l'objet annonce un remboursement à percevoir, et un lien promet d'expliquer la marche à suivre pour récupérer la somme due. Tout semble en ordre. Et pourtant, à peine la souris approchée du lien, plusieurs garde-fous se déclenchent les uns après les autres : Thunderbird signale une tentative de fraude, Firefox refuse de charger la page, et le site cible n'a rien à voir avec . Bienvenue dans le monde du phishing, ou hameçonnage en français.\r\n\r\n\r\n\r\nCe billet revient sur l'anecdote en détail, mais surtout l'utilise pour décortiquer le mécanisme général de ce type d'arnaque, comprendre pourquoi elle fonctionne sur tant de personnes, et adopter quelques réflexes simples qui suffisent à s'en prémunir dans la quasi-totalité des cas.\r\n\r\n1. Qu'est-ce que le phishing ?\r\n\r\nLe terme phishing est un mot-valise construit sur l'anglais fishing (la pêche) et phreaking (piratage téléphonique). L'image est exacte : l'escroc lance un appât — un message crédible — et attend qu'une victime morde. Sa cible n'est pas un ordinateur ni une faille technique, c'est un humain. Plus précisément, c'est la confiance, l'inattention ou l'envie de cette personne.\r\n\r\nConcrètement, une attaque par hameçonnage consiste à se faire passer pour un organisme légitime (banque, impôts, Assurance Maladie, opérateur télécom, service de livraison, etc.) afin d'obtenir de la victime qu'elle livre d'elle-même des informations sensibles : identifiants de connexion, numéro de carte bancaire, copie de pièce d'identité, parfois même un virement direct.\r\n\r\nTrois ingrédients reviennent à chaque fois :\r\nUne marque connue dont l'identité visuelle est imitée (logo, couleurs, ton du message).\r\nUn prétexte émotionnel qui pousse à agir vite : remboursement à percevoir, colis bloqué, compte suspendu, amende impayée.\r\nUn lien qui paraît légitime mais redirige en réalité vers un site contrôlé par l'attaquant.\r\n\r\nL'arnaque ameli.fr coche les trois cases.\r\n\r\n2. Décorticage du courriel reçu\r\n\r\nLe message annonce un versement de l'Assurance Maladie. Le scénario est habilement choisi : recevoir de l'argent flatte, intrigue, et désarme la vigilance. Personne ne se méfie d'un cadeau. Pourtant, en regardant de plus près le lien embarqué dans le message, on découvre une adresse pour le moins surprenante :\r\n\r\n\r\n\r\nTrois éléments doivent immédiatement alerter :\r\n\r\n1. Le domaine n'est pas . Le vrai domaine, lu de droite à gauche en partant du dernier point, est  — un hébergeur sud-coréen. Le reste () est un sous-domaine, et le mot  n'est qu'un nom de fichier choisi pour tromper. Aucun service public français n'héberge ses pages chez un hébergeur étranger commercial.\r\n2. Le protocole est , pas . Toute page officielle traitant de données personnelles ou bancaires utilise aujourd'hui une connexion chiffrée. Un site qui demande des informations sensibles en clair signe son illégitimité.\r\n3. Les segments  sont des marqueurs typiques de campagnes de phishing automatisées : chaque destinataire reçoit un identifiant unique, ce qui permet à l'attaquant de suivre qui a cliqué et d'affiner ses prochaines vagues.\r\n\r\nLire l'adresse d'un lien avant de cliquer dessus est donc la première compétence à acquérir. Sur un ordinateur, il suffit de survoler le lien sans cliquer : l'adresse réelle apparaît en bas de la fenêtre du navigateur ou du client de messagerie.\r\n\r\n3. Les garde-fous techniques font (parfois) leur travail\r\n\r\nDans le cas raconté ici, les outils ont parfaitement joué leur rôle. Thunderbird, le client de messagerie, a détecté que le texte affiché du lien ne correspondait pas à sa destination réelle et a affiché un avertissement clair.\r\n\r\n\r\n\r\nCette détection repose sur une règle simple mais efficace : si le texte visible du lien ressemble à une URL (par exemple ) mais que la destination effective pointe ailleurs, c'est un signal extrêmement fort de tentative de tromperie. Aucun site légitime ne fait cela.\r\n\r\nLe second rempart est intervenu côté navigateur. Firefox, en suivant malgré tout le lien, a interrogé une base de sites malveillants connus (le service Google Safe Browsing, partagé entre les principaux navigateurs) et a bloqué l'accès.\r\n\r\n\r\n\r\nCes protections sont précieuses, mais il faut bien comprendre leurs limites :\r\nElles arrivent toujours en retard. Une nouvelle campagne de phishing fonctionne pendant plusieurs heures, parfois plusieurs jours, avant d'être signalée et ajoutée aux listes noires. Les premières victimes ne sont jamais protégées par ces filtres.\r\nElles peuvent être contournées. L'utilisateur a la possibilité d'ignorer l'avertissement, comme dans l'exemple où la curiosité l'a emporté.\r\nElles ne couvrent pas tous les canaux. Un SMS, un appel téléphonique, un message sur les réseaux sociaux ne déclenchent pas ces alertes.\r\n\r\nLa vigilance humaine reste donc l'ultime ligne de défense, et c'est précisément sur elle que mise l'escroc.\r\n\r\n4. Pourquoi ça marche aussi bien\r\n\r\nComprendre pourquoi tant de personnes se font piéger malgré les avertissements aide à mieux résister. Plusieurs ressorts psychologiques sont systématiquement exploités.\r\n\r\nL'argument d'autorité\r\n\r\nLe message émane d'un organisme officiel, dont la légitimité ne se discute pas. L'Assurance Maladie, les impôts, la banque, La Poste : la marque seule impose le respect et désamorce le doute. L'escroc le sait et choisit toujours une institution familière de sa cible.\r\n\r\nL'urgence ou l'opportunité\r\n\r\nLe cerveau humain traite mal les décisions rapides. Soit le message annonce une catastrophe imminente (« votre compte sera suspendu sous 24 h »), soit il fait miroiter un gain immédiat (« un remboursement de 38,47 € vous attend »). Dans les deux cas, la fenêtre de réflexion se réduit, et c'est exactement l'effet recherché.\r\n\r\nLe mimétisme visuel\r\n\r\nLogos, couleurs, polices, pieds de page : tout est copié à l'identique depuis le vrai site. Pour un œil non entraîné, rien ne distingue le faux du vrai. Et pour cause, le faux a souvent été fabriqué en quelques minutes à partir du code source du vrai.\r\n\r\nLe coût de la vérification\r\n\r\nVérifier prend du temps : ouvrir un onglet, taper l'adresse, se connecter, retrouver son mot de passe. Cliquer ne coûte rien. À court terme, le cerveau choisit toujours la voie la moins coûteuse — et c'est par là que l'escroc s'invite.\r\n\r\n5. La règle d'or : ne jamais cliquer sur un lien d'argent\r\n\r\nDe cette anecdote se dégage un principe qui mérite d'être affiché en grand au-dessus de chaque boîte de réception :\r\nLorsqu'un organisme annonce un versement, un remboursement, un trop-perçu ou tout autre mouvement d'argent en sa faveur, on ne clique jamais sur le lien du courriel. On accède au site par ses propres moyens.\r\n\r\nConcrètement, cela signifie :\r\nOuvrir un nouvel onglet du navigateur.\r\nTaper l'adresse à la main dans la barre d'adresse, ou la sélectionner dans ses favoris.\r\nSe connecter à son espace personnel comme on le fait d'habitude.\r\nVérifier si l'information annoncée par le courriel s'y retrouve réellement.\r\n\r\nDans neuf cas sur dix, l'espace personnel ne mentionne aucun remboursement, et l'origine frauduleuse du message est confirmée. Dans le dixième cas, le remboursement est bien réel, et il sera traité depuis la source officielle sans avoir suivi le moindre lien suspect.\r\n\r\n\r\n\r\nCette règle vaut pour tous les organismes : Assurance Maladie, banques, impôts, CAF, opérateurs, plateformes de commerce. Elle ne demande aucune compétence technique et bloque l'écrasante majorité des tentatives.\r\n\r\n6. Les autres signaux qui doivent éveiller le doute\r\n\r\nAu-delà du lien lui-même, plusieurs détails trahissent souvent un courriel d'hameçonnage. Aucun n'est rédhibitoire à lui seul, mais leur cumul ne trompe pas.\r\n\r\nL'adresse de l'expéditeur. Le nom affiché peut être falsifié à volonté, mais l'adresse email réelle est plus difficile à maquiller. Une adresse en  n'a rien d'officiel : seules les adresses se terminant par  ou  le sont. La règle se généralise : le domaine légitime de chaque organisme est un et un seul, et il s'apprend une fois pour toutes.\r\n\r\nLes fautes d'orthographe et de syntaxe. Une administration française dispose de relecteurs. Un escroc traduit souvent depuis une autre langue, parfois à l'aide d'outils automatiques. Tournures bancales, accents oubliés, fautes d'accord doivent mettre la puce à l'oreille. À noter cependant : avec la généralisation des modèles de langue, ces erreurs disparaissent et ce critère perd progressivement de sa fiabilité.\r\n\r\nUne formule de politesse impersonnelle. « Cher client », « Madame, Monsieur », « Cher utilisateur » : une administration qui dispose de l'état civil de ses assurés s'en sert. Un escroc qui a acheté une liste d'adresses email ne dispose, lui, que de l'adresse.\r\n\r\nUne demande d'informations qu'on ne devrait jamais avoir à fournir. Aucun service public ne demande par courriel un numéro de carte bancaire complet, un mot de passe, un code reçu par SMS, ou la photo d'une pièce d'identité. Si la page d'arrivée réclame ce genre de données, c'est le moment de fermer l'onglet.\r\n\r\nUne pièce jointe inattendue. Une « facture » au format  ou  envoyée par un organisme public est presque toujours malveillante. Les administrations mettent leurs documents à disposition dans l'espace personnel, pas en pièce jointe.\r\n\r\n7. Que faire en cas de doute, ou en cas d'erreur\r\n\r\nRecevoir un courriel suspect n'est ni grave ni rare. Cliquer dessus par mégarde l'est davantage, mais reste rattrapable. Quelques gestes simples permettent de limiter la casse et de protéger les autres.\r\n\r\nSignaler le message. Le dispositif officiel français s'appelle Signal Spam et permet, via une extension de navigateur ou de client mail, de transmettre les courriels frauduleux aux autorités compétentes et aux fournisseurs d'accès. Pour les SMS, le numéro 33700 joue le même rôle. Pour les tentatives plus sophistiquées, la plateforme Pharos recueille les signalements.\r\n\r\nPrévenir l'organisme usurpé. L'Assurance Maladie dispose d'une adresse dédiée pour transférer les courriels suspects : . La plupart des grandes administrations et entreprises ont une adresse équivalente.\r\n\r\nEn cas de clic accidentel, ne rien saisir et fermer la page. Tant qu'aucune donnée n'a été tapée, le risque est limité au chargement du site, qui peut éventuellement tenter d'exploiter une faille du navigateur. Maintenir son navigateur à jour suffit à neutraliser l'essentiel.\r\n\r\nEn cas de saisie de données, agir vite. Si un mot de passe a été tapé sur le faux site, le changer immédiatement sur le vrai site, et partout ailleurs s'il était réutilisé. Si des données bancaires ont été communiquées, appeler sa banque pour faire opposition. Si une pièce d'identité a été transmise, déposer plainte et demander un signalement auprès de FranceConnect pour surveiller toute usurpation.\r\n\r\n8. Le réflexe à long terme\r\n\r\nAu fil des années, un principe simple et robuste s'impose : considérer par défaut qu'un courriel non sollicité demandant une action en ligne est suspect, et le vérifier par un canal indépendant. Cette posture coûte quelques secondes par message. Elle a évité, chez la plupart de ceux qui l'adoptent, l'écrasante majorité des arnaques en circulation.\r\n\r\nL'anecdote racontée ici se termine bien : les outils ont alerté, la curiosité s'est arrêtée à temps, et l'absence de la moindre saisie sur le faux site a évité tout dégât. Mais elle illustre parfaitement combien le scénario est crédible et combien il est facile, dans un moment de distraction, de baisser la garde.\r\n\r\nLa meilleure protection contre le phishing n'est ni un antivirus, ni un filtre anti-spam, ni un navigateur particulièrement vigilant : c'est l'habitude, lentement acquise, de séparer le messager du message. Un courriel n'est qu'une invitation à vérifier. La vérification, elle, se fait toujours à la source."},{"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."},{"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."}]