ERP généré par l’IA : six coincements qu’on voit trop

On ne compte plus les « ERP faits à l’IA ». Un dirigeant, un freelance, parfois une petite équipe : on décrit les écrans à un assistant, ça compile, ça ressemble à un logiciel. Le comité est content. Trois mois plus tard, on n’ose plus toucher.

Ce n’est pas que l’IA « code mal ». C’est qu’un ERP n’est pas une démo. Droits, stocks, factures, un utilisateur qui a quitté l’entreprise, une mise en production un vendredi. L’assistant enchaîne les itérations. Il n’a pas de dette. Vous si.

Les dossiers ci-dessous sont anonymisés. Accord de confidentialité avant les accès, quand le sujet est sensible.

• La démo Écrans, CRUD, un login. Ça marche sur l’ordinateur de celui qui génère.
• L’ERP Règles métier, droits, historique, sauvegardes, une prod que quelqu’un d’autre peut tenir.
• Le trou Tout ce que l’assistant n’a pas vécu : l’audit, le déploiement, le code mort, le fichier de 6 000 lignes.

1. On n’arrive pas à le finir

Cas fréquent : une PME de négoce. Le gérant a « fait l’ERP » le soir, stocks et commandes d’abord. La facturation, « on verra ». Les avoirs, les multi-dépôts, l’export comptable : jamais. Chaque nouvelle demande régénère un écran. L’ancien n’est pas branché. Au bout de six mois il y a trois façons de créer une commande. Aucune n’est complète.

L’IA accélère le début. Elle n’arbitre pas le périmètre. Sans gel, le projet n’a pas de fin. Il a une pile.

Ce qu’on fait : on arrête d’ajouter. On écrit les trois flux qui doivent marcher lundi. Le reste va au parking. Ça ressemble à une reprise, parce que c’en est une.

2. L’audit sécu arrive, et ça pique

Autre dossier, services. Avant de brancher la paie, un audit. Rapport court, brutal : clés d’API dans le front, politique RLS large ouverte, un compte admin partagé, pas de journal d’accès, mot de passe oublié dans un README généré.

Personne n’avait « voulu » ça. L’assistant a collé le plus simple pour que la démo passe. La démo n’est pas un système d’information.

On ne « finit pas les modules » dans cet état. On coupe les secrets, on borne les droits, on pose un vrai utilisateur, on sait qui a lu quoi. Parfois ça prend plus de temps que l’écran facture. C’est normal. Un ERP qui fuit, ce n’est pas un ERP en retard. C’est un incident en attente.

3. Trop d’itérations, trop de code mort

L’assistant n’efface pas. Il ajoute. Une fonction createOrder, puis createOrder2, puis handleNewOrderFix. Des composants jamais montés. Des schémas de tables en triple. Personne ne sait laquelle est vivante.

Le métier voit « 40 000 lignes, ça avance ». Le développeur qui reprend voit un grenier. Les tests n’existent pas, ou ils testent l’ancienne version.

Là, l’IA a fait ce qu’on lui demandait : encore une passe. Elle n’a pas un chef de projet. Si vous n’en avez pas non plus, le dépôt grossit jusqu’à ce que plus personne n’ose fusionner.

On cartographie ce qui est appelé en prod (ou en recette, s’il n’y a pas de prod). On jette le reste, ou on l’isole. Des tests automatiques sur les chemins métier, pas 4 000 cas pour faire joli.

4. Un fichier pour tout le projet

Oui, on le voit encore. app.js, page.tsx, backend.py : un monolithe d’un seul tenant, généré puis rallongé. L’assistant aime ça. Tout est sous les yeux. Jusqu’au conflit, jusqu’au bug qu’on ne retrouve plus, jusqu’au moment où deux personnes doivent travailler.

Ce n’est pas une question de mode. C’est qu’un ERP a des bords : stocks, tiers, factures, droits. Si tout tient dans un fichier, il n’y a pas de bords. Il n’y a qu’une bouillie.

Découper n’est pas « tout refaire ». C’est rendre le système lisible. Un dossier, une responsabilité. Ensuite on peut tester. Avant, non.

