Un fondateur licencie ses développeurs et fait évoluer son CRM avec Claude Code : 22 suites de tests

Une situation familière pour tout fondateur : le produit a été construit pendant des années, l'équipe a dû être dissoute, mais le code est resté. L'auteur de cette histoire développait depuis plusieurs années un CRM pour travailler avec des leads sur Telegram. Lorsque les développeurs ont été licenciés, il s'est retrouvé seul face à un système qu'il n'avait pas écrit. Il a raconté sur Habr comment il s'en est sorti avec l'aide de Claude Code.

Ce qu'il a hérité

Le système se compose de six services : une interface d'administration en React, le backend principal en FastAPI avec MongoDB et Redis, un moteur d'envoi en arrière-plan, un module de gestion de comptes Telegram réels via Telethon, l'enrichissement des leads et la réception des demandes depuis le site. Le tout repose sur Docker et GitLab CI.

La logique du produit est elle aussi un héritage de l'équipe. Elle comprend six blocs : l'accueil des nouveaux membres de groupes, les campagnes à partir de modèles, la relance de ceux qui n'ont pas répondu, les groupes d'introduction, les messages à froid et un analyseur des membres actifs pour une prise de contact personnalisée.

Il y a aussi eu de mauvaises surprises. Dans les six dépôts, il n'y avait pas un seul test automatisé, alors que pytest figurait dans les dépendances. Trois scripts auxiliaires contenaient des mots de passe de base de données. Le problème le plus grave ne se trouvait pas dans le code : tous les leads étaient stockés dans une seule base MongoDB, dont il n'existait aucune copie. Le code peut être récupéré depuis GitLab, pas les données.

Comment Claude Code a travaillé

La première étape a été un audit. Le token GitLab était en lecture seule, l'original ne risquait donc rien. Claude a cloné 10 dépôts, lu les README, déduit les liens entre services à partir des clés env et de docker-compose, puis dessiné une carte du système.

La deuxième étape fut inattendue. L'auteur comptait écrire un nouveau CRM de zéro, mais après l'audit, l'assistant lui a dit que ce n'était pas nécessaire : le système était correctement écrit et il fallait le renforcer. D'abord les tests et les secrets, ensuite des modifications par petits blocs.

Troisième étape : autour de l'ancien système est apparue une seconde couche, reposant sur des bases SQLite locales contenant les leads, la correspondance personnelle et les discussions. La base de leads compte aujourd'hui environ 99 000 enregistrements, et la nouvelle couche 22 suites de tests.

Quatrième étape : l'assistant et l'auteur ont identifié ensemble des lacunes dans le produit. Tous les blocs fonctionnaient uniquement vers l'extérieur, de l'auteur vers la personne. Il n'y avait pas de scénario pour ceux qui venaient d'eux-mêmes, ni de champ « en quoi la personne est utile », ni de date après laquelle la fiche d'un lead devient obsolète.

Comment le processus est organisé

L'auteur formule la tâche avec ses propres mots, souvent à la voix. Claude ouvre une session dédiée, lit le code et les données réelles, puis explique ce qui va changer et ce qui risque de casser. Il écrit ensuite un petit script et des tests. Le résultat est en outre examiné par d'autres modèles : Codex, Grok et Gemini. L'auteur trouve cela plus fiable.

Tous les envois vers Telegram passent par safe_send.py, et budget.py calcule les limites, généralement 5 messages par jour et par compte. La nuit, le CRM s'occupe de lui-même : il télécharge les conversations, recalcule quels leads sont chauds et rappelle les dates promises. Ce sont de simples scripts sans LLM, si bien que les tokens sont presque inutilisés et que l'évolution du produit se fait via l'abonnement.

Limites et conclusion

L'article est écrit à la première personne et n'a fait l'objet d'aucune vérification indépendante. Aucun chiffre d'économies n'est donné, seulement l'expression « beaucoup moins cher ». L'auteur reconnaît lui-même honnêtement que les programmeurs ont construit le produit, et que l'IA l'a lu et amélioré.

Trois enseignements pratiques. Premièrement : avant de réécrire un code hérité, demandez à l'agent de réaliser un audit et une carte des services en lecture seule. Deuxièmement : d'abord les tests et la sauvegarde des données, ensuite les nouvelles fonctionnalités. Troisièmement : tout ce qui peut fonctionner sans LLM doit être confié à de simples scripts. Ainsi, vous ne payez l'IA que pour le développement, et non pour chaque tâche nocturne. Pour les petites équipes et les fondateurs solo, c'est un schéma viable, à condition d'avoir de la discipline et un filet de sécurité sous forme de tests et de limites.