Créer un utilisateur en lecture seule sur sa base

Avant de laisser un outil, une IA ou un collaborateur interroger votre base de données, demandez un compte qui ne peut que lire : il voit les données dont il a besoin, mais toute tentative de modification ou de suppression est refusée par la base. C'est la protection la plus simple contre une requête mal écrite. Vous n'avez pas à le créer vous-même : c'est une demande précise à faire à votre prestataire ou à l'éditeur de votre logiciel.

Pourquoi c'est le premier réflexe

• Une requête générée peut contenir un DELETE ou un UPDATE. Avec un compte en lecture seule, elle échoue au lieu d'abîmer vos données. Voir repérer une requête qui supprime des données.
• C'est la règle du moindre accès. La CNIL (Commission nationale de l'informatique et des libertés) recommande de limiter les accès aux seules données nécessaires à chaque utilisateur, pour réduire l'impact d'un compte usurpé ou d'une erreur de manipulation. Elle déconseille notamment les comptes partagés non tracés et les privilèges excédentaires.
• Les outils reprennent les droits qu'on leur donne. Metabase indique que Metabot hérite des permissions de la personne qui discute avec lui ; Airtable indique qu'Omni ne voit que les données visibles par l'utilisateur et ne fait que les actions permises. Un compte trop large, c'est un assistant trop large.

Ce qu'il faut demander, en une phrase

« Pouvez-vous créer un compte nominatif, en lecture seule, limité aux tables suivantes, pour l'usage suivant ? »

Précisez :

1. Le nom de l'usage ou de la personne : « tableaux de bord de la direction », « assistant IA de Metabase ». Un compte par usage, pas un compte partagé.
2. Les tables utiles : par exemple clients, commandes, produits, devis. Pas les tables de paramétrage, ni celles qui contiennent des données sensibles dont l'usage n'a pas besoin.
3. Les colonnes à exclure si besoin : numéro de téléphone personnel, commentaires libres, coordonnées bancaires.
4. La durée : permanent, ou jusqu'à une date précise.

À quoi cela ressemble techniquement

Votre prestataire saura faire ; voici, à titre illustratif, ce que la documentation officielle de deux bases courantes décrit.

MySQL : le manuel recommande de créer d'abord le compte avec CREATE USER, puis de lui donner ses droits avec GRANT. Pour la seule lecture, il donne des exemples comme :

GRANT SELECT ON base1.* TO 'lecteur'@'localhost';
GRANT SELECT ON base2.factures TO 'lecteur'@'localhost';
SHOW GRANTS FOR 'lecteur'@'localhost';

La première ligne donne la lecture de toute une base, la deuxième d'une seule table, la troisième affiche les droits obtenus. Le manuel montre aussi qu'on peut accorder la lecture colonne par colonne.

PostgreSQL : la commande GRANT SELECT donne la lecture sur une table ou sur toutes les tables d'un schéma. Il existe aussi un rôle prédéfini, pg_read_all_data, qui donne la lecture de toutes les tables, vues et séquences. La documentation prévient que ces rôles donnent accès à des informations privilégiées et ne doivent être accordés qu'en cas de besoin : pour un usage précis, des droits table par table sont plus prudents.

Comment vérifier que le compte est bien en lecture seule

Demandez à votre prestataire de vous montrer la liste des droits du compte (SHOW GRANTS sous MySQL, par exemple). Vous devez y lire SELECT, et rien d'autre : ni INSERT, ni UPDATE, ni DELETE, ni ALL PRIVILEGES.

Vous pouvez aussi faire le test vous-même, avec votre prestataire à côté, sur une table sans importance : une requête de lecture doit fonctionner, une requête de modification doit être refusée avec un message d'erreur.

Et dans les outils sans accès direct à la base

• Airtable : les droits passent par les permissions de la base et par les réglages d'Omni, que seuls les propriétaires et les créateurs peuvent modifier. L'aide Airtable indique qu'on peut interdire la création, la modification et la suppression de données par Omni aux personnes qui n'ont accès qu'aux interfaces. Voir notre fiche Airtable.
• Metabase : Metabot suit les permissions de données et de collections des groupes. Metabase propose aussi un réglage qui empêche Metabot de lire les résultats des requêtes. Voir notre fiche Metabase.
• Logiciel métier hébergé par l'éditeur : la question devient « l'éditeur propose-t-il un accès en lecture, un export ou une interface de programmation ? ». Voir récupérer les données de son logiciel métier.

Revoir les droits chaque année

La CNIL recommande de revoir les habilitations au moins une fois par an, de retirer les droits dès qu'un utilisateur change de mission ou quitte l'entreprise, et de supprimer les comptes inutilisés. Un compte créé pour un essai d'outil d'IA est typiquement le compte qu'on oublie : notez sa date de fin dès sa création.