Audit de sécurité et certification

De la sécurité ad hoc à la conformité certifiable

Les leçons précédentes vous ont donné les outils techniques pour sécuriser un système IA. Mais la sécurité ponctuelle ne suffit pas, et la raison n’est pas seulement bureaucratique : ce qui a été vérifié une fois cesse de l’être dès la mise en production suivante, et rien ne le signale. Les clients, les régulateurs et les partenaires exigent des preuves formelles, c’est-à-dire la démonstration que vos contrôles existent, fonctionnent et tiennent dans la durée. L’audit et la certification transforment vos pratiques en un cadre vérifiable et continu.

Savoir à quel référentiel se rattacher

Cinq cadres se croisent sur le terrain de l’IA, avec des portées différentes qu’il faut distinguer avant d’engager quoi que ce soit.

La distinction décisive sépare ce qui s’impose de ce qui se choisit. L’AI Act est une réglementation : si votre système entre dans la catégorie haut risque, vous n’arbitrez pas. Les normes ISO et SOC 2 sont des certifications volontaires, généralement réclamées par vos clients grands comptes plutôt que par un régulateur. L’OWASP LLM Top 10, lui, ne se certifie pas — c’est un référentiel technique, et il constitue le meilleur point de départ pour un premier audit interne parce qu’il ne coûte que du temps.

Une checklist qui couvre les cinq domaines

Un audit sérieux ne se limite pas à la technique. La checklist ci-dessous répartit ses points de contrôle sur cinq domaines, et cette répartition raconte quelque chose : la gouvernance et la conformité pèsent autant que la sécurité, parce qu’un dispositif technique impeccable dont personne n’est responsable et qui n’est documenté nulle part échoue à tout audit externe.

La criticité distingue l’obligatoire du recommandé, distinction qui produira plus tard une décision binaire. Le sandboxing figure en recommandé plutôt qu’en obligatoire, et ce classement se justifie : il ne s’applique qu’aux systèmes exécutant du code généré, alors que le filtrage des entrées et sorties concerne toutes les applications sans exception. Une checklist bien calibrée ne demande pas à un chatbot de FAQ de justifier une isolation par conteneurs.

from dataclasses import dataclass, field
from datetime import datetime

@dataclass
class PointControle:
    id: str
    categorie: str
    description: str
    criticite: str  # obligatoire, recommande, optionnel
    conforme: bool | None = None
    preuve: str = ""
    commentaire: str = ""

def creer_checklist_audit() -> list[PointControle]:
    """Crée une checklist complète d'audit sécurité IA."""
    return [
        # Gouvernance
        PointControle("GOV-01", "Gouvernance",
            "Politique de sécurité IA documentée et approuvée", "obligatoire"),
        PointControle("GOV-02", "Gouvernance",
            "Responsable sécurité IA désigné (CISO/DPO)", "obligatoire"),
        PointControle("GOV-03", "Gouvernance",
            "Registre des traitements IA à jour", "obligatoire"),

        # Données
        PointControle("DAT-01", "Données",
            "Inventaire des données envoyées aux APIs LLM", "obligatoire"),
        PointControle("DAT-02", "Données",
            "Anonymisation/pseudonymisation des données personnelles", "obligatoire"),
        PointControle("DAT-03", "Données",
            "DPA signé avec chaque fournisseur d'API IA", "obligatoire"),
        PointControle("DAT-04", "Données",
            "Politique de rétention des conversations définie", "obligatoire"),

        # Sécurité technique
        PointControle("SEC-01", "Sécurité",
            "Prompt injection : défenses en profondeur implémentées", "obligatoire"),
        PointControle("SEC-02", "Sécurité",
            "Filtrage de contenu (entrées et sorties)", "obligatoire"),
        PointControle("SEC-03", "Sécurité",
            "Rate limiting et détection d'abus", "obligatoire"),
        PointControle("SEC-04", "Sécurité",
            "Clés API stockées dans un vault (pas en dur)", "obligatoire"),
        PointControle("SEC-05", "Sécurité",
            "Sandboxing pour l'exécution de code généré", "recommande"),
        PointControle("SEC-06", "Sécurité",
            "Monitoring et alertes sur les anomalies", "recommande"),

        # Red teaming
        PointControle("RED-01", "Red teaming",
            "Tests de sécurité avant chaque mise en production", "obligatoire"),
        PointControle("RED-02", "Red teaming",
            "Red teaming régulier (trimestriel minimum)", "recommande"),
        PointControle("RED-03", "Red teaming",
            "Rapport de red teaming avec suivi des remédiations", "obligatoire"),

        # Conformité
        PointControle("CONF-01", "Conformité",
            "AIPD réalisée pour les traitements IA", "obligatoire"),
        PointControle("CONF-02", "Conformité",
            "Droits des personnes implémentés (accès, effacement)", "obligatoire"),
        PointControle("CONF-03", "Conformité",
            "Information transparente aux utilisateurs sur l'usage de l'IA", "obligatoire"),
        PointControle("CONF-04", "Conformité",
            "Classification du risque selon l'AI Act", "recommande"),
    ]

