Cédrix
1 line
38 KiB
JSON
1 line
38 KiB
JSON
[{"uuid":"ce662705-eb9b-47b1-90f3-19e3c3633ed0","slug":"tar","title":"tar","category":"Informatique","author":"cedric@abonnel.fr","cover":"","published":true,"published_at":"2023-02-06 17:14:54","created_at":"2023-02-06 17:14:54","updated_at":"2023-02-06 17:14:54","tags":[],"plain":"--\nComparaison des résultats des archives\nLes archives tar ont une taille différentes suivant les options de compression utilisée. Par exemple, un dossier html contenant des fichiers HTML, CSS et JS :\narchive | taille (octets) |\n------- | --------------- |\ntar | 40960 |\ntar.gz | 6200 |\ntar.bz2 | 6003 |\ntar.xz | 5656 | Voyons les commandes et options possibles. tar sous Liunx : compresser et décompresser\nPour <u>créer une archive</u> tar <u>d'un ou plusieurs fichiers</u>, on utilise la syntaxe tar cvf archive.tar fichier1 fichier2...\n- Pour <u>créer une archive</u> tar <u>d'un dossier</u>, on utilise la syntaxe\n tar cvf archive.tar dossier/\n \nLe chemin complet de dossier sera copié dans l'archive. Attention à la décompression.\n- Pour <u>extraire les fichiers d'une archive</u> tar, on utilise la syntaxe \n tar xvf archivedossier.tar\n- Pour <u>afficher le contenu d'une archive</u>, on utilise la syntaxe tar tvf archivedossier.tar tar.gz sous Liunx : compresser et décompresser\nLa manipulation des archives tar.gz s'effectue systématiquement avec l'option z.\n- Pour <u>créer une archive</u> compressée tar.gz <u>d'un ou plusieurs fichiers</u>, on utilise la syntaxe avec l'option c\n tar zcvf archive.tar.gz fichier1 fichier2... Pour <u>créer une archive</u> compressées tar.gz <u>d'un dossier</u>, on utilise la syntaxe la même syntaxe\n tar zcvf archive.tar.gz dossier/\n- Pour <u>créer une archive</u> compressée tar.gz d'un ou plusieurs fichiers sans les informations de l'owner et du groupe renseignée, on utilise la syntaxe suivante : tar zcvf archive.tar.gz . --owner=0 --group=0\n \nIl faudra veiller à laisser des instructions pour attribuer des droits.\n- Pour <u>extraire les fichiers</u> d'une archive compressée tar.gz, on utilise la syntaxe avec l'option x\n tar zxvf archivedossier.tar.gz\n- Pour <u>afficher le contenu</u> d'une archive, on utilise la syntaxe avec l'option t tar ztvf archivedossier.tar.gz\n- Pour <u>supprimer un fichier</u> dans l'archive, on utilise la syntaxe avec l'option delete tar zvf archivedossier.tar.gz --delete your/path/to/delete\n \n \n \n \ntar.xz sous Liunx : compresser et décompresser\nPour <u>créer une archive</u> compressée tar.xz <u>d'un ou plusieurs fichiers</u>, on utilise la syntaxe\n tar Jcvf archive.tar.xz fichier1 fichier2...\n- Pour <u>créer une archive</u> compressées tar.xz <u>d'un dossier</u>, on utilise la syntaxe\n tar Jcvf archive.tar.xz dossier/\n- Pour <u>extraire les fichiers</u> d'une archive compressée tar.xz, on utilise la syntaxe\n tar Jxvf archivedossier.tar.xz\n tar.bz2 sous Liunx : compresser et décompresser\nPour <u>créer une archive</u> compressée tar.bz2 <u>d'un ou plusieurs fichiers</u>, on utilise la syntaxe \n- Pour <u>créer une archive</u> compressées tar.bz2 <u>d'un dossier</u>, on utilise la syntaxe \n- Pour <u>afficher le contenu</u> tar.bz2 d'une archive, on utilise la syntaxe tar tvf archive.tar.bz2 '.txt'\n-- Pour <u>extraire les fichiers</u> d'une archive compressée tar.bz2**, on utilise la syntaxe\n tar Jxvf archivedossier.tar.bz2"},{"uuid":"1509db76-2a49-4196-84bb-e8fa40479404","slug":"marque-ta-page","title":"Marque ta page","category":"Informatique","author":"cedric@abonnel.fr","cover":"","published":true,"published_at":"2020-04-17 18:05:21","created_at":"2020-04-17 18:05:21","updated_at":"2020-04-17 18:05:21","tags":[],"plain":"Replay\nCanal Plus\nLe Petit Journal\nLe Zapping France 2\nOn n'demande qu'en rire\nFrance 5\nOn n'est pas que des cobayes ! TF1\nC'est Canteloup M6\nEnquête d'action D8\nTouche pas à mon poste\nEn quête d'actualité Jeux en ligne\nBombermine Magazine / Hebdo\nAu menu des cantines de Grenoble\nLes nouvelles de Grenoble\nIsère magazine Musique\nLes Charts : Les n°1 depuis 1984 à aujourd'hui.\nTOP France : 40 ans de tubes\nLes classements SNEP/IFPOP : Les TOP 50 matériel et numérique\nVj & Dj Magrao : 1 heure de mix non stop en video SSII\nDEUZZI Conversion\nUnix Time - + d'infos Banque\nBanque Populaire Loire et Lyonnais Mathématiques appliquées\nExpressions régulières\nTester une expression régulière en JavaScript - regexPal Commerce\nLidl\nSuivi des offres LIDL\nManuels des produits en offres ponctuelles\nOutils Informatiques\nParted Magic 2012\nUltimate Boot CD\n<http:*www.commentcamarche.net/faq/21013-windows-creer-une-cle-usb-d-installation#methode-4-windows-xp>"},{"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":"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":"1363f454-ca59-4264-a8f0-a2446d645ebc","slug":"installation-et-mise-en-service-d-une-borne-de-recharge-murale-goneo-7-4-kw","title":"Installation et mise en service d'une borne de recharge murale GONEO 7,4 kW","category":"","author":"cedric@abonnel.fr","cover":"cover.jpg","published":true,"published_at":"2026-05-13 11:04","created_at":"2026-05-13 11:23:38","updated_at":"2026-05-13 15:17:04","tags":{"logiciels":["Home Assistant"]},"plain":"Une borne de recharge murale GONEO a été récemment acquise (référence Amazon B0FP288GM7). Il s'agit d'une wallbox monophasée 7,4 kW (32 A, 230 V), équipée d'un connecteur Type 2, d'un lecteur RFID, et pilotable via Wi-Fi, Bluetooth. La gamme constructeur est documentée sur le site officiel GONEO Global et son catalogue EV Charger sur it.goneoglobal.com.\r\n\r\nCaractéristiques techniques\r\n\r\nD'après les fiches constructeur et revendeurs, le modèle présente les caractéristiques suivantes :\r\nPuissance : jusqu'à 7 kW en monophasé (annoncée 7,4 kW selon le réglage de courant)\r\nCourant réglable : 8 A à 32 A\r\nTension : 230 V monophasé\r\nConnecteur : Type 2 (IEC 62196-2)\r\nProtection : IP65, IK10, ignifuge UL94 V-0, plage -30 °C à +55 °C\r\nDétection de défaut intégrée : protection de fuite Type A 30 mA + DC 6 mA\r\nConnectivité : Wi-Fi, Bluetooth, compatible OCPP et Home Assistant\r\nApplication : Goneo EV Charger (Android / iOS)\r\n\r\nCâblage et raccordement\r\n\r\nLe câble d'alimentation a été tiré soi-même, en s'appuyant sur les règles de dimensionnement détaillées dans cet article. La section retenue est conforme aux préconisations constructeur : câble 3G6 mm² pour un courant maximum de 32 A, avec en amont un disjoncteur 40 A et un interrupteur différentiel type A 40 A.\r\n\r\nUn soin particulier a été apporté au serrage des borniers : un serrage insuffisant entraîne une résistance de contact accrue, source d'échauffement et de chute de tension sous charge — risque non négligeable compte tenu des intensités mises en jeu (jusqu'à 32 A en continu pendant plusieurs heures).\r\n\r\nVérifications avant mise sous tension\r\n\r\nUne fois le raccordement effectué, les mesures suivantes ont été réalisées au multimètre :\r\nPhase – Neutre : 230 V (tension nominale du réseau)\r\nPhase – Terre : 230 V (confirme la continuité de la phase et de la terre)\r\nNeutre – Terre : 0 V (idéalement quelques volts maximum ; une valeur significative trahirait un défaut de neutre ou de mise à la terre)\r\n\r\nÀ noter : la protection différentielle intégrée à la borne couvre la composante DC (6 mA), ce qui permet en théorie de se contenter d'un différentiel type A en amont — là où une borne sans détection DC interne exigerait un type B beaucoup plus onéreux. La vérification de la valeur de la prise de terre au telluromètre et le test du déclenchement du différentiel restent recommandés.\r\n\r\nMise en service\r\n\r\nLa mise en service s'effectue via le Wi-Fi de l'appareil et l'application propriétaire Goneo EV Charger. Points à anticiper :\r\nTélécharger l'application avant de commencer la procédure.\r\nCréer un compte utilisateur.\r\nS'assurer que le téléphone est connecté à un réseau Wi-Fi 2,4 GHz et que le Bluetooth est activé ; la borne doit être à portée du signal Wi-Fi.\r\nAssocier la borne au compte (un appui court sur le bouton règle l'alimentation, un double appui lance la configuration Wi-Fi).\r\n\r\nLa borne ayant été achetée d'occasion, elle n'avait pas été dissociée du compte du précédent propriétaire — situation fréquente sur ce type d'achat. Un message au SAV par mail (info@goneoglobal.com) a suffi : la réponse a été rapide et la dissociation effectuée sans difficulté. Réflexe à prendre lors d'un achat d'occasion : demander au vendeur de procéder à la dissociation avant l'expédition.\r\n\r\nUsage au quotidien\r\n\r\nDeux modes d'utilisation cohabitent :\r\nProfil horaire programmé via l'application : pratique pour caler les sessions sur les heures creuses.\r\nBadge RFID** fourni avec la borne : démarrer ou arrêter une session par simple présentation du badge, sans passer par l'application.\r\n--\r\n\r\nÀ noter sur le plan réglementaire : depuis 2017, l'installation d'une borne de recharge d'une puissance supérieure à 3,7 kW à domicile relève en principe d'un électricien qualifié IRVE. Le fait de procéder soi-même au tirage du câble et au raccordement reste possible techniquement, mais sort du cadre permettant de prétendre aux aides publiques (crédit d'impôt, prime ADVENIR) et peut avoir des conséquences en matière d'assurance."}] |