Checklist sécurité de l’analytique IA : 10 questions aux éditeurs

Un outil d’analytique conversationnelle demande ce que peu de produits SaaS demandent : une connexion active à votre base de données, avec un modèle d’IA dans la boucle. Cette checklist est le questionnaire de sécurité de cette décision — dix questions validé ou rejeté, les questions de fond qui les sous-tendent et les preuves à exiger. Elle est indépendante de tout éditeur : vos équipes sécurité, achats et data peuvent évaluer le risque sur des preuves plutôt que sur des assurances.

Qui doit dérouler cette checklist

Les ingénieurs sécurité et les RSSI qui examinent l’achat d’un outil d’analytique conversationnelle. Les équipes achats qui ont besoin de questions structurées plutôt que d’une présentation fournie par l’éditeur. Les responsables de plateforme data qui porteront la connexion à la base. La checklist s’applique à tout éditeur de la catégorie — Datarelix compris — parce qu’elle teste ce que l’architecture applique, et non ce que l’éditeur affirme.

Est-il prudent de connecter un outil d’IA à votre base de données ?

Tous les produits de cette catégorie ont la même forme : un utilisateur pose une question en langage courant, un modèle d’IA la transforme en requête ou en analyse, et quelque chose exécute cela sur une vraie base de données. Le risque se déploie sur deux axes :

Ce qui parvient au modèle. La structure du schéma ? Des valeurs d’exemple ? Les tables de résultats brutes ? Les identifiants eux-mêmes ?
Ce que le modèle peut faire exécuter. Sa sortie peut-elle modifier des données, atteindre le réseau, échapper à une limite de lignes — ou bien chaque action proposée est-elle contrôlée par un composant que le modèle ne peut pas influencer ?

Séparez la politique de l’architecture au fil des réponses. Un contrôle de politique est une consigne : « on demande au modèle de ne pas écrire de données ». Un contrôle d’architecture est un chemin absent : « les instructions de modification n’ont aucune voie d’exécution ». Les consignes échouent par erreur du modèle et par injection de prompt délibérée : c’est pour cela que ces questions cherchent le second type. L’argumentaire complet sur la lecture seule appliquée par l’architecture est dans analyse de données par IA en lecture seule ; l’équivalent pour les identifiants est dans comment les identifiants restent hors du modèle.

Trois termes : la requête exécutée est l’instruction littérale qui a tourné, pas une reformulation ; un enregistrement d’exécution est la trace stockée et réouvrable d’une question — ce qui a été demandé, planifié, exécuté et renvoyé ; un identifiant restreint est un utilisateur de base de données ayant un accès en lecture aux seuls schémas que vous choisissez d’exposer.

Dix questions critiques, validé ou rejeté

Posez-les à chaque éditeur dès le premier échange ; traitez tout rejet comme un arrêt tant qu’il n’est pas levé par écrit.

#	Question	Ce qu’est une réponse validée
1	Pouvez-vous montrer la requête exécutée exacte avec chaque réponse ?	Le texte littéral de la requête, les tables sources et le nombre de lignes accompagnent chaque réponse — visibles dans le produit, pas disponibles sur demande.
2	L’écriture est-elle impossible par l’architecture plutôt que par la politique ?	Les instructions sont analysées et validées par un composant que le modèle ne peut pas influencer ; les modifications n’ont aucun chemin d’exécution. Pas « on demande au modèle de ne faire que lire ».
3	Où résident les identifiants de base de données, et le modèle les reçoit-il un jour ?	Les identifiants sont détenus par un composant d’exécution, chiffrés au repos, déchiffrés uniquement pour exécuter une requête — jamais dans le contexte du modèle.
4	Qu’envoyez-vous exactement au modèle d’IA ?	Une énumération précise (par exemple : la question et la structure du schéma — noms, types, clés), cas limites compris.
5	Le code d’analyse généré est-il isolé du réseau ?	Trafic sortant bloqué au niveau réseau, avec des plafonds de ressources stricts — pas une vérification dans le code, pas une consigne de prompt.
6	Comment les comptes sont-ils isolés les uns des autres ?	Un mécanisme nommé — un cloisonnement appliqué à chaque requête, idéalement doublé au niveau de la base — pas « une séparation logique ».
7	Pouvons-nous tester avec un identifiant restreint en lecture seule ?	L’éditeur y encourage et documente la configuration au moindre privilège.
8	Qu’enregistrez-vous par exécution, et pouvons-nous le relire plus tard ?	La question, le plan, les instructions exécutées et les résultats — réouvrables depuis l’historique.
9	Comment les échecs et les reprises sont-ils gérés ?	Les reprises sont bornées, et chaque reprise passe par la même validation que la première tentative — jamais un contournement.
10	Pouvez-vous démontrer tout cela en direct ?	Une session réelle sur une question que vous choisissez, montrant les preuves dans le produit — pas une diapositive qui les décrit.