5. Le stack du tutoriel, pas celui du métier

Supabase, Firebase, un auth magic-link, une base « assez bonne ». Pour un prototype interne de six utilisateurs, ça peut tenir. Pour un ERP avec des établissements, des rôles, de la donnée perso, un hébergement UE écrit au contrat : parfois oui, souvent non — ou pas comme ça.

Le problème n’est pas « Supabase c’est mal ». Le problème, c’est le choix par défaut de l’outil qui a généré le premier écran. Row Level Security mal calée. Fonctions trop privilégiées. Pas de stratégie de backup. Région cloud jamais décidée. Le jour où le DSI demande où sont les données, silence.

On recale : besoin, volume, droits, run, localisation. Make or buy. Parfois on garde l’outil en le durcissant. Parfois on sort le cœur métier. Ce n’est pas une guerre de frameworks. C’est un cadrage.

6. Personne ne sait mettre en production

Ça marche sur le portable. Le « déploiement », c’est un copier vers un VPS, ou un bouton Preview. Pas de CI. Pas d’environnement recette. Les variables d’environnement sont dans un fichier envoyé sur WhatsApp. Quand ça tombe, on ne sait pas quelle version tourne.

Un ERP sans mise en production, c’est un fichier. Les gens continuent Excel « en attendant ».

Là on pose le minimum qui tient : une branche, un pipeline, une recette, une prod, un rollback. SRE / DevSecOps à taille humaine. Pas vingt outils. Juste : on peut livrer un jeudi sans prier.

• InachevéFlux métier jamais fermés. Trois façons de faire la même chose.
• SécuAudit, secrets, droits trop larges. Prod reportée d’un coup.
• Dette IAItérations empilées, code mort, plus personne ne fusionne.
• Monolithe fichierUn seul fichier, tout le projet. Illisible à deux.
• Mauvais outilStack du tutoriel, pas du run ni du RGPD.
• Pas de prodÇa tourne en local. Personne ne déploie, personne ne rollback.

Ce n’est pas six projets. C’est souvent le même

Le client qui n’arrive pas à finir a, la plupart du temps, le fichier unique, le code mort, et pas de pipeline. L’audit arrive par-dessus. Le stack inadapté se découvre au moment d’industrialiser.

On n’attaque pas les six fronts le même jour. On regarde ce qui empêche de livrer un flux : commande, ou facture, ou stock. On rend ce flux honnête : droits, tests, déploiement. Puis le suivant.

1. Geler — plus de génération « en plus » tant qu’on n’a pas la carte.
2. Cartographier — ce qui est vivant, les secrets, où ça tourne (s’il tourne).
3. Sécuriser le minimum — clés, comptes, droits. Avant d’ajouter un écran.
4. Découper — sortir du fichier unique. Un flux, un bord.
5. Déployer pour de vrai — recette, prod, journal. Ensuite seulement le module manquant.

L’IA peut rester dans la boucle, après. Pour un correctif borné, une migration, des tests. Pas pour « refaire l’ERP ce week-end ». Les développeurs qui reprennent ont besoin d’un dépôt lisible, pas d’une nouvelle passe magique.

Si vous êtes coincé dans un de ces six cas — souvent plusieurs — un diagnostic sert à dire ce qui est tenable, ce qu’on jette, et ce que ça coûte de remettre en production. Sans promettre le même délai pour tous les dépôts.

Questions courantes

On jette tout ?

Non, sauf si c’est plus cher à détortiller qu’à recadrer un flux neuf. On le décide après la carte, pas sur un ressenti en comité.

C’est la faute de l’IA ?

Non. C’est un outil sans chef de projet. Sans périmètre, sans sécu, sans prod, n’importe quel générateur empile. Un humain seul, la nuit, aussi.

Combien de temps ?

Un dépôt petit, un flux, des accès : parfois une à deux semaines pour une première prod honnête. Un SI déjà « un peu en prod » avec de la donnée réelle : davantage. On l’annonce avant. Pas un délai unique.