En tant qu'ingénieur logiciel qui passe la majeure partie de sa journée sur des terminaux et des applications de chat, j'étais très fatigué par les configurations SaaS surchargées, les architectures cloud complexes et les factures d'abonnement galopantes. Je voulais un assistant personnel d'IA qui vivait exactement là où je travaille déjà : Telegram. Pas encore un autre tableau de bord Web, pas un bot Slack, pas un outil CLI que j'oublierais d'ouvrir. Juste moi, un fil de discussion et une IA qui peut réellement faire des choses.
J'utilise Telegram pour le travail, pour les discussions personnelles, pour les notifications, pour tout. C'est la seule application que je ne ferme jamais. C'était donc logique : au lieu de créer un outil d'IA autonome que je devrais penser à visiter, j'en créerais un qui apparaîtrait dans mon flux de messages existant. Un robot auquel je peux demander de vérifier mes e-mails, de me rappeler d'appeler quelqu'un à 18 heures, de me rappeler que je préfère la communication asynchrone le matin ou de résumer mes messages non lus, le tout sans quitter ma liste de discussion.
Voici comment je l'ai construit, l'architecture sous le capot, le modèle de sécurité, le pipeline de planification et les compromis que j'ai faits en cours de route pour conserver cette infrastructure totalement minimale.
Les choix technologiques étaient motivés par une contrainte stricte : une infrastructure minimale. Pas de serveurs à déployer, pas de conteneurs Docker, pas de factures cloud. Cela devait fonctionner sur un VPS à 5 $ ou sur mon ordinateur portable. L'ensemble de la pile devait s'intégrer dans un seul processus, utiliser une base de données basée sur des fichiers et n'avoir aucune dépendance externe en dehors des API qu'elle appelle.
Durée d'exécution : Bignon. Démarrage rapide, TypeScript natif, SQLite intégré et Web Workers pour les tâches en arrière-plan. C'est un seul binaire sansnoeud_modulesau moment de l'exécution. Chignonchignon:sqliteest plus rapide quemieux-sqlite3et ne nécessite aucune compilation native.
Cadre de robot : Telegraf v4. Mode d'interrogation mature (aucun serveur webhook requis) et modèle middleware allégé. Il gèregetUpdatesboucles, tentatives automatiques en cas d'erreurs réseau et fournit un nettoyage proprecxobjet pour chaque message.
SDK IA : SDK OpenAI v6. API de complétion de chat avec streaming. Je gère manuellement la boucle d'appel d'outil - le modèle répond avec des appels de texte ou de fonction, je les exécute, renvoie les résultats et boucle jusqu'à N étapes. Pas de framework wrapper, pas de magie.
Plateforme d'outils : Composio. Plus de 200 intégrations prédéfinies (Gmail, Slack, Calendar, GitHub, Jira, Notion). Il gère les flux OAuth, la gestion des sessions, les tentatives d'API et la limitation du débit. Je l'enveloppe dans un outil personnalisé qui exposerecherche(trouver des limaces d'outils) etexécuter(exécutez un outil par slug).
Base de données : SQLite viachignon:sqlite. Pas d'ORM, de requêtes brutes, de mode WAL pour les lectures simultanées. Six tables, zéro configuration, pas de cadre de migration - juste un tableau de versions avec suiviCRÉER UN TABLEAUinstructions qui s'exécutent dans l'ordre.
Planification : Bun Web Workers pour la boucle d'interrogation et l'exécution des tâches d'IA. Pas de cron, pas de Redis, pas de BullMQ, pas de planificateur externe. Deux travailleurs partagent le même fichier SQLite.
La plupart...
[Courte citation de 8% de l'article original]