Un agent IA ne devrait jamais avoir un accès direct et sans contrôle à votre base de production. Ce n'est pas de la prudence excessive : en juillet 2025, l'agent de Replit a supprimé la base de production d'un utilisateur, en pleine période de gel du code, malgré une consigne lui interdisant toute modification sans accord explicite. L'incident a été largement couvert par la presse.
La bonne nouvelle, c'est que les garde-fous qui protègent la relation entre un agent IA et une base de production sont connus. Ce sont, pour l'essentiel, ceux qu'on applique depuis longtemps aux développeurs humains : des environnements séparés, des droits limités, des sauvegardes vérifiées et une validation avant mise en production.
Cet article les passe en revue, dans des termes qu'un dirigeant peut vérifier sans lire une ligne de code.
Ce qui s'est passé chez Replit, et pourquoi ça vous concerne
Jason Lemkin, fondateur de SaaStr, testait Replit pour construire une application en « vibe coding », c'est-à-dire en décrivant ce qu'il voulait en langage naturel. D'après heise et eWeek :
- l'agent a exécuté une commande qui a effacé la base de production, pendant une période où aucune modification ne devait être faite ;
- une règle écrite dans le fichier d'instructions du projet exigeait pourtant une validation explicite avant tout changement ;
- l'agent a ensuite affirmé que la restauration était impossible, ce qui était faux : une sauvegarde existait et a pu être réimportée ;
- à l'époque, Replit utilisait la même base pour l'aperçu, les tests et la production. Le dirigeant de Replit a annoncé ensuite la séparation automatique des bases de développement et de production.
Lemkin a lui-même précisé qu'il s'agissait d'une application de démonstration. Mais la leçon vaut pour toute entreprise : une consigne écrite à un agent IA n'est pas une protection. L'agent peut l'ignorer, mal l'interpréter ou se tromper sur la situation. Seule une limite technique empêche réellement une action.
Vous êtes concerné si vous, un salarié ou un prestataire faites évoluer votre application avec Claude Code, Cursor, Replit ou un outil équivalent, et que cet outil tourne sur une machine ou dans un environnement qui a accès aux données réelles.
Séparer développement et production : la règle de base
La production, c'est l'application que vos clients utilisent, avec leurs vraies données. Le développement, c'est l'endroit où l'on modifie et teste. La règle est simple : l'agent IA travaille en développement, jamais directement en production.
Concrètement, vérifiez ces points :
- Deux bases de données distinctes. L'environnement de développement utilise sa propre base, avec des données fictives ou anonymisées. Si une commande vide cette base, vous perdez une heure, pas vos clients.
- Les identifiants de production ne sont pas sur le poste de développement. Si le fichier de configuration local (souvent un fichier .env) contient le mot de passe de la base de production, l'agent qui lit ce fichier y a accès.
- Un environnement de pré-production (ou staging), proche de la production, permet de tester une modification dans des conditions réalistes avant de la publier.
Posez la question à la personne qui gère votre application : « Si l'agent IA lance une commande de suppression sur la base, laquelle est touchée ? » La réponse doit être immédiate et rassurante.
Limiter ce que l'agent IA a le droit de faire
Les outils sérieux permettent de restreindre les actions de l'agent. Prenons Claude Code, dont la documentation sur les permissions est publique :
- on peut définir des règles qui autorisent, demandent confirmation ou interdisent certaines actions. Les interdictions sont évaluées en premier et l'emportent sur les autorisations ;
- on peut interdire la lecture de fichiers sensibles, par exemple le fichier .env qui contient les secrets ;
- il existe un mode qui saute toutes les demandes de confirmation. La documentation recommande de ne l'utiliser que dans des environnements isolés, comme un conteneur ou une machine virtuelle, où l'agent ne peut pas faire de dégâts. Une entreprise peut même le désactiver pour tous ses postes ;
- la documentation prévient aussi qu'une règle portant sur une commande ne constitue pas une barrière de sécurité complète, et renvoie vers le sandboxing (l'isolement de l'agent au niveau du système) quand la restriction doit vraiment tenir.
Ce dernier point rejoint la leçon de Replit : les règles de l'outil réduisent le risque, l'isolement le supprime. L'approche la plus sûre combine les deux :
- l'agent travaille dans un environnement qui n'a pas d'identifiants de production ;
- les actions destructrices (suppression de fichiers, commandes sur la base, déploiement) demandent une confirmation humaine ;
- les comptes de base de données utilisés en développement n'ont que les droits nécessaires.
Vous n'avez pas à configurer cela vous-même. Mais vous pouvez demander à voir la configuration et à ce qu'on vous explique ce que l'agent peut faire sans demander.
Des sauvegardes que vous avez déjà restaurées
Dans l'incident Replit, c'est une sauvegarde qui a sauvé la situation, alors même que l'agent affirmait qu'il n'y en avait pas. Deux enseignements :
- Une sauvegarde doit exister indépendamment de l'agent et de l'outil. Elle est faite automatiquement, stockée ailleurs que sur le serveur de production, et l'agent n'y a pas accès.
- Une sauvegarde qu'on n'a jamais restaurée est une hypothèse. Testez une restauration à intervalle régulier, sur un environnement à part, et notez combien de temps elle prend.
Ne vous fiez pas non plus à ce que l'agent dit de l'état de vos sauvegardes : vérifiez auprès de l'hébergeur ou de la personne responsable. Notre article sur le minimum de sauvegarde pour une application web en PME détaille ce socle.
Qui valide avant que ça parte en production
Le dernier garde-fou est organisationnel. Toute modification produite par un agent IA devrait passer par une étape de validation avant d'atteindre vos clients :
- Une relecture des changements par une personne qui comprend le code, au moins pour tout ce qui touche aux données, aux paiements et aux accès ;
- Des tests automatiques qui s'exécutent avant chaque déploiement et bloquent la mise en production s'ils échouent ;
- Un déploiement par un processus, et non par une commande lancée à la main depuis un poste de travail ;
- Une trace : qui a demandé quoi, quand, et ce qui a été publié. En cas de problème, c'est ce qui permet de revenir en arrière rapidement.
Rien de tout cela n'empêche d'aller vite avec l'IA. Ça évite seulement que la vitesse se paie un jour par une perte de données. Notre article sur la mise en production d'une application vibe coding complète cette liste.
Questions fréquentes
Faut-il arrêter d'utiliser des agents IA sur son application ?
Non. Le problème de l'incident Replit n'était pas l'agent lui-même, mais l'absence de séparation entre développement et production. Avec les bons garde-fous, un agent IA reste un outil très utile.
Une instruction claire du type « ne touche pas à la production » suffit-elle ?
Non. Dans l'incident Replit, une instruction de ce type existait et n'a pas été respectée. Une limite technique (pas d'accès, droits réduits, confirmation obligatoire) est la seule protection fiable.
Comment savoir si mon application est exposée ?
Demandez où tourne l'agent, à quelle base il peut se connecter, quelles actions il peut faire sans confirmation, et quand la dernière restauration de sauvegarde a été testée. Si les réponses sont floues, il y a du travail.
Si vous utilisez déjà Claude Code ou Cursor sur votre application et que vous voulez qu'un développeur senior vérifie ces garde-fous et les mette en place avec vous, c'est exactement ce que permet l'offre Copilote : une journée par mois pour cadrer, relire et sécuriser. Si vous voulez d'abord faire le point sur votre situation, écrivez-moi, on regarde ensemble.