Système d'approvisionnement Telegram : Cas de développement agentique sans code

# Comment un Tech Lead a Construit un Système d'Achats dans Telegram Sans Écrire de Code : Étude de Cas en Développement Agentique

Quand les achats internes dans l'équipe ont tourné au chaos avec des demandes perdues et des requêtes non coordonnées, le tech lead a décidé de créer un système basé sur Telegram. Sans écrire une seule ligne de code, en utilisant des systèmes agentiques et une architecture claire, il a construit une solution avec OCR, modération et déploiement sécurisé. Voici comment faire sans perdre le contrôle de la qualité.

Problème : Chaos au Lieu d'un Processus d'Achats

Dans les petites équipes, les achats commencent souvent par des accords informels. D'abord des bouts de papier, puis des notes, puis un fil dédié dans Telegram. Un processus émerge : déposer le lien, le prix, la quantité et la justification. Mais en pratique, certaines demandes se perdent, d'autres passent à travers les mailles du filet, certaines manquent de prix ou de justification, et les gens oublient leurs propres demandes. Résultat : le tech lead passe son temps à combattre le chaos au lieu de gérer les achats. Leçon clé : si un processus implique de l'argent, il ne devrait pas exister sous forme de chat libre.

Exigences en Infrastructure : Du « Petit Bot » à un Système Complet

L'idée initiale — un simple bot Telegram — s'est rapidement heurtée à des défis d'infrastructure. En raison de l'instabilité de Telegram sans VPN, il fallait :

• Un VPS étranger
• Une configuration VPN personnalisée
• Un redémarrage automatique fiable
• Un déploiement pratique
• Un mécanisme de rollback pour les releases défaillantes

Ce n'est plus un « script du soir », mais une véritable chaîne d'ingénierie. L'expérience montre : la « simple automatisation » cache souvent une infrastructure complexe en dessous.

Développement Agentique : Accélérateur, Pas Remplacement de la Pensée

Le projet a été réalisé avec ChatGPT et un système agentique, mais l'implication active du tech lead était essentielle. Le processus incluait :

• Formulation de la tâche et assignation des rôles
• Clarification de la logique métier
• Tests manuels des scénarios
• Identification des contradictions et bugs
• Itérations sur des correctifs ciblés
• Retests

L'agent a accéléré le cycle : en raccourcissant le temps entre la détection d'un problème et la vérification d'une nouvelle implémentation. Leçon clé : on peut déléguer la syntaxe du code, mais la pensée systèmes et l'architecture restent critiques. Sans un modèle de processus clair, l'agent ne fait qu'accélérer l'implémentation d'une logique défaillante.

Abandon du « Magic » : Passage à un Flux en Assistant

La première hypothèse — extraction automatique des données à partir des liens — s'est avérée non viable en raison de :

• La diversité des sites
• Les structures de pages instables
• Les prix ambigus
• Le rendu de données complexe
• La logique hostile des places de marché

À la place, un flux en assistant a été implémenté :

• Joindre une capture d'écran
• Fournir le lien
• Écrire la justification
• Spécifier la quantité
• Saisir manuellement le prix si nécessaire (si OCR échoue)
• Vérifier la carte finale avant confirmation

Cette approche est moins « wow », mais assure la contrôlabilité — le facteur clé pour les processus opérationnels.

Pourquoi le LLM N'Était Pas au Cœur du Système

Bien que tentant d'utiliser un LLM pour traiter les demandes, une pile simple a été choisie :

• Python
• Framework de bot Telegram
• SQLite
• OCR local
• Rapports HTML sur templates
• systemd pour les services et timers

Raisonnement :

• Fonctionne sur un VPS low-spec
• Aucune dépendance runtime sur des API externes
• Pas d'inférence payante par requête
• Débogage facile
• Comportement prévisible

Ce choix met en lumière un principe clé : toutes les tâches ne bénéficient pas de l'IA. Parfois, un FSM strict et une validation apportent plus de valeur que des modèles complexes.

Machine d'État : Fondement de la Fiabilité

Une demande est une entité avec un cycle de vie incluant des statuts :

• Brouillon
• En attente d'image
• En attente de lien
• En attente de justification
• En attente de confirmation
• En attente de modération
• Retournée pour révision
• Reportée à la période suivante
• Urgent
• Envoyée

Le FSM a été utilisé pour gérer ce cycle. Exemple de code :

