Code généré par IA : audit du code Cursor avant la production

Cursor permet de produire rapidement beaucoup de code d'apparence fonctionnelle. Cette rapidité est son intérêt, et aussi son problème : vous pouvez vous retrouver propriétaire d'une base de code que personne, vous compris, n'a lue ligne par ligne. Avant l'arrivée de vrais utilisateurs, quelqu'un doit le faire. Ce guide montre comment mener un audit de code généré par IA pour que votre application Cursor soit réellement prête pour la production, et par où commencer si vous voulez un aperçu rapide de votre situation avec l'AI App Health Check gratuit.

Pourquoi le code Cursor demande sa propre revue

Cursor est un éditeur de code assisté par IA. Il n'héberge pas votre application : contrairement à un constructeur hébergé, aucune plateforme ne décide donc du fonctionnement de votre base de données, de votre authentification ou de votre déploiement. Votre code se trouve dans un dépôt que vous déployez vous-même, ce qui vous donne le plein contrôle et la pleine responsabilité. Rien n'est caché, mais rien n'est vérifié à votre place non plus.

Le code généré par IA tend à échouer de façons reconnaissables. Il est localement plausible mais globalement incohérent : chaque fichier semble correct, alors que la même règle est implémentée de trois façons différentes dans le projet. Les préoccupations transversales, comme l'autorisation, la validation et la gestion des erreurs, sont les premières à manquer, car aucun prompt isolé ne les a demandées. Pour l'angle sécurité en particulier, consultez notre article sur les risques de sécurité du vibe coding avant le lancement. Cet article porte sur le code lui-même.

Étape 1 : automatiser d'abord les vérifications peu coûteuses

Ne dépensez pas d'attention humaine sur ce qu'une machine vérifie en quelques secondes. Configurez ces contrôles une fois et exécutez-les à chaque modification.

Vérification des types et linting

Activez une vérification stricte des types (par exemple le mode strict de TypeScript) et un linter. Le code d'IA s'appuie souvent sur des types lâches, des variables inutilisées et des erreurs ignorées en silence. Un compilateur strict transforme beaucoup de ces défauts en échecs visibles. Corrigez les erreurs plutôt que de les faire taire avec des commentaires d'exclusion, et comptez combien de suppressions existent déjà : un nombre élevé est en soi un signal.

Vérification des dépendances et des licences

Exécutez la commande d'audit de votre gestionnaire de paquets et examinez le résultat. Lisez ensuite la liste des dépendances d'un œil sceptique : les paquets suggérés par le modèle peuvent être abandonnés, être des imitations aux noms mal orthographiés ou simplement être inutiles. Vérifiez que chacun existe, est maintenu et possède une licence compatible avec la façon dont vous comptez vendre le produit. Supprimez ce que vous n'utilisez pas.

Analyse des secrets, historique compris

Analysez les fichiers actuels et tout l'historique git à la recherche de clés d'API, de jetons et de chaînes de connexion. Une clé supprimée dans un commit ultérieur reste dans l'historique : renouvelez donc tout ce qui a un jour été validé dans le dépôt, au lieu de simplement le retirer. Ajoutez une analyse des secrets en pre-commit ou en CI pour que cela ne se reproduise pas.

Une chaîne CI qui conditionne les fusions

Placez les vérifications ci-dessus, ainsi que vos tests et un build de production, dans l'intégration continue, et bloquez la fusion en cas d'échec. C'est le garde-fou le plus utile pour un travail assisté par IA, car il rend le niveau d'exigence indépendant du prompt qui a produit la modification.

Étape 2 : ce qui nécessite un relecteur humain

L'automatisation détecte les problèmes mécaniques. Les points suivants demandent du jugement.

Architecture et frontières

Dessinez la carte : où entrent les données, où sont-elles stockées, où se connectent les services tiers ? Cherchez la logique métier enfouie dans des composants d'interface, les appels à la base de données dispersés dans les fichiers et le code réservé au serveur qui pourrait finir dans le bundle du navigateur. Si vous ne pouvez pas décrire la structure en un paragraphe, les nouvelles fonctionnalités continueront de se heurter. Notre présentation de l'architecture logicielle en explique le vocabulaire.

Code mort et code dupliqué

Itérer avec un assistant IA laisse des débris : fichiers abandonnés, trois versions du même utilitaire et anciennes routes qui répondent encore. Le code mort n'est pas inoffensif. Les points d'accès oubliés restent accessibles, et les doublons divergent, de sorte qu'un correctif dans une copie n'atteint jamais les autres. Supprimez ce qui est inutilisé et consolidez ce qui est dupliqué avant d'ajouter quoi que ce soit de nouveau.

Autorisation sur chaque route

Listez chaque route, gestionnaire d'API et action serveur, et notez pour chacun qui peut l'appeler et comment le code l'impose. Être connecté n'est pas la même chose qu'être autorisé. L'erreur classique est un gestionnaire qui accepte un identifiant d'enregistrement et le renvoie sans vérifier que l'enregistrement appartient à l'appelant. Si votre couche de données utilise des règles au niveau des lignes, lisez les erreurs courantes de RLS Supabase dans les applications créées par IA.

Validation des entrées et injection

Tout ce qui arrive de l'extérieur, comme les champs de formulaire, les chaînes de requête, les fichiers téléversés, les webhooks et la sortie d'un modèle, n'est pas fiable. Vérifiez que ces données sont validées côté serveur, et pas seulement dans le navigateur, et que les requêtes de base de données sont paramétrées plutôt que construites par concaténation de chaînes. Si votre application transmet du texte d'utilisateur à un LLM ou affiche la sortie d'un modèle en HTML, considérez cela aussi comme une entrée non fiable.