La question 1 est le point d’ancrage : un système qui montre sa requête exécutée rend les autres affirmations vérifiables par vos propres équipes ; un système qui la cache fait de chaque réponse une affaire de confiance. L’habitude de relecture que cela permet est traitée dans comment vérifier les réponses d’une IA sur vos données.

Questions détaillées par domaine

À utiliser lors des points sécurité de suivi.

Identité et droits en base de données

Sous quelle identité de base les requêtes s’exécutent-elles — un compte de service partagé, ou les droits propres de l’utilisateur connecté ?
Une connexion peut-elle être restreinte à des schémas ou des jeux de données précis plutôt qu’à toute la base ?
Quels sont les droits minimaux nécessaires pour se connecter ?
Documentez-vous une configuration au moindre privilège avec un utilisateur de base en lecture seule ?
Si l’identifiant connecté dispose d’un accès plus large que prévu, quelles limites s’appliquent encore de votre côté ?

Validation et exécution des requêtes

Le SQL généré est-il analysé en arbre syntaxique complet, ou comparé à des mots-clés et à des motifs ?
Quels types d’instructions sont autorisés — une liste d’autorisation de lectures, ou une liste de blocage de commandes connues comme dangereuses ?
Pour les langages de requête autres que SQL que vous prenez en charge (KQL, ES|QL et similaires), existe-t-il un validateur dédié par langage ?
Des limites de lignes sont-elles appliquées automatiquement à chaque requête ?
La requête s’exécute-t-elle dans un service isolé du composant qui appelle le modèle ?
La validation peut-elle être affaiblie ou désactivée par connexion, par utilisateur, ou par le support ?

Flux de données vers le modèle

Que contient le contexte du modèle : la question, la structure du schéma, des valeurs d’exemple, des résultats précédents ?
Les résultats bruts des requêtes sont-ils un jour renvoyés au modèle — et si une valeur de résultat peut entrer dans le contexte des questions suivantes, lesquelles exactement ?
Quel fournisseur de modèle traite les requêtes, et sous quelles conditions d’utilisation des données — quelque chose sert-il à l’entraînement ?
Que conserve le fournisseur de modèle, et pendant combien de temps ?
Les descriptions de schéma sont-elles rédigées par les utilisateurs, ou échantillonnées automatiquement dans les données ?

Gestion des identifiants

Comment les identifiants sont-ils chiffrés au repos — y a-t-il un chiffrement applicatif par-dessus le chiffrement du stockage ?
Quel composant les déchiffre, à quel moment, et combien de temps existent-ils en clair en mémoire ?
Les identifiants peuvent-ils apparaître dans les journaux, les messages d’erreur ou les outils du support ?
Quelle est la procédure de rotation, et qu’est-ce qui casse quand nous effectuons une rotation ?
Prenez-vous en charge une authentification par identité, propre à chaque utilisateur, en alternative aux mots de passe de base stockés ?

Isolation du code généré

Le produit exécute-t-il du code généré par le modèle — et si oui, dans quel langage, et où ?
Le trafic sortant est-il bloqué au niveau réseau, ou seulement empêché dans le code ?
Quels plafonds de CPU, de mémoire et de temps s’appliquent à une exécution en bac à sable ?
Le code en bac à sable peut-il atteindre la base directement, ou seulement les jeux de résultats qui lui sont transmis ?
Que se passe-t-il quand le code en bac à sable plante ou dépasse ses plafonds ?

Enregistrements d’exécution et relecture

Que contient un enregistrement d’exécution — question, plan, instructions exécutées, résultats ?
Une exécution passée peut-elle être rouverte et sa requête exécutée lue mot pour mot ?
Combien de temps les enregistrements d’exécution et les jeux de résultats stockés sont-ils conservés, et peuvent-ils être supprimés sur demande ?
Qui, chez l’éditeur, peut accéder aux enregistrements d’exécution, et sous quels contrôles ?
L’enregistrement est-il assez complet pour que notre équipe puisse reproduire la réponse de son côté ?

Accès au compte et authentification

Quels fournisseurs d’identité sont pris en charge à la connexion, et pouvons-nous en imposer un ?
Le provisionnement et le déprovisionnement automatiques (SCIM) sont-ils disponibles si notre organisation l’exige ?
Quels rôles ou niveaux de permission existent aujourd’hui dans un compte — et lesquels relèvent de la feuille de route plutôt que de fonctionnalités livrées ?
La journalisation d’audit des actions d’administration (connexions créées, identifiants modifiés, ouvertures de session) est-elle accessible à notre équipe sécurité ?
Comment les données d’un compte sont-elles isolées de celles d’un autre — par des vérifications applicatives seules, ou également appliquées au niveau de la base ?

Exploitation

Quels sont vos engagements de notification d’incident, et figurent-ils au contrat ?
Votre liste de sous-traitants ultérieurs est-elle publiée, et comment les changements sont-ils communiqués ?
Dans quelles régions les données clients sont-elles traitées et stockées ?
Existe-t-il un canal de divulgation de vulnérabilités, et commandez-vous des tests de sécurité indépendants ?
Remplirez-vous notre questionnaire de sécurité, et des attestations de tiers sont-elles disponibles sous NDA ?
Qu’est-ce qui est supprimé lorsque nous partons, et comment la suppression est-elle confirmée ?

