Vérifier un diagnostic d’incident proposé par une IA

Votre assistant attribue une panne à la base de données, mais son explication ne constitue pas encore une preuve. Hostinger rapporte des corrections IA plausibles qui peuvent mal s’intégrer au système ; utilisez le protocole suivant pour vérifier le diagnostic avant d’agir.

1. Séparer faits et interprétations

Ouvrez une note d’incident et recopiez uniquement les observations confirmées : heure de début, parcours touché, code d’erreur et dernier changement connu. Ajoutez le fuseau horaire et la provenance de chaque élément. Un souvenir approximatif ne doit pas devenir une heure exacte dans la chronologie.

Demandez à l’assistant de classer son analyse en trois catégories : fait observé, hypothèse et information manquante. Par exemple, une réponse HTTP 502 est une observation ; une connexion saturée peut être une hypothèse. Si le modèle cite une ligne absente de vos extraits, retirez-la du raisonnement.

Conservez aussi les observations qui contredisent sa proposition. Une page qui fonctionne peut partager certains composants avec la page en panne. Cette comparaison aide à préciser le périmètre, sans démontrer à elle seule qu’un composant est sain.

2. Concevoir un contrôle qui peut échouer

Pour chaque cause proposée, écrivez ce que vous devriez constater si elle était vraie et ce qui la rendrait moins probable. Choisissez un relevé accessible sans modification : état du service, erreurs du composant, métrique disponible ou tentative contrôlée sur un environnement de test.

Utilisez cette fiche, avec vos propres informations :

Comparez les événements d’une même requête lorsque c’est possible. Deux anomalies proches dans le temps peuvent être indépendantes. Vérifiez également si l’erreur précède le changement incriminé : une cause proposée doit être compatible avec la chronologie réelle.

Limitez le premier essai à une seule hypothèse. Redémarrer plusieurs services et changer une configuration simultanément peut faire disparaître le symptôme sans vous apprendre ce qui l’a causé. Cela complique aussi la comparaison avec l’état initial.

3. Décider avec une trace explicite

Consignez le résultat brut du contrôle et votre conclusion séparément. Une mesure inaccessible signifie « non vérifié », pas « normal ». Demandez ensuite à l’IA de réviser son analyse à partir de ce résultat précis, sans compléter les trous par des suppositions.

Avant une correction, identifiez le composant ciblé, l’effet attendu, le moyen de revenir en arrière et le parcours à retester. Faites valider les changements selon votre procédure habituelle. L’objectif de cette méthode est de choisir une action justifiée, pas de multiplier les essais.

Fermez la note avec la cause confirmée ou, si elle reste inconnue, une formulation honnête du niveau de certitude. Joignez les preuves utiles. Un incident résolu et un incident expliqué sont deux états à distinguer dans votre suivi.

Sources : Hostinger