Contexte technique
Je suis ces expériences de près, car ce n’est plus un jouet, mais un domaine très concret pour l’implémentation de l’IA en développement et en opérations. Et voici ma conclusion après des dizaines de cas similaires : mettre Claude Code ou Codex dans un conteneur séparé et l’appeler « SRE proactif » semble audacieux, mais en pratique, l’agent commence très vite à faire ce qu’il ne faut pas.
Dans la discussion, les gens ont décrit un motif familier. Un agent révise le code, un autre le « corrige », et le résultat est un tas de cas d’utilisation superflus, de tâches de suivi et de modifications hors périmètre. J’ai aussi vu cela : le modèle ne se trompe pas simplement, il étend la tâche avec assurance, comme s’il s’ennuyait à suivre le cahier des charges.
Techniquement, trois défaillances convergent ici. La première, le biais d’action : psychologiquement, l’agent préfère changer quelque chose plutôt que de dire honnêtement « il n’y a rien à faire ». La deuxième, la dérive de contexte : sur une longue chaîne d’étapes, il perd les limites de la tâche et commence à optimiser localement, cassant le système globalement. La troisième, les hallucinations habituelles : API inexistantes, dépendances étranges, corrections pour le plaisir de corriger.
C’est pourquoi je n’aime pas l’idée de « laisser surveiller, corriger et écrire à l’équipe » sans un harnais externe. Si l’on veut lancer cela, ce ne doit être qu’en sandbox, avec un rôle dédié, des droits minimaux, un retour en arrière par git snapshot, des tests obligatoires et une deuxième boucle de vérification. Sinon, ce n’est pas du SRE, mais un générateur de bruit coûteux.
Impact sur l’entreprise et l’automatisation
Pour les microservices et le micro-SaaS, la leçon est très terre-à-terre. Ceux qui gagnent ne sont pas ceux qui ont donné toute liberté à l’agent, mais ceux qui lui ont taillé un périmètre étroit : enregistrement des incidents, création de tâches, ébauches de PR, diagnostic initial.
Ceux qui perdent sont les équipes qui confondent l’intégration de l’IA avec le remplacement total de la discipline d’ingénierie. Le code superflu doit ensuite être nettoyé à la main, et le coût de l’« autonomie » se transforme soudain en heures de revue, de régressions et en risque pour la production.
Chez Nahornyi AI Lab, c’est exactement ce que nous construisons pour nos clients : pas de la magie, mais de l’automatisation IA fonctionnelle, avec vérification, rôles et des arrêts d’urgence clairs. Si votre agent a déjà commencé à générer du bruit au lieu de valeur, examinons le processus avec lucidité et concevons une architecture de solutions IA où il fait vraiment gagner du temps au lieu de créer de nouveaux incidents.