Faire auditer une application codée avec l'IA, c'est demander à un développeur expérimenté de relire ce que Claude Code, Cursor, Lovable ou Bolt ont produit, pour répondre à trois questions simples. Est-ce que c'est sûr ? Est-ce que ça tiendra quand vous aurez plus d'utilisateurs ? Est-ce qu'un autre développeur pourra le reprendre ? Si votre application manipule des données clients ou des paiements, la réponse à « faut-il un audit ? » est oui, et de préférence avant le premier incident.
Un bon audit ne se juge pas à l'épaisseur du rapport. Il se juge à une liste courte de problèmes classés par gravité, avec pour chacun le risque concret et le coût de la correction. Ce guide vous explique ce qu'un audit d'application codée avec l'IA doit contenir, comment le préparer pour ne pas payer des heures de recherche d'accès, et comment lire le rapport sans paniquer.
Pourquoi faire auditer une application codée avec l'IA
Les assistants de code produisent du code qui fonctionne. Le problème est ailleurs : ils produisent aussi, régulièrement, du code qui fonctionne et qui est vulnérable. Veracode a fait réaliser 80 tâches de programmation à plus de 100 modèles d'IA. Dans 45 % des cas, le code contenait une faille classée dans le Top 10 de l'OWASP, la référence des risques de sécurité web. Surtout, Veracode note que les modèles progressent sur la justesse du code mais pas sur la sécurité, et que les gros modèles ne font pas significativement mieux que les petits (Veracode, 2025 GenAI Code Security Report).
Ce n'est pas une raison pour renoncer à l'IA : je l'utilise moi-même tous les jours. C'est une raison pour ne pas confondre « ça marche » avec « c'est prêt ». Trois situations rendent l'audit particulièrement utile :
- Avant d'ouvrir l'application à de vrais clients ou d'y brancher un paiement.
- Avant une levée de fonds, une cession ou un appel d'offres, quand quelqu'un d'autre va poser des questions sur la qualité du produit.
- Quand chaque nouvelle demande à l'IA casse autre chose. C'est souvent le signe d'une dette technique qui s'accumule. Si c'est votre cas, l'article Dette technique du code généré par IA : la repérer sans être développeur vous aidera à poser un premier diagnostic vous-même.
Ce que l'audit d'une application codée avec l'IA doit couvrir
Voici les points que je considère comme indispensables. Si un devis d'audit n'en mentionne pas la plupart, posez la question.
Le contrôle d'accès
C'est la première chose que je regarde. Le contrôle d'accès est la règle qui garantit qu'un utilisateur ne voit et ne modifie que ce qui le concerne. L'OWASP le place au premier rang des risques de son Top 10 2025 et indique que toutes les applications testées présentaient une forme de défaut sur ce point (OWASP Top 10 2025). Le cas typique : on change un numéro dans l'adresse de la page, /factures/1042 devient /factures/1043, et on voit la facture d'un autre client. Le code généré par IA vérifie souvent que l'utilisateur est connecté, moins souvent qu'il est bien propriétaire de la donnée demandée. L'OWASP recommande de tout refuser par défaut et de faire la vérification sur le serveur, jamais seulement dans l'interface. Si votre application repose sur Supabase, la question passe par les règles RLS, détaillées dans Application Lovable : comment vérifier la sécurité Supabase (RLS).
Les secrets et la configuration
Clés API écrites dans le code ou présentes dans l'historique Git, mode débogage actif en production (il affiche des informations internes en cas d'erreur), fichiers de configuration accessibles publiquement. Ces erreurs sont simples à repérer et graves quand elles sont exploitées.
Les dépendances et les versions
Les bibliothèques utilisées sont-elles maintenues ? Le framework reçoit-il encore des correctifs ? Exemple concret avec Laravel : la version 11 ne reçoit plus de correctifs de sécurité depuis le 12 mars 2026. La version 12 ne reçoit plus de corrections de bugs depuis le 13 août 2026 et perdra ses correctifs de sécurité le 24 février 2027 (politique de support Laravel). Un assistant IA peut très bien générer un projet sur une version déjà ancienne s'il s'appuie sur des exemples datés.
L'exploitation
Sauvegardes (et test de restauration), surveillance, procédure de mise en production. Une application sans sauvegarde testée n'est pas vraiment en production : elle est en sursis.
La maintenabilité
Le code est-il compréhensible, testé, organisé de façon cohérente ? C'est ce qui détermine le coût de chaque évolution future, que vous la confiiez à un développeur ou à l'IA.
Ce qu'un audit ne couvre pas. Il ne garantit pas l'absence de faille : il réduit le risque. Il ne remplace pas un test d'intrusion par un spécialiste quand vous avez de fortes exigences réglementaires (santé, finance). Et il ne corrige rien : c'est un diagnostic, la correction vient ensuite.
Préparer l'audit : les accès et documents à fournir
Dans un audit mal préparé, une bonne partie du temps passe à récupérer des accès. Avant de commencer, rassemblez :
- l'accès en lecture au dépôt de code (GitHub, GitLab…), ou l'export du projet si vous êtes sur Lovable ou Bolt ;
- l'accès en lecture à l'hébergement et à la base de données, idéalement sur une copie plutôt que sur la production ;
- la liste des services tiers branchés (paiement, e-mails, IA, stockage de fichiers) ;
- quelques lignes qui décrivent ce que fait l'application, qui l'utilise et quelles données sensibles elle manipule ;
- vos inquiétudes concrètes : « j'ai peur qu'un client voie les données d'un autre », « le site est lent le lundi matin ».
N'envoyez pas les mots de passe en clair par e-mail : créez des accès nominatifs que vous pourrez supprimer à la fin. Et si vous ne savez pas où se trouvent certains accès, c'est déjà un constat utile de l'audit.
Lire le rapport et prioriser sans tout réécrire
Devant une liste de problèmes, le réflexe est de vouloir tout reprendre de zéro. C'est rarement la bonne décision. Un rapport utile classe les constats en trois catégories :
- À corriger tout de suite : ce qui expose des données ou de l'argent (contrôle d'accès, secrets exposés, absence de sauvegarde).
- À planifier : ce qui fragilise l'application à moyen terme (version de framework en fin de support, absence de tests sur les parties critiques).
- À surveiller : ce qui gêne sans menacer (code dupliqué, nommage confus).
Pour chaque point, demandez trois choses. Quel est le risque concret pour votre activité ? Quel est l'effort de correction ? Peut-on corriger avec l'IA sous supervision, ou faut-il un développeur ? Beaucoup de corrections se font très bien avec Claude Code ou Cursor, à condition que quelqu'un sache quoi leur demander et vérifie le résultat.
Une réécriture complète se justifie quand les fondations elles-mêmes posent problème : modèle de données incohérent, aucune séparation entre ce qui se passe dans le navigateur et ce qui se passe sur le serveur, sécurité impossible à ajouter sans tout toucher. Cela arrive. Mais un auditeur qui la recommande d'emblée, sans chiffrer l'alternative, doit vous amener à poser des questions.
Audit ponctuel ou suivi régulier : que choisir ?
Un audit est une photo. Le lendemain, vous ou votre outil d'IA ajoutez une fonctionnalité, et la photo n'est déjà plus tout à fait exacte. Avec le vibe coding, le code change vite : c'est tout son intérêt, et c'est aussi la limite d'un audit unique.
En pratique, je conseille :
- un audit initial pour faire l'état des lieux et corriger l'urgent ;
- puis une relecture régulière des changements importants, complétée par des contrôles automatiques à chaque mise en production.
C'est le principe de Copilote : une journée de développeur senior par mois pour relire ce qui a été produit, trancher les choix techniques et vous aider à mieux piloter l'IA, que vous codiez vous-même ou qu'un freelance le fasse. Le premier mois sert souvent à l'état des lieux, les suivants à garder l'application saine pendant qu'elle évolue.
Questions fréquentes
Combien de temps prend un audit ?
Cela dépend de la taille de l'application et de la préparation. Une première lecture ciblée sur la sécurité et l'exploitation peut tenir en une journée ; un audit complet de maintenabilité demande davantage. Méfiez-vous d'un devis qui ne précise pas ce qui sera regardé.
Un outil d'analyse automatique ne suffit-il pas ?
Les outils automatiques repèrent bien les secrets exposés et les dépendances vulnérables. Ils repèrent mal les failles de logique, comme un client qui peut voir les données d'un autre : pour savoir que l'application ne devrait pas le permettre, il faut comprendre ce qu'elle est censée faire.
Puis-je demander à l'IA d'auditer son propre code ?
C'est utile en premier passage, et je fais moi-même relire le code par des agents IA. Mais un modèle qui a écrit une erreur peut ne pas la voir en relisant, et il ne connaît pas vos enjeux métier. Voyez-le comme un filet de sécurité, pas comme un avis final.
Si vous hésitez à faire auditer votre application, ou si vous avez un rapport en main sans savoir par où commencer, parlons-en. Un échange suffit en général pour savoir ce qui mérite d'être regardé en priorité.