Un assistant piloté par l'IA a géré mes astreintes pendant sept jours, traitant 11 alertes et réduisant mon temps moyen de résolution de problème de 45 minutes à 20 minutes. L'expérience est importante car un modèle de langage à portée modeste peut faire gagner une demi-heure sur la réponse aux incidents tout en exigeant une surveillance humaine stricte.

Pourquoi j'ai mis une IA en astreinte

Les équipes Cloud passent la majeure partie de leur service à fouiller dans les logs, vérifier les déploiements récents et confirmer qu'une demande de mise à l'échelle est sûre. Ces tâches « ennuyeuses » sont répétitives, gourmandes en données et sujettes à la fatigue humaine. Les récentes avancées des grands modèles de langage promettaient d'automatiser précisément ce travail de reconnaissance de formes, mais la plupart des démonstrations publiques s'exécutent dans des environnements sandbox. Je voulais voir si l'engouement survivait dans un cluster de niveau production qui sert réellement des clients payants.

La configuration du test

  • Accès – L'agent pouvait lire chaque métrique, log et définition de déploiement. Il ne pouvait écrire que sur une liste blanche restreinte : redémarrer un pod, augmenter le nombre de réplicas ou ajuster le scaling d'un déploiement. Toute action au-delà de celles-ci nécessitait mon approbation explicite.
  • Rôle – J'ai traité le modèle comme un ingénieur junior lors de sa première astreinte. Il recevait l'alerte, effectuait son analyse et postait une recommandation dans le canal d'incident.
  • Filets de sécurité – Toutes les actions d'écriture étaient soumises à une validation manuelle par un prompt « oui/non ». J'ai également plafonné l'utilisation des tokens du modèle pour maintenir des coûts prévisibles.

Là où l'IA a excellé

La rapidité de l'agent a été le gain le plus notable. Dès qu'une alerte se déclenchait, il récupérait les logs pertinents, traçait les métriques récentes et listait les trois derniers déploiements. Le temps que j'ouvre mon ordinateur, le travail d'enquête initial était déjà terminé. Sur les 11 alertes :

  • 8 étaient des problèmes de routine (pics de mémoire, redémarrages de conteneurs, erreurs de configuration simples). L'IA a correctement identifié la cause racine à chaque fois.
  • Elle a signalé une augmentation progressive de la mémoire dans un microservice avant que le problème ne se transforme en une panne à 2 heures du matin, donnant à l'équipe la possibilité d'intervenir tôt.
  • La consommation de tokens pour toute la semaine est restée autour de 30 $, ce qui est tout à fait raisonnable pour un budget d'astreinte classique lorsqu'il est plafonné.

Ces résultats se traduisent par une réduction mesurable du temps moyen de résolution (MTTR) de 45 minutes à 20 minutes, libérant ainsi les ingénieurs pour qu'ils se concentrent sur des tâches à plus fort impact.

Là où elle a trébuché

La confiance n'est pas synonyme de justesse. L'IA s'est trompée avec assurance sur 3 des 11 alertes :

  1. Elle a imputé une panne de connectivité de la base de données à un déploiement de code récent, mais cette explication était incorrecte.
  2. Face à une anomalie réseau inhabituelle, elle a proposé des correctifs génériques qui ne résolvaient pas le problème sous-jacent.
  3. Lors d'une alerte liée à la charge, elle a suggéré de passer un service de 3 à 30 réplicas. Le problème n'était pas la charge, mais une mauvaise configuration.

Comme mes garde-fous exigeaient une approbation manuelle pour toute opération d'écriture, les erreurs du modèle ont été détectées avant de pouvoir causer des dommages. Néanmoins, cet épisode a mis en évidence un risque majeur : le modèle peut produire des recommandations qui semblent plausibles mais qui sont inexactes, en particulier pour des problèmes inédits.

Gestion des coûts et des risques

La facture de 30 $ de tokens montre que l'exécution d'un LLM dans une boucle de production peut être peu coûteuse si l'utilisation est surveillée. Cependant, le coût réel est le risque opérationnel. Un mauvais ajustement de l'échelle d'un déploiement peut entraîner une explosion des dépenses cloud, et l'annulation (rollback) d'une version correcte peut éroder la confiance des clients. L'expérience a renforcé deux mesures de protection :

  • Contrôle des actions – Ne permettre au modèle que de suggérer, et jamais d'exécuter, des changements à fort impact sans une validation humaine.
  • Plafonds budgétaires – Définir des limites strictes sur la consommation de tokens et alerter l'équipe lorsque le modèle approche du plafond.

Ce qu'il faut surveiller ensuite

D'ici là, les équipes devraient :

  • Suivre la proportion de suggestions générées par l'IA qui nécessitent une intervention manuelle.
  • Mesurer l'impact sur le MTTR à travers différentes catégories d'incidents (de routine vs inédits).
  • Tester le modèle dans un environnement de staging avec des alertes synthétiques avant d'accorder des droits d'écriture en production.

Enseignements pour les équipes Ops

  • Automatisez les 80 % de tâches ennuyeuses – Utilisez l'IA pour l'agrégation de logs, la corrélation de métriques et la génération d'hypothèses initiales.
  • Réservez les 20 % de risques pour les humains – Le scaling au-delà d'un seuil modeste, les rollbacks et les suppressions doivent rester soumis à une étape d'approbation manuelle.
  • Considérez le modèle comme un partenaire, pas comme un remplaçant – Un ingénieur qui connaît le système peut valider les résultats de l'IA plus rapidement qu'un nouveau venu, transformant l'assistant en un multiplicateur de force.

Un agent IA ne peut pas encore gérer seul une opération cloud, mais en tant que partenaire de triage, il apporte déjà des gains de vitesse tangibles. La clé est de garder la confiance sous contrôle, d'imposer des garde-fous stricts et de laisser le modèle s'occuper des tâches répétitives et ingrates, tandis que l'expertise humaine oriente les décisions critiques.