LI Solutions

Telegram verrouille les Mini Apps le 20 juillet. Vérifiez la vôtre avant qu'elle ne casse.

Telegram locks down Mini Apps on July 20. Check yours before it breaks.

Points clés à retenir

Le 20 juillet, automatique, pour tous

Telegram active la protection cross-origin pour toutes les Mini Apps le 20 juillet 2026. Les méthodes appelées depuis toute origine autre que votre domaine enregistré cessent tout simplement de fonctionner.

Paiements et connexions, les suspects habituels

Les pages de checkout hébergées et les fournisseurs OAuth qui appellent des méthodes Mini App depuis leurs propres domaines échoueront en silence. Rien ne lève d'erreur ; l'appel n'a tout simplement jamais lieu.

L'opt-out déplace la responsabilité sur vous

BotFather permet de désactiver la protection, mais la formulation vous rend responsable de chaque page que votre application peut atteindre. Traitez-le comme une soupape d'urgence, pas comme un réglage.

Six jours de préavis, la vraie leçon

Construire sur la plateforme d'un autre signifie que le changement arrive selon son calendrier à lui. Une architecture à origine unique, c'est ce qui rend ce genre d'annonce ennuyeuse plutôt qu'urgente.

Le 14 juillet, Telegram a publié Bot API 10.2. L'essentiel du changelog relève de l'agréable habituel : les messages riches gèrent mieux les médias, les bots voient désormais quand l'abonnement payant d'un utilisateur change. Puis, tout en bas, sous 'General', une ligne qui mord vraiment si vous exploitez une Mini App : à partir du 20 juillet, les méthodes Mini App cessent de fonctionner depuis toute origine autre que le domaine de la Mini App elle-même. La protection s'active automatiquement, pour toutes les Mini Apps, que vous ayez lu le changelog ou non. Cela fait six jours de préavis.

Une traduction rapide pour ceux qui ne vivent pas dans cette stack. Une Mini App est une application web qui tourne à l'intérieur de Telegram et qui lui parle via un pont de messages étroit : ouvrir une facture, demander le contact de l'utilisateur, solliciter la biométrie, fermer l'application. Ces appels, ce sont les 'méthodes Mini App'. Jusqu'ici, n'importe quelle page qui se retrouvait dans la webview de votre application pouvait les utiliser. Après le 20 juillet, seules les pages servies depuis le domaine enregistré auprès de BotFather le pourront.

Si votre Mini App est une seule base de code sur un seul domaine, vous pouvez arrêter votre lecture et retourner travailler. Si de l'argent ou des connexions passent par un deuxième domaine quelque part dans votre application, vous avez jusqu'à lundi.

Pourquoi Telegram a appuyé sur la détente

La faille qui se referme est bien réelle. Quand votre Mini App liait ou intégrait une page d'un autre domaine, cette page héritait du pont. Une page partenaire compromise ou un script détourné pouvait déclencher les mêmes méthodes que votre propre code, avec l'identité de votre application et la session de votre utilisateur derrière.

C'est déjà arrivé. En 2024, un appel open-link forgé via le pont pouvait détourner des sessions Telegram Web (CVE-2024-33905, corrigé dans le client web). La plateforme fait désormais circuler de l'argent réel via les factures, les Stars et les abonnements, un pont ouvert a donc cessé d'être un réglage par défaut acceptable.

Il existe un opt-out, et il s'accompagne d'une phrase qui mérite deux lectures. Vous pouvez désactiver la protection via la Mini App de BotFather, mais ce faisant 'vous reconnaissez qu'il revient au bot de s'assurer que la Mini App ne contient aucun lien vers des sites non fiables'. C'est un transfert de responsabilité déguisé en interrupteur. Servez-vous-en comme d'une soupape d'urgence le temps de corriger votre architecture, pas comme d'un réglage permanent.

Les applications qui casseront lundi

Les pannes se concentreront dans les parcours qui traversent plusieurs domaines :

  • Les pages de paiement hébergées. L'utilisateur paie sur le domaine de votre prestataire, et cette page appelle une méthode pour fermer la webview ou signaler le succès. À partir du 20 juillet, cet appel est ignoré, et votre utilisateur reste bloqué sur une page de reçu à se demander si quelque chose s'est passé.
  • La connexion tierce. Les parcours OAuth qui se terminent sur le domaine du fournisseur puis sollicitent le pont pour rendre la main à l'application.
  • Les produits multi-domaines. Un domaine marketing et un domaine applicatif, ou des domaines par région, où le domaine secondaire appelle encore le SDK.
  • Les widgets et les configurations en marque blanche. Tout ce qui ressemble à un SDK servi depuis le CDN d'un fournisseur plutôt que depuis votre propre origine.
  • Les builds de préversion et de staging. Les deploy previews sur des URL générées par la plateforme sont elles aussi des origines distinctes. Votre application de production peut aller très bien pendant que la QA cesse de fonctionner en silence, ou l'inverse.

