Audit d’une application créée avec l’IA : sécuriser, comprendre et préparer la suite

Vous avez créé votre application avec l’IA. Elle fonctionne, vos premiers utilisateurs l’apprécient, et vous l’avez construite plus vite que vous ne l’imaginiez. C’est une vraie réussite, et elle vous appartient.

Pourtant, deux questions reviennent chez presque tous les dirigeants que nous rencontrons. La première : « Est-ce que c’est vraiment viable ? » Vous n’avez pas écrit le code et vous ne pouvez pas le relire. La seconde arrive juste après : « Et maintenant, je fais quoi ? » Faut-il continuer seul avec l’IA, recruter, tout refaire, ou rien du tout ?

Un audit répond aux deux. La plupart des articles sur le sujet ne parlent que de failles de sécurité. Elles comptent, et nous en parlons longuement ici. Mais un bon audit sert aussi à comprendre ce que vous avez construit, à vérifier que l’application sert toujours votre projet, et à décider de la suite sans précipitation. Nous proposons nous-mêmes ce service, mais les conseils qui suivent valent quel que soit le prestataire que vous choisirez.

Un audit d’application créée avec l’IA, c’est quoi ?

Un audit d’application est une relecture complète par des développeurs expérimentés. Ils examinent le code, la configuration des services, l’organisation de la base de données et la façon dont l’application gère les accès. Ils ne cherchent pas à tout réécrire, ni à juger vos choix. Ils cherchent ce qui pourrait poser problème quand l’application grandira, accueillera de vrais clients ou manipulera des données sensibles.

Pour une application créée avec Lovable, Bolt, Cursor, Replit ou Claude, un audit répond en réalité à trois questions :

• Est-ce solide ? Vos données et celles de vos clients sont-elles protégées, et l’application tiendra-t-elle la charge ?
• Qu’est-ce que j’ai construit ? Quels services, quelle base de données, quelles décisions l’IA a-t-elle prises pour vous ?
• Et maintenant ? Que faut-il corriger, dans quel ordre, et comment faire évoluer l’application sereinement ?

À la fin, vous recevez un rapport clair et une restitution de vive voix. Un bon rapport se lit sans être développeur, avec des priorités nettes plutôt qu’une longue liste de détails.

Pourquoi une application qui marche mérite quand même un regard humain

Une application qui fonctionne à l’écran n’est pas forcément une application qui tient. L’IA est excellente pour construire ce que vous lui demandez. Elle l’est beaucoup moins pour vous signaler ce que vous ne lui avez pas demandé : vérifier qu’un client ne voit que ses propres données, protéger une clé secrète, prévoir ce qui se passe à 1 000 utilisateurs.

Ce n’est pas une impression. Plusieurs études récentes vont dans le même sens :

• Veracode a testé plus de 100 modèles d’IA sur 80 tâches de programmation : dans 45 % des cas, le code produit contenait une faille de sécurité connue (juillet 2025).
• Escape a analysé 5 600 applications publiques créées avec des outils de vibe coding : plus de 2 000 vulnérabilités, plus de 400 clés secrètes exposées et 175 cas de données personnelles accessibles, dont des données médicales et des IBAN (octobre 2025).
• Le banc d’essai SusVibes montre que 61 % des solutions produites par des agents d’IA fonctionnent, mais que seulement 10,5 % sont aussi sûres (2025).

Ces chiffres ne disent pas que l’IA code mal. Ils disent qu’elle code ce qu’on lui demande, et que la sécurité fait rarement partie de la demande. La bonne nouvelle, c’est que ces problèmes sont presque toujours connus, repérables et corrigeables. Nous avons détaillé les plus fréquents dans notre article sur les failles de sécurité des applications créées avec l’IA.

Ce qu’un audit vérifie : le volet technique

Pour une application créée avec l’IA, voici les points que des développeurs examinent en priorité.

La sécurité et les accès

