Le questionnaire de sécurité IA exige des preuves, pas des promesses.

Votre interlocuteur côté client transmet un tableur de 94 lignes. Le dossier ne dépend plus de l’équipe produit, mais des risques fournisseurs.

D’expérience, ce passage de relais peut prendre deux à six semaines. Souvent, personne n’a découvert de nouvelle vulnérabilité. Le fournisseur ne sait simplement pas convertir ses affirmations en preuves qu’un tiers peut examiner.

Préparez le dossier avant l’arrivée du tableur. Pour une requête, montrez le parcours, les contrôles, l’effet produit et l’endroit exact où la preuve s’arrête. Les dix questions définissent ce dossier ; la séquence finale l’assemble en cinq jours.

Une réponse soignée ne constitue toujours pas une preuve

Le questionnaire évalue bien la sécurité. Il ne récompense pas l’assurance pour elle-même.

L’évaluateur cherche à savoir si vous pouvez expliquer ce que le système a fait, puis le vérifier lui-même. Une politique décrit une intention. Une trace, une requête, un fichier de configuration ou un test avec injection de panne établit le mécanisme appliqué à une requête précise.

Comparez deux réponses. « Les données sont chiffrées en transit et au repos » énonce une intention. « Le corps des prompts est écrit en clair dans spend_logs.messages sur Postgres, conservé 90 jours, et cette requête renvoie les lignes » expose un mécanisme. La seconde réponse révèle un constat gênant, mais donne à l’évaluateur un élément concret à examiner.

Un dossier sans aucun constat gênant inspire peu confiance. Les systèmes réels conservent des champs inattendus, héritent de valeurs par défaut et contiennent des contrôles jamais testés en panne. Consignez ces limites. Ne les lissez pas.

Quatre sources publiques annoncent déjà les questions

Les questionnaires d’entreprise varient, mais nombre de questions reprennent quelques référentiels publics d’achat et de gestion des risques. Consultez-les avant l’arrivée du tableur client, puis classez vos preuves dans le même ordre.

Questionnaires du secteur public et de la société civile. Le questionnaire de l’ACLU sur les fournisseurs d’IA générative aborde les données personnelles d’entraînement, les analyses de fuite, les droits de suppression, la journalisation, l’accès aux prompts et les limites contractuelles imposées à l’entraînement sur les données client. Utilisez ces questions pour inventorier les preuves, pas seulement pour cocher des cases.

Référentiels du secteur financier. Le guide d’évaluation fournisseur de FS-ISAC va de la découverte générale aux aspects juridiques, en passant par la confidentialité, la validation du modèle, la sécurité, l’intégration et le risque de rang n. Le risque tiers concerne le fournisseur sous contrat ; le risque de rang n couvre les prestataires et services dont ce fournisseur dépend. Reprendre cet ordre facilite la lecture du dossier.

Clauses européennes pour l’achat d’IA. Les clauses contractuelles types actualisées de l’Union européenne proposent une version complète et une version allégée aux acheteurs publics. Elles couvrent notamment la documentation, la journalisation, la supervision et la traçabilité. La traçabilité sur tout le cycle de vie relie une décision au modèle, à la configuration, à l’entrée, aux contrôles et à l’effet produit pendant l’exploitation du système.

Le règlement européen sur l’intelligence artificielle. Pour les systèmes classés à haut risque, les articles 12, 14 et 15 portent sur la tenue de registres, la supervision humaine, l’exactitude, la robustesse et la cybersécurité. Les obligations précises dépendent du rôle et de la classification. La question d’ingénierie reste concrète : quels champs et journaux permettent de reconstituer le registre demandé ?

Dessinez une requête avant de rédiger dix réponses

Commencez par une carte du parcours des données : chaque étape suivie par une requête et chaque système qui en conserve une copie. Contrairement à un schéma d’architecture général, elle nomme les champs, les points de terminaison, les juridictions, les durées de conservation et les mécanismes de suppression que l’évaluateur peut vérifier.