Gestion des erreurs et journalisation

Cherchez les blocs catch vides, les erreurs avalées pour que l'écran paraisse correct, et les réponses qui divulguent des traces d'appels ou des messages internes. La production exige des erreurs interceptées, présentées aux utilisateurs en termes simples et enregistrées à un endroit que vous consulterez vraiment. Sans cela, le premier signe d'un problème est l'e-mail d'un client.

Des tests qui testent vraiment le comportement

Les outils d'IA écrivent des tests avec empressement, et tous n'ont pas grande valeur. Méfiez-vous des tests qui simulent précisément ce qu'ils prétendent tester, des assertions qui ne peuvent pas échouer et des snapshots acceptés sans être lus. Un contrôle rapide : cassez volontairement une règle, par exemple en supprimant une vérification d'autorisation, et regardez si un test passe au rouge. Si aucun ne le fait, les tests ne sont que décoratifs. Écrivez des tests de comportement pour la connexion, les permissions, les paiements et tout ce qui modifie des données.

Fichiers de règles et dérive des prompts

De nombreux projets Cursor contiennent des règles de projet ou des fichiers d'instructions qui orientent l'assistant. Lisez-les. Ils accumulent des instructions contradictoires, des conventions obsolètes et parfois des informations sensibles qui n'ont pas leur place dans un dépôt. Si les règles disent une chose et que le code en fait une autre, le futur code généré suivra les règles : gardez-les donc courtes, à jour et cohérentes avec la façon dont le projet est réellement construit.

Une checklist de revue pour le code généré par IA

Utilisez-la comme une liste réussite ou échec. Tout ce que vous ne pouvez pas confirmer compte comme un échec.

• Le projet se construit depuis une copie propre, avec des étapes documentées.
• La vérification stricte des types et le linting passent sans suppressions généralisées.
• L'audit des dépendances est examiné ; les paquets inutilisés et non maintenus sont supprimés ; les licences sont vérifiées.
• Aucun secret dans les fichiers actuels ni dans l'historique git ; les clés divulguées sont renouvelées.
• Chaque route et chaque action serveur a une règle d'accès énoncée et appliquée.
• Toutes les entrées externes sont validées côté serveur ; les requêtes sont paramétrées.
• Les erreurs sont gérées, journalisées et n'exposent jamais les détails internes aux utilisateurs.
• Les tests couvrent les permissions, les paiements et les modifications de données, et échouent lorsque le comportement se dégrade.
• Le code mort et les doublons sont supprimés ; la structure peut être expliquée simplement.
• Les fichiers de règles et les prompts sont à jour et ne contiennent aucun secret.
• La CI exécute les vérifications et le build, et un déploiement peut être annulé.

Pour la vue d'ensemble du lancement, qui inclut les comptes, les paiements et l'exploitation, associez cette liste à notre checklist de préparation à la production.

Un parcours de remise en état, étape par étape

Si la revue révèle plus que ce que vous pouvez corriger en un week-end, procédez dans cet ordre pour que chaque étape rende la suivante plus sûre.

1. Geler les fonctionnalités. Cessez de générer du nouveau code tant que les fondations ne sont pas vérifiées.
2. Figer et protéger. Étiquetez l'état actuel, déplacez le dépôt vers un emplacement privé que vous contrôlez et renouvelez les secrets exposés.
3. Activer les barrières automatisées. Types, linting, audit, analyse des secrets et CI, en corrigeant les échecs à mesure qu'ils apparaissent.
4. Cartographier et prioriser. Listez les routes, les stockages de données et les intégrations, puis classez les risques en commençant par ce qui pourrait nuire aux utilisateurs ou à l'argent.
5. Corriger l'autorisation et la validation. Ce sont les changements aux conséquences les plus lourdes.
6. Ajouter des tests de comportement autour de ce que vous venez de corriger, pour que la correction tienne.
7. Nettoyer. Supprimez le code mort et les doublons, et mettez à jour les fichiers de règles.
8. Passer en préproduction, puis lancer. Déployez dans un environnement de préproduction, testez les vrais parcours, ajoutez la supervision et gardez un retour arrière prêt.

Vous ne savez pas si vous en êtes à l'étape 1 ou à l'étape 8 ? Notre article quand arrêter les prompts et faire appel à un ingénieur vous aide à trancher.

Où UnlockLive intervient

Vous n'avez pas besoin de confier votre projet pour bénéficier d'un regard d'expert. Notre AI App Technical Audit vous offre une revue indépendante de l'architecture, des chemins de code sensibles pour la sécurité, des dépendances et des tests, avec une liste priorisée de ce qu'il faut corriger. Si vous préférez que ce soit corrigé, AI App Repair & Launch couvre la réparation, le renforcement et le déploiement afin que l'application puisse être mise en ligne en toute confiance. Nos ingénieurs travaillent depuis Toronto et depuis notre centre d'ingénierie de Dhaka, et nous travaillons volontiers avec Cursor plutôt qu'à son encontre. Si vous ne savez pas de quel type de revue vous avez besoin, consultez audit technique, test d'intrusion ou revue de code.

Votre prochaine étape

Commencez par les vérifications peu coûteuses : activez les types stricts, lancez l'audit et analysez votre historique à la recherche de secrets. Lancez ensuite l'AI App Health Check gratuit pour voir quels domaines demandent de l'attention en premier. Aucun outil ne peut promettre que le code est irréprochable, mais une revue méthodique et reproductible vous en apprendra bien plus que le simple fait que l'application tourne sur votre ordinateur portable.