Aller au contenu

Application générée par IA

Reprendre une application générée par IA et la rendre fiable

Vous avez créé, ou fait créer, une application avec Claude Code, Cursor, Codex, Lovable, Bolt ou Replit. Elle fonctionne à peu près. Il lui faut maintenant un développeur qui lise tout le code, corrige ce qui est cassé, ferme ce qui est exposé et la prépare pour de vrais utilisateurs, sans tout refaire, sauf si tout refaire coûte réellement moins cher.

Les situations qui amènent à reprendre une application générée par IA

Les outils d'IA produisent facilement quelque chose qui tourne. Voici les moments où cela cesse de suffire.

  • Le prototype a convaincu, mais il ne tient pas la charge. Dès que plusieurs personnes l'utilisent en même temps, ou qu'un utilisateur fait autre chose que ce qui était prévu, l'application se comporte mal.
  • Chaque correction en casse une autre. Le code a dépassé ce qu'une seule instruction peut tenir en vue. Les modifications arrivent sans tenir compte de ce qui en dépend.
  • Vous ne savez pas qui peut voir vos données. Il y a bien une page de connexion. Mais ce qu'un utilisateur connecté peut lire ou modifier chez les autres n'a jamais été vérifié par quelqu'un.
  • Les derniers 20 % n'arrivent jamais. Le paiement, les e-mails, l'export, l'espace d'administration ou une intégration restent en suspens, et l'outil ne sait pas dire pourquoi.
  • Il faut sortir de la plateforme. Le coût de l'abonnement, la dépendance à l'outil ou l'exigence d'un client imposent de faire tourner le code sur une infrastructure que vous maîtrisez.
  • Un prestataire a dit « il faut tout refaire ». C'est parfois vrai. C'est souvent la réponse de quelqu'un qui n'a pas lu le code. Vous méritez un second avis fondé sur le dépôt réel.
Prestations

Ce que je peux faire sur votre application

Huit types d'intervention, du second avis écrit à la reprise durable du projet.

  • Audit technique et revue de code

    Je lis l'intégralité du code, pas un échantillon, et je vous remets un rapport : ce qui est solide, ce qui est fragile, ce qui est dangereux, classé par gravité avec l'effort de correction.

  • Correction des bugs

    Reproduire le problème, trouver la cause plutôt que le symptôme, corriger et ajouter un test pour que la prochaine modification ne défasse pas la correction.

  • Revue de sécurité et correction des failles

    Authentification et droits d'accès, clés exposées, règles d'accès à la base de données, validation des saisies, dépendances obsolètes, permissions accordées aux services tiers.

  • Refactorisation et maintenabilité

    Supprimer le code dupliqué ou mort, démêler ce que l'IA a enchevêtré et donner au projet une structure qu'un autre développeur pourra reprendre.

  • Finition d'une application inachevée

    Terminer ce qui est resté en plan : paiement, notifications, imports et exports, back-office, reporting, ou la partie du processus qui n'a jamais été que simulée.

  • Intégrations et API

    Relier l'application à un prestataire de paiement, à votre messagerie, à votre CRM, à votre gestion de stock ou à vos outils internes via leurs API, avec gestion des erreurs et journalisation.

  • Préparation à la mise en production

    Configuration des environnements, gestion des secrets, migrations de base de données, sauvegardes, supervision et un déploiement reproductible, avec retour arrière possible.

  • Reprise durable du projet

    Devenir le développeur responsable d'une application née avec l'IA : les évolutions sont planifiées, relues et testées plutôt que demandées à un outil en espérant que ça tienne.

Les projets que je peux prendre en charge

L'outil qui a généré le code compte moins que deux questions : le code peut-il être exporté, et s'agit-il d'une technologie que je pratique.

  • Assistants et agents de code. Claude Code, OpenAI Codex, Cursor, GitHub Copilot et outils comparables, dès lors que le résultat est un dépôt de code ordinaire que je peux lire et exécuter.
  • Générateurs d'applications. Lovable, Bolt, Replit et plateformes similaires, à condition que le code puisse être exporté ou synchronisé vers un dépôt Git. Lovable, par exemple, documente la synchronisation GitHub sur toutes ses offres et le téléchargement du code sur les offres payantes.
  • Technologies que je pratique. PHP et Laravel, JavaScript et TypeScript avec React et Next.js, back-ends Node.js, WordPress et WooCommerce, PrestaShop, ainsi que les bases de données et hébergements associés.
  • Ce que je refuse. Les applications mobiles natives, le code qui ne peut pas sortir d'une plateforme propriétaire et les technologies que je ne pratique pas. Je préfère vous le dire au premier échange plutôt qu'à la troisième semaine.