Le mode de défaillance est du genre vicieux : silencieux. Rien ne lève d'erreur, rien ne plante. L'appel n'a tout simplement pas lieu. Un checkout qui fonctionnait depuis un an se termine sur un bouton qui ne fait rien, et c'est votre boîte support qui vous l'apprend.

L'audit, en une après-midi

  1. Listez chaque origine qui touche au pont. Cherchez dans la base de code l'import du SDK et les appels postMessage directs, puis déroulez chaque parcours utilisateur et notez chaque domaine traversé.
  2. Scrutez d'abord les paiements et l'authentification. Toute étape où l'utilisateur quitte votre domaine et où quelque chose est censé se produire à son retour est candidate.
  3. Rapatriez les appels. Le correctif propre est une fine page de retour sur votre domaine enregistré : la page tierce y redirige, et c'est elle qui effectue l'appel au pont. La plupart des équipes peuvent livrer cela en une journée.
  4. Testez dans de vrais clients. Les webviews iOS, Android et desktop ne se comportent pas à l'identique, et ce n'est pas la semaine pour croire la documentation plutôt que l'appareil.
  5. Si lundi est intenable, désactivez, corrigez, réactivez. Laisser la protection éteinte en permanence, c'est assumer chaque page que votre application pourra jamais atteindre.

Le signal plus large

Prenez du recul : c'est la troisième plateforme cette année à durcir les règles en plein vol pour ceux qui construisent dessus. Apple a commencé à retirer les applications générées par IA qui ne passent pas sa barre de qualité. Shopify a coupé Scripts le 30 juin et a cassé la logique de checkout des boutiques qui n'avaient pas migré. Maintenant Telegram, avec le préavis le plus court des trois.

Aucun de ces gestes n'est hostile. C'est ce que font les plateformes une fois que l'argent réel et les vrais utilisateurs arrivent : les réglages par défaut se durcissent et les périodes de grâce raccourcissent. Les Mini Apps ont franchi cette ligne il y a un moment. Un demi-milliard de personnes en ont utilisé une, les paiements sont natifs, et les versions de la Bot API sortent désormais chaque mois. Les Rich Messages en juin, les événements d'abonnement et ce verrouillage en juillet.

La leçon pour quiconque construit sur un terrain loué n'est pas d'arrêter d'y construire. La portée, c'est pour cela que vous êtes venu. La leçon est architecturale : gardez votre application sur une seule origine, tenez les pages des autres à l'écart du pont, et traitez chaque domaine externe d'un parcours utilisateur comme une dépendance révocable d'une ligne de changelog. Les équipes qui construisent ainsi lisent ce genre d'annonce avec un café, pas avec une cellule de crise.

Le pari des Mini Apps de Telegram reste l'une des meilleures asymétries du logiciel grand public : un milliard d'utilisateurs, pas de revue d'app store, un coût de développement à la portée de la plupart des fondateurs. La plateforme vient de cesser de prendre la sécurité à la légère, et ce durcissement ne sera pas le dernier. Si votre application traverse plusieurs domaines, il vous reste le week-end.

Questions fréquentes

Qu'est-ce qui cesse exactement de fonctionner le 20 juillet 2026 ?

Les méthodes Mini App, c'est-à-dire les appels de pont qu'une Mini App adresse à Telegram (fermer l'application, ouvrir une facture, demander les coordonnées, la biométrie), sont ignorées quand elles proviennent d'une origine autre que le domaine enregistré de la Mini App. Le code qui tourne sur votre propre domaine n'est pas affecté.

Ma Mini App va-t-elle casser ?

Si toute l'application vit sur un seul domaine et qu'aucune page tierce n'appelle jamais le pont, non. Si un prestataire de paiement, un fournisseur de connexion ou n'importe quelle page intégrée sur un autre domaine appelle des méthodes Mini App au cours d'un parcours, cette étape cessera de fonctionner. Les deploy previews sur des URL générées par la plateforme comptent elles aussi comme des origines distinctes.

Puis-je désactiver la protection ?

Oui, via la Mini App de BotFather. Mais le texte de l'opt-out vous rend responsable de garantir que l'application ne contient aucun lien vers des sites non fiables, une responsabilité dont vous ne voulez probablement pas. Utilisez-le pour gagner du temps pendant que vous rapatriez les appels au pont sur votre propre domaine, puis réactivez la protection.

Pourquoi Telegram fait-il cela maintenant ?

L'ancien comportement laissait n'importe quelle page dans la webview de votre application utiliser le pont, et cela a déjà été exploité : CVE-2024-33905 a montré qu'un appel open-link forgé pouvait détourner des sessions Telegram Web. Avec les paiements, les Stars et les abonnements désormais natifs sur la plateforme, laisser le pont ouvert à chaque page intégrée a cessé d'être défendable.