[GN] Non-développeur + Claude en production pendant 238 jours — qu’est-ce qui a marché et qu’est-ce qui n’a pas marché ?

(chajooin.com)

7 points par workdriver 2026-04-12 | 5 commentaires | Partager sur WhatsApp

Je suis l’exploitant qui a créé chajooin.com. Niveau bac, 8 ans dans le transport par camion (depuis 2017). Sans savoir écrire une seule ligne de code, j’ai fait mon premier commit avec Claude le 16 août 2025. 238 jours ont passé, et aujourd’hui ce service collecte automatiquement des données chaque jour et publie des rapports.

Ce texte n’est pas le récit de « j’ai construit quelque chose », mais bien celui de « j’ai construit et je l’exploite en production ». On voit beaucoup de retours d’expérience sur des prototypes réalisés en vibe coding, mais plus rarement sur la continuité de l’exploitation en production, d’où cet article. Ce n’est pas un success story, mais un compte-rendu honnête de ce qui a fonctionné et de ce qui n’a pas fonctionné.

Contexte

Domaine : comparaison des prix de camions de fret (marché de 17 000 milliards de wons, sans registre officiel des prix de transaction réels)
Tentative précédente : projet clé en main sous-traité en 2024 pour 30 millions de wons → abandon, car le contrôle des modifications restait chez le prestataire
Transition : 2 mois d’apprentissage de l’IA en juillet 2025 → premier commit le 16 août

Stack

Frontend    Vite + React + TypeScript + Tailwind  
Backend     Node.js + Express + Prisma  
DB          PostgreSQL (Railway managed)  
수집        Playwright (headless) + 46 parseurs par source  
ML          LightGBM (Python, 75 features)  
배포        Railway (Docker)  
자동화      Node scheduler + alertes Telegram  
AI 협업     Claude (développement principal) + GPT-4o (scripts courts / prompts)  
인증        Naver/Kakao OAuth

Je n’ai pas « choisi » cette stack. J’ai demandé à l’IA : « qu’est-ce qu’il faut utiliser pour construire ça ? », puis j’ai repris sa réponse telle quelle. En regardant après coup, c’était une combinaison raisonnable. Valeur pratique d’un agent IA : il prend à sa charge le fardeau cognitif du choix.

Chiffres (2025-08-16 ~ 2026-04-12)

Élément	Valeur
Commits totaux	3 493
Jours avec commit	189 jours
Nombre de fichiers de code	environ 1 500 (base js/ts/py)
Rollbacks	20+
Échecs de déploiement	39 (2 jours de setup Railway au début)
Nombre maximal de répétitions du même bug	7 (unité de prix)
Annonces actives	environ 48 000 véhicules
Parseurs de sources externes	46
CLAUDE.md	187 lignes, 24 règles absolues
Fichiers mémoire	129

Partie 1. Construire — 3 éléments qui ont permis de faire fonctionner le système

1.1 CLAUDE.md — piloter l’IA avec des règles

Si le même bug survient deux fois, dire « fais attention » ne sert à rien. Il faut écrire des règles précises dans un fichier et faire en sorte que l’IA les lise au début de chaque session.

"parseur=source → normalisation=÷10 000 → DB=manwons. Interdiction de faire ×10 000 sur la valeur DB"  
"si l’extraction de l’année par le parseur échoue, interdiction de substituer getFullYear()"  
"interdiction d’ajouter kakaotalk au UA rewrite de vercel.json"  
"la valeur de setInterval doit obligatoirement être clampée avec Math.min(value, 2^31-1)"

Il y en a actuellement 24. Elles sont toutes nées après un incident réel.

1.2 Séparation des rôles — conception/jugement pour l’humain, implémentation pour l’IA

Même sans savoir lire le code, on peut juger le résultat. Si un Porter 2 tonnes apparaît à 5 millions de wons, on peut dire « c’est faux ». Si un wing body et un cargo apparaissent au même prix, on peut dire « sépare-les ». L’intuition métier joue le rôle de test.

1.3 Fichiers mémoire — conserver le contexte entre les sessions

129 fichiers mémoire accumulent décisions, échecs et politiques. Lorsqu’une nouvelle session s’ouvre, l’IA lit les mémoires pertinentes pour conserver les jugements passés. C’est une structure qui compense les limites de la fenêtre de contexte de l’IA via le système de fichiers.

Partie 2. Exploitation — des problèmes différents de la construction

2.1 Ce qui tourne automatiquement

Ingestion des annonces : le scheduler collecte les données depuis des sources externes → quality gate → intégration en DB
Rapports de prix : génération automatique chaque jour → publication automatique sur blog/café
Génération de scripts courts : GPT-4o génère des scripts / prompts Sora par tonnage (la composition vidéo est une étape séparée)
Réentraînement ML : réentraînement hebdomadaire du moteur de prix avec les nouvelles données
Monitoring : alertes Telegram en cas d’anomalie du pipeline

Je suis seul développeur.

2.2 Coûts

Infrastructure : Railway (PostgreSQL + Node + Playwright)
API IA : abonnement Claude (pour le développement) + API GPT-4o (pour la génération de shorts, estimée à environ 1 $/mois sur la base de api_usage_log)
Domaine/OAuth : Naver/Kakao

2.3 Journal de réponse aux incidents

