Observabilité et monitoring : voir ce que le système produit, pas seulement s'il répond.

La supervision répond à une question fermée : le service est-il disponible ? L’observabilité répond à une question ouverte : pourquoi se comporte-t-il ainsi ? La distinction n’est pas rhétorique. Sur une architecture répartie en dizaines de services, savoir qu’un service répond ne dit rien de l’expérience réellement servie, et un système d’intelligence artificielle peut répondre parfaitement tout en produisant des résultats qui se dégradent. Cette page traite les trois piliers, les dimensions propres à l’IA et la maîtrise du coût d’ingestion, dans le prolongement de notre couverture IA, données et plateformes.

Les trois piliers, et ce que chacun apporte

Définition. L’observabilité désigne la capacité à comprendre l’état interne d’un système à partir des signaux qu’il émet, sans avoir à le modifier pour investiguer. Elle repose sur trois familles de signaux : les journaux, les métriques et les traces distribuées.

Le pilier manquant dans la plupart des dispositifs est la trace. Beaucoup d’organisations disposent de métriques et de journaux, très peu de traces. Or sur une architecture répartie, sans trace, identifier lequel des huit services impliqués dans une requête a consommé le temps relève de la reconstitution manuelle.

À ces trois signaux s’ajoute la mesure de l’expérience réellement servie, du point de vue de l’utilisateur et non du service. Un service disponible à 99,9 % dont la latence a doublé est un service dégradé que la supervision déclare sain.

Les dimensions propres à un système d’IA

C’est le point où l’observabilité classique ne suffit plus, et que les projets découvrent après la mise en production.

Un modèle en service peut répondre dans les délais, sans erreur technique, avec des journaux propres, et produire des résultats qui s’éloignent progressivement de ce qui était validé. Quatre dimensions supplémentaires doivent être instrumentées :

• La dérive. Comparaison continue des données entrantes et des sorties produites avec la distribution observée lors de la validation. Sans elle, la dégradation se découvre par une réclamation.
• Le coût par appel. Proportionnel à l’usage, il devient rapidement le premier poste d’un système largement sollicité. Il s’instrumente à la mise en service, pas au moment de la facture.
• La latence de bout en bout, incluant les phases de recherche documentaire et d’appel au modèle, qui dominent souvent le temps total.
• La qualité des sorties, évaluée périodiquement sur un jeu de contrôle stable et par un échantillon de revue humaine.

Pour un système qui exécute des actions, deux mesures s’ajoutent : le taux d’escalade vers un humain et le taux d’erreur d’appel d’outils. Voir nos sections copilots et agents IA en production et MLOps et plateformes de données.

Le coût d’ingestion, sujet budgétaire réel

La facturation des plateformes d’observabilité repose sur le volume ingéré et la durée de conservation. C’est le mécanisme par lequel un budget d’observabilité atteint des niveaux qui surprennent la direction financière.

Quatre leviers, dans l’ordre d’effet :

1. Filtrer à la source. Tout journal n’a pas vocation à être ingéré. Les journaux applicatifs de niveau debug en production représentent souvent la majorité du volume sans jamais servir.

2. Échantillonner les traces, en conservant systématiquement celles qui présentent une erreur ou une latence anormale. Un échantillonnage intelligent conserve la valeur de diagnostic en divisant le volume.

3. Différencier les rétentions. Une rétention chaude courte et interrogeable rapidement, une rétention froide longue pour la recherche rétroactive et la conformité. Appliquer la même durée à toutes les sources est le premier facteur de dérive budgétaire.

4. Réviser périodiquement. Chaque nouveau service raccordé ajoute son volume. Sans revue, la trajectoire échappe au pilotage.

Le raisonnement est celui appliqué au SIEM en sécurité : la maîtrise budgétaire se joue au moment de définir, source par source, ce qui est collecté et pour combien de temps. Voir notre couverture du SIEM et de la journalisation de sécurité.

Alerter sur ce qui compte

Le défaut le plus répandu n’est pas l’absence d’alertes mais leur nombre. Une équipe qui reçoit des dizaines de notifications par jour cesse de les lire, et l’alerte qui comptait passe inaperçue.

Trois principes :

• Alerter sur les symptômes, pas sur les causes. Une alerte sur la dégradation du service rendu est actionnable. Une alerte sur l’occupation processeur d’une machine ne l’est pas, tant que le service tient.
• Chaque alerte doit appeler une action. Une notification informative n’est pas une alerte, c’est un tableau de bord.
• Définir des objectifs de niveau de service et alerter sur leur consommation, ce qui donne un critère commun aux équipes techniques et métier.

L’instrumentation des environnements et leur reproductibilité sont traitées dans notre section Infrastructure as Code.

Explorer le cluster

Cette page fait partie de notre couverture de l’intelligence artificielle, de la donnée et des plateformes : gouvernance, socle technique et industrialisation.

iTPro+ : recevez chaque semaine les analyses plateforme et production qui concernent les équipes techniques.