Du bot Telegram à l'application web évolutive : L'évolution d'un outil interne
Un analyste des pertes en entrepôt était confronté à une tâche routinière : le traitement quotidien de plusieurs fichiers Excel nécessitait 5 heures par jour, soit 150 heures par mois. Cela représentait des coûts temporels significatifs. La solution fut un MVP sous forme de bot Python sur Telegram : les utilisateurs envoyaient des fichiers, le bot renvoyait les résultats traités. La logique de traitement restait sous contrôle du développeur, sans interface nécessaire.
Cette approche fonctionna initialement : Telegram offrait un accès rapide sans nécessiter d'interface utilisateur. Cependant, avec la croissance de la complexité, les limites sont devenues apparentes.
Les limites de Telegram comme fondation système
Telegram n'est pas conçu pour servir de cœur central à un système. Les problèmes sont apparus rapidement :
- La limite de 20 Mo pour les fichiers bloquait les téléchargements volumineux.
- Le traitement devenait une "boîte noire" sans visibilité sur l'état d'avancement.
- Il n'y avait pas d'interface appropriée pour la gestion.
- Le développement de fonctionnalités devenait plus compliqué.
- Des problèmes d'accès en Russie dus à la réglementation.
Telegram fonctionnait comme point d'entrée, mais pas comme noyau. La solution fut de déplacer la logique vers un backend séparé.
Transition progressive vers une application web
La transition ne fut pas une refonte complète : le bot resta comme client mais délégua les tâches au backend. Une interface web émergea avec des capacités :
- Téléchargement de fichiers de toute taille.
- Suivi de l'état de traitement.
- Gestion des processus.
Le projet acquit des caractéristiques système : la séparation des responsabilités simplifia le développement. Le backend gère les données et la logique métier, la partie web gère l'interaction, et les intégrations (Google Sheets, Yandex.Disk) gèrent le stockage et le transfert.
Architecture : Séparation en couches
Le système est structuré par couches :
- Backend : Traitement des données avec pandas, logique métier.
- Interface web : Couche API, frontend pour les utilisateurs.
- Clients : Bot Telegram comme une interface.
- Intégrations : OAuth pour Yandex.Disk, API Google Sheets.
Cette séparation permet de changer les interfaces indépendamment de la logique. Les restrictions de politique d'entreprise (pas d'accès direct à la base de données sans proxy) ont nécessité cette approche.
Résolution des problèmes de fichiers volumineux
Le moment clé fut de contourner les limites de Telegram. Intégration avec Yandex.Disk via OAuth : le bot accepte un lien, le backend télécharge et traite le fichier. Cela a fourni stabilité et vitesse sans dépendances aux limitations de plateforme.
UX pour les outils internes
Les outils internes négligent souvent l'interface, mais des améliorations simples sont cruciales :
- Indicateurs de progression du traitement.
- Boutons et formulaires clairs.
- Adaptabilité aux appareils mobiles.
Cela améliore l'utilisabilité : le système devient un outil pour un usage quotidien.
Environnement de développement : De PyCharm aux agents IA
Le développement s'est déroulé dans PyCharm pour la recherche de données et le débogage. Passer à Cursor avec des agents IA a accéléré les tâches routinières :
- Génération de code passe-partout.
- Refactorisation simple.
- Encapsulation de nouvelles fonctionnalités.
Cursor est efficace pour l'architecture et le développement web. PyCharm reste pour l'analyse approfondie des données. Une approche hybride : IA pour l'automatisation, outils classiques pour les tâches complexes. Tester Claude Code et n8n pour les intégrations IA dans le traitement des données est prévu.
Résultats et économies
Le système a économisé 150 heures mensuelles pour l'équipe d'analyse. Le changement clé fut d'abandonner Telegram comme centre : ajouter des interfaces et des intégrations est devenu possible sans risque de rupture.
Ce qui compte :
- Extraire progressivement le backend du bot a rendu le système évolutif.
- L'intégration Yandex.Disk a résolu les problèmes de limites de fichiers.
- Séparer l'interface utilisateur et la logique a simplifié le développement.
- Les agents IA dans Cursor ont accéléré le développement passe-partout.
- L'interface web a ajouté le contrôle des processus.
Leçons et plans de développement
Conclusions : commencer par un MVP, puis refactoriser au fur et à mesure de la croissance. Ne pas construire une architecture parfaite immédiatement. Des outils comme Cursor impactent la productivité.
Prochaines étapes : analytique BI dans le web, tableaux de bord, conteneurisation Docker. Ceci est du matériel technique pour les développeurs intermédiaires/seniors construisant des systèmes internes.
— Editorial Team
Aucun commentaire pour le moment.