Comment créer un Telegram Mini App en 2026 : du prototype à 60 000 utilisateurs quotidiens

Les Telegram Mini Apps sont passées d'une fonctionnalité expérimentale à une véritable plateforme de distribution : 200 millions d'utilisateurs les ouvrent chaque mois, et c'est la façon qui croît le plus vite pour livrer un produit dans la messagerie. Nous avons lancé The Open Earn début 2024 et l'avons fait passer à 60 000 utilisateurs actifs quotidiens et 500 000+ tâches accomplies en 18 mois. Ce guide raconte ce que nous avons fait et ce que nous nous dirions au jour 1.

Mini App vs bot classique : quand choisir lequel

Un Telegram Bot est une interface de chat sur des messages. Un Telegram Mini App est une application web complète qui s'ouvre dans Telegram et a accès à l'API de la messagerie.

Un bot classique suffit quand :

• Le flow est linéaire : commandes → réponses (bot d'escrow, bot de notifications)
• La complexité de l'UI est minimale
• La vitesse de prototypage compte

Vous avez besoin d'un Mini App quand :

• UI complexe avec navigation, formulaires, listes
• Interactivité en temps réel
• Paiements via Telegram Payments ou Stars
• Catalogues produits, profils utilisateur, feeds

Dans The Open Earn nous faisons tourner les deux : un bot pour les notifications et l'onboarding, un Mini App pour l'interface principale (solde, retrait, stats).

Stack : ce que nous utilisons réellement

La stack de production de The Open Earn, sans baratin marketing :

Frontend (Mini App) :

• Next.js 16 (App Router, SSR) — pour un premier rendu rapide et le SEO sur la landing
• React 19 + TypeScript
• @twa-dev/sdk — wrapper autour du SDK Telegram Web Apps (thème, viewport, events)
• TonConnect SDK — pour connecter le wallet TON de l'utilisateur

Backend :

• Python 3.12 + FastAPI — serveur API
• aiogram 3.x — le bot
• PostgreSQL 16 — stockage principal
• Redis — cache de session, rate limiting, pub/sub pour les workers
• Celery — jobs en arrière-plan (paiements, vérification de tâches)

Infrastructure :

• Un serveur dédié (8 Go RAM, 4 vCPU)
• nginx en reverse proxy
• PM2 pour les processus Node, systemd pour Python
• Let's Encrypt pour le SSL

Cela tient jusqu'à 50–100K DAU. Nous n'avons dû upgrade qu'au passage de 60K — nous avons déplacé Postgres vers une managed instance.

Authentification : initData et validation côté serveur

L'erreur de débutant la plus courante : faire confiance à Telegram.WebApp.initDataUnsafe. C'est falsifiable dans les DevTools.

Le flow correct :

1. Le Mini App reçoit initData (raw string) de Telegram via le JS SDK au lancement
2. Il l'envoie à votre backend dans Authorization: TelegramInitData ...
3. Le backend valide la signature avec HMAC-SHA256 dérivé du bot token
4. Sur signature valide — extraire user.id et émettre un token de session

Validation en Python :

import hmac, hashlib
from urllib.parse import parse_qs

def validate_init_data(init_data: str, bot_token: str) -> dict:
    parsed = parse_qs(init_data)
    received_hash = parsed.pop("hash")[0]
    data_check = "\n".join(f"{k}={v[0]}" for k, v in sorted(parsed.items()))
    secret = hmac.new(b"WebAppData", bot_token.encode(), hashlib.sha256).digest()
    expected = hmac.new(secret, data_check.encode(), hashlib.sha256).hexdigest()
    if not hmac.compare_digest(expected, received_hash):
        raise ValueError("Invalid signature")
    return parsed

Vérifiez aussi auth_date — rejetez les sessions de plus de 24 heures (protection contre le replay).

Paiements : Stars, TON, USDT

Trois vraies façons d'encaisser à l'intérieur de l'écosystème Telegram en 2026 :

1. Telegram Stars (pour biens numériques) — via Bot API: sendInvoice avec currency: "XTR". Achats intangibles uniquement. Telegram prend ~30%.

2. TON directement — via TonConnect : l'utilisateur connecte un wallet et signe la transaction. Frais de l'ordre de quelques centièmes de centime.

3. USDT sur TON (Jetton) — comme TON mais en stablecoin. Pratique pour le B2B et la facturation à prix fixe.

Dans The Open Earn nous payons les gains en USDT via TonConnect — les utilisateurs voient un montant en dollars, pas un prix TON fluctuant. Retrait minimum : 1 $.

Déploiement et scaling

Le layout de production le plus simple pour les premiers 10K DAU :

[Cloudflare] → [nginx] → [Next.js on :3000] → [FastAPI on :8000] → [Postgres]
                                                  ↓
                                              [Redis]

Ce qui a cassé chez nous à 30K DAU et comment on a corrigé :

• Postgres connection pool épuisé — ajout de pgbouncer et split lecture/écriture
• Redis OOM lors des pics — augmenté maxmemory, basculé sur allkeys-lru
• Latence webhook du bot — déplacé les vérifications lourdes vers Celery
• CDN pour les assets statiques — poussé vers Cloudflare R2

La seule règle qui compte : mesurer, pas deviner. Sentry pour les erreurs, Grafana + Prometheus pour les métriques, dès le jour 1.

Ce que nous ferions différemment

Si on recommençait au jour 1 :

1. Diviser en 2 services dès le départ — API publique (Mini App) et privée (admin/workers). Fusionner coûte moins cher que séparer plus tard.
2. Mettre des feature flags dès le jour 1 (Unleash, GrowthBook) — auraient été utiles pour les A/B tests pendant la croissance.
3. Utiliser les Server Actions Next.js au lieu d'une couche REST custom pour les formulaires simples. Moins de code.
4. Sauter les jolies animations au jour 1 — les utilisateurs viennent pour la fonction, pas pour le polish. Le polish prend du sens après le product-market fit.
5. Construire l'i18n dès le jour 1 — les traductions dans 12 langues ont 4× notre trafic, mais les rajouter ensuite a été pénible.

Et après

Les Mini Apps en 2026 ne sont plus « l'expérience de Telegram » — ce sont un vrai canal de distribution. Si votre produit recoupe l'audience active de la messagerie, ça vaut au moins un prototype. La stack de départ est petite, le risque est plus faible que pour une app mobile native.

Si vous voulez voir à quoi ça ressemble en production — ouvrez The Open Earn ou allez directement sur le bot.