Audit de sécurité pour les applications créées avec l’IA : ce qui est inclus et ce qui ne l’est pas

Quiconque demande un audit de sécurité pour une application créée avec l’IA se retrouve souvent face à deux questions concrètes : qu’est-ce qui sera réellement contrôlé et qu’est-ce qui reste en dehors du périmètre. La réponse dépend du type d’application : une application web classique générée avec l’IA nécessite un WAPT, une revue de code et une vérification des configurations ; une application intégrant des LLM nécessite également des tests sur les prompts, le RAG, les appels d’outils (tool calls) et les sorties.

Le but n’est pas de juger l’IA en tant qu’outil de développement. L’approche est beaucoup plus pragmatique : comprendre quels contrôles sont nécessaires lorsque du code ou des flux de travail générés ou accélérés par l’IA entrent dans un produit, un processus métier ou un environnement contenant des données réelles.

[Callforaction-WAPT]

Pourquoi une application qui fonctionne n’est pas nécessairement sécurisée

Les outils d’IA réduisent le temps nécessaire pour créer du code, des interfaces, des flux de travail et des configurations. Cependant, cette vitesse peut occulter des étapes qui rendent normalement le logiciel fiable : modélisation des menaces (threat modeling), revue de code, gestion des secrets, contrôles des rôles, validation des entrées, vérification des dépendances et tests manuels des chemins critiques.

Une démonstration fonctionne avec un seul utilisateur, des données fictives et des permissions implicites. La même logique peut échouer lorsque des clients réels, des locataires multiples (multi-tenancy), des rôles différents, des API publiques, des intégrations, des données personnelles, des paiements ou des automatisations avec des effets externes entrent en jeu. La sécurité doit être évaluée sur le comportement réel de l’application, et non sur la promesse de l’outil qui l’a générée.

Ce qu’il faut pour lancer un audit

Pour mener un audit sérieux, il faut : le dépôt (repository) ou la build, les URL et environnements de test, la définition des rôles utilisateurs, les flux critiques, le schéma de données, les intégrations externes, les pipelines CI/CD, les configurations cloud pertinentes et l’indication des parties ayant été générées ou modifiées avec l’IA.

Ce qu’inclut un audit proportionné

Un audit proportionné couvre l’authentification, les autorisations, les API, la gestion des données, les secrets, les dépendances, les configurations, la journalisation (logging), la gestion des erreurs, les pipelines et les surfaces exposées. Si l’application utilise des LLM, il inclut également les injections de prompt, la gestion des sorties, la récupération de données (retrieval), la mémoire, les appels d’outils et les limites de débit (rate limits).

Ce qu’il n’inclut pas

Un audit n’est pas une certification de l’outil d’IA utilisé pour le développement, il ne garantit pas l’absence de bugs futurs et ne remplace pas la gouvernance, le monitoring, le patching et la remédiation continue. Sans accès au code, aux rôles et à un environnement représentatif de la production, l’audit devient inévitablement partiel.

Principaux risques à contrôler

• Périmètre ambigu entre WAPT, revue de code, VA et tests IA : définir à l’avance quelles surfaces sont incluses dans le test et lesquelles ne le sont pas.
• Environnement de test non représentatif de la production : les données fictives et les permissions simplifiées masquent des vulnérabilités réelles.
• Rôles et données non fournis au testeur : sans accès aux rôles réels, les contrôles sur les autorisations restent incomplets.
• Code généré non tracé dans les diffs : les parties générées avec l’IA et non révisées manuellement constituent un angle mort.
• Risques LLM ignorés pour les applications utilisant des modèles : les injections de prompt, les appels d’outils non contrôlés et les sorties non validées sont des vecteurs concrets.
• Risques classiques ignorés parce que l’application est “IA” : l’authentification, les autorisations et la gestion des secrets restent critiques, quelle que soit la manière dont le code a été écrit.
• Livrables sans priorité de remédiation : un rapport sans distinction entre les découvertes bloquantes et le risque résiduel ne permet pas de prendre des décisions opérationnelles.

La combinaison correcte de contrôles dépend de l’impact, pas du nom de l’outil. Une application exposée nécessite des tests applicatifs manuels ; une modification critique du code nécessite une revue ; un flux de travail interne nécessite un contrôle des permissions et des identifiants ; une application agentique nécessite des tests sur les prompts, les outils et les sorties.

Contrôles minimaux avant la mise en ligne (go-live)

