Exemple : une base de code en Telegram Mini App et en PWA

Une Mini App qui ne s’ouvre que dans Telegram est un produit à une porte. C’est juste pour un salon dont les clients écrivent déjà dans le bot. C’est faux pour un tracker, un cabinet de cours ou un petit SaaS dont le prochain user arrive d’une bio Instagram. Subeasy - un suivi d’abonnements qui est PWA et Mini App - est le modèle que je reprendrais pour ce second cas.

La tâche dans cet exemple, c’est une liste perso d’abonnements : Netflix, salle, Adobe, le domaine oublié. L’intéressant n’est pas la liste. C’est que les mêmes écrans marchent dans une feuille Telegram et sur une icône d’écran d’accueil, sans deux apps à maintenir.

1. Deux portes, un produit

Détectez l’hôte. Pas une histoire marketing.

• Dans Telegram : `initData` est là. Valider le HMAC côté serveur, session = id Telegram. Thème depuis `themeParams`. MainButton pour « ajouter » et « upgrade ». Le bot peut rappeler « Adobe prélève dans 3 jours ».
• Dans un navigateur / PWA installée : pas d’`initData`. Magic link ou passkey. La même UI de liste. Bouton CSS en bas au lieu du MainButton. Notifs via Web Push là où ça marche ; une cloche in-app sur iOS.
• Local-first dans les deux cas. IndexedDB ou un petit store local tient la liste. Sync vers Postgres quand une session existe. Le point de Subeasy : les cinq premiers abonnements sont ajoutés avant un mur de login.

2. Ce qui reste partagé, ce qu’il faut séparer

Si vous séparez les écrans, la Mini App aura trois semaines de retard sur la PWA. Séparez les adaptateurs. Gardez les pages.

• Partagé : modèle métier, UI liste, charts, export, textes tarif. Une app Next.js. Un objet `runtime` : `platform: "telegram" | "web"`.
• Séparer : adaptateur d’auth, chrome (MainButton vs CSS), haptics, CloudStorage vs localStorage, paiement. Le chemin Telegram peut ouvrir les Stars. Le web ouvre Stripe ou Mono. La même ligne d’entitlement dans Postgres.
• Liez les comptes plus tard, pas au premier paint. Si l’user commence en PWA puis ouvre Telegram, proposez une fois « lier ce Telegram ». N’imposez pas l’e-mail dans la Mini App à la minute une.

3. Monetisation sans peindre deux checkouts

Le premium est un flag sur l’user, pas un SKU par plateforme. Le mur est le même : thèmes, export, sièges famille, IA « vous payez 3× la médiane pour le streaming ». Comment l’argent entre change avec la porte.

• Porte Telegram : Stars pour un mois premium. Pas de coupe Apple au-delà de ce que Telegram prend déjà. Bien pour un équivalent 4-12 €. Le bot peut envoyer le reçu.
• Porte web : abonnement Stripe ou Mono. Le même webhook écrit `premium_until`. N’inventez pas un second nom de plan.
• Le palier gratuit reste utile. Subeasy ne limite pas le tracker exprès. Si la Mini App gratuite est une démo, personne n’installera la PWA non plus.

4. Quand je ne m’embêterais pas avec une PWA

Si 90 % du travail se passe dans un groupe qui existe déjà, une seconde porte est de la vanité. L’exemple de répartition n’a pas besoin d’une PWA. Un menu livraison pour des habitués qui commandent seulement dans Telegram non plus.

• Double porte quand des inconnus arrivent d’une URL : Instagram, un site, un e-mail. La Mini App est pour la cohorte qui vous écrit déjà.
• N’emballez pas un admin desktop en PWA « parce qu’on peut ». La feuille reste phone-first. L’admin reste un site normal.

Les mêmes écrans, deux hôtes, un ledger

J’ouvrirais avec ce modèle pour un tracker, un cabinet de cours, un petit CRM freelance, ou tout outil qui doit survivre à « je vis dans Telegram » et à « je n’installe pas de bot ». Next.js, un switch `runtime`, liste local-first, Postgres à la connexion, Stars dans Telegram et un checkout carte ennuyeux sur le web. Si vous voulez cette double porte au lieu de deux codebases - écrivez via le formulaire. On livrera le chemin Telegram d’abord si l’argent est déjà là, puis on accrochera la PWA aux mêmes routes.