Bases de données avec des agents : sûr plutôt que risqué

Pourquoi les bases de données sont particulièrement risquées

Un agent qui écrit du mauvais code produit un bug. Un agent qui exécute une mauvaise requête sur la base de données peut supprimer ou altérer des données réelles – souvent sans possibilité de revenir en arrière. C'est pourquoi les bases de données sont soumises à des règles plus strictes que le code normal.

La lecture seule en premier

Pour la recherche et le débogage, ne donne à un agent qu'un accès en lecture. Un agent qui ne peut faire que des requêtes SELECT t'aide à comprendre les données et le schéma, mais ne peut rien détruire. L'accès en écriture ne vient qu'en cas de besoin réel – et même là, de façon limitée.

La discipline des migrations

Les changements de schéma (migrations) ne vont jamais directement dans une base de données en production. Ils passent par des fichiers de migration versionnés, qui sont revus, testés, et seulement ensuite appliqués. Un agent peut proposer et écrire une migration – mais son exécution devrait passer par un processus contrôlé, pas une commande shell spontanée.

Jamais de prod sans garde-fou

L'accès à la base de données de production a toujours besoin d'une autorisation délibérée : un humain qui confirme, un jeton d'accès séparé, ou les deux. Un agent ne devrait jamais pouvoir passer automatiquement d'un environnement de staging à un environnement de production.

Ne pas oublier les sauvegardes

Avant toute opération d'écriture, aussi petite soit-elle : une sauvegarde à jour doit exister. C'est la dernière protection quand tout le reste échoue.