Sécurité et maintenabilité : ce que la revue vérifie

Ces vérifications sont faites sur chaque application générée par IA que je reprends. Ce sont aussi les endroits où le code généré se distingue le plus du code écrit par quelqu'un qui en répond.

  • Qui a le droit de faire quoi. La connexion est généralement en place. Savoir si un utilisateur connecté peut lire ou modifier les données d'un autre est la question que le code généré laisse le plus souvent ouverte.
  • Clés et secrets. Clés d'API dans le code côté navigateur, dans l'historique du dépôt ou dans les journaux ; clés de service utilisées là où une clé restreinte s'imposait.
  • Règles d'accès aux données. Sécurité au niveau des lignes, filtres de requêtes, chemins d'administration qui supposent que le client est honnête.
  • Saisies et fichiers. Validation présente dans l'interface mais absente côté serveur ; téléversements sans contrôle du type, de la taille ou du chemin.
  • Dépendances et configuration. Paquets obsolètes avec vulnérabilités connues, mode débogage resté actif, CORS trop permissif, absence de limitation de débit.
  • Maintenabilité. Composants dupliqués, code mort hérité d'instructions abandonnées, absence de tests, logique dispersée qui rend chaque évolution risquée.

Les études indépendantes sur le code généré par IA relèvent de façon récurrente des failles d'autorisation, des secrets exposés et du code dupliqué, et constatent qu'une part importante de ces problèmes persiste longtemps après l'écriture du code. C'est ce que les vérifications ci-dessus sont conçues pour attraper. Je cite ces études dans les articles liés plus bas plutôt que d'avancer des statistiques qui seraient les miennes.

Audit, correction, stabilisation ou finition : choisir le périmètre

Vous n'avez pas à trancher avant notre premier échange. L'audit est conçu pour prendre cette décision à votre place, chiffres à l'appui.

  • Audit seul. Une revue écrite du code avec les constats classés par gravité et une estimation pour chacun. Utile pour obtenir un avis indépendant avant de décider quoi que ce soit, ou avant de payer quelqu'un d'autre.
  • Lever les blocages. Corriger ce qui empêche la mise en ligne ou met les données en danger, et documenter le reste pour plus tard. Le chemin le plus court vers une mise en production sûre.
  • Stabiliser et refactoriser. Lever les blocages, puis restructurer ce qui rend chaque modification risquée, ajouter des tests sur les parcours critiques et mettre en place un vrai déploiement. Pour une application appelée à évoluer.
  • Terminer l'application. Tout ce qui précède, plus la finition des fonctionnalités jamais achevées, sous forme de projet cadré avec un cahier des charges écrit.
Méthode

Comment se déroulent l'audit et la correction

  1. Accès et inventaire

    Vous me donnez un accès en lecture au dépôt, à l'hébergement et aux services utilisés. J'en dresse l'inventaire : technologies, dépendances, environnements, données, intégrations.

  2. Lecture complète du code

    Avant de modifier quoi que ce soit, je lis tout. Le rapport d'audit repose sur le code réel, pas sur un coup d'œil aux parties qui se trouvent être cassées.

  3. Rapport d'audit

    Constats classés critique, élevé, moyen et faible, chacun avec le risque qu'il porte, l'effort de correction et s'il bloque la mise en ligne. Vous pouvez vous arrêter là et conserver le rapport.

  4. Périmètre et devis

    Une proposition écrite pour la formule retenue : ce qui sera fait, dans quel ordre, le délai et le prix de ce travail précis.

  5. Corrections sur une branche, avec tests

    Le travail se fait sous gestion de versions, jamais directement sur l'application en ligne. Les parcours critiques reçoivent des tests pour que la prochaine évolution ne défasse pas la correction.

  6. Mise en production et passation

    Déploiement à l'heure convenue, avec possibilité de retour arrière, puis documentation de ce qui a changé et du fonctionnement actuel, pour que vous ne dépendiez pas de moi non plus.

Ce à quoi vous pouvez vous attendre

Je suis un développeur indépendant, pas une agence, et je travaille depuis Marrakech avec des clients dans plusieurs pays. Vous traitez donc avec la personne qui lit votre code, et je prends un nombre limité de projets à la fois. Je ne revendique aucune certification que je ne détiens pas, je ne publie ni noms de clients ni chiffres, et je ne vous dirai jamais qu'une application est « totalement sécurisée », parce qu'aucun développeur honnête ne peut le dire.

