Bases de données, OAuth, clés API : ce qu'il faut comprendre avant de coder avec l'IA

Une IA générative peut aujourd'hui créer une base de données, écrire les règles qui protègent son contenu, et connecter un outil à un service externe en quelques échanges. C'est une avancée réelle, et un risque si personne ne comprend ce que l'IA vient de faire. Voici les quatre notions à connaître avant de la laisser coder pour votre activité : la base de données, le RLS, OAuth, et la clé API.

Qu'est-ce qu'une base de données, et pourquoi une PME en a besoin ?

Une base de données est un système qui stocke de l'information de façon structurée, sous forme de tables, chacune composée de lignes (un enregistrement, par exemple un client) et de colonnes (une information sur cet enregistrement, son nom, son email, sa date d'inscription). C'est l'équivalent numérique d'un classeur de fiches, mais interrogeable et modifiable à grande vitesse.

Un fichier Excel fonctionne pour quelques dizaines de lignes. Au-delà, dès qu'une PME gère plusieurs dizaines de clients actifs, plusieurs personnes qui consultent ou modifient les mêmes données en même temps, ou un outil (site web, agent IA) qui doit lire et écrire automatiquement, une vraie base de données devient nécessaire.

Les bases les plus courantes en PME sont dites relationnelles (Postgres, MySQL) : les tables sont reliées entre elles par des identifiants, une commande à un client, un client à une entreprise. C'est cette organisation qui permet à un assistant capable d'agir sur vos systèmes de répondre à « combien de clients ont commandé plus de trois fois ce trimestre » en interrogeant plusieurs tables à la fois.

Comment une IA génère et modifie une structure de base de données ?

Quand on demande à une IA de « créer une base pour gérer les commandes », elle écrit du code de définition de structure, exactement comme le ferait un développeur : chaque table, chaque colonne, son type, les relations entre elles. Ce code s'exécute ensuite contre la base pour créer réellement la structure.

Cette étape s'appelle une migration : un fichier de code qui décrit un changement de structure, rejouable à l'identique sur un autre environnement. Une IA qui « ajoute un champ téléphone à la table clients » écrit en réalité une migration.

Le point de vigilance : cette structure engage tout ce qui sera construit dessus. Une table mal conçue au départ coûte beaucoup plus cher à corriger une fois en production, avec des données réelles dedans. Mieux vaut relire ce que l'IA propose avant de l'exécuter, même sans tout comprendre en détail : la question à poser reste toujours « qu'est-ce que cette structure empêche, et qu'est-ce qu'elle autorise ».

Qu'est-ce que le RLS (Row Level Security), et pourquoi c'est indispensable ?

Le RLS, pour Row Level Security (sécurité au niveau des lignes), est une règle appliquée directement par la base de données, qui filtre les lignes qu'un appelant a le droit de voir ou de modifier selon son identité. Elle vit dans la base elle-même, ce qui la rend beaucoup plus difficile à contourner par erreur qu'une règle codée dans l'application au-dessus.

Exemple : une table factures contient les factures de tous les clients d'un cabinet comptable qui utilise une application partagée. Sans RLS, n'importe quel utilisateur connecté pourrait en théorie accéder aux factures des autres clients en modifiant une requête. Avec RLS, une règle est écrite une fois pour toutes : « un utilisateur ne voit que les lignes où client_id correspond à son identité ». Elle s'applique automatiquement, quel que soit le code qui interroge la base ensuite, y compris du code écrit par une IA plus tard.

La documentation officielle de PostgreSQL sur les Row Security Policies le formalise clairement : sans politique RLS explicite sur une table, tout utilisateur autorisé à interroger la table voit toutes ses lignes. Dès qu'une base est partagée entre plusieurs clients ou plusieurs comptes, activer et tester le RLS n'est pas une option, c'est une condition de base.

Qu'est-ce qu'OAuth, et en quoi ce n'est pas la même chose qu'un mot de passe ?

OAuth est un protocole d'autorisation déléguée : il permet à un service de donner un accès limité à un autre service, sans que l'utilisateur ait à communiquer son mot de passe au service demandeur. C'est le mécanisme derrière tous les boutons « Se connecter avec Google » ou « Autoriser cette application à accéder à mon compte ».

