Translation in progress. The English version of this article isn't ready yet — the original French text is shown below. We're working on translating the rest of the content.
« Il nous faudrait une appli. »
Si vous portez un projet associatif, culturel, santé ou territorial, vous avez probablement déjà prononcé cette phrase. Ou on vous l'a soufflée en réunion. Une appli, ça fait sérieux. Ça fait moderne. Ça se télécharge, ça a une icône sur l'écran d'accueil, ça envoie des notifications.
Le problème, c'est que cette phrase déclenche presque toujours le même réflexe : direction l'App Store et Google Play. Et là, le devis triple, le calendrier double, et le projet meurt parfois avant d'avoir commencé.
Voici un contre-exemple : Peer to Peer, une plateforme gratuite d'outils d'auto-observation et de soutien au rétablissement en santé mentale. Questionnaires, parcours guidés, carnets. Sans compte, sans donnée envoyée, tout reste dans le navigateur.
Elle s'installe sur un téléphone. Elle s'ouvre en plein écran. Elle a son icône. Et elle n'existe sur aucun store.
C'est une PWA : une Progressive Web App. Et c'est de ce choix-là que je veux parler aujourd'hui.
Une PWA est un site web qui se comporte comme une application. Concrètement, quand vous visitez le site depuis votre téléphone, vous pouvez l'ajouter à votre écran d'accueil. Elle s'ouvre alors sans barre d'adresse, en plein écran, avec sa propre icône. Elle peut fonctionner hors connexion, mémoriser des choses localement, et — sous conditions — envoyer des notifications.
Pour la personne qui l'utilise, la différence avec une « vraie » application est souvent invisible.
Pour celle qui la finance et la maintient, la différence est énorme.
Pour Peer to Peer, trois contraintes étaient non négociables.
Pas de revenus, juste des contributions libres. Une application native, c'est au minimum un développement iOS et un développement Android (ou un framework hybride, qui a ses propres coûts), deux processus de publication, deux cycles de validation, des comptes développeur payants. Pour un projet sans modèle économique, c'est rédhibitoire avant même la première ligne de code.
On parle de santé mentale. Principe d'architecture numéro un : aucune donnée ne quitte l'appareil. Or passer par les stores aurait poussé dans la direction inverse (comptes utilisateurs, conditions des plateformes, mécaniques d'engagement). Le web, lui, me laissait construire exactement le niveau de confidentialité que je voulais : pas de compte, pas de serveur qui collecte, des saisies qui vivent le temps d'une session.
Une personne en difficulté qui cherche un outil d'auto-observation ne doit pas avoir à télécharger 80 Mo, créer un compte et accepter des CGU. Elle clique sur un lien, elle est dedans.
Un lien se partage par SMS, dans un mail, sur une affiche en QR code, par un pair-aidant en entretien. Essayez de faire ça avec une app native : « télécharge l'app, attends, crée un compte… ». Résultat : vous avez perdu la moitié des gens en route.
La PWA n'était pas un choix par défaut ou par économie. C'était le choix aligné avec le projet — son éthique, son modèle économique et son public.
Parlons franchement de ce qu'implique le passage par l'App Store et Google Play, parce que c'est rarement dit aux porteurs de projet.
| Poste | App native (stores) | PWA |
|---|---|---|
| Développement initial | iOS + Android (ou hybride lourd) | Une seule base web |
| Compte développeur | Apple ~99 €/an, Google ~25 € à vie | Aucun |
| Commission sur ventes | 15–30 % | 0 % |
| Cycle de validation | Plusieurs jours, refus possibles | Aucun — déploiement direct |
| Mise à jour | Soumise à revue, propagée selon l'OS | En ligne instantanément |
| Référencement Google | Invisible (seule la fiche store existe) | Chaque page est indexable |
| Dépendance plateforme | Forte (règles révocables) | Aucune |
Il y a aussi un coût plus sournois : la dépendance. Votre projet vit sur le terrain de quelqu'un d'autre, selon ses règles, révocables.
Avec une PWA, une mise à jour, c'est un déploiement web. Elle est en ligne pour tout le monde, instantanément, sans validation de personne. Quand je corrige un outil sur Peer to Peer un mardi soir, il est à jour chez tous les utilisateurs le mardi soir.
Bonus que les apps natives n'auront jamais : une PWA est référençable sur Google. Chaque outil de Peer to Peer est une page web indexable. Une app native est invisible des moteurs de recherche — votre seule vitrine, c'est la fiche du store.
La PWA n'est pas une solution universelle.
La PWA est probablement le bon choix si :
L'application native se justifie si :
Dans le doute ? Commencez par la PWA. C'est l'option réversible : si le projet décolle et que le natif devient nécessaire, vous aurez validé les usages avec un investissement maîtrisé. L'inverse — partir du natif pour redescendre vers le web — coûte beaucoup plus cher.
La question n'a jamais été « PWA ou native, laquelle est la meilleure ? ». La question est : que doit faire votre application, pour qui, avec quel budget de départ, et quelle équipe pour la faire vivre ?
Avant de choisir une techno, choisissons ce que le projet doit vraiment faire.
Vous vous demandez si une PWA correspond à votre projet ? Faites le diagnostic techno en 2 minutes, ou écrivez-moi directement avec votre projet — je vous donne un premier avis.
Peer to Peer est en ligne sur peer-to-peer.fr — gratuit, sans compte, et vos données restent chez vous.