Évaluer la sécurité d’un fournisseur d’IA générative

Un fournisseur d’IA (Intelligence Artificielle) générative s’évalue comme n’importe quel prestataire en nuage, plus trois questions que les questionnaires standard ne posent pas : comment les clients sont isolés au moment de l’inférence, ce que le fournisseur fait des incidents propres aux modèles, et quelles preuves il accepte de montrer. La position défendue ici : une réponse de questionnaire ne vaut rien sans la pièce qui la prouve, et l’isolation entre clients pèse plus lourd que la collection de logos de certification.

→ Lire l’explication complète de la marmotte

Certifications ISO 27001, SOC 2 et ISO 42001 : lire le périmètre avant le logo

Trois référentiels reviennent dans les dossiers des fournisseurs.

ISO/IEC 27001 (International Organization for Standardization / International Electrotechnical Commission) certifie un système de management de la sécurité de l’information. La question décisive est la déclaration d’applicabilité et le périmètre du certificat : il couvre souvent l’entité juridique ou l’infrastructure principale, pas forcément le service d’IA générative lancé après le dernier audit.

SOC 2 (System and Organization Controls 2) est un rapport d’auditeur. Le type I décrit des contrôles à une date ; le type II les teste sur une période. Seul le type II renseigne sur le fonctionnement réel. Les sections utiles sont celles que personne ne lit : les exceptions relevées par l’auditeur, les contrôles attendus du client (souvent longs, et qui transfèrent une partie de la sécurité à l’acheteur) et la période couverte. Un rapport dont la période s’est achevée il y a longtemps se complète par une lettre de continuité.

ISO/IEC 42001 certifie un système de management de l’IA : gouvernance, analyse d’impact, cycle de vie des modèles. Elle dit que le fournisseur a une méthode, pas que ses modèles résistent à une attaque.

Aucune de ces certifications ne teste l’isolation entre clients d’un service d’inférence ni la résistance à l’injection de consignes. Le registre STAR (Security, Trust, Assurance and Risk) de la CSA (Cloud Security Alliance), présenté dans la rubrique Organismes, fournit un format de réponse commun, pas une preuve de plus. Accumuler les logos sur une page de confiance est à la sécurité ce que le nombre d’étoiles d’un hôtel est à la propreté des draps.

Isolation entre clients : cache, affinage et bases vectorielles

Un service d’inférence mutualisé fait tourner les requêtes de milliers de clients sur les mêmes accélérateurs. Les points de contact entre locataires sont précis et doivent être interrogés un par un :

Cache de préfixe. Les fournisseurs mettent en cache le début des requêtes pour accélérer les suivantes. Des travaux publics ont montré qu’un cache partagé entre clients se détecte par mesure du temps de réponse, ce qui révèle qu’un autre client a envoyé le même préfixe. La question à poser : le cache est-il cloisonné par organisation ?
Affinage et modèles personnalisés. Les poids issus d’un affinage sur les données d’un client doivent rester propres à ce client, chiffrés et supprimables. Demander où ils sont stockés et qui peut les charger.
Bases vectorielles et fichiers. Les services de recherche documentaire hébergés stockent des index par client ; le cloisonnement repose sur des contrôles applicatifs, dont on demande la description et le résultat du dernier test d’intrusion.
Accès humain. Qui chez le fournisseur peut lire une conversation, dans quel cas (enquête d’abus, support), avec quelle approbation et quelle journalisation visible par le client.

Les bogues d’isolation arrivent : un défaut de bibliothèque de cache a déjà exposé à des utilisateurs des titres de conversation d’autres utilisateurs chez un grand fournisseur public. Ce qui distingue un fournisseur sérieux n’est pas l’absence d’incident, c’est la qualité de sa réponse.

Gestion des incidents et questionnaire : exiger des preuves

La gestion des incidents s’évalue sur pièces. Demander l’historique des incidents publiés et leurs analyses post-incident : un fournisseur qui n’en a jamais publié n’est pas un fournisseur sans incident. Vérifier l’existence d’un fichier security.txt (normalisé par la RFC 9116, Request for Comments), d’une politique de divulgation de vulnérabilités et d’un programme de récompense qui inclut explicitement les attaques propres aux modèles (injection de consignes, extraction de données d’entraînement, contournement des filtres). Obtenir un engagement écrit de notification, avec un point de contact nommé côté sécurité.

