Reprendre une application créée avec l’IA : du prototype à la production

Vous avez créé une application avec l’IA. Les écrans existent, la démonstration fonctionne et les premiers utilisateurs comprennent l’intérêt du produit. Mais chaque nouvelle fonctionnalité semble casser autre chose. Un changement de formulaire perturbe la connexion. Les données de test sont encore mélangées aux données réelles. Le déploiement dépend d’une suite de manipulations que personne n’a documentée.

Cette situation ne signifie pas que votre projet est à jeter. Elle indique qu’il faut changer de méthode pour passer du prototype à un logiciel exploitable au quotidien.

Reprendre une application créée avec l’IA consiste à comprendre ce qui fonctionne, identifier les risques réels, puis sécuriser les évolutions sans réécrire inutilement l’existant. L’objectif est concret : permettre aux utilisateurs de travailler, à l’équipe de livrer et au produit de continuer à évoluer.

Chez CrazyDev, cette approche s’inscrit dans nos missions de développement sur mesure et de modernisation d’applications. Voici comment aborder une reprise technique, ce qu’un audit de code IA doit examiner et les décisions à prendre avant de mettre votre application en production.

Application créée avec l’IA : de quoi parle-t-on ?

Une application créée avec l’IA peut recouvrir des situations très différentes : un fondateur qui construit son premier outil avec un générateur, une équipe qui utilise un assistant de développement, ou des développeurs expérimentés qui délèguent une partie des modifications à des agents.

Le terme « vibe coding » désigne souvent une démarche où le produit évolue principalement par instructions en langage naturel et essais successifs. Cette démarche peut aider à explorer un besoin, comparer des interfaces et obtenir un premier résultat. Elle devient plus délicate lorsque les changements s’accumulent sans compréhension suffisante du code et des données.

L’origine du code ne suffit pas à juger sa qualité. Un projet assisté par IA peut être structuré, testé et maintenable. Un projet écrit entièrement à la main peut présenter les mêmes défauts qu’un prototype généré rapidement. L’audit doit donc examiner des faits : règles métier, permissions, architecture, dépendances, tests et fonctionnement en production.

Il faut également distinguer une application développée avec l’aide de l’IA d’une application qui intègre une fonctionnalité d’intelligence artificielle. La première n’utilise pas forcément de modèle en production. La seconde doit aussi maîtriser les appels aux modèles, les coûts, les données transmises et la qualité des réponses. Ces sujets relèvent de notre accompagnement en assistants IA, agents et automatisation.

Pourquoi une démonstration réussie ne suffit pas pour la production

Une démonstration suit généralement un parcours préparé : un utilisateur connu, quelques données propres, une connexion stable et des actions exécutées dans le bon ordre. La production ajoute les situations que la démonstration n’a pas rencontrées.

Deux personnes peuvent modifier le même dossier. Un paiement peut être confirmé alors que la réponse réseau n’arrive jamais. Un utilisateur peut rafraîchir la page au milieu d’une opération. Un service externe peut ralentir, refuser une requête ou envoyer deux fois le même événement.

Prenons un exemple fictif : un outil de gestion de devis permet de passer un dossier au statut « accepté ». L’écran affiche une confirmation. Mais que se passe-t-il si le même bouton est utilisé deux fois ? Si un collaborateur n’a pas le droit de valider ce devis ? Si le montant a changé depuis l’ouverture de la page ? Ces questions concernent le fonctionnement du produit, bien au-delà de son apparence.

Passer en production demande donc de définir les comportements attendus lorsque tout ne se déroule pas comme prévu. Ce travail doit être proportionné aux conséquences d’une erreur : un outil personnel et un service qui traite les opérations de plusieurs entreprises n’ont pas les mêmes enjeux.

Les signes qu’une reprise technique devient nécessaire

Certains symptômes justifient de faire examiner le projet avant d’ajouter de nouvelles fonctionnalités :

• Une correction sur un écran provoque régulièrement des régressions ailleurs.
• Des règles métier identiques donnent des résultats différents selon la page.
• Les droits d’accès reposent surtout sur des boutons masqués dans l’interface.
• Personne ne sait expliquer précisément où sont stockées les données ou qui peut les lire.
• Le projet fonctionne sur un poste, mais son installation sur un autre échoue.
• Les mises en production demandent des modifications manuelles non tracées.
• Les erreurs ne sont découvertes que lorsque les utilisateurs se plaignent.
• L’équipe évite certaines parties du code parce qu’elle ne sait plus comment elles fonctionnent.