Retracer ce parcours depuis la configuration, les conteneurs et les schémas prend environ une journée. La carte étaye les questions 1, 2, 3 et 9. Pour imputer les coûts de la question 10, il faut aussi relier les identifiants aux consommations et aux tarifs applicables ; la carte seule ne chiffre pas une tâche. Chaque <FILL> non résolu constitue un constat, pas un simple manque documentaire.

Lors de mes revues, je retrouve régulièrement des requêtes complètes stockées en clair parce que la journalisation de la passerelle était activée par défaut. Personne n’a décidé de les conserver : l’équipe a simplement hérité de ce réglage.

Dix questions, dix réponses reproductibles

Pour chaque question, nommez le mécanisme et joignez un élément qu’un tiers peut reproduire. S’il n’existe pas, consignez la limite et attribuez la correction.

1. Où part physiquement une requête, et quels systèmes la conservent ?

Réponse improvisée : « Les requêtes sont traitées de manière sécurisée et ne sont pas conservées plus longtemps que nécessaire. »

Preuve : la carte du parcours des données, la requête qui liste les systèmes de stockage et une ligne d’exemple dont les champs sensibles ont été masqués.

2. Le système crée-t-il des représentations vectorielles, et où les stocke-t-il ?

Les embeddings, ou représentations vectorielles, servent à rechercher et à retrouver de l’information. Ils ne sont pas anonymes par défaut. Si vous en produisez, précisez leur stockage, les contrôles d’accès, le lien avec les sources et l’effet d’une suppression. Sinon, dites-le et montrez la configuration qui le confirme.

3. Qu'est-ce qui est conservé, pendant combien de temps, et qu'est-ce qui le supprime réellement ?

Le piège tient au mot réellement. Une politique de conservation ne constitue pas un mécanisme de suppression. Si une tâche planifiée efface les données, nommez-la. Si l’opération reste manuelle, dites-le. Si les sauvegardes dépassent la durée annoncée, donnez cette réponse.

4. Peut-on reconstituer une décision de bout en bout depuis un identifiant, et en combien de temps ?

L’évaluateur veut savoir si un incident peut être analysé. Ici, la reconstitution consiste à retracer une requête passée, pas à relancer le modèle en espérant la même sortie. Une réponse solide prend un identifiant et affiche, dans l’ordre, chaque appel de modèle, appel d’outil, décision de politique et effet.

Une démonstration en moins d’une minute remplace plusieurs affirmations par un enregistrement vérifiable. Elle ne prouve pas que cet enregistrement résiste aux altérations ; la question 8 traite cette propriété séparément.

5. Quelle version de modèle et quel point de terminaison fournisseur ont servi une requête donnée ?

« Nous utilisons des modèles de type GPT » ne suffit pas. Les identifiants changent, les fournisseurs retirent des versions et le comportement varie. La réponse attendue est un champ enregistré pour chaque requête, pas un paragraphe.

6. Quels paramètres permettent de déroger aux contrôles, et leurs modifications sont-elles journalisées ?

Configuration du routage, règles du filtre textuel, politique des outils : qui peut les modifier, par quelle interface et avec quelle trace ? Si un fichier de politique peut changer sans laisser d’entrée d’audit, consignez-le comme un constat.

7. Qu’est-ce qui arrête une action destructive, et que se passe-t-il si le contrôle devient injoignable ou déclenche une exception ?

L’exigence se résume simplement : autorisez l’action avant qu’elle n’atteigne le système capable de l’exécuter.

Un filtre limité au texte peut ignorer les arguments structurés d’un appel d’outil. Une phrase anodine peut accompagner un delete avec un identifiant générique. Vérifiez les champs réellement lus par votre filtre : même leur inspection ne suffit pas à établir le droit de l’appelant à exécuter cette action.

