Pourquoi la surveillance est essentielle pour les applications générées par IA

Une fois votre application générée par IA en production, vous avez besoin de visibilité sur trois couches : la santé applicative, la charge d'infrastructure, et l'expérience utilisateur. Sans surveillance, une fuite mémoire ou une requête SQL lente ne se manifestera que lorsque les utilisateurs se plaindront. Le code généré par IA est particulièrement sujet à des problèmes de performance subtils — le modèle écrit du code qui compile et fonctionne, mais qui peut ne pas utiliser d'algorithmes optimaux, peut laisser fuir des connexions à la base de données, ou peut effectuer des appels API redondants vers des services coûteux comme OpenAI. Considérer la surveillance comme une étape de déploiement de premier plan (et non comme une réflexion après coup) est ce qui distingue un prototype d'un système de qualité production.

Les quatre piliers couverts dans cette leçon : journalisation structurée, suivi des erreurs, métriques de performance, et configuration d'auto-scaling. Ensemble, ils vous permettent de détecter les problèmes, d'en diagnostiquer la cause racine, et de répondre automatiquement à la charge.

Journalisation structurée

De simples instructions print ne sont pas recherchables, ne sont pas filtrables, et disparaissent lors des redémarrages de conteneurs. La journalisation structurée consiste à émettre des logs sous forme d'objets JSON avec des champs cohérents (timestamp, level, route, user_id, duration_ms, status_code). Un agrégateur centralisé comme Loki, CloudWatch Logs ou Datadog peut alors les indexer et les interroger.

En Python avec FastAPI, utilisez le module `logging` avec un formateur JSON plutôt que de vous appuyer sur `print` :

import logging
import json
from datetime import datetime, timezone

class JsonFormatter(logging.Formatter):
    def format(self, record):
        return json.dumps({
            "ts": datetime.now(timezone.utc).isoformat(),
            "level": record.levelname,
            "msg": record.getMessage(),
            "route": getattr(record, "route", None),
            "duration_ms": getattr(record, "duration_ms", None),
        })

logger = logging.getLogger("app")
handler = logging.StreamHandler()
handler.setFormatter(JsonFormatter())
logger.addHandler(handler)
logger.setLevel(logging.INFO)

Maintenant chaque ligne de log est un objet JSON que votre agrégateur peut filtrer par champ. En Node.js, l'équivalent est `pino` ; en Go utilisez `zap` ou `slog`. L'important est la cohérence : choisissez un format et appliquez-le partout — y compris dans les logs des workers en arrière-plan et des tâches cron.

Suivi des erreurs

Les logs vous disent ce qui s'est passé ; les outils de suivi des erreurs vous disent quand et à quelle fréquence quelque chose s'est cassé, avec des stack traces complètes et une agrégation. Les deux outils les plus courants sont Sentry et Rollbar. Les deux s'installent via un SDK qui encapsule votre application, capture les exceptions non gérées, et regroupe les erreurs répétées en issues.

Pour une application Node.js Express, l'initialisation tient en deux lignes :

const Sentry = require("@sentry/node");
Sentry.init({ dsn: process.env.SENTRY_DSN, tracesSampleRate: 0.2 });

Pour Python Flask, l'équivalent est `sentry-sdk` avec `FlaskIntegration`. Une fois initialisé, chaque exception non gérée est automatiquement signalée avec la stack trace complète, les en-têtes de requête et la version de release de votre application. Paramètre clé : réglez `tracesSampleRate` entre 0.1 et 0.3 en production — échantillonner 100% des traces est coûteux et rarement nécessaire. Capturez le contexte métier pertinent avec des `tags` (par ex. `plan: pro`) pour pouvoir filtrer les erreurs par segment d'utilisateurs.

Une erreur fréquente : ne suivre les erreurs que dans le processus principal. Si vous exécutez des workers en arrière-plan (Celery, BullMQ, Sidekiq), chacun a besoin de sa propre initialisation du SDK. Les erreurs dans un worker silencieux ne remonteront jamais sinon.

