Plus un logiciel roule loin de l’équipe qui l’a construit, plus « ça ne marche pas » coûte cher. Le débogueur n’était pas branché et le problème refuse souvent de revenir au labo. La télémétrie doit permettre de reconstruire l’opération sans enregistrer toute la vie de l’utilisateur.

Une ligne Erreur 500 ne relie rien. Je veux un événement structuré avec horodatage UTC, version du logiciel, appareil, opération, étape, durée, résultat et identifiant de corrélation. Cet identifiant suit le travail du clic jusqu’à la base ou au service distant.

Une trace raconte une séquence

Pour une synchronisation terrain, on pourrait retrouver :

1. sync.start, corrélation 8F3, 42 éléments en attente;
2. auth.ok, même corrélation, 120 ms;
3. upload.batch, éléments 1 à 20, 1,8 s;
4. upload.timeout, éléments 21 à 40, tentative 1;
5. sync.pause, réseau absent, 22 éléments restants.

Le technicien sait que vingt éléments sont confirmés et que le reste demeure local. L’équipe sait où le délai est apparu. Si chaque composant invente son identifiant, ces cinq lignes se perdent parmi des milliers.

Les logs ne remplacent pas les mesures. Un compteur de synchronisations réussies, un taux d’échec, le 95e percentile de durée et la taille des files montrent une tendance. Une alerte devrait porter sur un symptôme utile, par exemple plus de 5 % d’échecs pendant dix minutes, plutôt que sur chaque exception individuelle.

Diagnostiquer sans créer une fuite

Les champs de formulaire, jetons, mots de passe et coordonnées précises ne devraient pas finir dans les traces. Les données sensibles peuvent être masquées ou remplacées par un identifiant permettant une recherche autorisée. Le transport vers le collecteur doit être chiffré, l’accès limité et la rétention courte. Un journal très détaillé devient lui-même une base sur les utilisateurs.

Un appareil déconnecté doit mettre ses événements en tampon. La file locale a une taille maximale; lorsqu’elle est pleine, on garde les erreurs et résumés importants plutôt que de remplir le disque. À la reconnexion, l’envoi se fait par lots avec reprise. L’horloge de l’appareil peut être fausse : un numéro de séquence local aide à remettre les événements dans l’ordre.

Le collecteur peut aussi tomber. L’application principale ne doit pas bloquer une transaction parce que le serveur de logs répond lentement. L’écriture asynchrone et un timeout court protègent le service, au prix d’une possible perte de télémétrie qu’il faut mesurer.

Échantillonner sans perdre l’incident rare

Tout enregistrer à pleine cadence coûte du disque et du réseau. Je conserverais les erreurs à 100 %, un résumé de chaque opération et seulement un échantillon des succès ordinaires. Une trace lente ou liée à une version nouvelle peut recevoir un taux supérieur. Le collecteur publie aussi le nombre d’événements abandonnés; sinon un tableau calme pourrait simplement signifier que les appareils ne transmettent plus. Lors d’un incident, on augmente temporairement le niveau sur un groupe ciblé, avec expiration automatique. Cette stratégie garde les cas rares, limite le volume et empêche qu’une option de diagnostic oubliée sature les terminaux une semaine plus tard.

Je construirais un tableau d’exploitation à partir de trois parcours critiques et je jouerais une panne contrôlée pour voir si les traces suffisent. Si l’équipe doit demander un nouveau build juste pour savoir quelle étape a échoué, l’instrumentation arrive trop tard. Le bon log n’est pas le plus bavard; c’est celui qui permet de décider quoi faire ensuite.