Placez un service d’autorisation devant le serveur d’outils. Ce composant séparé autorise ou refuse chaque appel selon des règles explicites. Il examine le nom de l’outil, l’appelant, les arguments et l’état utile. En cas de panne, il doit refuser par défaut : s’il devient injoignable ou lève une erreur, l’action reste interdite. Prouvez ce comportement par un test avec injection de panne.

8. Comment détecteriez-vous une altération de la piste d'audit ?

Conservez une copie du journal hors des droits d’écriture de l’application. Un chaînage de hachage peut révéler une entrée altérée, mais ne prouve pas à lui seul que le journal est complet : quelqu’un pourrait en supprimer la fin ou réécrire les entrées et recalculer les empreintes. Protégez le stockage et conservez des points de contrôle hors du contrôle de l’émetteur. Testez les altérations que vous prétendez détecter.

9. Qu'est-ce qui sort du périmètre, vers quelle juridiction, et quelle est la preuve de cette sortie ?

Les flux sortants regroupent les données qui quittent votre environnement contrôlé. Nommez les points de terminaison, les champs, les sous-traitants et les juridictions, puis fournissez les traces réseau ou de passerelle. Si les requêtes quittent l’Union européenne, dites-le. Pour certains acheteurs, cette réponse détermine le mode de déploiement acceptable.

10. Combien coûte une unité de travail, et comment la dépense est-elle imputée ?

Les achats posent cette question de plus en plus souvent. Ventilez la dépense par clé, par équipe et par tâche. Si vous ne pouvez pas plafonner une boucle d’agent incontrôlée, indiquez l’exposition maximale.

Toute preuve a besoin d’une frontière

Chaque réponse du dossier devrait porter quatre champs : l'affirmation, la preuve (chemin de fichier et commande ou requête exacte), la façon dont un tiers la reproduit, et ce que cela n'établit pas.

Ce quatrième champ empêche de transformer un test ciblé en promesse générale. Par exemple : « Ce test démontre que le service d’autorisation applique la politique. Il ne démontre pas que l’hôte résisterait à une compromission. » L’évaluateur peut accepter la première affirmation sans présumer la seconde.

Dans les revues que j’ai observées, une limite déclarée ouvre la discussion sur sa correction. Une affirmation exagérée déclenche un nouveau cycle d’audit. La précision fait gagner plus de temps qu’un discours rassurant.

Un premier passage en cinq jours

Commencez par les éléments qui répondent à plusieurs questions d’un coup :

• Jour 1. Dessinez la carte du parcours des données. Ne devinez aucune flèche. Lisez la configuration, inspectez les conteneurs et interrogez le schéma. Chaque <FILL> non résolu constitue un constat.
• Jour 2. Construisez la reconstitution. À partir d’un identifiant, retracez toute la requête depuis les systèmes existants. Beaucoup d’équipes découvrent alors que leurs identifiants ne se raccordent pas entre systèmes.
• Jour 3. Écrivez le test du contrôle des actions destructives, y compris le cas d’injection de panne.
• Jour 4. Répondez aux dix questions avec les quatre champs.
• Jour 5. Demandez à une personne qui n’a pas construit le système de reproduire trois réponses à partir des seules commandes. Ce qu’elle ne peut pas reproduire n’est pas encore une preuve.

Au bout de la semaine, le dossier ne prouvera pas que tout le produit est sécurisé. Il donnera un compte rendu reproductible d’un processus, de ses contrôles et de ses lacunes connues. De nombreux échanges de suivi pourront ainsi céder la place aux preuves.

Laissez une requête porter la discussion commerciale

Une fois le dossier prêt, cessez d’affirmer que le système est gouvernable : démontrez-le sur une requête. Montrez son parcours, reconstituez sa trajectoire, injectez une panne dans un contrôle et indiquez la limite exacte. L’acheteur voit le mécanisme et sa frontière.

Tôt ou tard, chaque affirmation rencontre une requête, une trace ou un test. Préparez cette rencontre avant le tableur des achats.