Qui peut voir quoi, et le serveur le vérifie-t-il vraiment ? C’est la faille la plus répandue : un contrôle qui existe dans l’interface, mais pas dans la base de données. L’audit vérifie aussi la gestion des comptes, les mots de passe, le stockage des fichiers et les clés secrètes, qui ne doivent jamais se retrouver dans le navigateur. Voir aussi notre article sur les clés API exposées.

Les données et la conformité

Où sont hébergées les données, qui peut y accéder, comment elles sont sauvegardées, et si l’application permet de respecter vos obligations, comme supprimer un compte ou exporter les données d’un utilisateur. Si vous traitez des données de santé, l’hébergement doit être certifié HDS, en plus des exigences renforcées du RGPD. L’audit technique complète votre démarche RGPD, sans remplacer l’avis d’un juriste.

La solidité et la montée en charge

La façon dont les données sont organisées et lues, les pages qui ralentiront avec plus d’utilisateurs, les limites des services utilisés, ce qui se passe quand un service tiers tombe. De quoi savoir si votre application tiendra avec 1 000 utilisateurs.

Les coûts

Les services qui risquent de coûter cher à l’usage, les appels inutiles, les modèles d’IA surdimensionnés pour la tâche, les abonnements qui se cumulent. Un audit repère souvent des économies faciles, et vous aide à anticiper le coût réel de votre application quand elle grandira.

La capacité à évoluer

La lisibilité du code, l’organisation du projet, les morceaux copiés à plusieurs endroits, la présence ou non de tests. C’est ce qui détermine si la prochaine fonctionnalité prendra une heure ou une semaine, et si un développeur pourra reprendre le projet.

Votre indépendance

Pouvez-vous récupérer votre code et vos données ? L’application dépend-elle d’un seul outil ou d’un seul compte ? Qui détient les accès ? Ces questions semblent secondaires jusqu’au jour où elles deviennent urgentes.

Ce que la plupart des audits oublient : comprendre ce que vous avez construit

Quand vous créez une application avec l’IA, elle prend pour vous des dizaines de décisions. Quelle base de données utiliser, comment organiser vos clients et vos commandes, où héberger l’application, comment gérer les connexions, quels services externes appeler. Elle les prend vite, souvent bien, mais sans vous les expliquer.

Résultat : beaucoup de dirigeants possèdent une application qu’ils utilisent tous les jours, sans savoir vraiment comment elle fonctionne. Ce n’est pas un reproche, c’est la promesse même du vibe coding. Mais c’est inconfortable au moment de parler à un investisseur, de répondre à un client qui pose des questions sur ses données, ou de demander une évolution à l’IA.

C’est pourquoi nous considérons qu’un audit doit aussi être un moment de transmission. Concrètement, à la fin, vous devriez savoir :

• comment votre application est faite ;
• où vivent vos données, et qui peut y accéder ;
• quelles décisions l’IA a prises pour vous, et lesquelles mériteraient d’être revues ;
• quels mots utiliser pour décrire votre application à un développeur, un client ou un investisseur ;
• comment formuler vos prochaines demandes à l’IA pour qu’elle aille dans la bonne direction.

Notre article sur la base de données, l’hébergement et les API vous donne déjà les bases de ce vocabulaire. L’audit l’applique à votre propre application.

Le regard produit : votre application sert-elle encore votre projet ?

Une application créée avec l’IA grandit vite, souvent au fil des idées. Une fonctionnalité en appelle une autre, un écran est ajouté pour un client, un essai reste en place. Au bout de quelques semaines, l’application fait beaucoup de choses, et il devient difficile de dire lesquelles comptent vraiment.

Un audit mené par des personnes qui construisent des produits ne s’arrête pas au code. Il regarde aussi :

• le parcours de vos utilisateurs : ce qui est clair, ce qui les perd, ce qui manque pour qu’ils reviennent ;
• les fonctionnalités qui coûtent (en maintenance, en services, en complexité) sans vraiment servir ;
• la cohérence entre l’application et votre modèle : à qui elle s’adresse, ce que vous vendez, comment vous comptez grandir ;
• ce qui mérite d’être simplifié avant d’ajouter quoi que ce soit.

