Imaginons une situation illustrative. Le comité exécutif reçoit un tableau de bord rassurant : 99,9 % de disponibilité, incidents majeurs clôturés dans les délais, pénalités contractuelles inexistantes. Pourtant, chaque lundi matin, les agences attendent plusieurs minutes pour ouvrir les dossiers clients, l’ERP ralentit à la clôture mensuelle et le service support absorbe des appels récurrents. Le fournisseur respecte son SLA. L’entreprise, elle, perd du temps, de la confiance et parfois des opportunités. Pour le DSI, le problème n’est pas d’obtenir un indicateur supplémentaire : il est de décider quelle performance doit réellement être garantie.
Quand la disponibilité masque l’indisponibilité réelle
Un SLA mesure ce que le contrat a défini, pas nécessairement ce que l’utilisateur subit. Une application peut être déclarée disponible dès lors que son serveur répond, alors que l’authentification échoue, qu’une interface critique est bloquée ou qu’une transaction prend trop longtemps. Chaque composant peut afficher du vert tandis que le parcours métier reste inutilisable.
Ce décalage naît souvent d’un découpage technique : infrastructure, réseau, base de données, application, SaaS et support sont pilotés séparément. Aucun acteur n’est responsable du résultat de bout en bout. Le DSI doit donc déplacer la question : non plus « le composant fonctionne-t-il ? », mais « le processus prioritaire peut-il être exécuté dans des conditions acceptables ? ». Cette reformulation change le contrat, les outils de mesure et la gouvernance.
Définir le service avant de négocier le chiffre
Avant de revoir les seuils, il faut nommer les services essentiels et leurs utilisateurs. Pour une application de gestion, les parcours critiques peuvent être la prise de commande, la préparation, la facturation ou la clôture. Ils n’ont ni la même sensibilité horaire ni le même impact. Une interruption nocturne et un ralentissement au pic d’activité ne peuvent recevoir le même poids.
Le DSI réunit alors métiers, exploitation, RSSI, achats et fournisseurs pour établir une fiche de service : propriétaire métier, plages critiques, dépendances, volumes attendus, modes dégradés, exigences de sécurité et conditions de reprise. Le compromis devient explicite. Exiger une performance maximale en permanence augmente les coûts ; tolérer une dégradation suppose une solution de continuité réellement praticable. La direction peut arbitrer parce qu’elle compare désormais coût, risque et capacité opérationnelle.
Mesurer le parcours, pas seulement la machine
Un pilotage utile combine quelques indicateurs complémentaires. Le taux de succès des transactions révèle les opérations abouties. Le temps de réponse doit être observé par parcours et par plage horaire, avec une mesure des cas dégradés que la moyenne efface. Le nombre d’utilisateurs affectés distingue l’incident local de la panne structurante. Le délai de détection montre si l’IT voit le problème avant les appels. Le délai de rétablissement mesure le retour effectif du service, pas seulement la fermeture administrative du ticket.
Il faut rapprocher ces données des tickets, des erreurs d’authentification, des versions déployées, de la qualité réseau et des changements récents. La télémétrie aide à prévenir, à condition d’être transparente, proportionnée et orientée vers le service, jamais vers la surveillance individuelle. Enfin, un indicateur métier — commandes finalisées, dossiers traités ou opérations reprises manuellement — relie la technique à l’activité sans prétendre attribuer toute variation à l’application.
Construire une chaîne de responsabilité de bout en bout
La démarche peut avancer en cinq étapes. Premièrement, sélectionner deux ou trois parcours dont l’interruption justifie une décision de direction. Deuxièmement, cartographier leurs dépendances techniques et contractuelles. Troisièmement, installer des tests synthétiques et des mesures côté utilisateur, puis vérifier leur cohérence avec les constats du support. Quatrièmement, fixer des objectifs de niveau de service internes avant de les traduire en engagements fournisseurs. Cinquièmement, organiser une revue mensuelle centrée sur les écarts, les causes récurrentes et les actions datées.
Cette chaîne évite le jeu classique du renvoi de responsabilité. L’intégrateur ne peut plus invoquer une infrastructure disponible si le parcours échoue ; l’hébergeur ne peut clore l’incident sans preuve de rétablissement ; le métier ne peut exiger l’absence totale de risque sans assumer le coût correspondant. Un responsable unique du service consolide les faits et porte les arbitrages, même lorsque plusieurs contrats contribuent à la performance.
Les erreurs qui fabriquent des tableaux de bord verts
La première erreur consiste à confondre moyenne et expérience réelle. Quelques périodes excellentes peuvent masquer les pointes critiques. La deuxième est de multiplier les KPI jusqu’à rendre la revue illisible. La troisième est de négocier des pénalités avant de disposer de mesures indépendantes : l’entreprise dépend alors des chiffres du fournisseur qu’elle doit contrôler.
Autre piège : traiter chaque incident isolément. Dix ralentissements mineurs peuvent peser davantage qu’une panne spectaculaire, sans jamais franchir le seuil contractuel. Fermer rapidement les tickets sans éliminer la cause racine améliore artificiellement le reporting. Enfin, réduire les capacités cloud pour respecter un budget peut restaurer un indicateur financier tout en dégradant la performance. Le bon pilotage recherche une valeur soutenable, pas le coût minimal ni une disponibilité théorique.
L’arbitrage du dirigeant : payer, transformer ou accepter
À l’issue de l’analyse, trois décisions sont possibles. Renforcer le service lorsque l’impact justifie davantage de capacité, de redondance ou d’astreinte. Transformer l’architecture ou le processus lorsque les incidents révèlent une dette devenue structurelle. Accepter formellement un niveau de risque lorsque le coût de réduction serait disproportionné, avec un mode dégradé testé et un responsable identifié.
Le DSI doit présenter ces options sans promettre l’infaillibilité. Il expose le coût complet, les dépendances, le risque résiduel et le délai de mise en œuvre. Cette logique rejoint l’approche de gouvernance défendue dans « Révolution Numérique ! » : relier les choix technologiques aux décisions réelles de l’entreprise et garder la maîtrise des fournisseurs. Un SLA cesse alors d’être un écran contractuel. Il devient un engagement vérifiable sur la capacité de l’organisation à travailler, résister et décider.
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
#GouvernanceIT #ArchitectureSI #DSI #GuyDeLussigny #TransformationNumerique
