D'où vient la confusion
Quand une organisation dit « on a besoin d'un audit IA », elle peut vouloir dire n'importe lequel des deux. Le terme « audit » suggère un diagnostic complet. Mais complet du point de vue de qui ? Financier, réglementaire, sécurité, technique ?
La confusion est aggravée par le fait que les deux audits partagent des outils : on interview les gens, on lit de la documentation, on teste. Mais les questions posées, les critères d'évaluation, et les livrables sont radicalement différents.
Un audit peut passer à 9/10 en besoins mais obtenir 2/10 en sécurité. Ou inversement. Ce sont deux dimensions indépendantes. Confondre les deux signifie recevoir un diagnostic incomplet — ou un diagnostic du mauvais sujet.
Les deux dimensions côte à côte
Objectif
L'IA répond-elle aux besoins métier de l'organisation ? Les données alimentent-elles correctement le modèle ? La gouvernance est-elle en place ?
Objectif
Ce système résiste-t-il aux attaques ? Les garde-fous tiennent-ils ? Y a-t-il des fuites de données, des accès non autorisés, des détournements possibles ?
Questions posées
Le modèle produit-il les réponses attendues ? Les performances sont-elles acceptables ? La factualité est-elle suffisante ? La couverture métier est-elle complète ?
Questions posées
Un attaquant peut-il détourner le système ? Peut-il extraire des données sensibles ? Peut-il faire faire des actions non autorisées au modèle ?
Compétences requises
Expertise métier (finance, santé, RH selon le secteur), connaissance des données, compréhension des processus organisationnels. Peu de technique sécurité requise.
Compétences requises
Red teaming, exploitation LLM, pentesting, compréhension des architectures IA. Expertise métier moins critique que la capacité à casser le système.
Livrables
Rapport sur la conformité aux specs, mesures de performance (accuracy, couverture, pertinence), liste des ajustements requis. Tonalité : amélioration continue.
Livrables
Dossier de failles reproductibles, matrice de criticité, scénarios d'exploitation, pistes de remédiation. Tonalité : démonstration de vulnérabilité.
Durée typique
2–4 semaines. Dépend de la complexité métier et de la taille de la base documentaire à tester.
Durée typique
4–12 semaines selon la surface d'attaque et si l'automatisation est utilisée. Le red teaming itératif prend du temps.
Quand faire l'un, quand faire l'autre
Tu fais un audit des besoins si :
- Le système est nouveauTu veux vérifier que la première itération répond réellement aux besoins avant de le déployer plus largement.
- Il y a une non-conformité métier signaléeLes réponses sont souvent fausses, ou la couverture de cas d'usage est insuffisante.
- Tu dois montrer de la gouvernance à un fournisseur« Nous avons audité que votre solution IA répond à nos besoins avant de la déployer. »
- C'est avant un déploiement en productionUne première passe des besoins, une deuxième passe de sécurité après.
Tu fais un audit de sécurité si :
- Le système a accès à des données sensiblesDonnées clients, données financières, données de santé. Même un système qui fonctionne bien métier peut être une fuite de données.
- Le système prend des actions autonomesUn agent qui envoie des emails, qui passe des commandes, qui modifie des bases de données.
- La régulation l'exigeL'EU AI Act, à partir d'une certaine catégorie de risque, demande une évaluation de robustesse. C'est un audit de sécurité.
- Tu dois montrer que le système ne peut pas être détournéÀ un régulateur, à un assureur, à un client.
Tu fais les deux si :
- Le système doit être à la fois utile et sûrPasse l'audit des besoins, puis l'audit de sécurité. Les deux dimensions importent.
- C'est un déploiement critiqueSanté, finance, infrastructure critique. Pas de compromis sur l'un ou l'autre.
Déroulé : audit des besoins
Phase 1 : Cadrage métier — Comprendre les cas d'usage réels, les métriques de succès métier, les données attendues.
Phase 2 : Test fonctionnel — Donner au modèle des inputs représentatifs, vérifier que les outputs sont corrects ou acceptables. Mesurer accuracy, recall, F1-score selon le contexte.
Phase 3 : Couverture — Le système couvre-t-il tous les cas d'usage promis ? Y a-t-il des edge-cases non traités ?
Phase 4 : Gouvernance — Les processus de validation, d'amélioration, de monitoring sont-ils en place ? Comment le système apprend-il des erreurs ?
Livrable : Rapport avec scores d'acceptabilité, liste des ajustements, feuille de route d'amélioration.
Déroulé : audit de sécurité
Phase 1 : Cadrage de menace — Qu'est-ce qu'un attaquant plausible pour ce système ? Quel est l'enjeu ?
Phase 2 : Reconnaissance — Cartographier l'architecture, les données qu'il peut accéder, les outils qu'il peut appeler, les garde-fous en place.
Phase 3 : Attaque itérative — Red teaming : jailbreak, injection, escalade. Chaque faille trouvée est documentée et reproduite.
Phase 4 : Exploitation — Pour chaque faille, jusqu'où peut-on aller ? Extraction de données ? Action non autorisée ?
Livrable : Dossier de vulnérabilités reproductibles, matrice de criticité, scénarios d'exploitation, recommandations de remédiation.
Comment les combiner : l'ordre compte
Si tu fais les deux, l'ordre est critique :
| Approche | Avantage | Risque |
|---|---|---|
| Besoins d'abord Puis sécurité | Tu sais d'abord que le système fonctionne métier. La sécurité s'ajoute après. Approche logique. | Si la sécurité échoue, tu dois redéployer. Coûts d'itération plus élevés. |
| Sécurité d'abord Puis besoins | Tu identifies les fuites et les risques avant tout déploiement. Plus rigoureux. | Peut révéler des problèmes architecturaux qui ne sont pas faciles à corriger. |
| Parallèle avec retours | Les deux équipes s'informent mutuellement. Les recommandations de sécurité influencent le design dès le départ. | Plus coûteux, demande une coordination étroite. |
Cas spécifiques : RAG et hallucinations
Un système RAG (Retrieval Augmented Generation) mélange les deux audits d'une manière particulière :
- Audit des besoinsLe système récupère-t-il les bons documents ? Les explications citent-elles les bonnes sources ? Le hallucination est-il acceptable pour le cas d'usage ?
- Audit de sécuritéUn attaquant peut-il injecter de faux documents ? Peut-il forcer le système à halluciner des informations sensibles ? La source du RAG peut-elle être compromise ?
Pour un RAG, il existe un audit intermédiaire : audit RAG & hallucinations, spécialisé en taux d'hallucination et en quality de retrieval.
Checklist : quel audit choisir ?
- Le système a-t-il accès à des données sensibles ou à des outils ?Si oui → sécurité obligatoire.
- Y a-t-il une exigence réglementaire (EU AI Act, GDPR, etc.) ?Si oui → audit de sécurité.
- Les utilisateurs se plaignent des réponses fausses ou incomplètes ?Si oui → audit des besoins d'abord.
- C'est un déploiement nouveau en production ?Si oui → besoins d'abord, puis sécurité.
- Tu dois montrer de la diligence raisonnable à un régulateur ou un investisseur ?Si oui → fais les deux.