iDBQuery se connecte-t-il à ma base de données avec un accès en lecture seule ?

Le rôle d'iDBQuery est de répondre aux questions, pas de modifier vos systèmes, et son modèle d'accès le reflète.

• Vos propres identifiants. Vous connectez une source à l'aide d'un identifiant que vous provisionnez, et la pratique recommandée est un utilisateur en lecture seule doté des seuls droits `SELECT`.
• Sécurité imposée par la base de données. Lorsque le compte lui-même est en lecture seule, la garantie réside dans votre base de données, et pas seulement dans l'application — même en principe, iDBQuery ne peut ni insérer, ni mettre à jour, ni supprimer.
• Restreignez-le. Vous pouvez en outre limiter cet utilisateur à des schémas, des tables ou une réplique de lecture spécifiques, de sorte qu'iDBQuery ne touche jamais que ce que vous prévoyez.

C'est rassurant pour les équipes qui pointent un outil d'IA vers des données de production pour la première fois : le rayon d'impact est borné par les autorisations que vous accordez. Cela se marie aussi naturellement avec la requête sur place — iDBQuery lit vos données en direct là où elles se trouvent sans les copier à l'extérieur — et avec des options de déploiement comme votre propre VPC, l'application Desktop ou une installation isolée du réseau pour les environnements les plus stricts. Chaque réponse montre toujours son SQL et rattache les lignes qu'il a lues, l'ensemble relevant strictement d'une activité de lecture.