• Mapper les utilisateurs, les rôles, les données réelles, les intégrations, les environnements et les responsables du service.
• Identifier quelles parties ont été générées ou modifiées avec l’IA et qui les a révisées.
• Vérifier les autorisations côté serveur, l’isolation des locataires (tenant isolation) et les fonctions administratives.
• Rechercher les secrets dans le code, les prompts, les logs, les variables d’environnement, les builds et l’historique du dépôt.
• Contrôler les dépendances, les licences, les paquets, les modèles, les plugins et les composants générés.
• Tester les entrées hostiles, la gestion des erreurs, la journalisation, les limites de débit et les chemins non prévus.
• Séparer les correctifs bloquants, la remédiation planifiée et le risque résiduel accepté en connaissance de cause.
• Répéter le test ou le retest après des corrections touchant des flux critiques.

Quand une vérification indépendante est-elle nécessaire ?

Une vérification indépendante est nécessaire lorsque l’application ou le flux de travail gère des données réelles, des utilisateurs externes, des rôles, des API, des intégrations d’entreprise, des paiements, du stockage, des flux de travail automatiques ou du code critique généré avec l’IA. Elle est également nécessaire lorsque l’équipe ne peut pas démontrer quelles parties ont été révisées et quels contrôles bloquent les régressions ou les abus.

Le périmètre conseillé par ISGroup dans ce cas comprend : Web Application Penetration Testing, Code Review, Vulnerability Assessment et, pour les applications avec LLM, AI Application Testing. La meilleure revue produit des découvertes reproductibles, des priorités de remédiation, une indication du risque résiduel et, si nécessaire, un retest après les corrections.

Questions opérationnelles pour les fondateurs, CTO et équipes de sécurité

• Quelles données réelles entrent dans le système et où sont-elles enregistrées, loguées ou envoyées ?
• Quels rôles existent et quelles actions sont bloquées côté serveur, et pas seulement dans l’interface ?
• Quels secrets, jetons, webhooks ou identifiants permettraient d’accéder à des systèmes critiques ?
• Quelles parties ont été générées ou modifiées par l’IA et lesquelles ont été révisées par une personne compétente ?
• Quels tests couvrent les abus, les erreurs, les rôles différents et les locataires différents, et pas seulement le “chemin heureux” (happy path) ?
• Quelle preuve peut être présentée aux clients, aux audits, aux achats ou à la direction ?

Approfondissements utiles

• Penetration test pour SaaS et applications IA : comment configurer un test sur des produits SaaS ou des applications intégrant des composants IA, avec un focus sur le périmètre et la méthodologie.
• Contrôles de sécurité pour applications IA avant la mise en ligne : liste opérationnelle des contrôles à effectuer avant de mettre en ligne une application développée avec l’IA.
• AI Application Testing : approfondissement sur les tests spécifiques pour les applications intégrant des LLM, des agents et des flux de travail autonomes.

FAQ

• Quelle est la différence entre un audit, un WAPT et une revue de code ?
• Le WAPT vérifie le comportement de l’application exposée en simulant un attaquant externe. La revue de code analyse le code source à la recherche de vulnérabilités logiques et de mauvaises pratiques. L’audit combine des contrôles proportionnés au périmètre et peut inclure les configurations, le processus et les risques spécifiques à l’IA.
• Quand l’AI Application Testing est-il nécessaire ?
• Lorsque l’application intègre des LLM, du RAG, des agents, des appels d’outils, de la mémoire ou des flux de travail autonomes. Si l’IA a été utilisée uniquement pour écrire du code, les contrôles prioritaires restent généralement le WAPT et la revue de code.
• Quels documents dois-je préparer avant l’audit ?
• URL, définition des rôles, flux critiques, dépôt ou build, architecture, intégrations, données de test, pipeline CI/CD et liste des parties générées ou modifiées avec l’IA.
• Quelle doit être l’étendue du périmètre ?
• Suffisamment large pour couvrir ce qui peut causer un impact réel : données, utilisateurs, rôles, API, fonctions administratives, stockage, paiements, intégrations et déploiement.
• Le rapport suffit-il pour aller en ligne ?
• Uniquement si les découvertes bloquantes ont été corrigées ou acceptées en connaissance de cause. La décision finale doit inclure une évaluation de la remédiation effectuée et du risque résiduel.

Sources et références

• OWASP Top 10 2021
• OWASP ASVS
• OWASP Code Review Guide
• NIST SP 800-218 SSDF
• OWASP Top 10 for LLM Applications 2025

Si vous êtes sur le point de mettre en ligne une application ou un flux de travail développé avec l’IA, ISGroup peut vous aider à choisir le bon contrôle : test applicatif, revue de code, évaluation architecturale ou vérification ciblée sur les risques spécifiques à l’IA.

[Callforaction-WAPT-Footer]