Le questionnaire se construit autour de ce principe : chaque question appelle une preuve, et une réponse sans preuve compte comme une réponse négative. Les sujets contractuels (accord de sous-traitance, durée de conservation des requêtes, exposition au droit extraterritorial, fédération d’identité) ont chacun leur page dédiée ; ils s’ajoutent à la grille sans la remplacer. La rubrique Cloud couvre l’évaluation générique d’un prestataire en nuage.

Exemple : grille d’évaluation en YAML et vérification de security.txt

La grille tient en un fichier versionné, qui sert de trame au questionnaire et de trace de la décision. La commande qui suit vérifie un premier point sans rien demander au fournisseur.

# grille-fournisseur-ia.yaml : chaque critère exige une preuve, sinon il est noté "non"
fournisseur: exemple-fournisseur
service_evalue: api-chat-entreprise            # le service précis, pas l'entité
criteres:
  - id: certif-perimetre
    question: Le service évalué figure-t-il dans le périmètre du certificat ISO 27001 ?
    preuve: certificat + déclaration d'applicabilité
    eliminatoire: false
  - id: soc2-type2
    question: Rapport SOC 2 type II couvrant le service, exceptions comprises ?
    preuve: rapport complet sous accord de confidentialité
    eliminatoire: true
  - id: cache-cloisonne
    question: Le cache de préfixe est-il cloisonné par organisation cliente ?
    preuve: documentation technique ou attestation d'auditeur
    eliminatoire: true
  - id: acces-humain
    question: Accès du personnel aux conversations journalisé et visible du client ?
    preuve: procédure + exemple d'extrait de journal
    eliminatoire: false
  - id: divulgation
    question: Politique de divulgation couvrant les attaques sur le modèle ?
    preuve: adresse publique de la politique
    eliminatoire: false
decision: { date: 2026-09-29, revue: annuelle }

# Vérifie la présence d'un contact sécurité publié (RFC 9116) chez le fournisseur.
curl -fsS https://fournisseur.example/.well-known/security.txt \
  | grep -Ei '^(Contact|Expires|Policy):'   # Expires dépassé = fichier abandonné

L’absence de security.txt n’élimine personne ; un fichier expiré en dit long sur l’attention portée au sujet. L’évaluation se refait à chaque nouveau service activé et au moins une fois par an ; la rubrique Gouvernance traite le cadre de revue des tiers.

🐝 Ce qui arrive si on s’en passe

Sans évaluation, la chaîne réelle de sous-traitance reste invisible : un service présenté comme fournisseur d’IA peut n’être qu’une surcouche qui relaie les requêtes vers l’API d’un autre éditeur, avec ses propres journaux et son propre personnel. Les données transitent alors par deux organisations dont une seule a été vue. Lors d’un incident chez l’éditeur sous-jacent, aucune notification n’est due au client final, et l’organisation apprend l’exposition de ses requêtes en même temps que le public.

🦫 Explication de la marmotte 🍫

Avant d’utiliser le service d’intelligence artificielle d’une entreprise extérieure, une organisation vérifie que ce service protège les informations qu’elle va lui envoyer. Elle commence par les certificats : ce sont des attestations délivrées par des auditeurs indépendants. Il faut regarder ce qu’ils couvrent exactement, car un certificat peut concerner l’entreprise en général et pas le service d’intelligence artificielle récent. Il faut aussi lire les défauts relevés par l’auditeur. Ensuite, elle vérifie la séparation entre clients. Les mêmes ordinateurs traitent les demandes de milliers d’entreprises ; si une mémoire temporaire est partagée, un client peut parfois deviner ce qu’un autre a envoyé en mesurant la vitesse des réponses. Elle demande aussi qui, chez le fournisseur, peut lire les conversations et si ces lectures sont enregistrées. Puis elle examine la façon dont le fournisseur gère les problèmes : publie-t-il ses incidents, accepte-t-il les signalements de chercheurs, s’engage-t-il par écrit à prévenir ses clients ? Chaque réponse du fournisseur doit être accompagnée d’un document qui la prouve ; une promesse sans document vaut refus. Enfin, l’évaluation se refait chaque année et à chaque nouveau service, car les offres changent vite.

Pages voisines

La citent

Évaluer la sécurité d'un fournisseur d'IA générative

Elle cite