Reprendre les systèmes défaillants construits par IA : audit, sauvetage, correction ou migration
Service de reprise de systèmes cassés et inachevés (créateurs d'apps IA, Claude/ChatGPT, « constructeurs de systèmes ») : audit, sauvegarde des données d'abord, puis corriger, migrer ou reconstruire.
Projet de démonstration
Une entreprise a payé pour un système censé supprimer le travail manuel. La démo semblait convaincante, mais dans les opérations quotidiennes, il casse : des enregistrements se corrompent en silence, des erreurs tournent en boucle, personne ne peut rien changer sans casser autre chose — et le constructeur d'origine a disparu ou propose une refonte complète. Le dirigeant reste avec des coûts engloutis, une dépendance opérationnelle et aucune sortie.
TL;DR
| Étape | Ce que vous avez aujourd’hui | Ce que vous avez après |
|---|---|---|
| Verdict | « Personne ne peut me dire si c’est récupérable » | Une réponse écrite : corriger, migrer ou retirer — avec le coût de chaque voie |
| Données | Coincées dans un système fragile à moitié construit | Exportées et sauvegardées avant que quiconque ne touche à quoi que ce soit |
| Opérations | Des contournements quotidiens autour de flux cassés | Des flux stabilisés qui survivent aux changements et aux nouveaux employés |
| Propriété | Le constructeur détient les clés | Vous les détenez : code, données, documentation et accès de déploiement |
Cette page décrit le service et l’ordre exact du travail. Les articles liés en bas contiennent les prix vérifiés et les calculs de coût qui le sous-tendent.
Le problème : « C’était terminé à 95 % » il y a six mois
C’est aujourd’hui l’une des situations les plus courantes que je rencontre. Un système a été construit avec un créateur d’apps par IA (Replit, Lovable, Bolt, Bubble), généré de bout en bout avec Claude, ChatGPT ou Cursor par un « constructeur de systèmes » freelance, ou assemblé à partir de blocs no-code — et la démo fonctionnait réellement. Puis les vraies opérations ont commencé, et le tableau a changé :
- Ça marche pour une personne et casse pour l’équipe. Le fondateur arrive à le piloter ; un nouvel employé se heurte à des erreurs dès le premier jour.
- Les données vivent dans des endroits fragiles. La moitié dans Google Sheets, l’autre moitié dans la base privée du créateur, une partie uniquement dans le compte du fournisseur d’IA. Personne ne peut dire où se trouve la copie maître.
- Les erreurs sont silencieuses. Clients en double, commandes qui disparaissent entre deux étapes, chiffres qui ne se réconcilient pas en fin de mois — découverts des semaines plus tard, par les clients ou par votre comptable.
- Chaque changement en casse deux autres. Pas de tests, pas d’historique de versions qui veuille dire quelque chose, pas de documentation de ce que le code fait réellement.
- Les factures continuent de courir. Abonnement du créateur, consommation de tokens IA, frais par utilisateur — pendant que le système payé reste à moitié utilisable.
- Le constructeur a disparu — ou répond à chaque demande par un devis de refonte complète.
L’argent englouti n’est pas le pire. Le pire, c’est la dépendance opérationnelle : votre équipe fait passer le travail quotidien par un système que personne ne peut réparer, étendre, ou même arrêter sans risque.
Ce que je reprends
- Projets issus de créateurs d’apps par IA — Replit, Lovable, Bolt, Bubble et similaires, dans tous les états, de « presque fonctionnel » à « abandonné en cours de construction ».
- Systèmes générés avec Claude, ChatGPT ou Cursor par un freelance ou un passionné interne, sans revue d’ingénierie derrière.
- Systèmes no-code au plafond — AppSheet, Retool, Glide, chaînes Zapier/Make devenues ingérables.
- Prototypes d’agents IA qui brûlent des tokens, répondent de façon peu fiable ou n’ont jamais été terminés.
Une note honnête : parfois le verdict est « garder l’essentiel, corrigez deux choses précises » — et la mission s’arrête là, à bas coût. Vous obtenez aussi cette réponse, avec le raisonnement par écrit.
Comment se déroule une reprise — l’ordre de mon travail
Étape 1 — Un appel de appel de cadrage de 20 minutes
Vous me montrez ce qui fait le plus mal et ce que vous avez. Je vous dis immédiatement si c’est le type de projet que je reprends et combien coûte le premier regard. Aucun engagement au-delà de cet appel.
Étape 2 — Inventaire et accès
Avant tout jugement : une liste complète de ce qui existe réellement — comptes, code, feuilles de calcul, bases de données, abonnements, intégrations, et où vivent les vraies données. Dans les projets inachevés, cette seule étape fait généralement remonter des choses que le dirigeant ignorait (et des abonnements dont personne ne se souvenait).
Étape 3 — Sauvegarde avant tout
Un export complet, en lecture seule, de chaque enregistrement métier, avant le moindre changement. Quoi qu’il arrive ensuite — correction, migration ou décision de retirer le système — vos données sont déjà en sécurité et entre vos mains. Cette étape ne présente aucun risque pour les opérations quotidiennes.
Étape 4 — Audit et verdict
J’examine comment le système est construit et où il casse réellement, puis je vous donne un verdict écrit :
- corriger sur place — ce qui est cassé exactement, ce que la réparation coûte, et ce qui restera faux ensuite ;
- migrer — ce que coûte une reconstruction sur des bases saines, en argent et en temps calendaire, avec vos données existantes transférées ;
- retirer — parfois le système résout un problème que vous n’avez plus, et la bonne décision est de l’éteindre proprement.
Vous choisissez la voie avec de vrais chiffres, pas avec de l’espoir.
Étape 5 — Stabilisation
Quelle que soit la voie choisie, les opérations quotidiennes doivent survivre aux travaux : les boucles d’erreurs sont arrêtées, les factures IA dérapées sont plafonnées, et les deux ou trois flux dont votre équipe dépend le plus reçoivent des étaiements temporaires, pour que personne ne travaille des mois en contournant un système cassé.
Étape 6 — Corriger sur place, ou migrer
Pour une correction : des changements bornés, chacun vérifié contre une liste d’acceptation en langage clair que vous approuvez — pas de « croyez-moi, ça marche maintenant ».
Pour une migration : les données sont modélisées proprement, déplacées avec validation à chaque étape (comptages de lignes, totaux de contrôle, vérifications ponctuelles que vous pouvez lire), et les anciens et nouveaux systèmes tournent en parallèle jusqu’à réconciliation. Votre équipe bascule quand les chiffres coïncident — pas avant.
Étape 7 — Bascule et passation
Un rapport de réconciliation du fonctionnement en parallèle, une démonstration pour l’équipe, une documentation qu’une personne non technique peut suivre, et le tout dans des comptes qui vous appartiennent. Aucun enfermement : n’importe quel développeur compétent peut le reprendre après moi — c’est délibéré.
Ce que vous obtenez
- Un verdict en quelques jours, pas en quelques mois — la vraie question de la plupart des dirigeants (« est-ce récupérable ? ») reçoit tôt une réponse écrite, pour un coût fixe modeste.
- La sécurité des données comme première étape, pas comme après-pensée.
- Un système que votre équipe peut modifier sans crainte — avec des tests comme filet de sécurité et un propriétaire qui détient toutes les clés.
- Abonnements zombies et fuites de tokens trouvés et stoppés — qui paient souvent la mission à eux seuls.
Pour aller plus loin — les chiffres derrière ce service
- Votre app Replit ou Lovable n’est pas prête pour la production : le vrai coût des logiciels construits par IA — ce qu’il y avait à l’intérieur d’un sauvetage Replit à cinq chiffres : ce que couvre l’abonnement à 25 $ par mois et ce qu’il ne couvrira jamais.
- Le vrai coût d’AppSheet avec 20 utilisateurs — et pourquoi un agent IA ne peut pas le sauver — le calcul par siège, et pourquoi une configuration uniquement par clics ne peut pas être pilotée par un agent IA.
- Retool avec 20 utilisateurs : le calcul par siège que personne ne fait avant de s’abonner — le calcul par siège et par exécution mesurée à faire avant de s’engager sur une plateforme de construction.
- Préparer les données de votre entreprise pour les agents IA — la checklist que je déroule avant qu’une fonctionnalité IA ne touche vos données.
- Des centaines de prompts plus tard, toujours pas de système fiable — pourquoi multiplier les prompts ne répare jamais un processus cassé, et ce qui le répare.
Questions fréquentes
Mon projet est-il récupérable, ou faut-il tout refaire ? C’est exactement ce que l’audit répond. Certaines reprises se terminent par une correction de deux semaines ; d’autres sont des refontes honnêtes avec reprise des anciennes données. Les deux réponses viennent avec des chiffres, et vous choisissez.
Le constructeur d’origine a disparu ou ne répond plus. Pouvez-vous quand même travailler dessus ? En général, oui — si vous contrôlez les comptes sur lesquels le système tourne (ou pouvez les récupérer). L’étape d’inventaire établit exactement ce qui est accessible et ce qui ne l’est pas.
Devons-nous quitter la plateforme actuelle ? Non. Si la plateforme est saine et que seule la construction est cassée, corriger sur place est la voie la moins chère. La migration se recommande quand la plateforme elle-même est le plafond — et l’audit dit dans laquelle des deux situations vous êtes.
Vous voulez un verdict sur votre projet bloqué ?
Apportez-le à une appel de cadrage de 20 min. vous repartirez de l’appel en sachant si votre système est récupérable, quelle est la prochaine étape réaliste et ce qu’elle coûte — même si vous ne m’engagez jamais.