MeetCal : Pourquoi j'ai construit Calendly dans Telegram
Chaque 'on peut se parler ?' sur Telegram finit avec un lien Calendly dans le navigateur. MeetCal garde toute la planification dans un chat
Il y a un moment précis qui m’a cassé.
Quelqu’un m’envoie un message sur Telegram : “on peut se faire un call cette semaine ?” Je réponds : “bien sûr, voici mon Calendly.” Il clique dessus, le navigateur s’ouvre, charge lentement sur mobile, lui demande peut-être de créer un compte, peut-être qu’il time out. Cinq minutes plus tard, il est de retour sur Telegram pour confirmer le créneau. Toute la conversation est maintenant répartie sur deux apps et un onglet de navigateur.
Ça arrive des dizaines de fois par semaine. J’ai construit MeetCal parce que j’en avais assez de cette rupture.
Le problème avec Calendly dans Telegram
Calendly est bien. Il fait ce qu’il dit. Mais l’hypothèse produit qui y est intégrée, c’est que la planification est une tâche autonome — quelque chose vers lequel on navigue délibérément, comme réserver un vol.
La planification sur Telegram ne fonctionne pas comme ça. “On peut se parler ?” est une ligne anodine au milieu d’une conversation sur autre chose. Quand tu glisses un lien Calendly dans ce moment, tu demandes à l’autre personne de faire une pause, de changer de contexte, de compléter un flux en plusieurs étapes dans une interface étrangère, puis de revenir. La moitié du temps, l’élan est parti au moment où elle revient.
La friction n’est pas seulement les étapes supplémentaires. C’est la rupture dans le fil conversationnel. Le changement de contexte signale “c’est maintenant une tâche formelle de planification” alors que tu voulais juste trouver une heure libre.
Ce que fait MeetCal
L’hôte configure ses disponibilités une fois dans le bot. À partir de là, tu peux partager ta carte de réservation en inline — tape @MeetCalBot dans n’importe quelle conversation Telegram et ça insère directement une carte de prévisualisation riche dans la conversation. L’invité tape dessus, une Mini App s’ouvre dans Telegram, il choisit un créneau, c’est fait. Pas de navigateur, pas d’email, pas de création de compte.
La confirmation et les rappels arrivent comme des messages Telegram. Toute la boucle — suggérer, réserver, confirmer, rappeler — reste au même endroit.
La partie partage en inline compte plus qu’il n’y paraît. Ça signifie que tu n’as pas à quitter le chat pour partager ton calendrier. Tu tapes juste le nom du bot en milieu de message et la carte apparaît. Le destinataire ne voit jamais un lien brut.
Le problème technique le plus difficile
L’app est React + Vite. Les Telegram Mini Apps te donnent accès à WebApp.MainButton, qui est le bouton en bas de l’écran qui flotte au-dessus de ton contenu. C’est le bouton d’action principal dans presque toutes les Mini Apps.
L’API est impérative : MainButton.show(), MainButton.hide(), MainButton.setText('Réserver un créneau'), MainButton.showProgress(). Tu appelles des méthodes, Telegram gère le rendu.
React est déclaratif. Tu décris l’état, React décide quoi rendre.
Le décalage a créé un bug spécifique : chaque fois que l’état du composant changeait — même un état sans rapport avec le bouton — le bouton flickait. Il disparaissait pendant une seule frame avant de réapparaître avec le bon texte. Sur un écran de téléphone, ça semblait cassé.
La cause racine était que j’avais un seul useEffect qui regardait tout l’état lié au bouton et appelait show() puis setText() à chaque rendu. Le bref hide() entre les rendus était visible.
La solution était de diviser le hook en effets séparés avec des tableaux de dépendances séparés. Un effet ne s’exécute qu’au montage pour initialiser le bouton et attacher le gestionnaire de clic. Un effet séparé ne s’exécute que quand le texte du bouton ou l’état de chargement change, et il n’appelle jamais hide() — seulement setText() et showProgress(). La visibilité est gérée indépendamment avec son propre effet qui ne se déclenche que quand le flag visible change.
Trois effets au lieu d’un. Chacun avec un tableau de dépendances minimal. Le flickering a arrêté.
C’est un petit truc mais ça a pris une demi-journée à isoler, et c’est le genre de chose qui fait la différence entre une app qui se sent native ou bricolée.
Ce que la plateforme Mini App fait bien et mal
Bien : la distribution est gratuite. Si le bot fonctionne, les gens le trouvent via la recherche inline. Pas de validation app store, pas d’étape d’installation. Les primitives UI de Telegram — MainButton, BackButton, retour haptique, la feuille de partage native — suffisent pour construire quelque chose qui ressemble à une vraie app.
Mal : l’expérience de débogage est difficile. Les erreurs dans la Mini App s’affichent de façon difficile à tracer. L’objet WebApp se comporte différemment selon les clients Telegram (desktop, iOS, Android) de façons non documentées. J’ai passé une journée à déboguer un problème de mise en page qui ne se reproduisait que sur Android parce que le calcul de la hauteur du viewport inclut le clavier sur une plateforme mais pas l’autre.
La plateforme est jeune. Tu le ressens. Mais les contraintes te poussent vers des interfaces plus simples, ce qui est généralement une bonne chose.
État actuel
MeetCal a trois niveaux : gratuit (réservation basique, créneaux limités par mois), Starter, et Pro. Les niveaux payants débloquent les disponibilités récurrentes, les buffers personnalisés entre réunions, et quelques autres trucs que les utilisateurs avancés demandent.
La monétisation passe par Telegram Stars — la monnaie intégrée de Telegram. C’est un match naturel parce que les utilisateurs ne quittent jamais la plateforme pour payer. La conversion de gratuit en payant est précoce, mais les gens qui paient ont tendance à utiliser le produit sérieusement.
Ce que je ferais différemment
Je passerais moins de temps sur le polish du flux de réservation dans la première version et plus de temps sur l’onboarding de l’hôte. Le moment où quelqu’un configure sa disponibilité pour la première fois est là où la plupart des gens abandonnent. Le flux marche mais il n’est pas assez évident. Je continuais à optimiser l’expérience de l’invité — la personne qui réserve — quand l’expérience de l’hôte était le vrai goulot d’étranglement.
Aussi : j’aurais lu le changelog Telegram Mini Apps plus attentivement avant de commencer. Il y avait des changements d’API entre le moment où j’ai commencé à construire et le moment où j’ai publié qui ont nécessité de réécrire des parties de la couche d’authentification. Leçon : traite la plateforme comme instable jusqu’à ce que tu aies publié au moins une version.
Le pari de base tient toujours. La messagerie, c’est là où vit l’attention. La planification devrait y vivre aussi.