Auditer, c’est exiger une preuve

Le champ qui change tout dans l’exécution de l’audit est preuve. Cocher « conforme » sans référence documentaire ne vaut rien face à un auditeur externe, qui demandera systématiquement sur quoi repose l’affirmation. L’exemple d’utilisation le montre bien : la conformité de GOV-01 s’appuie sur un document nommé et daté, pas sur une déclaration d’intention.

Le troisième appel illustre le cas le plus instructif — une non-conformité assortie de son plan de correction. Une clé d’API dans un fichier d’environnement n’est pas un scandale, c’est une pratique répandue ; elle reste néanmoins non conforme au regard du point de contrôle, et le commentaire indique la trajectoire de remise en conformité. Un audit qui ne remonte aucune non-conformité doit d’ailleurs éveiller votre méfiance : il signale plus souvent une checklist complaisante qu’un système parfait.

La décision finale est binaire et ne pondère rien : une seule non-conformité obligatoire suffit à basculer le verdict. Le taux de conformité, calculé à côté, sert à mesurer la progression entre deux audits, jamais à négocier le verdict lui-même.

class AuditSecuriteIA:
    """Exécute et documente un audit de sécurité IA."""

    def __init__(self, nom_systeme: str, auditeur: str):
        self.nom_systeme = nom_systeme
        self.auditeur = auditeur
        self.date = datetime.now().strftime("%Y-%m-%d")
        self.checklist = creer_checklist_audit()

    def evaluer(self, point_id: str, conforme: bool, preuve: str, commentaire: str = ""):
        """Évalue un point de contrôle."""
        for point in self.checklist:
            if point.id == point_id:
                point.conforme = conforme
                point.preuve = preuve
                point.commentaire = commentaire
                return
        raise ValueError(f"Point de contrôle inconnu : {point_id}")

    def rapport(self) -> dict:
        """Génère le rapport d'audit."""
        evalues = [p for p in self.checklist if p.conforme is not None]
        conformes = [p for p in evalues if p.conforme]
        non_conformes = [p for p in evalues if not p.conforme]
        non_evalues = [p for p in self.checklist if p.conforme is None]

        # Non-conformités obligatoires = bloquantes
        bloquantes = [
            p for p in non_conformes if p.criticite == "obligatoire"
        ]

        return {
            "systeme": self.nom_systeme,
            "auditeur": self.auditeur,
            "date": self.date,
            "total_controles": len(self.checklist),
            "évalués": len(evalues),
            "conformes": len(conformes),
            "non_conformes": len(non_conformes),
            "non_evalues": len(non_evalues),
            "bloquantes": len(bloquantes),
            "taux_conformite": f"{len(conformes) / max(len(evalues), 1) * 100:.0f}%",
            "decision": "NON CONFORME" if bloquantes else "CONFORME",
            "non_conformites_bloquantes": [
                {"id": p.id, "description": p.description, "commentaire": p.commentaire}
                for p in bloquantes
            ],
        }

# Exemple d'utilisation
audit = AuditSecuriteIA("Chatbot Service Client v2.3", "analyste_securite")
audit.evaluer("GOV-01", True, "Document POL-SEC-IA-2026 approuvé le 15/01/2026")
audit.evaluer("SEC-01", True, "Guardrails multi-couche implémentés (voir architecture)")
audit.evaluer("SEC-04", False, "Clé API OpenAI en variable d'environnement .env",
              "Migrer vers un vault (HashiCorp Vault ou AWS Secrets Manager)")

resultat = audit.rapport()
print(f"Décision : {resultat['decision']}")
print(f"Taux de conformité : {resultat['taux_conformite']}")

Un dernier compteur, celui des points non évalués, joue un rôle discret mais décisif. Il empêche de confondre « conforme » et « non vérifié », confusion qui s’installe insidieusement quand un audit s’étale sur plusieurs semaines et que personne ne se rappelle où il s’était arrêté.

Automatiser ce qui peut l’être

Un audit annuel photographie un instant. Entre deux photographies, une clé d’API peut être commitée en dur, une limite de débit désactivée pour dépanner un client pressé, une modération contournée le temps d’un test. Les vérifications automatisées comblent cet intervalle en s’exécutant à chaque intégration continue.

Toutes ne se prêtent pas à l’exercice, et il faut le reconnaître franchement. La recherche de clés en dur est mécanisable, car elle inspecte le code. Les deux autres vérifications de l’exemple retournent des valeurs codées en dur, ce qui n’a de sens que comme point de départ : en production, elles doivent réellement solliciter le service — appeler l’API vingt et une fois pour vérifier qu’un code 429 apparaît, ou soumettre un contenu de test à la modération pour confirmer qu’elle répond. Une vérification qui retourne toujours vrai est pire que pas de vérification, parce qu’elle fabrique de la confiance sans rien mesurer.