Ce que je peux promettre, c'est la méthode décrite sur cette page : tout le code lu avant tout avis, des constats écrits, un travail sous gestion de versions avec des tests, et une passation qui vous laisse libre de travailler ensuite avec qui vous voulez. Pour comprendre ce qui fait varier le coût de ce type de mission et comment choisir à qui la confier, commencez par l'article sur la reprise d'une application générée par IA. Et si vous en êtes encore à vous demander ce que le vibe coding peut raisonnablement produire, le guide à l'intention des dirigeants est fait pour cela.

Préparer votre demande de devis

  • L'outil ou la plateforme utilisé pour créer l'application, et si le code est dans un dépôt Git ou encore dans la plateforme
  • Ce que fait l'application, qui l'utilise aujourd'hui et si elle est déjà en ligne avec de vraies données
  • Ce qui est cassé, manquant ou inquiétant, avec un exemple pour chaque point si possible
  • La pile technique si vous la connaissez : langage, framework, base de données, hébergement, services tiers
  • Votre échéance, et si vous envisagez un audit, une correction ou une reprise complète

Une courte description et un lien vers le dépôt suffisent pour commencer. Si le code est encore dans une plateforme, dites laquelle et je vous expliquerai comment l'en sortir. S'il s'avère que vous n'avez pas besoin de moi, je vous le dirai aussi.

Demander un devis
FAQ

Questions sur la reprise d'une application générée par IA

Les questions qui reviennent lorsqu'une application créée avec des outils d'IA doit passer du prototype qui marche à quelque chose que l'on peut exploiter, sécuriser et maintenir.

Pouvez-vous reprendre une application créée avec Lovable, Bolt ou Replit ?

En général oui, à condition que le code puisse sortir de la plateforme. Lovable documente la synchronisation GitHub sur toutes ses offres et le téléchargement du code sur les offres payantes ; Bolt et Replit permettent aussi d'envoyer le projet sur GitHub ou de le télécharger. La base de données gérée, le stockage et les secrets restent sur la plateforme et doivent être remplacés : c'est un travail de migration classique. Les plateformes qui ne laissent pas sortir le code sont l'exception, et je vous le dirai.

Faut-il tout refaire ?

Pas par principe. Refaire est la bonne réponse lorsque l'architecture ne peut pas porter le produit, ou lorsque corriger coûterait plus cher que réécrire. La plupart des applications générées par IA ont besoin de corrections ciblées et de structure, pas d'un remplacement. L'audit sert précisément à trancher cette question avec des éléments concrets, et si refaire est réellement moins cher, je vous le dirai.

L'application sera-t-elle sécurisée après votre intervention ?

Elle aura été relue par un développeur selon les vérifications décrites sur cette page, et les problèmes trouvés auront été corrigés ou documentés. Personne ne peut honnêtement garantir qu'un logiciel est totalement sécurisé, et je ne le ferai pas. Ce que vous obtenez, c'est un état connu : ce qui a été vérifié, ce qui a été trouvé, ce qui a été corrigé et ce qui a été accepté comme risque.

Combien ça coûte ?

Cela dépend de la taille du code et de ce que révèle l'audit, donc je ne publie pas de tarifs. L'audit fait l'objet d'un devis écrit et fixe ; les corrections et la refactorisation sont chiffrées par périmètre après l'audit. L'article sur la reprise d'une application générée par IA détaille ce qui fait varier le coût.

Travaillez-vous avec des clients en France, en Belgique ou en Suisse ?

Oui. Je suis basé à Marrakech et je travaille à distance avec des clients au Maroc et en Europe, en français ou en anglais. Les échanges se font par e-mail, visioconférence et au travers du dépôt de code, et l'hébergement reste celui que vous choisissez.

Utilisez-vous vous-même des outils d'IA ?

Oui, comme des outils, chaque modification étant relue et testée par moi avant d'arriver dans votre dépôt. Le problème des applications générées par IA tient rarement à l'outil. Il tient à l'absence de quelqu'un qui soit responsable de lire ce qu'il a produit.

À qui appartient le code ensuite ?

À vous, comme avant. Le travail est livré dans votre dépôt et sur vos comptes d'hébergement. Je ne conserve ni copie de votre application ni vos données au-delà de la mission, et je ne publie pas les projets de mes clients.

Une application créée avec l'IA qui a besoin d'un développeur ?

Envoyez le dépôt ou décrivez le problème. Je vous réponds avec des questions ou une première estimation pour l'audit.

Contact

Demander un devis

Décrivez ce que vous souhaitez créer, corriger ou améliorer. Je lis votre message, je vous pose les questions nécessaires et je reviens vers vous avec les prochaines étapes ou une première estimation. Je ne publie pas de grille tarifaire : chaque devis est établi à partir de votre projet.

Parlez-moi de votre projet