Comment nous avons ramené la configuration de Telegram à zéro

Pendant presque toute la première année de Vyneron, quiconque voulait Telegram avait cinq étapes devant lui. La plupart ne dépassaient pas la deuxième.

Le problème : configurer un bot perso tuait les inscriptions

Avant, le côté Telegram du produit marchait comme ça :

Ouvrir Telegram. Écrire à @BotFather. Créer un nouveau bot. Copier un jeton de 46 caractères qui ressemble à du charabia. Ouvrir les réglages de Vyneron. Coller le jeton dans « Utiliser mon propre bot ». Attendre l'enregistrement du webhook. Pouvoir enfin écrire à sa liste de tâches.

Chaque inscription qui voulait Telegram devait faire les cinq. La plupart ne finissaient jamais la deuxième.

Ce n'était pas que les gens manquaient de motivation. C'était que chaque étape relevait du genre de chose que seul un développeur apprécie : faire naître un bot, le nommer, trouver un pseudo encore libre, copier-coller un jeton entre deux applis, faire confiance au fait que le collage s'est bien enregistré. Pour quelqu'un qui voulait juste envoyer acheter du lait demain depuis le chat où il organise déjà le dîner, ce rituel était sans commune mesure avec la valeur obtenue.

Alors ils partaient. Et la surface Telegram, sans doute ce que Vyneron a de plus distinctif, restait là, derrière un mur de friction que le reste du produit n'avait pas.

Ce billet raconte la suppression de ce mur. Ce que nous avons livré, c'est un bot Telegram partagé : chaque compte Vyneron parle au même @VyneronAIBot, et le bot devine à quel espace de travail le message appartient. Aucun jeton perso. Aucun copier-coller. Aucune visite à @BotFather.

En bref

En bref : Vyneron a remplacé le modèle « chaque compte configure son propre jeton de bot » par un seul @VyneronAIBot partagé, que n'importe quel compte relie en moins de dix secondes. La liaison du compte se fait en collant dans le chat du bot un code court de six caractères, généré dans l'appli web. L'appli web reste la surface principale ; Telegram est une couche compagnon optionnelle, pour ceux qui vivent déjà dans leur messagerie. Toute la migration a pris environ 24 heures : trente-trois commits, une migration de base de données unique, et une bascule nette qui n'a pas cassé les deux utilisateurs déjà reliés.

Pourquoi un bot partagé a pris un an

La réponse honnête : les jetons par compte étaient plus simples à livrer en premier.

Au lancement de Vyneron, « chaque compte amène son propre bot » était une histoire d'isolement propre. Le trafic Telegram de chaque espace de travail passait par son propre webhook, les jetons étaient stockés chiffrés par entreprise, et il n'y avait aucune identité partagée à gérer. Si le bot d'un client tombait en panne, c'était son bot : le débogage restait local, et il n'y avait rien de global à faire tomber par accident.

