Cédrix
1 line
29 KiB
JSON
1 line
29 KiB
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":"70b5f213-db76-4072-afb6-f876fe67aaf8","slug":"non-le-compteur-linky-ne-reconnait-pas-les-voitures-electriques","title":"Non, le compteur Linky n'est pas conçu pour repérer votre voiture électrique","category":"actualité","author":"cedric@abonnel.fr","cover":"cover.jpg","published":true,"published_at":"2025-12-06 06:36","created_at":"2025-12-06 06:36:25","updated_at":"2026-05-12 01:32:46","tags":[],"plain":"Démêlons le vrai du faux sur une affirmation qui revient régulièrement dans les débats autour de la fiscalité des véhicules à batterie.\r\n\r\nDepuis plusieurs mois, à mesure que s'intensifient les discussions sur une éventuelle taxe kilométrique visant les voitures électriques, une affirmation refait surface avec insistance sur les réseaux sociaux et dans certains articles : « Le compteur Linky a été conçu pour reconnaître la connexion d'une voiture à batterie. » La formule est efficace, presque inquiétante, et elle nourrit l'idée d'un État qui aurait anticipé depuis longtemps la surveillance des automobilistes électriques via leur compteur domestique.\r\n\r\nLe problème, c'est que cette affirmation est tout simplement fausse. Ou plus exactement : elle confond grossièrement ce que Linky mesure réellement et ce qu'on lui prête comme capacités. Pour comprendre pourquoi, il faut revenir aux fondamentaux de ce qu'est un compteur électrique, même \"intelligent\".\r\n\r\nCe que Linky mesure réellement\r\n\r\nUn compteur Linky, c'est avant tout un instrument de mesure. Il enregistre la consommation électrique globale du logement, en temps quasi réel, avec une précision bien supérieure à celle des anciens compteurs électromécaniques. Concrètement, il relève la puissance instantanée appelée par l'ensemble de l'installation, l'intensité du courant qui circule sur les phases, ainsi que quelques paramètres plus techniques comme les harmoniques — des perturbations du signal qui renseignent sur la qualité du courant.\r\n\r\nTout cela est agrégé. Linky voit un total, pas une ventilation appareil par appareil. Quand votre four à 3 kW se met en route, le compteur enregistre une montée de 3 kW. Quand une wallbox commence à charger une voiture à 3,7 kW, il enregistre une montée de 3,7 kW. Du point de vue de Linky, ces deux événements sont parfaitement indiscernables. Il n'a aucun moyen de savoir si l'électricité part vers une plaque de cuisson, un chauffe-eau, un radiateur ou une Tesla branchée au garage.\r\n\r\nC'est une limitation fondamentale, pas un oubli de conception : un compteur de tableau électrique se situe en amont de tout, sur l'arrivée générale. Il voit ce qui entre dans la maison, point final.\r\n\r\nCe que Linky ne sait pas faire — et ne saura jamais faire en l'état\r\n\r\nContrairement à ce que certains articles laissent entendre, Linky n'a aucune capacité à identifier la nature des appareils qui se branchent. Il ne reconnaît pas une voiture électrique, ne lit pas les protocoles de communication entre une borne et un véhicule (Type 2, CCS, CHAdeMO), ne dialogue ni avec le chargeur embarqué ni avec le BMS — le système de gestion de batterie qui pilote la charge côté voiture. Aucune de ces fonctions ne figure dans ses spécifications techniques, qui sont publiques et consultables.\r\n\r\nLinky n'est ni une prise connectée capable de profiler ce qui s'y branche, ni un analyseur de charge avancé, ni un dispositif de reconnaissance d'appareils par signature. C'est un compteur de facturation, conçu pour relever votre consommation à distance et permettre à votre fournisseur d'affiner les offres tarifaires (heures creuses dynamiques, par exemple). Tout le reste relève du fantasme ou de la confusion.\r\n\r\nD'où vient cette idée alors ?\r\n\r\nLa rumeur n'est pas née de nulle part. Elle s'enracine dans deux éléments réels, mais largement mal interprétés.\r\n\r\nLe premier, c'est l'existence de la TIC, la « télé-information client ». Il s'agit d'une interface physique présente sur le compteur Linky, qui diffuse en continu certaines données : puissance souscrite, puissance instantanée appelée, index de consommation, période tarifaire en cours. Cette interface est sortante : elle envoie des informations vers l'extérieur, vers des appareils domestiques compatibles, mais elle ne reçoit rien en retour.\r\n\r\nCertaines wallbox modernes sont capables de se brancher sur cette TIC pour lire en direct la puissance déjà consommée dans le logement. Elles ajustent alors automatiquement la puissance de charge de la voiture pour ne pas faire disjoncter l'installation : si quelqu'un allume le four pendant que la voiture charge, la borne réduit son appel de courant. C'est une fonction très utile, mais elle fonctionne dans un seul sens. La wallbox lit Linky. Linky ne lit pas la wallbox, et encore moins la voiture. Beaucoup de gens, en entendant parler de wallbox \"communiquant avec Linky\", imaginent un dialogue bidirectionnel qui n'existe pas.\r\n\r\nLe second élément, c'est l'arrivée du débat sur une taxe kilométrique. Avec la baisse des recettes de TICPE liée à l'électrification du parc automobile, plusieurs think tanks et rapports parlementaires ont effectivement évoqué l'idée de taxer les kilomètres parcourus en VE, et certains ont mentionné Linky parmi les outils techniques envisageables. De cette spéculation prospective, une partie du public a tiré la conclusion que le compteur était déjà équipé pour le faire. Or il y a un gouffre entre « on pourrait peut-être un jour utiliser Linky comme brique d'un dispositif fiscal » et « Linky a été conçu pour ça ». Le premier est une hypothèse politique discutable ; le second est un raccourci qui ne correspond à aucune réalité technique.\r\n\r\nEt techniquement, ce serait possible un jour ?\r\n\r\nC'est la question intéressante, et la réponse mérite plus de nuance qu'un simple oui ou non.\r\n\r\nIl existe effectivement un champ de recherche actif, baptisé NILM pour Non-Intrusive Load Monitoring. L'idée : analyser la courbe de consommation globale d'un logement pour en déduire, par traitement du signal et apprentissage automatique, quels appareils s'y trouvent et quand ils fonctionnent. Chaque appareil aurait, en théorie, une \"signature électrique\" reconnaissable — un profil d'appel de courant au démarrage, un comportement en régime, etc.\r\n\r\nEn pratique, l'exercice est très difficile, et il l'est particulièrement pour la recharge d'un véhicule électrique. Une borne en charge se comporte comme une charge quasi constante de plusieurs kilowatts pendant plusieurs heures. C'est une signature… qui ressemble énormément à celle d'un chauffe-eau, d'un convecteur, d'un sèche-linge en cycle long ou d'un radiateur à inertie. Sans cadence de fonctionnement caractéristique, sans pics distinctifs, sans cycles courts, il n'y a rien de très spécifique à exploiter. Identifier de manière fiable qu'on a affaire à une voiture et pas à un autre appareil de puissance similaire reste un problème ouvert dans la littérature scientifique.\r\n\r\nMais surtout, et c'est le point essentiel : Linky n'embarque aucun de ces algorithmes. Il transmet des données de comptage agrégées à Enedis, qui les utilise pour la facturation et la gestion du réseau. Enedis n'a ni la mission, ni le droit légal, ni l'infrastructure pour analyser appareil par appareil les usages domestiques de ses clients. Le cadre réglementaire français, notamment via la CNIL, encadre strictement ce qui peut être fait des données de consommation, et toute exploitation plus fine — même la courbe de charge à pas fin — nécessite le consentement explicite de l'abonné.\r\n\r\nCe qu'il faut retenir\r\n\r\nLe compteur Linky mesure votre consommation globale, c'est vrai. Il permet à certaines bornes de recharge de moduler intelligemment leur puissance via la TIC, c'est vrai aussi. Mais il ne reconnaît pas, n'identifie pas et ne distingue pas une voiture électrique des autres appareils du logement. Cette capacité n'existe ni dans son matériel, ni dans son logiciel, ni dans les données qu'il transmet à Enedis.\r\n\r\nL'affirmation selon laquelle « Linky a été conçu pour reconnaître la connexion d'une voiture à batterie » mélange donc trois choses très différentes : des capacités réelles mais limitées (mesure de puissance, interface TIC sortante), des usages techniques existants côté wallbox, et des hypothèses politiques sur de futurs dispositifs fiscaux. De cette confusion naît une rumeur frappante, mais infondée.\r\n\r\nLe débat sur la fiscalité des véhicules électriques est légitime et important. Il mérite mieux que des affirmations qui n'ont pas de base technique."},{"uuid":"186f0911-bb49-41ca-9ace-99b08157995a","slug":"reflets-info","title":"reflets.info","category":"Informatique","author":"cedric@abonnel.fr","cover":"","published":true,"published_at":"2023-03-04 23:27:55","created_at":"2023-03-04 23:27:55","updated_at":"2023-03-04 23:27:55","tags":[],"plain":"- https:reflets.info/ Voir aussi la page <https:fr.wikipedia.org/wiki/Reflets.info> C'est un site web francophone de nouvelles et d'analyse axé sur la technologie, la sécurité informatique, la vie privée, la politique et les libertés numériques. Le site est connu pour son point de vue critique sur les questions de surveillance en ligne, de vie privée et de droits numériques."},{"uuid":"da8225be-1b25-4d02-9765-a576fc89c543","slug":"lithium-battery-charger-2s-a1","title":"Module de chargeur de batterie Li-ion","category":"Électronique","author":"cedric@abonnel.fr","cover":"","published":true,"published_at":"2022-08-24 05:23:05","created_at":"2022-08-24 05:23:05","updated_at":"2022-08-24 05:23:05","tags":[],"plain":"Description\nChargeur de 2 batteries Lithium-Ion (Li-Ion) de 7.4V (2 x 3.7V) au format 18650. Interface d'entrée prise USB-C Caractéristiques\nCourant d'entrée : 1A Tension d'entrée : DC de 3.7V à 5V (tolérance de 3V à 6V) Courant de charge : 0.55A (0.40A si tension d'entrée à 3.7V) Tension de charge : 8.4V LED CR pour indiquer le statut de charge LED OK pou rindiquer que la charge est complète Température de fonctionnement : de -40°C à +85°C Fréquence de commutation jusqu'à 1MHz, compense la perte de tension en mode quadruple CV. La résistance interne et la résistance de suivi de la batterie sont chargées automatiquement. La tension de la batterie de Protection est inférieure à la tension d'entrée et au court-circuit de la batterie. Forte adaptabilité à l'alimentation d'entrée, la capacité de conduite est limitée batterie de protection contre les surtensions. Photos du produit Montage"},{"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).*"}] |