1 138 cas de corruption de données (2/3) : découverte d’un bug de fallback sur l’année → patch DB + pipeline de retraitement + ajout d’une règle
Alertes Slack inopérantes pendant 6 mois (découvert le 18/3) : problème de variable d’environnement / chemin → refonte unifiée vers un chemin unique Telegram
Overflow 32-bit de setInterval (10/4) : login bloqué → hotfix + ajout d’une règle de clamping
Écran vide sur KakaoTalk (31/1) : le SEO UA rewrite interceptait aussi le navigateur in-app de KakaoTalk → correction de la liste d’UA

2.4 Extrait des règles d’exploitation

CLAUDE.md inclut aussi des règles liées à l’exploitation.

"après déploiement, rapporter 3 chiffres : état du serveur (health 200),  
 nombre de crawls du jour (dans une plage de ±20 % par rapport à hier), nombre d’annonces actives (pas de variation brutale)"  
  
"si 4 fichiers ou plus sont modifiés, si le scheduler est concerné, si le schéma DB change,  
 ou si une zone déjà revertée est de nouveau modifiée → rapport préalable obligatoire"  
  
"les changements temporaires (fallback/TODO/hardcoding) doivent être consignés :  
 quoi doit être remis en état et avant quand, et ce qui cassera si ce n’est pas fait"

L’IA lit ces règles à chaque fois et, lorsque la situation correspond, elle fait d’abord un rapport avant de commencer le travail.

Partie 3. Ce qui n’a pas fonctionné

3.1 Le même bug répété 7 fois — incapacité à voir toute la chaîne de données

Si le bug d’unité de prix s’est produit 7 fois, c’est que, dans la chaîne collecte → parseur → normalisation → DB → API → UI, corriger un seul des 6 maillons ne fait que le laisser réapparaître ailleurs. La capacité à « voir l’ensemble » est ce qui manque le plus dans la combinaison non-développeur + IA. L’IA ne corrige que l’endroit qu’on lui désigne, et l’humain ne sait pas qu’il existe d’autres chemins.

3.2 1 138 cas de corruption de données — les valeurs par défaut « bienveillantes » de l’IA

Quand le parseur échouait à extraire l’année, du code a été ajouté pour renvoyer getFullYear(). Du point de vue de l’IA, elle a sans doute jugé que « l’année courante vaut mieux que null ». Résultat : des Porter de 2003 se sont retrouvés enregistrés en DB comme modèles 2026. Si on n’écrit pas explicitement à l’IA « si tu ne sais pas, mets null », elle remplira quand même quelque chose.

3.3 Alertes Slack inopérantes pendant 6 mois — absence de surveillance du système de surveillance

Les alertes échouaient, et cet échec lui-même n’était pas journalisé, donc tout est resté silencieux pendant 6 mois. Pendant ce temps, plusieurs anomalies de pipeline se sont produites, mais j’ai cru qu’« il n’y avait pas de problème ». Dans un système construit avec l’IA, l’état le plus dangereux est celui qui « a l’air de bien tourner ». Aujourd’hui, tout a été simplifié vers un chemin unique Telegram.

3.4 Overflow 32-bit de setInterval — piège du langage

Si on ne sait pas que setInterval n’accepte qu’un int32, on ne sait pas non plus qu’en lui donnant 30 jours en millisecondes, il s’exécutera immédiatement. Login bloqué. L’IA ne signale pas spontanément ce genre d’edge case. La règle de clamping n’est apparue qu’après l’incident.

3.5 Surapprentissage ML — MAPE d’entraînement à 8,56 % vs 42 % en conditions réelles

Avec LightGBM et 75 features, j’ai atteint une MAPE d’entraînement de 8,56 % et j’ai pensé que « c’était bon ». En réel : 42 %. Raison : limites structurelles des données de prix affichés (absence de prix de transaction réels, sous-déclaration sur contrat, marge des concessionnaires). Un expert métier l’aurait su dès le départ, mais je suis resté enfermé dans l’idée que « si les résultats d’entraînement sont bons, alors ça marche ».

Réflexions restantes

En prenant du recul après 238 jours :

L’IA accélère fortement la vitesse d’implémentation. Même quelqu’un qui ne connaît pas le code peut créer un service fonctionnel.
En revanche, la qualité d’exploitation ne suit pas automatiquement. Les incidents arrivent sans exception, et l’IA ne prévient pas spontanément.
Le travail du non-développeur se déplace de l’écriture de code vers la conception des règles, de la surveillance et de la validation. Juger les résultats et prévenir les récidives devient le vrai métier.

C’est une production exploitée seul, donc un échantillon n=1. Je n’en tirerai pas de généralisation. J’aimerais connaître l’expérience d’autres personnes dans les mêmes conditions.

Liens

Service : https://chajooin.com (comparaison et analyse des prix de camions de fret)

Vos retours sont les bienvenus. En particulier, je suis curieux de savoir comment vous surveillez seul un état qui « a l’air de bien tourner ».

5 commentaires

savvykang 2026-04-13

Le problème d’état qui semble bien fonctionner pourrait sans doute être atténué dans une certaine mesure en organisant régulièrement des exercices de reprise après incident et en définissant quelles caractéristiques des données sont considérées comme normales.

workdriver 2026-04-13

Oui, merci pour ce bon commentaire.
C’est vrai qu’à mesure que le système grossit, il devient difficile à gérer.