Le compromis, c'était celui d'au-dessus : chaque prospect qui voulait Telegram devait s'enfoncer de cinq étapes en terrain d'outils de développement avant d'obtenir de la valeur. On a toléré ça au début, parce que la base d'utilisateurs était assez petite pour les accompagner un par un. Quand la friction a commencé à apparaître dans les vraies données du tunnel (des comptes qui s'inscrivaient, ne reliaient jamais Telegram et dérivaient en silence), le calcul a changé.

Le bot partagé est ainsi passé de « ce serait bien » à « c'est la contrainte ». Le travail : garder chaque garantie d'isolement que les jetons par compte nous donnaient, tout en réduisant la configuration à un seul message dans le chat.

L'architecture, en clair

Dans le modèle partagé, il y a exactement un bot Telegram pour tout le produit : @VyneronAIBot. Le webhook de Telegram dirige chaque message entrant vers un seul point d'entrée du backend, qui doit répondre à une question avant de faire quoi que ce soit d'utile :

Quel compte Vyneron est cet utilisateur Telegram ?

Tant que l'utilisateur n'est pas relié, la réponse est « personne qu'on connaisse ». Son message reçoit une invitation à s'inscrire, polie et limitée en fréquence, et c'est tout : aucune création de tâche, aucun appel d'IA, aucune fuite de compte. (La limite existe parce que le flux /start d'un seul bot partagé est aussi une belle cible à bruit ; les expéditeurs non reliés reçoivent une réponse polie au plus une fois par minute.)

Une fois l'utilisateur relié, la réponse est une ligne dans une petite table : telegram_user_id → user_id. À partir de là, le backend traite les messages entrants exactement comme l'ancien flux par compte. Même pipeline d'IA, même création de tâches, même retour vers le tableau de bord. Le bot partagé est un routeur ; la logique de l'espace de travail n'a pas bougé.

Une image simplifiée :

Telegram → webhook @VyneronAIBot → backend
                                     │
                                     ├─ telegram_user_id connu ?
                                     │      ├─ oui → charger le compte → lancer le pipeline
                                     │      └─ non → invitation à s'inscrire (limitée)
                                     │
                                     └─ le pipeline écrit dans la BDD de l'appli web
                                              │
                                              └─ l'appli web le récupère

La partie qui a demandé le plus de soin, c'est la troisième étape du routage : transformer le tout premier message Telegram d'un inconnu en une liaison vérifiée, sans jamais demander de coller un jeton.

Comment la liaison de compte fonctionne vraiment

Quand un utilisateur connecté ouvre Réglages → Intégrations et clique sur Connecter Telegram, le backend fabrique un code de liaison court :

code        = "8X4-K2Q"       # 6 caractères, alphabet sans 0/O/1/I
user_id     = 42
expires_at  = now + 10 minutes
consumed    = false

L'appli web affiche le code et un lien direct comme t.me/VyneronAIBot?start=8X4-K2Q. À partir de là, l'utilisateur a deux chemins aussi courts l'un que l'autre :

• Toucher le lien direct. Telegram s'ouvre, le bot l'accueille, et la charge start arrive dans la première mise à jour.
• Taper le code à la main dans le bot. Même résultat, juste un peu plus lent.

Dans les deux cas, le backend se retrouve avec une seule mise à jour Telegram contenant un code et un champ from.id (l'identifiant numérique côté Telegram). Ensuite :

1. Chercher le code. S'il n'existe pas, a expiré ou a déjà été utilisé, répondre par une erreur claire.
2. Le marquer comme utilisé de façon atomique. Le même code ne peut pas être réclamé deux fois, même par le même utilisateur en deux touchers parallèles.
3. Écrire telegram_user_id = from.id sur le compte Vyneron correspondant.
4. Répondre dans le chat : « ✅ Relié à votre espace de travail. »

Tout le flux, c'est une seule requête HTTP du point de vue de l'utilisateur, et trois opérations en base côté backend. Pas de jeton. Pas de copier-coller. Pas de @BotFather. Et aucun scénario où un inconnu au compte peut relier son identifiant Telegram sans d'abord être connecté à l'appli web et avoir cliqué sur le bouton qui a généré le code.

Quelques détails qui comptent plus qu'il n'y paraît :

• Le code est court. Six caractères avec un alphabet amical rendent la saisie à la main réaliste sur un clavier mobile. Dix caractères auraient été techniquement plus sûrs ; six était le bon compromis face aux taux de fautes de frappe qu'on avait mesurés pendant la migration.
• Il expire en dix minutes. Assez long pour marcher de l'ordinateur au téléphone, assez court pour qu'une capture d'écran qui fuite ne serve plus à rien le temps que quelqu'un s'en aperçoive.
• Les codes sont à usage unique et invalidés dès qu'un nouveau est généré. Cliquer une deuxième fois sur « Connecter Telegram » brûle le précédent : la tentative la plus récente est donc toujours la seule valable. Ça élimine le piège du « j'ai cliqué deux fois et je ne sais plus quel code est actif ».

Le déploiement en 24 heures

Toute la migration est sortie en gros sur une seule journée, en deux temps.

Phase 1 — backend. Vingt-trois commits pour monter le bot partagé, la table des codes de liaison, l'invitation limitée et le routage. Puis neuf correctifs post-revue pour fermer les cas limites qui n'apparaissent que quand on cesse de faire confiance au chemin heureux : la tâche de fond gérée par le cycle de vie qu'on n'attendait pas, le code de liaison utilisable deux fois si deux requêtes se couraient après, la commande d'aide qui sautait en silence pour les non-reliés, la comparaison à temps constant que le commit d'origine avait oubliée, une limite de débit trop zélée, et quelques autres.

Phase 2 — canari à huit tests. Avant d'ouvrir la porte d'entrée, on a déroulé un scénario explicite : un message non relié reçoit l'invitation, le code de liaison marche sur le chemin heureux, le même code ne peut pas être réutilisé, régénérer un code invalide le précédent, la commande d'aide se comporte bien pour les reliés comme pour les non-reliés, le webhook renvoie 200 même quand le message ne peut pas être traité (Telegram réessaie indéfiniment sur tout ce qui n'est pas 200), et le bot central reste sain dans /api/health. Chaque contrôle devait passer avant la bascule du frontend.

Phase 3 — frontend. L'interface « Utiliser mon propre bot » des réglages a disparu. À sa place : une seule section Telegram à trois états — Non connecté (un bouton), Code affiché (compte à rebours, copier, lien direct) et Connecté (carte du compte avec Déconnecter). Vingt et une nouvelles clés de traduction sur six langues.

La bascule nette a marché parce qu'à ce stade la base d'utilisateurs était minuscule (le fondateur et un ami), et que tous deux se sont reliés à nouveau via le nouveau flux le même soir. Pour une base plus large, la même migration aurait demandé un drapeau de fonctionnalité et une fenêtre de tolérance. On a évité cette complexité à dessein, parce qu'elle aurait coûté plus de temps que toute la base d'utilisateurs.

Ce qui n'a pas changé : l'appli web reste centrale

Disons-le clairement : rien de tout cela ne rend Telegram obligatoire.

L'appli web est et reste la surface principale de Vyneron. Tâches, routines, notes, fichiers et recherche par IA marchent tous dans le navigateur sans jamais ouvrir Telegram. Si vous vous inscriviez demain et ne reliiez jamais le bot, vous auriez le produit complet. L'e-mail d'activation qu'on envoie 24 heures après l'inscription dit exactement ça : l'appli web est prête, et Telegram est une surface bonus optionnelle pour ceux qui vivent déjà dans leur messagerie.

Le travail sur le bot partagé visait à retirer la friction pour les utilisateurs qui voulaient Telegram, pas à imposer la surface à ceux qui n'en voulaient pas. Traiter Telegram comme un super-pouvoir plutôt qu'une obligation, c'est la ligne sur laquelle on revient toujours. Beaucoup d'utilisateurs de Vyneron ne relieront jamais de compte Telegram, et le produit doit rester complet pour eux aussi.

La suite

Le bot partagé ouvre quelques portes que le modèle par compte gardait fermées.

• Mini-applis Telegram. Une seule identité de bot nous permet d'attacher une adresse Web App t.me/VyneronAIBot/app et de laisser les utilisateurs ouvrir toute la PWA depuis Telegram en un toucher, en plus de générer des liens directs partageables vers des tâches et des notes précises. C'est un travail post-lancement : il s'amortit avec la base d'utilisateurs, donc il rapporte davantage plus tard.
• Mode en ligne. @VyneronAIBot chercher facture depuis n'importe quel autre chat Telegram, avec les résultats en ligne. La place pour ça vit derrière la même identité partagée.
• Accueil intelligent. Avec un seul bot, on peut itérer sur la toute première réponse /start pour tous les utilisateurs à la fois : changements de texte, suggestions de commandes, détection de la langue via from.language_code.

Mais avant tout ça, la suite la plus utile est la plus petite : garder la friction à zéro. La victoire, ce n'était pas « on a livré un bot partagé ». C'était que quelqu'un peut désormais passer de l'inscription à une tâche Telegram fonctionnelle en moins d'une minute, sans le moindre rituel de développeur, tout en gardant une surface web principale qui se moque qu'il ouvre un jour le bot ou non.

Ce genre de travail est invisible quand il atterrit, et c'est précisément le but.

Vyneron est un espace de travail de productivité par IA, pensé pour Telegram, avec une connaissance intégrée des jours fériés de plus de 250 pays, une tarification BYOK et l'OCR pour les photos et les fichiers. L'appli web est la surface principale ; Telegram est optionnel. Essayez Vyneron gratuitement ou parcourez l'étude des bots de tâches Telegram pour le contexte de l'écosystème.