class AuditContinu:
    """Vérifie automatiquement les contrôles de sécurité en continu."""

    def __init__(self):
        self.verifications = {}

    def ajouter_verification(self, nom: str, fonction_check):
        """Ajoute une vérification automatisée."""
        self.verifications[nom] = fonction_check

    def executer(self) -> dict:
        """Exécute toutes les vérifications."""
        resultats = {}
        for nom, check in self.verifications.items():
            try:
                ok, detail = check()
                resultats[nom] = {"statut": "OK" if ok else "ECHEC", "detail": detail}
            except Exception as e:
                resultats[nom] = {"statut": "ERREUR", "detail": str(e)}
        return resultats

# Vérifications automatisées
audit_continu = AuditContinu()

def check_cles_api():
    """Vérifie qu'aucune clé API n'est en dur dans le code."""
    import subprocess
    result = subprocess.run(
        ["grep", "-r", "sk-", "src/", "--include=*.py", "-l"],
        capture_output=True, text=True,
    )
    fichiers = result.stdout.strip().split("\n") if result.stdout.strip() else []
    return len(fichiers) == 0, f"{len(fichiers)} fichier(s) avec clé en dur"

def check_rate_limiting():
    """Vérifie que le rate limiting est actif."""
    return True, "Rate limiting actif (429 après 20 req/min)"

def check_moderation():
    """Vérifie que la modération est active sur le pipeline."""
    return True, "API Moderation appelée sur entrées et sorties"

audit_continu.ajouter_verification("cles_api_securisees", check_cles_api)
audit_continu.ajouter_verification("rate_limiting_actif", check_rate_limiting)
audit_continu.ajouter_verification("moderation_active", check_moderation)

Ce qu’attend un certificateur

Viser une certification comme ISO 42001 ou SOC 2 déplace l’effort, et il vaut mieux le savoir avant de s’engager. La documentation vient en premier : politiques, procédures et registres à jour, c’est-à-dire le travail que les équipes techniques repoussent le plus volontiers. Les preuves suivent — logs, rapports de test, captures d’écran — et se collectent d’autant plus facilement qu’on les a archivées au fil de l’eau plutôt qu’à trois semaines de l’audit. L’historique constitue l’exigence la plus dure à rattraper : un SOC 2 Type II examine le fonctionnement des contrôles sur plusieurs mois, ce qu’aucun effort de dernière minute ne fabrique. Vient la formation, dont il faut prouver qu’elle a eu lieu, ce qui suppose des feuilles de présence et des supports datés. L’amélioration continue, enfin, exige de montrer que les trouvailles sont corrigées puis retestées — exactement la boucle de revalidation du chapitre précédent, dont vous mesurez ici la valeur : c’est elle qui produit la preuve que le certificateur réclamera.

Le cycle audit, correction, retest, certification n’a donc pas de terme. Chaque nouvelle fonctionnalité rouvre des points de contrôle, et c’est le sens même du mot « continu » dans « amélioration continue ».

Points clés à retenir

• L’audit transforme les bonnes pratiques de sécurité en preuves vérifiables
• La checklist couvre gouvernance, données, sécurité technique, red teaming et conformité
• Les non-conformités obligatoires sont bloquantes — elles doivent être corrigées avant déploiement
• L’audit continu automatise les vérifications répétitives (clés API, rate limiting, modération)
• La certification (ISO 42001, SOC 2) demande documentation, preuves et historique : le cycle audit, correction, retest est continu, jamais ponctuel

Testez vos connaissances

Sécurité offensive et défensive : le contrôle final avant l’audit.

1. Qu'est-ce qu'une attaque par prompt injection ?

Réponse : Des instructions malveillantes glissées dans les données que traite le modèle (page web, document, message) pour détourner son comportement — la défense : cloisonner instructions et données, valider les sorties, limiter les capacités exposées.

2. Jailbreaking et prompt injection : quelle différence ?

Réponse : Le jailbreak vise à faire contourner ses règles au modèle par la conversation directe ; l’injection passe par les contenus tiers qu’il traite. Les deux se testent — et se contrent — différemment.

3. Pourquoi un filtrage multi-couche ?

Réponse : Parce qu’aucune couche n’est parfaite : modération des entrées, guardrails applicatifs, contrôle des sorties et rate limiting se complètent — la défense en profondeur appliquée à l’IA.

4. En quoi consiste une campagne de red teaming IA ?

Réponse : Attaquer méthodiquement son propre système (scénarios d’injection, jailbreaks, exfiltration) avec une taxonomie de risques, documenter les brèches, prioriser la remédiation — puis re-tester.

5. Que couvre le volet RGPD d'un déploiement OpenAI ?

Réponse : La base légale des traitements, la minimisation des données envoyées, les droits des personnes et les garanties contractuelles — la conformité se conçoit avec l’architecture, pas après.

Un système IA sûr se prouve : taxonomie, tests offensifs, défenses en couches, audit — le cycle que ce cours vous a fait pratiquer.