Surveillance des performances et les Quatre Signaux d'Or

Le framework des « Quatre Signaux d'Or » de Google est le point de départ de tout tableau de bord de performance. Latence : combien de temps prennent les requêtes (p50, p95, p99 — pas seulement la moyenne). Trafic : requêtes par seconde. Erreurs : taux de requêtes échouées. Saturation : à quel point vous êtes proche de la capacité (CPU, mémoire, profondeur de file).

En pratique vous mesurez cela avec Prometheus + Grafana (auto-hébergé) ou avec Datadog / New Relic (managé). Pour un déploiement Kubernetes, le node-exporter Prometheus et les bibliothèques clientes applicatives (par ex. `prometheus-fastapi-instrumentator`, `prom-client` pour Node) exposent des endpoints `/metrics` que Prometheus scrape toutes les 15 secondes. Grafana les visualise ensuite avec des règles d'alerte (par ex. réveiller l'astreinte quand la latence p95 dépasse 2 secondes pendant 5 minutes).

Pour les applications gourmandes en IA, ajoutez une métrique personnalisée : coût API externe par requête. Suivez les tokens consommés ou les USD dépensés sur chaque requête — c'est le seul moyen de détecter des coûts qui s'emballent à cause d'une boucle infinie ou d'un prompt mal configuré.

Règles d'auto-scaling

L'auto-scaling ajoute ou retire de la capacité de calcul en fonction de métriques de charge. Sur Kubernetes, utilisez le Horizontal Pod Autoscaler (HPA). Sur AWS utilisez ECS Service Auto Scaling ou EC2 Auto Scaling Groups. Sur les plateformes serverless (Vercel, Cloud Run, Lambda) le scaling est généralement automatique mais vous contrôlez la concurrence et la mémoire.

La configuration de base est la même partout : une métrique à surveiller (CPU, mémoire, requêtes par pod, profondeur de file) et des seuils cibles. Voici un HPA Kubernetes typique :

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: web-app-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: web-app
  minReplicas: 2
  maxReplicas: 20
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 60
  - type: Pods
    pods:
      metric:
        name: http_requests_per_second
      target:
        type: AverageValue
        averageValue: "100"

Ce HPA scale entre 2 et 20 pods, ajoutant de la capacité quand le CPU dépasse 60% ou quand la moyenne de requêtes par pod dépasse 100/seconde. Régler `minReplicas: 2` (et 1) évite l'interruption de service pendant les déploiements et les rolling updates. Régler `maxReplicas` trop bas provoque de la limitation sous les pics ; trop haut provoque des coûts cloud qui s'emballent — dimensionnez-le sur le scénario réaliste le plus coûteux, pas la moyenne.

Pour les charges de travail IA, scaler uniquement sur le CPU est trompeur car le goulot d'étranglement est souvent un appel API externe en attente d'OpenAI ou une requête en base de données. Scaler sur la profondeur de file (nombre de requêtes en attente dans votre file de tâches) plutôt, ou combinez métriques CPU + profondeur de file. La latence de cold start est aussi un facteur : gardez au moins un pod chaud en exécution si la latence côté utilisateur compte.

Synthèse

Surveillance et auto-scaling ne sont pas des phases séparées — elles forment une boucle de rétroaction. Les métriques révèlent quand scaler ; les logs et les outils de suivi des erreurs révèlent ce qui se casse sous la charge ; l'auto-scaling évite la casse. Pour les applications générées par IA en particulier, les risques uniques sont les coûts d'API externes qui s'emballent et la latence imprévisible des appels au modèle, donc tracez-les explicitement. Commencez simple : un logger structuré, un outil de suivi des erreurs (Sentry), un HPA basique basé sur le CPU. Ajoutez de la complexité uniquement quand les tableaux de bord vous montrent que vous en avez besoin.