Observabilité IT : mesurer l’expérience utilisateur plutôt que les serveurs

Imaginons une scène illustrative. À 8 h 30, le comité d’exploitation apprend que tous les voyants sont au vert : serveurs disponibles, bases accessibles, réseau conforme aux seuils. Pourtant, les agences n’arrivent pas à finaliser une commande, le centre d’appels demande aux clients de rappeler et le support reçoit une vague de tickets. Le DSI doit trancher : annoncer un service opérationnel parce que l’infrastructure répond, ou reconnaître un incident majeur parce que le travail réel est empêché ? Cette contradiction résume l’échec d’une observabilité centrée sur les composants plutôt que sur l’expérience.

Un système disponible peut être inutilisable

La supervision traditionnelle répond à une question nécessaire mais insuffisante : les éléments techniques fonctionnent-ils ? Elle surveille processeurs, mémoire, stockage, liens, conteneurs et journaux. Chaque équipe optimise ainsi son périmètre. Mais l’utilisateur traverse plusieurs couches : poste, identité, réseau, application, API, données, ERP, prestataire et parfois terminal distant. Une dégradation modérée à chaque étape peut produire un parcours catastrophique sans déclencher aucune alarme locale.

Le mécanisme est trompeur. Les moyennes absorbent les situations extrêmes, les seuils isolés ignorent les dépendances et la disponibilité binaire masque les lenteurs. De plus, un contrôle exécuté depuis le centre de données ne reproduit ni un site éloigné, ni un accès mobile, ni une authentification saturée. Le dirigeant IT reçoit alors une vérité technique exacte mais une représentation opérationnelle fausse. Son premier devoir n’est pas d’ajouter des métriques : il est de définir ce que signifie « fonctionner » pour le métier.

Partir des parcours qui font tourner l’organisation

La démarche commence par une liste courte de transactions critiques, formulées en verbes métier : enregistrer une commande, ouvrir un dossier, valider un paiement, publier un résultat, préparer une expédition. Pour chacune, le DSI réunit métier, support, exploitation, réseau, sécurité et responsable applicatif. Ils précisent le point de départ, le résultat attendu, les dépendances, les populations concernées et les modes dégradés acceptables.

Vient ensuite l’instrumentation croisée. Les tests synthétiques rejouent régulièrement une transaction de référence. La mesure réelle observe les temps vécus par les utilisateurs, selon le site, le terminal ou le canal. Les traces relient les appels entre services. Les tickets et verbatims du support apportent enfin le signal qualitatif que les sondes ne captent pas. Aucun outil ne suffit seul : leur rapprochement permet de distinguer incident global, difficulté locale, régression applicative et erreur de données.

Construire des indicateurs qui provoquent une décision

Un tableau de bord de direction ne doit pas reproduire la console des exploitants. Il doit présenter, par service critique, le taux de transactions réussies, le délai de bout en bout, la part d’utilisateurs affectés, la répartition par site ou canal, la durée avant détection et le temps de restauration. Il faut y ajouter le volume de contacts au support, les récidives après changement et la disponibilité du mode dégradé.

Ces indicateurs gagnent à être accompagnés d’un objectif et d’une règle d’escalade. Une hausse de latence sur une fonction secondaire appelle une analyse planifiée ; l’impossibilité de terminer un parcours essentiel justifie une cellule immédiate, même si les serveurs restent « verts ». Le RSSI doit aussi distinguer lenteur et blocage protecteur : une authentification renforcée peut ajouter une friction légitime, mais un contrôle mal calibré peut détourner les utilisateurs vers des pratiques risquées.

Accepter les compromis au lieu de fabriquer un score magique

Améliorer l’expérience ne signifie pas rechercher la vitesse maximale. Le DSI arbitre entre fluidité, sécurité, coût, résilience et maintenabilité. Ajouter des sondes partout accroît la visibilité, mais aussi le volume de données, la complexité et les risques liés aux informations collectées. Répliquer un service près des utilisateurs réduit certains délais, tout en augmentant les dépenses et les dépendances. Assouplir un contrôle peut fluidifier un parcours, mais fragiliser la maîtrise des accès.

La bonne gouvernance conserve donc plusieurs dimensions visibles. Elle évite l’indicateur composite qui donne une note rassurante en compensant une faiblesse critique par de bons résultats ailleurs. Dans l’esprit de « Révolution Numérique ! », l’enjeu est de relier les choix technologiques aux capacités concrètes de vendre, produire, décider, protéger et servir. L’observabilité devient ainsi un instrument d’arbitrage, non une collection de graphiques.

Éviter les faux progrès qui détruisent la confiance

La première erreur consiste à mesurer uniquement ce qui est facile. La deuxième est de fixer des seuils identiques pour tous les sites, alors que les conditions d’accès diffèrent. La troisième est de célébrer la baisse des tickets après avoir compliqué leur ouverture. Fermer automatiquement les demandes, exclure les lenteurs des incidents ou agréger les populations minoritaires améliore les statistiques, jamais le service.

Autre piège : confier le sujet à une seule équipe d’outillage. Sans propriétaire du parcours, chacun démontre que sa brique respecte son contrat et personne ne porte le résultat final. Enfin, collecter des données d’usage sans finalité précise crée un coût et un risque inutiles. Il faut documenter les données captées, limiter leur conservation et séparer l’analyse de performance de toute surveillance individuelle.

Arbitrer sur l’impact, puis vérifier le retour au service

Face à l’incident initial, le DSI ne demande pas quel serveur est en faute. Il demande quels parcours sont empêchés, qui est touché, depuis quand, quel contournement existe et quelle action réduit le plus vite l’impact sans créer un risque supérieur. Il peut alors prioriser une correction applicative, renforcer temporairement un lien, désactiver une fonctionnalité non essentielle ou basculer vers un mode dégradé.

La décision finale doit inclure sa preuve. Le retour au vert technique ne clôt pas l’incident : une transaction de référence doit réussir depuis les contextes réellement affectés, les utilisateurs concernés doivent retrouver un délai acceptable et le support doit confirmer la décrue des symptômes. Puis la revue compare détection technique et signal utilisateur, ajuste les seuils et attribue les actions. Mesurer l’expérience, ce n’est pas remplacer l’exploitation par la perception ; c’est obliger toute la chaîne IT à répondre du service effectivement rendu.

Pour approfondir

Ouvrage : Révolution Numérique !: Le guide pour comprendre, décider et agir dans l’entreprise numérique — Amazon

Ouvrage : DSI EN CRISE: Reprendre le contrôle de l’IT, des ERP et des grands programmes — Amazon

Consulter la référence

Consulter la référence

#GouvernanceIT #ArchitectureSI #DSI #GuyDeLussigny #TransformationNumerique