Analyse de logs
Identifier rapidement la cause racine d'un incident en analysant des logs volumineux et hétérogènes (application, infra, network).
Lors d'un incident en production, l'analyse des logs est l'une des phases les plus chronophages : naviguer entre Kibana, CloudWatch, Datadog, retrouver les patterns anormaux, corréler entre services. L'IA permet de gagner un temps précieux quand chaque minute compte (SLA, expérience utilisateur dégradée, perte business). Bien utilisée, elle peut diviser par 3 le MTTR (Mean Time To Repair). Le défi : ne pas substituer le jugement de l'opérateur expérimenté à des suggestions IA. Ce guide présente le workflow d'incident assisté par IA et les pièges à éviter sous pression.
Workflow étape par étape
Collecter les logs pertinents
Identifier la fenêtre temporelle de l'incident, les services impliqués, et exporter les logs (filtrés par sévérité, error/warn/critical). Limiter à un volume gérable (10-50k lignes max pour une analyse IA efficace).
Pseudonymiser les éléments sensibles
Avant envoi à l'IA : retirer ou masquer les tokens, secrets, IPs internes, identifiants utilisateurs, données personnelles. C'est non-négociable, même en urgence.
Soumettre avec contexte d'incident
Décrire l'incident à l'IA : symptômes observés, services impactés, dernières modifications (déploiements, configs), heure de début. Plus le contexte est riche, plus l'analyse est ciblée.
Demander une analyse structurée
Pas "qu'est-ce qui se passe ?" mais "identifie : (1) erreur racine probable, (2) chronologie de propagation, (3) hypothèses alternatives, (4) commandes de diagnostic à lancer". Le format structuré accélère la décision.
Valider avec des tests ciblés
Ne jamais agir sur la seule analyse IA. Lancer des commandes de diagnostic (ping, curl, kubectl describe, etc.) pour confirmer l'hypothèse avant toute action corrective. L'IA suggère, l'opérateur arbitre.
Prompts copiables
4 prompts testés et optimisés. Adaptez les variables entre crochets [VARIABLE] à votre contexte.
Analyse d'incident à partir de logs
Tu es SRE senior. J'ai un incident en production : **Symptômes** : [DESCRIPTION — ex : 5xx errors en hausse, latence dégradée, service down] **Services impactés** : [LISTE] **Heure de début** : [TIMESTAMP] **Dernières modifications** : [DÉPLOIEMENTS, CONFIGS, INFRA] **Logs (pseudonymisés)** : [COLLER LES LOGS] Produis : 1. **Cause racine probable** : qu'est-ce qui s'est cassé en premier ? 2. **Chronologie** : quel événement a déclenché quoi (avec timestamps si visibles) 3. **Hypothèses alternatives** : 2-3 autres pistes à investiguer 4. **Commandes de diagnostic** à lancer immédiatement pour confirmer/infirmer 5. **Action corrective rapide** (workaround) si possible sans risque additionnel 6. **Action corrective de fond** à planifier post-incident Reste lucide : si tu n'es pas sûr, dis-le. Pas d'invention de causes plausibles non sourcées dans les logs.
Détection de patterns anormaux
Voici un échantillon de logs sur [PÉRIODE] pour le service [SERVICE] : [LOGS] Identifie : 1. **Patterns récurrents normaux** (à ignorer dans l'analyse) 2. **Patterns anormaux** : erreurs nouvelles, fréquence inhabituelle, séquences suspectes 3. **Top 5 erreurs** par fréquence avec exemple de ligne représentative 4. **Anomalies temporelles** : pics, creux, périodicités étranges 5. **Corrélations probables** entre événements Format : tableau pour les patterns, prose pour les hypothèses. Sois précis sur ce qui est observé vs supposé.
Génération de query Datadog/Kibana
Pour cette question d'investigation : [QUESTION — ex : "trouve les requêtes lentes (>2s) sur /api/checkout dans les 24 dernières heures, groupées par user agent"] Génère la query pour [DATADOG / KIBANA / SPLUNK / CLOUDWATCH INSIGHTS]. Fournis : 1. La query complète, prête à coller 2. Une explication des champs et opérateurs utilisés 3. Les variantes utiles (ex : ajouter des filtres, changer le groupBy) 4. Les pièges à éviter sur la perf (full scan vs index)
Synthèse post-mortem
Pour l'incident suivant : **Description** : [INCIDENT] **Logs analysés** : [RÉSUMÉ] **Action corrective prise** : [ACTION] **Durée totale** : [DURÉE] Produis un post-mortem structuré (format blameless) : 1. **Résumé exécutif** (3 lignes) 2. **Chronologie détaillée** : qui a fait quoi, quand, pourquoi 3. **Cause racine** : pas juste "erreur 500" mais la chaîne complète d'événements 4. **Facteurs contributifs** : ce qui a aggravé ou retardé la résolution 5. **Ce qui a bien fonctionné** : détection, réponse, communication 6. **Action items** : 5 à 10 mesures pour prévenir / mieux gérer la prochaine fois 7. **Owner et deadline** pour chaque action item Ton : factuel, sans blame personnel, focus système et processus.
Top outils pour ce cas d'usage
Sélection commentée des 3 meilleurs outils IA pour analyse de logs.
Pourquoi pour ce cas d'usage : Le meilleur reasoning sur des chaînes causales complexes ("erreur A → cascade B → impact C"). Précis sur les hypothèses alternatives.
Pourquoi pour ce cas d'usage : Pour l'analyse en contexte projet : peut accéder aux logs locaux, runbooks, Dockerfiles. Idéal en investigation profonde.
Pourquoi pour ce cas d'usage : Code Interpreter excellent pour parser des logs volumineux (>1M lignes), agréger, visualiser des patterns en quelques secondes.
ROI estimé
Temps gagné
50-60% de réduction du MTTR sur les incidents complexes
Gain qualité
Hypothèses systématiques, chronologies claires, post-mortems plus riches
Coût stack
Inclus dans abonnements Claude Pro / ChatGPT Plus
Estimations basées sur des benchmarks 2026 et retours d'utilisateurs. Le ROI réel dépend de votre contexte.
Questions fréquentes
Peut-on envoyer des logs de production à un LLM grand public ?
Pas tels quels : risque de fuite de secrets, tokens, données personnelles. Solutions : (1) pseudonymiser systématiquement avant envoi, (2) utiliser Claude for Work / ChatGPT Enterprise (no-training contractuel), (3) self-hosted (Ollama, vLLM) pour les données les plus sensibles.
L'IA peut-elle vraiment trouver une cause racine ?
Sur des incidents "classiques" (configuration, déploiement raté, certificat expiré, OOM) : très souvent oui en quelques minutes. Sur des incidents subtils (race conditions, bugs distribués, corruption silencieuse) : elle propose des pistes mais l'expertise humaine reste centrale. C'est un assistant, pas un oracle.
Comment intégrer l'IA dans une plateforme observability ?
Plusieurs approches : (1) Datadog/New Relic ont leurs propres copilots IA intégrés, (2) MCP (Model Context Protocol) pour brancher Claude sur vos sources de logs, (3) script custom qui pull les logs et appelle l'API. Le standard 2026 émerge autour de MCP.
L'IA aide-t-elle pour la prévention d'incidents ?
Oui, en pré-incident : analyse régulière de logs pour détecter des dérives, génération d'alertes plus pertinentes, revue de runbooks pour les rendre plus actionnables. C'est moins spectaculaire que la résolution d'incidents, mais souvent plus rentable à long terme.