Cédrix
1 line
46 KiB
JSON
1 line
46 KiB
JSON
[{"uuid":"a2487513-2848-4e62-bd19-d8ebb205e502","slug":"progressive-web-apps-dossier-2026","title":"Progressive Web Apps — Dossier 2026","category":"","author":"cedric@abonnel.fr","cover":"cover.jpg","published":true,"published_at":"2026-05-15 07:53","created_at":"2026-05-13 18:58:29","updated_at":"2026-05-13 19:06:33","tags":[],"plain":"1. Qu'est-ce qu'une PWA ?\r\n\r\nUne Progressive Web App est une application web qui, grâce à des APIs modernes des navigateurs, se comporte comme une application native : installable sur l'écran d'accueil, capable de fonctionner hors ligne, de recevoir des notifications push, de s'intégrer au système d'exploitation, tout en restant un site web indexable par les moteurs de recherche.\r\n\r\nLe mot clé est progressive : l'expérience s'enrichit selon les capacités du navigateur et de l'appareil. Sur un Chrome récent sous Android, la PWA offre une expérience proche du natif ; sur un vieux navigateur, elle reste un site web fonctionnel.\r\n\r\nUne PWA repose sur trois piliers techniques :\r\nHTTPS obligatoire — sécurité et confiance, prérequis pour toutes les APIs sensibles.\r\nService Worker — un script JavaScript qui tourne en arrière-plan, intercepte les requêtes réseau, gère le cache et les notifications.\r\nManifest () — un fichier JSON qui décrit l'application (nom, icônes, couleurs, mode d'affichage) pour permettre son installation.\r\n\r\nTrois critères définissent une PWA selon Google : elle doit être fiable (charge instantanément, même hors ligne), rapide (réagit vite aux interactions) et engageante (sensation d'application native, réengagement par notifications).\r\n\r\n2. Histoire et promoteurs\r\n\r\nL'idée d'une convergence web/natif n'est pas neuve. Steve Jobs, en 2007, présentait initialement l'iPhone sans App Store : les développeurs étaient censés faire des « web apps ». L'App Store est arrivé un an plus tard et a marginalisé cette vision pendant près d'une décennie.\r\n\r\nLe terme « Progressive Web App » est proposé en 2015 par la designer Frances Berriman et l'ingénieur Google Alex Russell, pour désigner les sites tirant parti des nouvelles APIs (service workers notamment, standardisés à partir de 2014-2015).\r\n\r\nLes promoteurs historiques :\r\nGoogle — moteur principal. Pousse la spécification, intègre les PWA à Chrome, Android, ChromeOS, et au Play Store (depuis 2019, on peut publier une PWA empaquetée via TWA — Trusted Web Activity).\r\nMicrosoft — second souffle majeur. Edge intègre les PWA nativement, et Windows permet leur publication au Microsoft Store via packaging MSIX. En mai 2025, Edge a ajouté les App Actions on Windows pour les PWA, améliorant la découvrabilité système.\r\nMozilla — soutien historique des standards, support solide dans Firefox (bien que l'installation desktop ait été retirée puis partiellement réintégrée selon les versions).\r\nApple — adoption lente et réticente, voir section 6.\r\n\r\nLes premiers grands déploiements (vers 2016-2017) ont servi de cas d'école : Twitter Lite, AliExpress, Pinterest, Flipkart, Starbucks, Uber, Tinder, Trivago. Tous ont publié des chiffres montrant des gains d'engagement et de conversion significatifs, ce qui a légitimé le modèle auprès des grandes entreprises.\r\n\r\n3. Comment ça marche techniquement\r\n\r\n3.1 Le manifeste\r\n\r\nFichier JSON déclaratif qui dit au navigateur : « ce site est installable, voici comment il doit se présenter ».\r\n\r\n\r\n\r\nRéférencé dans le HTML :\r\n\r\n\r\n\r\nLe mode retire la barre d'adresse au lancement depuis l'écran d'accueil ; masque même la barre système.\r\n\r\n3.2 Le Service Worker\r\n\r\nScript JavaScript qui s'exécute dans un thread séparé, sans accès direct au DOM, et qui agit comme un proxy programmable entre l'application et le réseau.\r\n\r\n\r\n\r\nEnregistrement depuis la page principale :\r\n\r\n\r\n\r\n3.3 Stratégies de cache\r\n\r\nQuatre patterns canoniques selon le type de ressource :\r\nCache-first — sert le cache, va sur le réseau si absent. Idéal pour les assets statiques (CSS, JS, polices).\r\nNetwork-first — tente le réseau, retombe sur le cache en cas d'échec. Idéal pour les contenus dynamiques (articles, posts).\r\nStale-while-revalidate — sert le cache immédiatement, met à jour en arrière-plan. Bon compromis pour les contenus semi-dynamiques (listes, avatars).\r\nNetwork-only / Cache-only — cas particuliers (analytics, données critiques).\r\n\r\n3.4 Les APIs modernes mobilisables\r\n\r\nEn 2026, l'écosystème PWA s'appuie sur un éventail large :\r\nPush API + Notifications API — notifications push, y compris sur iOS 16.4+ (sous conditions).\r\nBackground Sync — différer une requête jusqu'au retour de la connectivité (Chrome/Edge ; pas sur iOS).\r\nPeriodic Background Sync — déclencher du code à intervalle régulier (Chrome/Edge uniquement).\r\nWeb Share API — utiliser le menu de partage natif du système.\r\nFile System Access API — lire/écrire dans des fichiers locaux (Chrome/Edge).\r\nWebGPU, WebAssembly SIMD, WebNN — calcul intensif et inférence IA côté client.\r\nBadging API — afficher un badge numérique sur l'icône d'app.\r\nWeb Bluetooth, Web USB, Web Serial — accès matériel (Chrome/Edge, hors iOS).\r\nPayment Request API — paiements unifiés, dont Apple Pay sur Safari.\r\n\r\n4. Exemples emblématiques\r\n\r\nLes références suivantes ont structuré la perception du modèle PWA. Les chiffres sont ceux publiés par les entreprises à l'époque de leur migration.\r\n\r\nTwitter Lite (2017) — Twitter a déployé une PWA pesant moins de 1 Mo (contre 23 Mo pour l'app native Android). Résultat : +65 % de pages par session, +75 % de tweets envoyés, −20 % de taux de rebond. Nicolas Gallagher, alors lead du projet, résumait : « Twitter Lite is now the fastest, least expensive, and most reliable way to use Twitter. »\r\n\r\nAliExpress — Migration de leur site mobile vers une PWA. Doublement du temps passé par session, +104 % de taux de conversion pour les nouveaux utilisateurs sur tous les navigateurs.\r\n\r\nPinterest — Refonte en PWA en 2017. Le poids initial du bundle JavaScript est passé de 650 Ko à 150 Ko. Temps passé +40 %, revenus publicitaires +44 %, engagement utilisateur +60 %.\r\n\r\nStarbucks — Une PWA pour la commande en ligne, environ 600 Ko (contre 148 Mo pour l'app iOS native). Double des commandes quotidiennes via le web, avec des chiffres particulièrement marqués sur les marchés à faible bande passante.\r\n\r\nSpotify, Uber, Tinder, Trivago, BMW, Forbes, The Washington Post — Tous ont déployé des versions PWA, soit en remplacement de leur site mobile, soit en complément de l'app native.\r\n\r\nNote d'objectivité : ces cas remontent majoritairement à 2017-2019. Beaucoup ont été suivis d'allers-retours stratégiques (certaines entreprises ont depuis re-priorisé le natif pour des raisons de fonctionnalités ou de distribution). Twitter, par exemple, a depuis fait évoluer son web app et son app native en parallèle. Ces chiffres restent illustratifs d'un potentiel, pas d'une vérité universelle.\r\n\r\n5. Où en est-on en 2026 ?\r\n\r\n5.1 Maturité du modèle\r\n\r\nTrois leviers ont fait basculer les PWA d'une expérimentation à une option pragmatique :\r\n\r\n1. Maturité des APIs clés — service worker stable, manifest standardisé, Web Push enfin disponible sur Safari (iOS 16.4+).\r\n2. Intégration croissante par les OS et stores — packaging MSIX vers le Microsoft Store, TWA vers le Play Store, App Actions sur Windows, mode app par défaut sur iOS 26.\r\n3. Preuves de ROI répétées sur une décennie de déploiements.\r\n\r\n5.2 Chiffres du marché\r\n\r\nLes estimations convergent vers une croissance soutenue. Selon Research Nester, le marché mondial des PWA dépassait 2,47 Md$ en 2025, est estimé à 3,14 Md$ en 2026, avec une projection à 34,58 Md$ d'ici 2035 (TCAC supérieur à 30 %).\r\n\r\nL'adoption reste cependant concentrée : selon les datasets publics (HTTP Archive / Web Almanac), une fraction modeste des sites déclarent un service worker, mais ces sites représentent une part disproportionnée du trafic mondial — autrement dit, ce sont les gros sites qui adoptent.\r\n\r\n5.3 Nouveautés récentes\r\nDeclarative Web Push (Safari 18.4, 2025) — alternative simplifiée au Web Push impératif, ne nécessitant pas de service worker pour des notifications basiques.\r\nApp Actions on Windows pour les PWA (Edge, mai 2025) — les PWA peuvent déclarer des actions invocables depuis la barre de recherche Windows.\r\niOS 26 — tout site ajouté à l'écran d'accueil s'ouvre par défaut en mode application, même sans manifest. Avancée notable côté Apple.\r\nWebGPU, WebNN, WebAssembly SIMD — débloquent l'inférence IA côté client, ouvrant la voie à des PWA capables de traitements lourds locaux (vision, NLP, recommandation).\r\n\r\n5.4 Verrous résiduels\r\nDécouvrabilité — beaucoup d'utilisateurs ne savent pas qu'« ajouter à l'écran d'accueil » installe une vraie app. Pas de prompt automatique sur iOS.\r\nFragmentation des APIs — Chrome/Edge avancent vite, Safari traîne, Firefox se positionne au cas par cas. Le détection de feature reste obligatoire.\r\nStockage — quotas plus stricts sur iOS qu'ailleurs, avec un risque d'éviction du cache après 7 jours sans utilisation sur certaines configurations.\r\nMonétisation — pas de système intégré de paiement in-app comme l'App Store. Il faut passer par Stripe, Apple Pay via Payment Request, etc.\r\n\r\n6. Le cas iOS : limites et particularités\r\n\r\nApple a toujours été le frein principal à l'adoption universelle des PWA. Les raisons sont à la fois techniques et stratégiques (revenus de l'App Store, contrôle de la plateforme, monopole de WebKit).\r\n\r\nCe qui marche en 2026 sur iOS :\r\nInstallation manuelle sur l'écran d'accueil (mais pas de prompt automatique).\r\nMode standalone (fenêtre sans barre d'adresse).\r\nService workers (avec des quotas et limitations).\r\nPush notifications, uniquement si la PWA a été installée à l'écran d'accueil (depuis iOS 16.4).\r\nApple Pay via Payment Request API.\r\nGéolocalisation, caméra, microphone.\r\n\r\nCe qui ne marche pas ou mal :\r\nPas de Background Sync ni de Periodic Background Sync.\r\nPas de Web Bluetooth, Web USB, Web NFC.\r\nStockage limité, susceptible d'être purgé sans usage.\r\nPas de silent push ni de réveil en arrière-plan.\r\nL'audience effectivement joignable par push est environ 10 à 15 fois plus petite que sur app native, une fois pris en compte le parcours d'installation multi-étapes.\r\n\r\nLe détour DMA en Europe : en 2024, Apple a brièvement annoncé supprimer le mode standalone pour les PWA dans l'UE (iOS 17.4) au prétexte du Digital Markets Act, ce qui aurait réduit les PWA à de simples raccourcis Safari. Décision rapidement annulée après tollé : le support PWA complet a été rétabli dans l'UE. Épisode révélateur de la position ambiguë d'Apple.\r\n\r\nVerdict pratique 2026 : Apple a fait des progrès (push en 16.4, Declarative Web Push en 18.4, app mode par défaut en iOS 26), mais à un rythme lent et avec des marges de manœuvre étroites. Pour un projet ciblant fortement iOS et reposant sur du push fiable, du background sync ou de l'intégration profonde au système, le natif (ou hybride) reste l'option plus sûre.\r\n\r\n7. PWA vs natif vs hybride\r\nCritère | PWA | Natif (iOS/Android) | Hybride (RN, Flutter) |\r\n---|---|---|---|\r\nCodebase | Unique (web) | 2 séparés | 1 partagé, ponts natifs |\r\nDistribution | URL + stores optionnels | App Store, Play Store obligatoires | Stores obligatoires |\r\nMises à jour | Instantanées | Validation store (jours) | Validation store |\r\nDécouvrabilité SEO | Oui (indexé Google) | Non | Non |\r\nCoût de dev (typique) | 1× | 2-3× | 1,3-1,8× |\r\nPerformance UI | Bonne à très bonne | Maximale | Très bonne |\r\nAccès matériel | Partiel, variable selon OS | Total | Quasi-total |\r\nNotifications push iOS | Oui, sous conditions | Oui, sans conditions | Oui |\r\nFrais store (achats numériques) | 0 % | 15-30 % | 15-30 % |\r\nHors ligne | Oui via service worker | Oui | Oui |\r\n\r\nQuand choisir une PWA\r\nAudience web-first (desktop + mobile navigateur).\r\nSEO comme canal d'acquisition stratégique.\r\nTime-to-market et coût de maintenance prioritaires.\r\nContenu plutôt que fonctionnalités matérielles avancées.\r\nMarchés émergents (stockage, bande passante limités).\r\nOutils internes B2B, portails, contenus éditoriaux, e-commerce léger.\r\n\r\nQuand préférer le natif\r\nAccès matériel profond (BLE, NFC, capteurs avancés, ARKit/ARCore).\r\nPerformances graphiques 120 fps, jeux, AR/VR.\r\nMonétisation reposant sur l'achat in-app via stores.\r\nMarque dépendant fortement de la présence App Store/Play Store.\r\n\r\nQuand choisir hybride (React Native, Flutter)\r\nPrésence store nécessaire mais sans le budget de deux codebases natives.\r\nÉquipe JavaScript ou Dart.\r\nBesoins matériels modérés mais réels.\r\n\r\n8. Pour commencer : un MVP en 4 fichiers\r\n\r\nVoici la PWA minimale viable. Quatre fichiers, aucun framework, déployable sur n'importe quel hébergement HTTPS.\r\n\r\nIcônes\r\n\r\nDeux fichiers PNG : (192×192) et (512×512). L'attribut permet à Android de découper l'icône selon la forme système (cercle, squircle, etc.).\r\n\r\nServir le tout en HTTPS (obligatoire en production ; fonctionne en dev). Configuration nginx/Apache : s'assurer que est servi avec le content-type et que n'est jamais mis en cache HTTP côté navigateur (sinon les mises à jour ne se propagent pas).\r\n\r\n\r\n\r\nTester avec Lighthouse (intégré à Chrome DevTools, onglet Lighthouse puis catégorie Progressive Web App) — fournit un score, identifie les manques, propose des corrections.\r\n\r\n9. Outils et frameworks\r\n\r\nWorkbox (Google) — la bibliothèque de référence pour les service workers. Génère du SW à partir de configurations déclaratives, gère les stratégies de cache, le préchargement, la mise à jour. Souvent utilisée via un plugin de bundler.\r\n\r\nVite PWA Plugin () — l'option la plus simple pour un projet moderne basé sur Vite. Wrap Workbox, génère manifest et SW automatiquement.\r\n\r\nNext.js — supporte les PWA via (basé sur Workbox).\r\n\r\nNuxt — officiel.\r\n\r\nAngular, Vue, Svelte — tous disposent d'intégrations PWA officielles ou bien maintenues.\r\n\r\nPWA Builder (Microsoft) — outil web qui audit un site et génère le packaging pour les stores (MSIX pour Microsoft, TWA pour Play Store).\r\n\r\nLighthouse — audit intégré à Chrome DevTools. Standard de fait pour vérifier la conformité PWA.\r\n\r\nCôté PHP (pertinent au regard du contexte de cette doc) — Symfony et Laravel n'ont pas d'extension PWA officielle, mais l'intégration est triviale puisqu'une PWA n'exige côté serveur que de servir correctement quelques fichiers statiques en HTTPS. Bundles comme ne couvrent pas le sujet ; c'est plutôt à l'asset pipeline (Webpack Encore, Vite) de gérer la génération du service worker.\r\n\r\n10. Pièges fréquents et bonnes pratiques\r\n\r\nLe service worker piégé en cache — lui-même ne doit jamais être mis en cache HTTP, sinon les utilisateurs restent bloqués sur une ancienne version. strict côté serveur.\r\n\r\nVersionner le cache — toujours inclure une version dans le nom du cache (, ...) et purger les anciens à l'activation. Sans cela, des assets périmés peuvent persister indéfiniment.\r\n\r\nNe pas tout cacher — précharger uniquement le strict nécessaire au shell de l'application. Le reste doit être mis en cache à la demande, avec une stratégie adaptée.\r\n\r\nTester hors ligne — Chrome DevTools propose un mode Offline dans l'onglet Network. C'est le seul moyen de vérifier que les stratégies de cache fonctionnent.\r\n\r\nGérer la mise à jour — quand un nouveau service worker est détecté, il s'installe mais n'est actif qu'après fermeture de tous les onglets de la PWA. Soit forcer via + (rapide mais peut casser une session en cours), soit afficher à l'utilisateur une bannière « nouvelle version disponible ».\r\n\r\nDétection de feature, jamais détection de navigateur — , . Ne jamais sniffer .\r\n\r\nTester sur iOS réel — l'émulateur Safari ne reproduit pas toutes les limitations. Un iPhone physique est indispensable pour valider l'expérience.\r\n\r\nHTTPS impératif — même en pré-prod. Les certificats Let's Encrypt sont gratuits ; un reverse proxy bien configuré (Caddy, nginx, Traefik) suffit. NB : ce point recoupe directement la configuration habituelle d'un homelab avec reverse proxy.\r\n\r\nManifest et icônes adaptatives — utiliser avec des icônes ayant une zone de sécurité de 10 % autour du contenu, sinon Android va découper dans le visuel.\r\n\r\nPas de prompt d'installation intrusif — Chrome déclenche automatiquement un mini-info-bar quand les critères PWA sont remplis. Si on veut un prompt personnalisé, intercepter l'événement et le déclencher au moment opportun (jamais au premier chargement).\r\n\r\n\r\n\r\n11. Ressources\r\n\r\nDocumentation officielle\r\nweb.dev — section Progressive Web Apps : https://web.dev/explore/progressive-web-apps\r\nMDN Web Docs — Progressive web apps : https://developer.mozilla.org/fr/docs/Web/Progressivewebapps\r\nApple Developer — Sending web push notifications : https://developer.apple.com/documentation/usernotifications/sending-web-push-notifications-in-web-apps-and-browsers\r\nMicrosoft Edge — PWA on Windows : https://learn.microsoft.com/en-us/microsoft-edge/progressive-web-apps-chromium/\r\n\r\nOutils\r\nWorkbox : https://developer.chrome.com/docs/workbox\r\nPWA Builder : https://www.pwabuilder.com/\r\nLighthouse : intégré à Chrome DevTools, ou via CLI \r\n\r\nVeille\r\nWeb Almanac (HTTP Archive) — rapport annuel sur l'état du web, chapitre PWA.\r\nCan I Use : https://caniuse.com/ — compatibilité navigateur pour chaque API.\r\n\r\nÉtudes de cas\r\nweb.dev cases : https://web.dev/case-studies\r\n--\r\n\r\nDocument de référence — état au 13 mai 2026. À revoir tous les 6 à 12 mois, l'écosystème évoluant rapidement (notamment côté Apple).*"},{"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":"32242b73-c564-41b0-892a-ae97b0e1861e","slug":"spf-ou-comment-votre-boite-mail-repere-les-imposteurs","title":"SPF, ou comment votre boîte mail repère les imposteurs","category":"informatique","author":"cedric@abonnel.fr","cover":"cover.svg","published":true,"published_at":"2026-05-18 07:18","created_at":"2026-05-12 11:18:53","updated_at":"2026-05-12 12:58:33","tags":[],"plain":"Vous recevez un mail qui semble venir de votre banque. L'adresse a l'air correcte, le logo est bon, le ton est sérieux. Sauf que ce mail n'a peut-être jamais été envoyé par votre banque. N'importe qui, depuis n'importe quel ordinateur, peut techniquement écrire « De : votre-banque@exemple.fr » en haut d'un mail. C'est ce qu'on appelle l'usurpation d'expéditeur, et c'est à la base de la quasi-totalité des arnaques par mail.\r\n\r\nLe SPF, ou Sender Policy Framework, est l'un des mécanismes inventés pour limiter ce problème. C'est une technologie discrète, invisible à l'utilisateur, mais qui tourne en arrière-plan chaque fois qu'un mail arrive dans votre boîte.\r\n\r\nL'analogie de l'enveloppe et de la liste d'invités\r\n\r\nImaginez que chaque domaine de mail (par exemple ) soit une grande entreprise qui envoie du courrier. Cette entreprise a plusieurs bureaux de poste autorisés : son siège, sa filiale belge, son prestataire de marketing. Tous ces bureaux ont le droit d'envoyer du courrier en son nom.\r\n\r\nLe SPF, c'est tout simplement la liste publique de ces bureaux autorisés, affichée à la vue de tous. L'entreprise publie quelque part : « Le courrier authentique en mon nom ne peut venir que de ces adresses précises. Toute autre origine est suspecte. »\r\n\r\nQuand un mail prétendument envoyé par arrive chez votre fournisseur (Gmail, Orange, Free…), celui-ci fait deux choses :\r\n\r\n1. Il regarde l'adresse IP du serveur qui lui livre le mail.\r\n2. Il consulte la liste SPF publiée par .\r\n\r\nSi l'IP figure sur la liste, le mail est considéré comme légitime de ce point de vue. Sinon, c'est un signal d'alerte.\r\n\r\nPourquoi ça existe\r\n\r\nÀ l'origine d'internet, personne n'avait imaginé que le mail servirait à frauder à grande échelle. Le protocole d'envoi (SMTP) a été conçu avec une confiance totale : on déclare son identité et on est cru sur parole. Aucun mécanisme natif ne vérifie quoi que ce soit.\r\n\r\nLe SPF a été ajouté par-dessus, dans les années 2000, pour combler ce trou. C'est volontairement simple : une liste, une vérification, un verdict. L'idée n'est pas de tout résoudre, mais de filtrer les usurpations les plus grossières — celles où un escroc envoie depuis un serveur quelconque en se faisant passer pour une grande marque.\r\n\r\nCe que le SPF fait, et ce qu'il ne fait pas\r\n\r\nLe SPF vérifie d'où vient le mail, pas ce qu'il contient. Un mail légitime envoyé depuis un serveur autorisé peut très bien contenir une arnaque (cas typique : un compte interne piraté). Inversement, un mail forwardé par un ami passe parfois pour suspect alors qu'il est inoffensif, parce que le serveur de transfert n'est évidemment pas sur la liste du domaine d'origine.\r\n\r\nLe SPF n'agit pas non plus sur le contenu visible. Il regarde une information technique — l'identité du serveur émetteur — que l'utilisateur ne voit jamais. C'est précisément ce qui le rend utile : un escroc peut falsifier le « De : » affiché, mais il ne peut pas falsifier l'adresse IP de la machine qui établit la connexion.\r\n\r\nPour une vraie protection, le SPF est combiné à deux autres mécanismes : DKIM (qui signe cryptographiquement le mail) et DMARC (qui indique au destinataire quoi faire quand SPF ou DKIM échoue). Les trois ensemble forment le socle de l'authentification mail moderne. Aucun n'est suffisant seul.\r\n\r\nCe qui se passe concrètement à la réception\r\n\r\nQuand votre fournisseur reçoit un mail, la vérification SPF aboutit à l'un de ces verdicts : autorisé, refusé, douteux, ou indéterminé. Selon le résultat, le mail peut être livré normalement, placé en spam, ou rejeté avant même d'arriver dans votre boîte.\r\n\r\nVous ne voyez jamais cette décision. Elle est inscrite dans les en-têtes techniques du mail, consultables si on creuse, mais transparente pour l'usage quotidien. C'est précisément le but : une protection silencieuse qui élimine une partie du bruit avant qu'il ne vous atteigne.\r\n\r\nEt pour les expéditeurs ?\r\n\r\nSi vous gérez un site, une newsletter, ou même simplement une adresse mail professionnelle sur votre propre domaine, configurer correctement le SPF est devenu indispensable. Sans SPF, vos mails légitimes ont de plus en plus de chances d'être marqués comme suspects par les grands fournisseurs. Avec un SPF bien réglé, vous dites au monde entier : « voici exactement qui a le droit d'écrire en mon nom », et le reste devient automatiquement reconnaissable comme une usurpation.\r\n\r\nC'est un de ces réglages qu'on fait une fois, qu'on oublie ensuite, mais qui décide silencieusement chaque jour du sort de millions de mails."},{"uuid":"bea327e2-9d1c-4ff6-a5a5-26748c80018b","slug":"anatomie-d-un-script-d-auto-deploiement-bash-fetch-scripts-sh","title":"Script Bash d'auto-déploiement : `fetch_scripts.sh`","category":"informatique","author":"cedric@abonnel.fr","cover":"cover.svg","published":true,"published_at":"2026-05-04 07:04","created_at":"2026-05-12 10:55:39","updated_at":"2026-05-12 11:10:51","tags":[],"plain":"Comment un simple script Bash peut télécharger, mettre à jour et synchroniser une bibliothèque de scripts distants — et pourquoi il faut le lire avec un œil critique.\r\n\r\nfetchscripts.sh\r\n📝 Note — Cet article est une autocritique. Le script analysé ici est de ma propre fabrication, déployé sur mes propres machines. L'exercice consiste à le relire avec la distance d'un reviewer extérieur, pour identifier ce qui tient la route et ce qui mériterait d'être repris.\r\n\r\nLe contexte\r\n\r\nL'idée derrière ce script est élégante : centraliser une collection de scripts utilitaires dans un dépôt Git public (ici, une instance Forgejo auto-hébergée), puis fournir un unique point d'entrée que l'on télécharge sur n'importe quelle machine. Ce point d'entrée se met à jour tout seul, propose à l'opérateur de choisir quels sous-ensembles de scripts récupérer, et maintient une synchronisation locale du dépôt distant.\r\n\r\nC'est typiquement le genre d'outil qui se déploie en une ligne :\r\n\r\n\r\n\r\nDécortiquons ce qu'il fait, étape par étape, puis voyons où il faudrait taper.\r\n--\r\n\r\nÉtape 1 — L'auto-mise à jour\r\n\r\n\r\n\r\nCe qui se passe : le script télécharge sa propre version distante dans , la compare octet-à-octet avec lui-même (), et si elle diffère, il s'écrase, se rend exécutable, et se relance via (qui remplace le processus courant — pas d'empilement de shells).\r\n\r\nPourquoi c'est malin : ça garantit qu'à chaque exécution, l'opérateur travaille avec la version canonique du dépôt. Pas besoin de mécanisme de versioning, pas de vérification de hash, pas de paquet à publier.\r\n\r\nPourquoi c'est risqué : on y reviendra dans la critique, mais en résumé — l'auto-mise à jour silencieuse depuis une URL en HTTPS sans signature est une porte d'entrée pour la chaîne d'approvisionnement.\r\n--\r\n\r\nÉtape 2 — Récupération du catalogue de dossiers\r\n\r\n\r\n\r\nLe dépôt distant contient un fichier qui liste les catégories de scripts disponibles (par exemple : , , , …). Ce fichier est la source de vérité : ajouter une catégorie côté serveur la rend immédiatement disponible côté client.\r\n\r\n (alias ) lit le fichier ligne à ligne dans un tableau Bash. Plus propre qu'une boucle .\r\n\r\nUn dossier est marqué comme obligatoire — il sera toujours téléchargé, sans demander à l'utilisateur.\r\n--\r\n\r\nÉtape 3 — Mémoire de la sélection précédente\r\n\r\n\r\n\r\nÀ chaque exécution, le script relit la sélection de la fois précédente. C'est ce qui permet à l'interface graphique (étape suivante) de pré-cocher les bons dossiers : on n'a pas à refaire son choix à chaque mise à jour.\r\n--\r\n\r\nÉtape 4 — L'interface \r\n\r\n\r\n\r\n est l'outil de dialogue ncurses standard sur Debian/Ubuntu — il affiche cette boîte bleue familière avec des cases à cocher, navigable au clavier. Idéal en SSH.\r\n\r\nLa gymnastique est un classique : écrit son interface sur stdout et sa réponse sur stderr. Il faut donc échanger les deux pour capturer la sélection dans tout en laissant l'interface s'afficher.\r\n\r\nL'expression est une astuce courante pour tester l'appartenance à un tableau Bash — on entoure d'espaces pour éviter les correspondances partielles ( qui matcherait ).\r\n--\r\n\r\nÉtape 5 — Synchronisation : ajouts et suppressions\r\n\r\n\r\n\r\nLogique de diff : tout ce qui était sélectionné avant et ne l'est plus est supprimé du disque. Ça maintient le répertoire local propre — pas de scripts orphelins qui traînent.\r\n\r\n renvoie la sélection sous forme de chaîne entre guillemets (), d'où le pour les retirer avant de constituer le tableau.\r\n--\r\n\r\nÉtape 6 — Téléchargement des fichiers de chaque dossier\r\n\r\n\r\n\r\nMême logique récursive d'un niveau plus bas : chaque dossier contient son propre listant ses fichiers. On télécharge ceux qui y figurent, on supprime ceux qui n'y figurent plus, et on rend tout exécutable.\r\n\r\nC'est une forme de artisanal, basé sur des manifestes plats. Ça fonctionne sans avoir à installer sur la machine cible — seuls et sont requis.\r\n--\r\n\r\nCritique : ce qui marche, ce qui inquiète\r\n\r\nLes bons côtés\r\n\r\nLa logique d'idempotence est solide. Le script peut tourner cent fois de suite, il convergera toujours vers le même état : les dossiers sélectionnés contiendront exactement les fichiers du manifeste, ni plus, ni moins. C'est le bon réflexe DevOps.\r\n\r\nL'auto-bootstrap est ergonomique. Une seule URL à retenir, tout le reste se télécharge tout seul. Pour une bibliothèque personnelle de scripts d'admin, c'est imbattable en simplicité.\r\n\r\nPas de dépendances exotiques. , , : tout est disponible nativement sur Debian. Le script tourne aussi bien sur un conteneur LXC fraîchement provisionné que sur une machine établie.\r\n\r\nLe manifeste séparé ( et ) découple la liste des fichiers de leur contenu. C'est plus simple qu'un parsing HTML de l'index Git, et ça reste sous contrôle éditorial.\r\n\r\nLes angles morts\r\n\r\n1. Aucune vérification d'intégrité\r\n\r\nC'est le point critique. Le script télécharge du code exécutable en HTTPS, sans vérifier :\r\nni signature GPG,\r\nni hash SHA256,\r\nni même que le serveur a bien répondu correctement.\r\n\r\n en mode silencieux n'échoue pas visiblement : si la requête renvoie une page d'erreur 404 ou une page de connexion captive Wi-Fi en HTML, elle sera écrite dans le fichier de destination. La vérification suivante () considérera ce HTML comme « différent », fera le , et au prochain le shell essaiera d'exécuter du HTML. Au mieux ça crashe, au pire ça exécute des balises interprétables.\r\n\r\nPire encore pour l'auto-update : si quelqu'un compromet l'instance Forgejo (ou interpose un proxy malveillant capable de servir un certificat valide pour ), le prochain télécharge et exécute du code arbitraire avec les privilèges de l'utilisateur courant — souvent root pour ce genre d'outils d'admin.\r\n\r\nCorrectif minimal : publier un fichier signé GPG dans le dépôt, le télécharger, vérifier sa signature avec une clé connue localement, puis valider chaque fichier téléchargé contre ce manifeste.\r\n\r\n2. sans gestion d'erreur\r\n\r\n\r\n\r\nSi échoue (réseau coupé, DNS HS, certificat expiré), sera soit vide soit absent. retournera « différent », et le script écrasera la version locale par un fichier vide. À la prochaine exécution, plus rien ne fonctionne.\r\n\r\nCorrectif : vérifier le code de retour de , vérifier que le fichier téléchargé n'est pas vide, et vérifier qu'il commence bien par avant d'écraser quoi que ce soit.\r\n\r\n\r\n\r\n3. Le perd les modifications de l'environnement\r\n\r\nSi le script a été lancé par (donc sans le bit exécutable, sans shebang utilisé), vaut . Après , on un fichier qui pourrait ne pas être dans le . En pratique ça marche parce qu'on est dans le bon répertoire, mais c'est fragile — un quelque part dans le script suffirait à le casser.\r\n\r\n4. Injection via les noms de fichiers du manifeste\r\n\r\n\r\n\r\nLe contenu de est utilisé directement dans une URL et dans un chemin de fichier local. Si quelqu'un peut écrire dans ce fichier manifeste (ce qui revient à pouvoir pousser sur le dépôt Forgejo), il peut y mettre des chemins comme et écrire en dehors du répertoire prévu.\r\n\r\n neutralise partiellement la chose côté nom local, mais l'URL côté distant accepte n'importe quoi. C'est moins critique que la première faille, mais ça mérite un filtre regex ( uniquement).\r\n\r\n5. et la sélection vide\r\n\r\nSi l'utilisateur ne coche rien et valide, est vide. Le script continue avec seulement , ce qui est probablement le comportement attendu. Mais si n'est pas installé (rare mais possible, par exemple sur Alpine ou un Debian minimal sans ), le script échoue avec une erreur peu explicite. Un test préalable éviterait la déconvenue.\r\n\r\n6. Pas de log, pas de mode dry-run\r\n\r\nPour un outil qui supprime des fichiers (), l'absence d'option qui afficherait ce qui serait fait sans rien toucher est gênante. Une frappe distraite sur la checklist, et un dossier entier disparaît sans warning.\r\n\r\n7. Le verrou manquant\r\n\r\nRien n'empêche deux instances de de tourner en parallèle (par exemple via et un opérateur en interactif). Un sur un fichier de lock éviterait des courses sur les opérations de download/delete.\r\n--\r\n\r\nVerdict\r\n\r\nC'est un script utile, lisible, et bien construit pour un usage personnel sur des machines de confiance. La logique de synchronisation est saine, l'ergonomie est appréciable, l'auto-bootstrap est élégant.\r\n\r\nMais dès qu'on franchit la frontière du « j'utilise ça sur mes propres machines avec mon propre dépôt », les manques se font sentir : pas de vérification d'intégrité, pas de gestion d'erreur réseau, pas d'option de récupération. Dans un contexte d'équipe ou de production, ces points sont bloquants.\r\n\r\nPistes d'évolution prioritaires\r\n\r\n1. Signature ou checksum : publier un signé GPG, le vérifier avant tout ou exécution.\r\n2. en tête de script pour faire échouer proprement à la première erreur.\r\n3. Vérifier : code de retour, fichier non vide, shebang présent.\r\n4. Backup avant écrasement : conserver la version précédente () pour pouvoir revenir en arrière.\r\n5. Option pour visualiser sans appliquer.\r\n6. Filtre regex sur les noms de fichiers du manifeste pour éviter les traversées de chemin.\r\n7. Lock file** via pour éviter les exécutions concurrentes.\r\n\r\nAvec ces ajouts, on passe d'un script « pratique » à un outil de déploiement digne de ce nom — sans rien perdre de sa simplicité initiale."},{"uuid":"7cf4eff3-2bab-4f2e-8982-247c89f7ca16","slug":"installer-webmin-l-outil-d-administration-en-mode-web","title":"Mettre en place un serveur Debian administrable avec Webmin","category":"linux","author":"cedric@abonnel.fr","cover":"cover.svg","published":true,"published_at":"2025-11-13 11:57","created_at":"2025-11-13 11:57:05","updated_at":"2026-05-12 10:48:26","tags":[],"plain":"Quand on monte un nouveau serveur, les premières heures sont toujours les mêmes : on durcit la machine, on crée un utilisateur correct, on coupe ce qui traîne, et on met en place de quoi l'administrer sans avoir à ouvrir un terminal pour chaque détail. Cet article décrit la procédure que j'utilise sur mes Debian fraîches : préparation via mes scripts, installation de Webmin, et activation de pour ne laisser passer que ce qui doit l'être. L'idée n'est pas de transformer le serveur en sapin de Noël, mais d'avoir une base saine sur laquelle bâtir, qu'il s'agisse d'expérimenter dans un LXC ou de préparer une VM destinée à recevoir une vraie charge. Étape 1 — Préparer la machine Sur une Debian neuve, on commence par récupérer un petit script qui en télécharge d'autres. C'est juste un point d'entrée : il va chercher dans mon dépôt Forgejo un ensemble de scripts d'initialisation que je maintiens à jour. À ce stade, un dossier apparaît à côté du script. C'est là que se trouve le vrai travail : fait ce qu'on a tous fini par écrire un jour : mise à jour des paquets, installation des outils de base, création d'un utilisateur non-root avec les bons droits sudo, durcissement minimal de SSH. Rien de magique, mais c'est répétable et c'est ce qui compte quand on provisionne souvent. Important : une fois le script terminé, il faut se déconnecter de la session et se reconnecter avec l'utilisateur que le script vient de créer. Tout ce qui suit se fait avec cet utilisateur, en passant par quand nécessaire. Continuer en root est une mauvaise habitude qui finit toujours par se payer. Étape 2 — Installer Webmin Webmin est une interface web d'administration système. Pour quelqu'un qui débute, c'est une porte d'entrée appréciable : on voit les services qui tournent, les utilisateurs, les paquets installés, les logs, le tout depuis un navigateur. Pour quelqu'un d'expérimenté, c'est un complément pratique quand on veut donner un accès limité à un collègue moins à l'aise en ligne de commande. Webmin fournit son propre script pour configurer le dépôt apt : Ce script ajoute le dépôt officiel Webmin à la liste des sources apt et importe la clé GPG associée. Une fois fait, l'installation devient une commande apt classique : Petite précision sur les deux paquets : Webmin sert à l'administration système (root ou utilisateur sudo), Usermin est sa version pour les utilisateurs standards, qui leur permet de gérer leur propre compte, leurs mails, leurs fichiers, sans toucher au système. Sur une machine mono-utilisateur, on peut se passer d'Usermin, mais l'installer maintenant coûte trois mégaoctets et évite d'y revenir plus tard. Étape 3 — Se connecter à l'interface Webmin écoute par défaut sur le port 10000 en HTTPS. Depuis un navigateur : est à remplacer par l'adresse de la machine. Le navigateur va râler à propos du certificat — c'est normal, Webmin génère un certificat auto-signé à l'installation. On peut accepter l'avertissement pour l'instant ; si la machine est destinée à un usage durable, on remplacera ça plus tard par un vrai certificat (Let's Encrypt via un reverse proxy, par exemple). Pour la connexion, on utilise les identifiants Linux de l'utilisateur sudo, pas un compte spécifique à Webmin. C'est l'utilisateur que a créé à l'étape 1. Webmin s'appuie sur PAM, donc tout compte système autorisé à se connecter peut potentiellement entrer — d'où l'importance de l'étape suivante. Étape 4 — Activer le pare-feu Une machine accessible sur internet sans pare-feu, c'est une question de temps avant les premiers ennuis. Sur Debian, je préfère à ou à la configuration brute de : la notion de zones est pratique, la syntaxe se retient, et l'intégration avec Webmin est correcte. Installation et activation : rend le service persistant au redémarrage, le lance immédiatement. Vérification : Le retour attendu est . Si c'est autre chose, permet de comprendre ce qui coince — c'est souvent un conflit avec un autre service de filtrage déjà en place. À ce stade, le pare-feu tourne mais avec une configuration par défaut qui, selon la zone active, peut bloquer Webmin. Il faut donc explicitement autoriser le port 10000 : Le écrit la règle dans la configuration ; sans ça, elle disparaît au prochain redémarrage. Le recharge la configuration pour que la règle prenne effet immédiatement. C'est l'erreur classique : on ajoute une règle, on continue à ne pas pouvoir se connecter, on perd dix minutes avant de se rappeler du . Pour aller plus loin Une fois cette base en place, plusieurs directions s'offrent selon le rôle de la machine. Si elle est destinée à héberger un service web public, l'étape logique suivante consiste à placer Webmin derrière un reverse proxy plutôt que de l'exposer directement sur le port 10000. Le port 10000 est alors fermé vers l'extérieur, et l'interface devient accessible via un sous-domaine en HTTPS avec un vrai certificat. C'est plus propre, plus sûr, et ça évite l'avertissement de certificat à chaque connexion. Si la machine est un serveur d'applications, autant profiter du fait que est en place pour réfléchir aux ports en amont. Mieux vaut décider tout de suite quelles applications écoutent où, plutôt que d'empiler les au fil de l'eau et de finir avec une configuration que plus personne ne comprend. Et dans tous les cas, garder une trace écrite des choix faits : quels ports ouverts, quel utilisateur sudo, quelle convention de nommage. Un fichier à la racine du home de l'admin, peu importe le support — l'important c'est que dans six mois, on puisse retrouver le fil sans avoir à tout rétro-ingénierer."}] |