Un symptôme isolé ne justifie pas automatiquement une refonte. Il permet de formuler une question à vérifier. Par exemple, un build difficile à reproduire peut venir d’une configuration manquante, sans nécessiter de changer toute l’architecture.

Audit de code IA : les six points à examiner

1. Les parcours métier et leurs conséquences

La première étape consiste à identifier les actions qui rendent le produit utile : créer un compte, enregistrer un dossier, produire un document, réserver une prestation ou administrer une organisation.

Pour chaque parcours, on précise les entrées, les règles, le résultat attendu et les cas d’échec. On regarde aussi les conséquences d’une erreur : perte de données, montant incorrect, accès indu, tâche en double ou simple gêne d’affichage.

Cette cartographie évite de commencer par un grand nettoyage esthétique du code pendant que le principal risque métier reste intact. Elle donne une base commune au décideur, au développeur et à la personne qui validera les changements.

2. L’architecture et la circulation des données

Une reprise d’application React, Next.js ou Node.js commence par comprendre les responsabilités des différentes parties : interface, API, accès aux données, traitements asynchrones et services externes.

L’objectif n’est pas d’imposer un maximum de couches. Il est de savoir où une règle doit vivre et comment la modifier sans rechercher ses copies dans dix fichiers. Une règle de calcul importante ne devrait pas dépendre d’une implémentation différente dans chaque écran.

On vérifie également les dépendances : sont-elles nécessaires, comprises et compatibles avec le projet ? Un package ajouté pour résoudre un problème ponctuel peut introduire plus de complexité qu’il n’en retire. La bonne décision dépend de son usage réel, pas de sa popularité.

3. La sécurité des accès et des opérations

Un contrôle affiché dans le navigateur ne protège pas à lui seul une ressource. L’API doit vérifier que l’appelant a le droit d’exécuter l’action sur le document demandé. Cela compte particulièrement pour les applications multi-entreprises : être connecté ne doit pas permettre de lire les dossiers d’une autre organisation.

La revue examine aussi la validation des entrées, la gestion des secrets, les fichiers téléversés et les informations exposées dans les erreurs. Les catégories du Top 10 OWASP constituent un repère pour organiser cette revue ; elles ne remplacent pas une analyse adaptée au produit.

Une vérification utile consiste, par exemple, à tenter une opération avec un rôle insuffisant et à confirmer son refus côté serveur. Il faut tester ce refus, pas seulement constater l’absence du bouton dans l’interface.

4. La cohérence du modèle de données

Un écran peut paraître correct alors que les données enregistrées sont incohérentes. Deux statuts peuvent représenter la même chose. Un montant peut être recalculé selon des règles différentes. Une relation peut pointer vers un document supprimé.

L’audit examine les validations, les relations, les migrations et les opérations concurrentes. Il vérifie comment l’application réagit à une demande répétée, ainsi que les possibilités d’export et de restauration.

Les erreurs métier doivent être traitées explicitement. Enregistrer une valeur arbitraire pour éviter un message d’erreur peut transformer une anomalie visible en incohérence silencieuse, plus difficile à réparer ensuite.

5. Les tests qui protègent les usages réels

Le nombre de tests ne permet pas, à lui seul, d’évaluer la fiabilité d’un logiciel. Un test qui reproduit la logique de l’implémentation peut confirmer le même défaut. À l’inverse, quelques scénarios bien choisis peuvent protéger les opérations les plus importantes.

Avant une modification risquée, on peut écrire des tests qui décrivent le comportement actuel à préserver. On complète ensuite avec les règles métier attendues, les droits d’accès et les cas d’erreur. Les tests unitaires, d’intégration et de bout en bout répondent à des besoins différents ; leur combinaison doit rester utile et maintenable.

Faire générer les tests par une IA n’exonère pas de vérifier leurs assertions. GitHub recommande lui aussi de relire et tester le code produit par ses fonctionnalités agentiques. Une proposition de code reste une proposition à valider.

6. Le déploiement, les erreurs et l’exploitation

Une application prête à être exploitée doit pouvoir être installée, configurée et déployée de façon reproductible. Les variables d’environnement doivent être identifiées et les secrets séparés du code public.

