Contexte technique
Ce n'est pas le mème « agentic oops » qui a attiré mon attention, mais les réactions dans le fil de discussion. Le problème principal est vite apparu : l'erreur ne venait pas de l'agent, mais d'une infrastructure totalement impréparée à une telle éventualité.
Lorsque je travaille sur l'intégration d'IA ou que je développe de l'automatisation par IA, je pars depuis longtemps d'un principe de base désagréable : l'agent finira par cliquer au mauvais endroit. Non pas parce qu'il est « devenu fou », mais parce qu'on lui a donné des permissions excessives, un périmètre d'accès mal défini ou une connexion aveugle à la production.
C'est ici que la magie s'arrête et que commence l'ingénierie ennuyeuse qui sauve l'entreprise. Les sauvegardes ne doivent pas se trouver dans le même compte, la même région, et encore moins à côté de la production simplement parce que « c'est pratique ».
Le strict minimum que je considère comme professionnel est un compte de sauvegarde séparé, une région différente, et de préférence une juridiction distincte pour les données critiques. De plus, une règle doit stipuler que le système de sauvegarde extrait les données de l'environnement live, et non l'inverse, afin que l'environnement live ne puisse pas écraser ou supprimer les sauvegardes.
Si l'équipe est petite ou manque d'ingénieurs en infrastructure expérimentés, une base de données gérée est presque toujours moins chère que l'héroïsme. Un PostgreSQL auto-hébergé semble romantique jusqu'à la première nuit où vous restaurez une base de données sous charge et découvrez que personne n'a jamais testé la procédure de restauration complète.
Un autre point que je ne négligerais pas dans les systèmes d'agents est l'observabilité de leurs actions. Pas seulement les journaux de requêtes au modèle, mais une piste d'audit au niveau de « ce que l'agent voulait faire », « avec quel jeton », « dans quel environnement », « avec quel résultat », et où l'interrupteur d'urgence (kill switch) s'est déclenché.
Qu'est-ce que cela change pour l'entreprise et l'automatisation ?
Les gagnants seront ceux qui construisent l'automatisation avec l'IA comme un système avec des contraintes, et non comme une démo sous stéroïdes. Les perdants seront ceux qui ont donné à un agent un accès à la production et considèrent la sauvegarde comme une simple case à cocher dans un panneau de cloud.
La première conséquence est simple : le coût d'une mauvaise architecture augmente. Une seule mauvaise action d'un agent peut anéantir non seulement une tâche, mais aussi une chaîne de données, des rapports, la synchronisation CRM et les opérations clients d'un seul coup.
Deuxièmement : la restauration devient une partie intégrante du produit, pas un complément. Je ne déploierais jamais un agent IA dans un environnement critique sans une restauration de test, des rôles d'accès distincts et un scénario de rollback clair.
Chez Nahornyi AI Lab, nous nous spécialisons justement dans l'analyse de ces points faibles : où un stack géré est nécessaire, où un environnement séparé est crucial, et où il est préférable de ne pas laisser un agent accéder directement aux données. Si vous sentez que votre automatisation par IA est déjà utile mais repose sur la chance, examinons votre architecture et construisons une solution sans surprises, aussi belles que coûteuses.