Le fonctionnement, décrit dans la RFC 6749 qui définit OAuth 2.0, suit toujours la même logique : l'utilisateur s'authentifie une fois auprès d'un tiers de confiance (Google, Microsoft, le fournisseur du service), qui délivre un jeton d'accès, limité dans le temps et dans son périmètre, que l'application utilise pour agir en son nom. Le mot de passe original n'est jamais transmis à l'application tierce, et le jeton peut être révoqué à tout moment.

La confusion la plus fréquente en PME est de traiter OAuth comme une simple authentification par mot de passe. Ce n'est pas le cas : OAuth répond à « qu'est-ce que cette application a le droit de faire en mon nom », pas seulement « qui êtes-vous ». Un agent IA connecté via OAuth à une messagerie ou un CRM ne doit se voir accorder que les permissions strictement nécessaires, jamais un accès complet par facilité.

Comment créer et gérer ses clés API en sécurité ?

Une clé API est un secret, une chaîne de caractères qui donne accès à un service (base de données, messagerie, modèle IA, paiement) sans connexion interactive. Elle joue un rôle proche d'un mot de passe, mais destiné à une machine plutôt qu'à un humain devant un écran.

La règle la plus importante, rappelée par le projet OWASP dédié à la sécurité des API, est qu'une clé API ne doit jamais apparaître en clair dans du code partagé, un prompt envoyé à une IA, une capture d'écran, ou un fichier versionné publiquement. Une clé qui fuite donne un accès direct au service concerné, souvent sans que cela se voie immédiatement.

En pratique, une clé API se stocke dans une variable d'environnement (un fichier séparé du code, jamais partagé, souvent nommé .env) ou un gestionnaire de secrets. Trois réflexes suffisent : ne jamais coller une clé dans un message à une IA, générer une clé différente par usage et par environnement pour pouvoir la révoquer sans tout casser, et en régénérer une dès qu'un doute existe sur sa confidentialité.

Comment appliquer ces notions concrètement selon l'outil IA utilisé ?

Le vocabulaire est le même partout, mais chaque outil a ses propres réflexes à prendre pour ne pas exposer une clé ou une structure de données par erreur.

Avec Claude (Claude Code, Claude Cowork)

Claude Code lit et écrit du code, y compris des migrations de base de données, directement dans un projet local. Le réflexe : demander une relecture explicite avant exécution (« explique-moi ce que fait cette migration avant de la lancer ») et vérifier que le .gitignore exclut bien les fichiers de secrets dès la première utilisation. Claude Cowork ne doit jamais recevoir de clé API en texte dans une conversation : les identifiants se configurent via les intégrations dédiées, pas dans le fil de discussion. Pour aller plus loin sur le vocabulaire de l'outil lui-même, voir artefacts, skills, hooks : le vocabulaire de Claude Code.

Avec ChatGPT / Codex

Codex peut, comme Claude Code, générer des migrations et manipuler des fichiers de configuration dans un dépôt. Même vigilance : ne jamais taper de clé API dans une invite ChatGPT classique (conservée dans l'historique), et pour Codex, vérifier que l'environnement d'exécution (sandbox ou dépôt réel) ne donne pas accès par défaut aux identifiants de production.

Avec Antigravity

Antigravity, l'IDE agentique de Google, fonctionne en connexion directe à un dépôt local ou distant. La clé de la sécurité est en amont : un .gitignore configuré avant le premier commit généré par l'agent, des variables d'environnement séparées du code, et une revue humaine des politiques RLS générées automatiquement, avant tout déploiement en production.

Et après ?

Ces quatre notions (base de données, RLS, OAuth, clé API) forment le socle minimum pour dialoguer avec une IA qui code sans se faire piéger par sa propre rapidité. Deux sujets complémentaires vont plus loin : GitHub et .gitignore, pour ne jamais exposer une clé API avec l'IA générative, et sécurité et IA générative, les bonnes pratiques et audits à mettre en place en PME.