Il faut également savoir détecter un incident et comprendre son origine : journaux utiles, suivi des erreurs, état des traitements et alertes adaptées. Les logs ne doivent pas devenir une copie incontrôlée des données sensibles manipulées par l’application.

Enfin, le retour arrière doit être préparé. Restaurer une ancienne version du code ne restaure pas automatiquement la base de données. Une migration doit tenir compte de cette différence, surtout si des utilisateurs continuent à travailler pendant le déploiement.

Faut-il corriger, refactoriser ou réécrire l’application ?

La réponse dépend de ce qui peut être conservé et du coût de transition. La réécriture complète peut sembler séduisante parce qu’elle promet un nouveau départ. Elle oblige aussi à redécouvrir des règles métier, reconstruire des parcours et gérer la migration des données.

Une décision de reprise doit comparer plusieurs options. « Tout refaire » et « ne toucher à rien » sont rarement les seules possibilités. On peut conserver une interface appréciée, remplacer un traitement fragile, puis reprendre progressivement le reste.

Une méthode pour reprendre le projet sans arrêter les évolutions utiles

Étape 1 : rendre l’existant observable et reproductible

On rassemble le dépôt, les accès nécessaires, les instructions de démarrage et les informations sur les environnements. On identifie une version de référence et on vérifie les sauvegardes avant les changements sensibles.

Le premier livrable est une compréhension partagée de l’application : ce qui fonctionne, ce qui manque et ce qui reste à vérifier. Les inconnues doivent être visibles, notamment lorsqu’un service externe ou une partie du déploiement échappe encore à l’équipe.

Étape 2 : prioriser selon le risque et la valeur métier

Chaque problème est décrit avec un exemple, un impact et une proposition de correction. On distingue les risques bloquants, les améliorations nécessaires avant une montée en usage et les sujets qui peuvent attendre.

Une erreur de permission ou une perte de données mérite une priorité différente d’un composant un peu long. Cette hiérarchie permet de discuter du budget à partir d’éléments concrets et de définir un premier lot réaliste.

Étape 3 : livrer des changements limités et vérifiables

La reprise avance par modifications dont l’effet peut être expliqué, testé et relu. Une règle métier est centralisée, un parcours reçoit des tests, une intégration est isolée ou le déploiement est automatisé.

Les améliorations sont présentées régulièrement. L’équipe produit peut vérifier que les usages restent couverts et signaler les écarts avant qu’ils se propagent. Cette progression conserve de la visibilité sur les résultats du travail technique.

Étape 4 : transmettre une base que l’équipe peut maintenir

La mission ne s’arrête pas lorsque les tests passent. Les décisions structurantes, les commandes utiles, les paramètres et les procédures d’incident doivent être accessibles à ceux qui reprendront le projet.

Une bonne transmission permet à un autre développeur de démarrer, de comprendre une fonctionnalité et de livrer une modification sans dépendre d’une personne unique. Elle évite que la reprise crée une nouvelle dépendance difficile à gérer.

Retour d’expérience : industrialiser des applications chez Sillant

La mission React et qualité logicielle chez Sillant illustre ce type d’intervention. De juillet à décembre 2025, Anthony a accompagné une équipe de cinq personnes dans la transformation de bases de code générées avec l’IA en applications adaptées à la production.

Le travail décrit dans ce parcours associait des standards de qualité avec ESLint et Prettier, des tests unitaires et de bout en bout avec Cypress et Playwright, ainsi que des déploiements automatisés vers les environnements de staging et de production. La collaboration s’appuyait sur les pull requests, les issues et les tableaux de projet GitHub.

Les ateliers, démonstrations et corrections d’anomalies accompagnaient cette structuration. Cette expérience souligne une dimension souvent sous-estimée : reprendre le code implique aussi de donner à l’équipe des pratiques qu’elle peut appliquer après l’intervention.

D’autres contextes demandent une attention différente. Le travail sur les API bancaires NestJS chez Linxo porte notamment sur la modularité du backend et les intégrations. La mission EasierLabs dans les parcours de santé et d’assurance met en jeu des règles métier, des documents et des transitions de statut. Le plan de reprise doit suivre ces contraintes propres au produit.

Quel budget et quel délai prévoir pour un audit ou une reprise ?