C’est souvent là que se trouvent les plus belles surprises : une fonctionnalité que vous pensiez indispensable et que personne n’utilise, une étape d’inscription qui fait fuir la moitié des visiteurs, une idée simple qui débloquerait vos ventes.

Imaginer la suite sereinement : la feuille de route

Un audit utile ne se termine pas sur une liste de problèmes. Il se termine sur un plan. Nous classons les points relevés selon le moment où ils deviennent importants :

• avant le lancement : ce qui protège vos utilisateurs et vos données dès le premier jour ;
• avant vos premiers clients : ce qui rend l’application fiable, et ce qu’un client exigeant vous demandera ;
• quand ça décolle : ce qui permettra de tenir la charge, de maîtriser les coûts et d’accueillir une équipe.

Chaque point est priorisé, expliqué avec ses conséquences concrètes, et accompagné d’une action claire. Ensuite, c’est vous qui décidez qui la mène. Trois chemins sont possibles, et aucun n’est meilleur que les autres :

• continuer avec votre IA : le rapport vous dit précisément quoi lui demander, et quoi vérifier ensuite ;
• vous faire accompagner sur quelques points précis, le temps de consolider ;
• confier l’application à un développeur ou à une équipe, quand elle devient le cœur de votre activité.

Un exemple : la plateforme de Sophie

Sophie dirige un cabinet de recrutement de douze personnes. En trois semaines, avec Lovable, elle a créé une plateforme où ses clients suivent l’avancement de leurs recrutements et consultent les profils présélectionnés. Ses clients adorent. Elle prépare une campagne pour en signer dix de plus.

Avant de lancer la campagne, elle fait auditer l’application. Les constats :

• priorité haute : en appelant directement la base de données, un client pouvait voir les candidats d’un autre client. L’interface le cachait, le serveur ne le vérifiait pas. Correction en une demi-journée ;
• priorité haute : la clé du service d’envoi d’e-mails était visible dans le navigateur. Correction en une heure ;
• peut attendre : les CV étaient conservés sans limite de durée, ce qui pose une question RGPD à traiter avant la campagne suivante ;
• peut attendre : chaque ouverture de profil appelait un modèle d’IA pour résumer le CV, même quand le résumé existait déjà. Une économie d’environ 70 % sur la facture du service ;
• ce qui va bien : une base de données bien structurée, des écrans clairs, un code lisible pour un développeur.

Lors de la restitution, Sophie a surtout découvert comment son application fonctionnait : où étaient stockés les CV, pourquoi la connexion passait par un service externe, ce qui se passerait avec cinquante clients. Elle a corrigé les deux priorités avec l’IA en suivant le rapport, nous avons vérifié les corrections, et elle a reporté une fonctionnalité de messagerie qui aurait doublé la complexité sans rien apporter à ses clients. La campagne est partie deux semaines plus tard. (Exemple fictif, inspiré de situations courantes.)

Quand faire auditer son application

Il n’est pas nécessaire d’auditer un prototype que vous montrez à quelques personnes. En revanche, certains moments s’y prêtent particulièrement :

• avant d’ouvrir l’application au public ou à vos premiers clients ;
• avant une campagne d’acquisition ou un lancement important ;
• avant de traiter des paiements, des données de santé, bancaires ou concernant des mineurs ;
• avant une levée de fonds, une vente ou un partenariat, quand on vous demandera des garanties ;
• quand l’IA n’arrive plus à faire évoluer l’application sans casser autre chose ;
• après un incident, pour comprendre ce qui s’est passé et éviter qu’il se reproduise ;
• avant de confier l’application à un développeur ou à une équipe.

Si vous vous reconnaissez dans l’un de ces cas, c’est probablement le bon moment. Notre article sur les étapes avant la mise en production vous aide aussi à faire le point.

Audit, scanner automatique, test d’intrusion : quelle différence ?