Preuves à exiger

Demandez ces quatre éléments avant de signer :

Une description écrite de l’architecture et des flux de données — assez précise pour que votre équipe puisse en tirer le schéma.
Une démonstration en direct des preuves. Posez votre propre question dans le produit de l’éditeur et regardez où apparaissent la requête exécutée, les tables sources et le nombre de lignes.
Un questionnaire de sécurité rempli. Des réponses vagues par écrit annoncent des réponses vagues pendant un incident.
Un essai avec un identifiant restreint. Créez un utilisateur de base en lecture seule limité à un schéma non sensible et menez l’évaluation vous-même. Exemple illustratif sur un schéma de commerce fictif :

-- Illustrative (PostgreSQL, fictional demo schema): a scoped read-only trial user
CREATE ROLE analytics_trial LOGIN PASSWORD '<generated>';
GRANT USAGE ON SCHEMA sales TO analytics_trial;
GRANT SELECT ON sales.orders, sales.customers, sales.order_items TO analytics_trial;

Un modèle de notation simple

Gardez une notation tranchée :

Les dix questions critiques sont validé ou rejeté. Tout rejet est un arrêt : l’éditeur le lève par écrit, ou l’évaluation s’arrête.
Notez chaque domaine satisfaisant ou insatisfaisant selon la précision et la cohérence des réponses. Le nombre de domaines satisfaisants que vous exigez dépend de la sensibilité de vos données — mais fixez ce nombre avant le début des échanges.
Pesez les preuves plus que les réponses. Une démonstration en direct d’une frontière pèse plus qu’une page de prose à son sujet.

Signaux d’alerte

Signal d’alerte	Ce que cela signifie en général
L’éditeur ne peut pas montrer la requête exécutée derrière une réponse	Les réponses sont invérifiables par conception ; chaque résultat est un acte de foi.
La « lecture seule » est appliquée par des consignes de prompt	La garantie tombe précisément quand le modèle dérape — le cas pour lequel elle existe.
Les identifiants sont intégrés aux prompts ou au contexte du modèle	Les paramètres de connexion sont à une injection de l’extraction.
Les réponses restent à « nous sommes sécurisés » face à des questions précises	Aucun mécanisme derrière l’adjectif — supposez que l’architecture ressemble à la réponse.
Refus d’un essai avec un identifiant restreint en lecture seule	L’éditeur veut plus d’accès que l’évaluation n’en demande, au moment où la confiance est la plus faible.

Dérouler cette checklist face à Datarelix

Nos réponses sont sur la page sécurité : ce qui est envoyé au modèle, ce qui est stocké, ce qui n’est jamais fait, et comment chaque frontière est appliquée. Plutôt que de les répéter ici, menez l’évaluation directement :

Lisez cette page à l’aune des dix questions critiques.
Lancez un essai avec un identifiant restreint en lecture seule, en suivant les guides de connexion pour votre moteur. Posez une question, puis ouvrez l’exécution et lisez ses preuves — chaque exécution reste réouvrable depuis l’historique.
Envoyez votre questionnaire de sécurité, vos questions sur l’état de conformité ou vos demandes de DPA via la page contact.

Ce que cette checklist ne teste pas

Cette checklist évalue l’architecture de sécurité, pas la qualité des réponses. Un éditeur peut valider chaque question et mal interpréter malgré tout la logique métier de votre schéma. Évaluez l’exactitude séparément, avec vos propres questions sur vos propres données.
Le binaire validé/rejeté écrase les nuances. Certains rejets sont des écarts qu’un éditeur peut combler vite ; distinguez « ne peut pas » de « ne fait pas encore », et faites confirmer le second par écrit, avec une date.
Les réponses vieillissent. Les architectures et les sous-traitants changent — refaites les dix questions critiques au renouvellement, pas seulement à l’achat.
Elle ne remplace pas une revue juridique. Les DPA, la responsabilité et les clauses de transfert de données relèvent d’un travail juridique que cette checklist n’aborde pas.
Les données réglementées relèvent le niveau d’exigence. Les obligations réglementaires propres aux données connectées passent avant et s’ajoutent à tout ce qui précède.
Si votre politique interdit tout traitement des métadonnées de schéma par un modèle tiers, aucune réponse d’éditeur n’y changera rien — la catégorie elle-même peut ne pas convenir, et mieux vaut l’établir dès le premier jour.

Portée et provenance

Les affirmations sur le produit décrivent Datarelix tel que livré en août 2026 ; la page sécurité fait référence. La checklist elle-même est indépendante de tout éditeur et n’avance aucune affirmation sur un autre éditeur. L’exemple SQL utilise un schéma de démonstration de commerce fictif et n’est qu’illustratif. Les dix questions et le modèle de notation sont les nôtres ; ce guide ne cite aucune source externe.