class PurchaseWizard(StatesGroup):
    waiting_for_image = State()
    waiting_for_link = State()
    waiting_for_reason = State()
    waiting_for_qty_lots = State()
    waiting_for_lot_size = State()
    waiting_for_manual_price = State()
    waiting_for_confirmation = State()

et statuts métier :

class PurchaseStatus(str, Enum):
    DRAFT = "draft"
    AWAITING_IMAGE = "awaiting_image"
    AWAITING_LINK = "awaiting_link"
    AWAITING_REASON = "awaiting_reason"
    AWAITING_QTY = "awaiting_qty_lots"
    AWAITING_CONFIRMATION = "awaiting_confirmation"
    COMPLETE = "complete"
    PENDING_MODERATION = "pending_moderation"
    RETURNED_FOR_REVISION = "returned_for_revision"
    APPROVED = "approved"
    CANCELLED = "cancelled"
    SENT = "sent"

Quand des rôles, de l'argent et des délais sont en jeu, passez de la gestion des messages à la gestion d'états.

Architecture : Simplicité comme Signe de Maturité

Schéma du système :

Telegram user
    ↓
Bot handlers / FSM
    ↓
Purchase service
    ├── SQLite
    ├── OCR service
    ├── Moderation logic
    ├── HTML report builder
    └── Reminder / maintenance jobs
            ↓
        systemd service + timers

Structure du projet :

purchase_bot/
├── app/
│   ├── bot/
│   ├── db/
│   ├── services/
│   ├── templates/
│   └── main.py
├── data/
│   ├── uploads/
│   ├── reports/
│   └── bot.db
├── scripts/
├── deploy/
└── README.md

Sauter Docker et les DB lourdes en première version a permis de se concentrer sur la fonctionnalité. Pour les outils internes, une architecture simple est un signe de maturité, pas de faiblesse.

UX Telegram : Interface Plutôt que Flux de Messages

Travailler avec Telegram a révélé des défis :

• Boutons anciens persistants
• Cartes superposées
• Versions parallèles anciennes et nouvelles des demandes
• Retards de notifications
• Comportement incohérent du bouton « Retour »
• Boucles d'écran
• Encombrement du chat

Solution : concevoir le bot comme un système d'états basé sur des écrans. Principes clés :

• Un seul écran actif
• Suppression des messages obsolètes
• Gestion sécurisée des anciens boutons de callback
• Règles séparées pour les menus, notifications et cartes de travail

Cette approche, bien que peu spectaculaire, assure une utilisabilité quotidienne.

Les Vrais Processus Brisent la Symétrie

Implémenter la modération, les demandes urgentes et les reports périodiques a montré que les vrais processus ne correspondent pas à des diagrammes nets. Par exemple, une seconde étape de modération peut ajouter une friction inutile si la première a fully géré la demande. La logique a dû être reconstruite pour les besoins réels, pas pour les diagrammes. Les tech leads connaissent ce pattern : si le schéma entrave le flux, cassez le schéma.

Les Bugs les Plus Sournois aux Frontières des Couches

Les erreurs critiques sont apparues non dans les fonctionnalités cœur, mais aux intersections de couches. Par exemple :

• Bouton « Confirmer » bloqué à cause d'une comparaison d'objets timezone-aware vs. timezone-naive
• Incompatibilités de formats de données entre modules
• Problèmes de synchro d'états lors des mises à jour

Ces bugs soulignent l'importance d'un design soigné des interfaces de composants.

Leçons Clés

• Architecture avant agents : Même avec des systèmes agentiques, une architecture claire et une pensée systèmes sont obligatoires. Les agents accélèrent l'implémentation mais ne remplacent pas le design.
• Contrôlabilité avant « intelligence » : Pour les processus opérationnels, la fiabilité et la simplicité l'emportent sur l'automatisation complexe. Les flux en assistant surpassent souvent les tentatives d'automatisation totale.
• États, pas messages : Avec des rôles, de l'argent et des délais, concevez comme un cycle de vie géré avec des statuts explicites.
• Simplicité comme stratégie : Pour les outils internes, évitez le gonflement architectural. Une pile minimale sur du hardware modeste assure fiabilité et maintenance facile.
• UX Telegram exige de la discipline : Les bots doivent être conçus comme des systèmes d'écrans, pas des flux de messages. Supprimer les éléments obsolètes et un seul écran sont critiques pour l'expérience utilisateur.

— Editorial Team