Analytique IA en lecture seule : architecture, contrôles et menaces
Ce qu’exige réellement l’analytique IA en lecture seule : le modèle de menace, les couches de contrôle qui l’appliquent et les risques résiduels à examiner.
Par l'équipe Datarelix · Publié le · Mis à jour le · Vérifié le
L’analytique IA en lecture seule signifie qu’un système d’IA peut répondre à des questions posées sur votre base de données, mais qu’il n’a aucun chemin — accidentel ou malveillant — pour la modifier. Cette propriété ne se décrète pas dans un prompt ; elle doit être appliquée à des frontières indépendantes : l’identité de la base de données, un validateur qui analyse chaque requête, une couche d’exécution séparée, un chemin réseau isolé et une trace enregistrée.
À qui s’adresse cette évaluation
Aux ingénieurs sécurité et aux auditeurs IT qui mènent une évaluation fournisseur sur un outil d’analytique conversationnelle. Aux responsables de bases de données et de plateformes data qui décident quel identifiant confier et ce qu’il doit avoir le droit de voir. Aux responsables data qui doivent répondre à « que se passe-t-il quand le modèle se trompe ? » par un mécanisme plutôt que par une assurance.
Comment empêcher un outil d’IA d’écrire dans votre base de données
Beaucoup d’outils annoncent un comportement en lecture seule parce qu’un prompt système demande au modèle de ne pas écrire. Un prompt ne peut pas l’appliquer. Les modèles se laissent orienter par des entrées malveillantes, et les instructions injectées arrivent par le même canal que les instructions légitimes. La lecture seule par conception veut dire quelque chose de plus strict : même si le modèle propose une écriture, aucun composant en aval ne l’exécutera.
Le plan structuré est la seule sortie du modèle, et il n’exécute rien par lui-même. La couche d’exécution valide ce plan selon un schéma strict et exécute chaque étape. Le validateur en lecture seule rejette toute requête générée qui n’est pas une lecture. Le service de requêtes isolé est le seul composant qui détient la connexion à la base de données.
Le modèle de menace
Cinq menaces couvrent l’essentiel de ce qu’une revue de sécurité doit sonder dans cette catégorie.
| # | Menace | Vecteur | À quoi ressemble la défaillance |
|---|---|---|---|
| T1 | Tentative d’écriture par injection de prompt | Du texte malveillant dans une question, ou dans des descriptions de tables renseignées à la main, oriente le modèle vers une instruction de modification | Le système exécute une écriture que l’utilisateur n’a jamais voulue |
| T2 | SQL destructif | Le modèle émet DROP, DELETE, TRUNCATE ou du DDL — halluciné ou induit | Perte de données ou dégradation du schéma dans la base connectée |
| T3 | Exfiltration par le code d’analyse généré | Le code Python généré tente d’envoyer les résultats de requête vers un hôte externe | Les données de résultat quittent l’environnement par le réseau |
| T4 | Exposition des identifiants au modèle | Un prompt façonné amène des détails de connexion dans une réponse du modèle | Des chaînes de connexion ou des secrets apparaissent dans la conversation |
| T5 | Accès entre comptes | Une requête émise par un compte atteint les connexions, exécutions ou tableaux de bord d’un autre compte | Les données d’un client sont visibles par un autre |
T1 et T2 diffèrent par l’intention — l’une malveillante, l’autre une erreur du modèle — mais convergent vers le même point de passage obligé.
Les couches de contrôle
Une identité de base de données au moindre privilège
Le premier contrôle vous appartient, pas au fournisseur : ce que l’identifiant connecté a le droit de faire. Un outil d’analytique en lecture seule doit être connecté avec un utilisateur de base de données disposant du SELECT sur les schémas que vous voulez interroger, et de rien d’autre — les guides de connexion par moteur indiquent les droits à accorder pour chacun. Sur Azure SQL, Databricks SQL et Kusto, une formule Enterprise permet à la place d’exécuter une connexion avec les propres permissions de base de données de l’utilisateur connecté (On-Behalf-Of par utilisateur) : les questions de chaque personne sont alors bornées par les accès qu’elle détient déjà. Comme c’est le moteur de base de données qui applique cette couche, elle ne dépend pas du bon comportement du système d’IA.
Un validateur en lecture seule qui analyse au lieu de filtrer par motifs
Chaque instruction SQL générée est analysée en arbre syntaxique complet avant de s’exécuter, et rejetée si ce n’est pas une lecture : uniquement des instructions SELECT, des CTE et des opérations ensemblistes. L’analyse syntaxique compte parce que les filtres par mots-clés échouent sur du SQL réel. Prenons une CTE qui modifie les données, écrite ici sur le schéma de démonstration d’un distributeur fictif :
-- Looks like a read to a keyword filter. It is a write.
WITH removed AS (
DELETE FROM orders
WHERE status = 'test'
RETURNING order_id
)
SELECT COUNT(*) FROM removed;
Un filtre qui vérifie si l’instruction « commence par SELECT ou WITH » la laisse passer. Un parcours de l’arbre syntaxique trouve le nœud DELETE à l’intérieur de la CTE et rejette l’instruction entière. KQL et ES|QL ne partagent pas la grammaire de SQL : chacun passe donc par un validateur dédié qui bloque toute commande de modification ou d’administration. Des limites de lignes automatiques sont appliquées à chaque requête, de sorte qu’aucune question ne peut renvoyer un résultat non borné. Face à T1 et T2, c’est le point de passage obligé : ce qui n’est pas une lecture n’a aucun chemin d’exécution.
La séparation plan / exécution
Le modèle ne produit qu’un plan structuré ; il n’exécute rien lui-même. La couche d’exécution valide ce plan selon un schéma strict, puis exécute elle-même chaque étape. Un plan est une donnée inerte : il peut être inspecté, rejeté et enregistré avant que quoi que ce soit ne touche une base de données. Comme l’autorité d’exécution n’appartient jamais au modèle, une injection de prompt peut changer au mieux ce qui est proposé, jamais ce qui est autorisé. Chaque exécution est enregistrée étape par étape et peut être rouverte depuis l’historique : un auditeur voit exactement ce qui a tourné.
Un service de requêtes isolé détient la connexion
Les requêtes validées s’exécutent dans un service de requêtes isolé, le seul composant qui dispose de la connexion à la base de données. Les identifiants de connexion sont chiffrés au repos et déchiffrés au seul moment où une requête s’exécute, sous la garde de la couche d’exécution. Le modèle ne les reçoit jamais : il n’y a donc aucune chaîne de connexion à extraire de son contexte. Cela ferme T4 par construction plutôt que par comportement, et l’argument complet est dans comment les identifiants restent hors du modèle.
Un bac à sable sans réseau pour le code Python généré
Les questions qui demandent plus que du SQL — une prévision, une répartition par cohorte — font tourner du code Python généré dans un bac à sable isolé, sans accès réseau : le trafic sortant est bloqué au niveau réseau (un pare-feu, pas une vérification dans le code), sous des plafonds stricts de CPU et de mémoire. Le code qui tente d’envoyer des résultats où que ce soit échoue au niveau du socket. C’est le contrôle qui répond à T3 : l’exfiltration a besoin d’un chemin réseau, et il n’y en a aucun.
Faire correspondre les contrôles aux menaces
Une propriété utile à exiger de toute architecture de cette catégorie : chaque menace devrait être couverte par au moins deux couches indépendantes, pour qu’aucune défaillance isolée ne suffise à elle seule.
| Menace | Contrôle principal | Garde-fou indépendant |
|---|---|---|
| T1 Tentative d’écriture par injection de prompt | Le validateur en lecture seule rejette ce qui n’est pas une lecture | Séparation plan / exécution ; identité de base de données en lecture seule |
| T2 SQL destructif | Validateur en lecture seule (arbre syntaxique complet) | L’identité de base de données en lecture seule refuse au niveau du moteur |
| T3 Exfiltration par le code d’analyse | Bac à sable sans réseau (blocage du trafic sortant au niveau réseau) | Les résultats bruts des requêtes ne sont jamais renvoyés au modèle ; plafonds de CPU et de mémoire |
| T4 Exposition des identifiants au modèle | Les identifiants ne sont détenus que par la couche d’exécution | Chiffrement au repos ; déchiffrement au seul moment de l’exécution de la requête |
| T5 Accès entre comptes | Chaque enregistrement est rattaché au compte demandeur dans chaque requête | Sécurité au niveau des lignes dans la base de données |
Le rattachement au compte est appliqué par la couche d’exécution sur chaque enregistrement qu’elle touche, avec la sécurité au niveau des lignes de la base de données comme garde-fou en dessous.
Les risques résiduels qu’une revue doit sonder
Trois risques subsistent après toutes les couches ci-dessus.
La portée de l’identifiant connecté relève de vous. La plateforme peut lire tout ce que l’identifiant que vous connectez peut lire. Connectez un compte large et les questions porteront sur tout ce qu’il voit — la validation continue de restreindre l’exécution aux lectures, mais lire des données que vous ne vouliez pas exposer reste une exposition. Un utilisateur de base de données restreint et en lecture seule est un contrôle que vous seul pouvez appliquer.
Une valeur de réponse unique peut passer dans le contexte des questions suivantes. Les résultats bruts des requêtes — les tables de résultats — ne sont jamais renvoyés au modèle. Mais une valeur de réponse sur une seule ligne, disons un montant de chiffre d’affaires, peut être reprise dans le contexte des questions suivantes, pour qu’un « et par rapport à l’an dernier ? » ait du sens. Une revue menée en profondeur doit fixer la frontière exactement : la structure du schéma et les valeurs de réponse uniques, pas les tables de résultats.
Les questions ambiguës peuvent être mal comprises. « Clients actifs » au sens de la dernière connexion et « clients actifs » au sens d’un achat récent sont deux requêtes différentes, et le modèle doit trancher pour une lecture. La requête exacte accompagne chaque réponse : une mauvaise interprétation se voit d’un coup d’œil.
Les questions à poser à tout fournisseur
Six questions séparent une lecture seule appliquée d’une lecture seule simplement affirmée. Elles annoncent la checklist sécurité de l’analytique IA, qui développe chacune d’elles en critères validé ou rejeté.
- La lecture seule est-elle appliquée en analysant chaque instruction en arbre syntaxique, ou par des filtres de mots-clés et des consignes de prompt ?
- Le modèle détient-il à un moment des identifiants ou une connexion active à la base de données, même de façon transitoire ?
- Qu’est-ce qui, dans ma base de données, entre exactement dans le contexte du modèle — la structure seule, ou aussi des valeurs d’exemple et des lignes de résultat ?
- Le code d’analyse généré peut-il atteindre le réseau, et est-ce appliqué dans le code ou au niveau réseau ?
- Pour chaque réponse, puis-je voir la requête exacte qui s’est exécutée et les tables sources qu’elle a touchées ?
- Quel mécanisme empêche quoi que ce soit de franchir les frontières entre comptes ?
Le même pipeline, sur Datarelix
Datarelix applique les cinq couches ci-dessus telles qu’elles sont décrites, sur n’importe quel moteur pris en charge et, idéalement, avec un identifiant en lecture seule dont vous définissez vous-même la portée. Le modèle reçoit la question et la structure du schéma, puis renvoie un plan structuré ; la couche d’exécution le valide, et le pipeline se déroule étape par étape. L’énoncé de référence de chaque frontière se trouve sur la page sécurité.
Là où les contrôles en lecture seule cessent d’aider
Si votre cas d’usage exige d’écrire dans la base de données — créer des tables, insérer ou mettre à jour des scores de modèle, exécuter des transformations —, une couche d’analytique en lecture seule est par définition le mauvais outil, et Datarelix n’a aucun chemin d’écriture à proposer.
Les contrôles en lecture seule bornent le rayon d’impact d’une mauvaise réponse. Ils ne rendent pas les réponses justes. Vérifier qu’une question ambiguë a bien été comprise comme prévu reste une étape humaine, et la trace de preuve existe pour rendre cette étape rapide, pas pour la supprimer.
Une revue qui s’arrête à la frontière d’exécution s’arrête trop tôt. Les trois risques résiduels ci-dessus sont ceux qui survivent à toutes les couches, et le premier vous revient, pas à nous.
Notes et provenance
Les affirmations produit décrivent Datarelix tel qu’il est livré en août 2026 ; la page sécurité fait référence. L’exemple SQL utilise le schéma de démonstration d’un distributeur fictif et sert d’illustration ; ce n’est pas la sortie d’un système réel. Le tableau des menaces est notre propre grille de lecture plutôt qu’une taxonomie publiée, et aucune source externe n’est citée.
Lisez la page sécurité, puis vérifiez une réponse
Lisez l’aperçu de la sécurité pour le détail frontière par frontière. Connectez ensuite une base de données, posez une question, et vérifiez que la requête affichée est bien une lecture et que ses tables sources sont celles que vous attendiez.