Il y a des révolutions qui arrivent en fanfare, pis il y en a d’autres qui montent tranquillement, sans bruit, jusqu’à ce qu’on se demande comment on faisait avant. La télémétrie pis l’observabilité logicielle, en août 2011, sont de cette deuxième sorte. Personne ne fait de grande annonce sur le sujet. Mais petit à petit, dans les systèmes sérieux, l’idée s’impose: tu ne peux pas exploiter ce que tu ne peux pas voir.

Le principe est simple à énoncer, dur à appliquer. Un système logiciel qui tourne en production — surtout un système exigeant, déployé loin du bureau — est une boîte noire si on n’a rien prévu pour l’observer. Il fonctionne ou il ne fonctionne pas, mais quand quelque chose accroche, on est aveugle. La télémétrie, c’est l’art d’instrumenter le système pour qu’il raconte ce qu’il vit: combien de temps prend telle opération, combien de fois telle erreur survient, où la mémoire monte, quand un capteur arrête de répondre. Sans ça, on diagnostique au pif.

flowchart LR
    S[Systeme en production] --> T[Telemetrie<br/>il se raconte]
    T --> M[Metriques]
    T --> L[Journaux]
    T --> E[Evenements]
    M --> O[Observabilite]
    L --> O
    E --> O
    O --> D[On comprend<br/>sans deviner]
    D --> F[On corrige<br/>avant la panne]

Dans les environnements embarqués pis exigeants où je travaille, cette montée de l’observabilité a un poids particulier. Quand un logiciel tourne sur un équipement déployé sur le terrain — loin, dans des conditions dures, pas toujours accessible — on ne peut pas juste « aller voir ». Le système doit être capable de dire lui-même comment il se porte. La télémétrie devient alors moins un luxe qu’une nécessité d’exploitation: c’est ce qui permet de comprendre l’état d’un système qu’on ne peut pas toucher physiquement.

Ce que je trouve intéressant, c’est que bien instrumenter coûte un effort qui ne paie pas tout de suite. Au moment de développer, ajouter de la télémétrie semble du travail « en plus » — du code qui ne fait pas la fonction principale. La tentation est de le sauter pour livrer plus vite. Mais c’est exactement ce raccourci qui se paie cher plus tard, le jour où un problème surgit pis qu’on n’a aucune donnée pour comprendre. L’observabilité, c’est un investissement qu’on fait avant d’en avoir besoin, pour le jour où on en aura désespérément besoin.

// L'idee, en pseudo-code : instrumenter sans alourdir

operation("calcul_trajectoire") {
    timer.start()
    try {
        resultat = calculer()
        metric.increment("trajectoire.ok")
    } catch (e) {
        metric.increment("trajectoire.erreur")
        log.error("echec calcul", contexte, e)
        throw
    } finally {
        metric.record("trajectoire.duree_ms", timer.stop())
    }
}

// Trois lignes de telemetrie autour de chaque
// operation critique. Invisible quand tout va bien.
// Indispensable le jour ou ca casse.

Il y a un piège à nommer: la télémétrie pour la télémétrie. Instrumenter sans réfléchir, c’est se noyer dans des montagnes de données que personne ne regarde. Le but n’est pas de tout mesurer, mais de mesurer ce qui aide à répondre aux vraies questions: est-ce que le système est en santé? Où ça ralentit? Qu’est-ce qui a changé juste avant le problème? Une bonne observabilité, c’est de la donnée choisie avec intention, pas un déluge brut.

Ce que je retiens en août 2011, c’est que l’observabilité logicielle est en train de passer du « bonus pour les pros » au « socle des systèmes sérieux ». Cette montée est tranquille parce qu’elle ne se voit pas de l’extérieur — l’utilisateur final ne sait pas qu’un système est bien instrumenté. Mais les équipes qui l’exploitent, elles, font toute la différence du monde entre piloter avec des instruments pis voler à l’aveugle.

La suite, je la vois dans cette généralisation tranquille: de plus en plus, instrumenter un système ne sera plus une option qu’on ajoute si on a le temps, mais une partie normale de bien le construire. Tu ne peux pas exploiter ce que tu ne peux pas voir — pis plus les systèmes deviennent critiques pis distants, plus cette vérité-là devient incontournable. L’observabilité monte sans bruit, mais elle monte pour rester.