Ces trois démarches sont souvent confondues. Elles sont complémentaires.

• Un scanner automatique passe l’application au crible en quelques minutes et repère des failles connues. C’est utile et peu coûteux, mais il ne connaît pas votre métier : il ne sait pas qu’un client ne doit pas voir les devis d’un autre. Un scan sans alerte n’est pas une preuve de sécurité.
• Un audit est une relecture humaine du code et de la configuration, avec votre contexte en tête. Il repère les failles de logique, évalue la solidité et les coûts, et vous explique ce qu’il trouve.
• Un test d’intrusion simule une véritable attaque sur l’application en ligne. Il s’adresse plutôt aux applications déjà matures ou soumises à des exigences fortes, et se fait de préférence après un audit, une fois les points principaux corrigés.

Vous pouvez aussi demander à votre IA de relire son propre travail. C’est une bonne habitude, mais elle relit avec les mêmes angles morts que ceux qu’elle avait en écrivant le code.

Comment se déroule un audit chez AZTK

Les modalités varient d’un prestataire à l’autre. Chez nous, l’audit se déroule en une semaine :

• un échange gratuit de 30 minutes, pour comprendre votre application, vos utilisateurs et ce qui vous inquiète, et vous dire si un audit est utile ;
• un accord de confidentialité, signé avant tout accès ;
• l’accès à votre code et à vos services : rien n’est modifié sans votre accord ;
• 5 jours ouvrés d’analyse par nos développeurs ;
• une restitution d’une heure, en visio, pour tout expliquer et répondre à vos questions ;
• un rapport écrit, avec les points classés par priorité et la feuille de route.

À la fin, vous retirez nos accès, sauf si vous souhaitez que nous intervenions. Nos audits démarrent à 990 € HT, selon l’étendue de l’application.

Comment choisir qui audite votre application

Que vous fassiez appel à nous ou à un autre prestataire, quelques questions permettent de faire le bon choix :

• Le rapport est-il compréhensible sans être développeur ? Demandez un exemple.
• Y a-t-il une restitution de vive voix, ou seulement un document ?
• Les priorités sont-elles claires, ou s’agit-il d’une liste de 80 points sans hiérarchie ?
• Le prestataire signe-t-il un accord de confidentialité avant d’accéder à votre code ?
• Vous dit-il aussi ce qui va bien, et quand un audit n’est pas nécessaire ?
• Vous laisse-t-il libre de faire les corrections vous-même, ou pousse-t-il systématiquement à tout reconstruire ?

Méfiez-vous d’un audit qui conclut toujours qu’il faut tout refaire. C’est parfois vrai, mais c’est rare : dans la grande majorité des cas, quelques corrections ciblées suffisent.

Bien préparer votre audit

Pour gagner du temps et tirer le meilleur de l’audit :

• synchronisez votre code avec GitHub, ou préparez un export ;
• listez les services utilisés par l’application ;
• décrivez en quelques lignes ce que fait l’application, pour qui, et ce que vous envisagez pour la suite ;
• notez ce qui vous inquiète, même si cela vous semble flou ;
• préparez des comptes de test pour chaque type d’utilisateur ;
• notez les incidents ou les comportements étranges déjà observés.

En résumé

Un audit d’application créée avec l’IA, c’est une relecture par des développeurs qui vous dit ce qui est solide, ce qui doit être renforcé et dans quel ordre. Il couvre la sécurité, les données, la solidité, les coûts et la capacité à évoluer. Mais un bon audit va plus loin : il vous aide à comprendre ce que vous avez construit, vérifie que l’application sert toujours votre projet, et vous donne une feuille de route pour la suite. Le bon moment, c’est avant d’ouvrir l’application au public, avant de traiter des données sensibles ou des paiements, ou quand l’IA n’arrive plus à avancer. Si vous vous posez la question, un échange gratuit permet d’y voir clair. Dans le dernier article de cette série, nous verrons quand faire appel à un développeur, et comment bien travailler avec lui.