Un nombre d’écrans ne suffit pas pour estimer le travail. Une interface simple peut cacher des calculs complexes, plusieurs profils d’accès et des intégrations difficiles à tester. À l’inverse, un grand nombre de pages peut reposer sur une structure répétitive et bien organisée.

Les principaux facteurs sont l’état du code, la disponibilité des accès, la qualité des données, le nombre d’intégrations et les exigences de continuité de service. Le besoin d’une migration ou l’absence de tests sur les parcours critiques influencent aussi l’effort.

Pour obtenir une estimation exploitable, préparez une démonstration du produit, les problèmes observés, vos priorités et les contraintes de lancement. Un accès de lecture au dépôt et une description de l’hébergement permettront ensuite d’affiner l’analyse. N’envoyez pas de secrets ni de données clients dans un premier message.

L’audit doit aboutir à une proposition compréhensible : éléments à conserver, risques constatés, corrections prioritaires et hypothèses d’estimation. Une promesse de réécriture rapide sans examen préalable ne donne pas cette visibilité.

Continuer à utiliser l’IA après la reprise

Une fois le socle stabilisé, les outils d’IA peuvent rester utiles pour préparer des tests, explorer une modification ou accélérer des tâches répétitives. Il faut leur fournir le contexte du projet : conventions, documentation, limites du périmètre et commandes de validation.

Les modifications doivent rester lisibles et leur résultat contrôlable. Si une proposition ajoute une dépendance, modifie une permission ou supprime un test, l’équipe doit pouvoir en expliquer la nécessité. Un agent qui produit plus de code ne produit pas automatiquement plus de valeur.

Pour les produits qui embarquent eux-mêmes de l’IA, cette discipline s’étend aux évaluations des réponses, aux outils appelés par les agents et aux droits sur les données. La référence DentistryGPT sur les assistants, agents et pipelines RAG présente ce second volet du travail.

Questions fréquentes sur la reprise d’applications créées avec l’IA

Peut-on reprendre un projet construit sans développeur ?

Oui, si l’on peut accéder aux éléments nécessaires : code lorsqu’il est exportable, données, services utilisés et configuration de déploiement. Les possibilités dépendent de la plateforme choisie. La première étape consiste à vérifier ce qui est récupérable et les limites imposées par l’outil.

Faut-il abandonner le framework utilisé au départ ?

Pas automatiquement. Un changement de framework doit répondre à une contrainte identifiée. Si React, Next.js, Node.js ou une autre technologie couvre les besoins du produit, il peut être plus pertinent d’en améliorer l’usage que d’organiser une migration complète.

Un audit de code IA garantit-il l’absence de faille ?

Non. Un audit réduit les incertitudes dans un périmètre donné et permet de corriger des problèmes identifiés. Il doit préciser les vérifications réalisées et leurs limites. La sécurité demande aussi des pratiques de développement, des mises à jour et un suivi dans le temps.

Peut-on conserver les fonctionnalités déjà utilisées ?

C’est généralement un objectif de la reprise. Il faut identifier les comportements utiles, les documenter et les protéger par des validations adaptées. Si une évolution modifie un parcours, elle doit être décidée explicitement et accompagnée lorsque des utilisateurs en dépendent.

Peut-on poursuivre le développement pendant la remise à niveau ?

Souvent, avec un périmètre organisé et des priorités communes. Certaines évolutions peuvent continuer pendant que des parties ciblées sont consolidées. En revanche, un risque critique sur les accès ou les données peut justifier de suspendre temporairement le parcours concerné.

Faire le point sur votre application avec CrazyDev

Vous avez un prototype créé avec l’IA, une application qui accumule les régressions ou un produit que vous souhaitez ouvrir à vos premiers clients ? Nous pouvons vous aider à déterminer ce qui doit être conservé, corrigé et préparé avant la prochaine étape.

Basé à Saint-Raphaël dans le Var, CrazyDev accompagne les projets à distance, du cadrage technique au développement et au suivi de production. Notre travail couvre la reprise d’applications, le développement full-stack, les API et l’intégration d’intelligence artificielle.

Parlons de votre application et de vos priorités. Présentez-nous ce que fait le produit, ce qui vous bloque et ce que vous voulez rendre possible : ce sont les meilleurs points de départ pour une reprise utile.