Le TRS : l'indicateur que les DSI attendaient sans le savoir
Comment transposer un standard industriel centenaire pour enfin piloter ce que les SLA et les KPIs classiques ne savent pas mesurer.
Deux tiers des DSI n'ont pas d'indicateurs d'efficience de leur production informatique. Ce n'est pas faute de tableaux de bord — c'est précisément parce qu'ils en ont trop, et que ces tableaux mesurent la mauvaise chose. Le Taux de Rendement Synthétique change la question posée. Et c'est pour cela qu'il change tout.
J'ai découvert le TRS en 2013, sollicité par l'éditeur Orsyp — qui deviendra Automic — pour rejoindre un groupe de travail sur la transposition de cet indicateur industriel à l'informatique. Mais si j'ai dit oui immédiatement, c'est parce que le problème qu'il adressait était exactement celui que je vivais à la DSI de l'Académie de Versailles depuis plusieurs années : des tableaux de bord pléthoriques, peu consultés, qui ne me permettaient pas de répondre aux questions qui comptaient vraiment.
Le problème que personne ne nomme clairement
La DSI de l'Académie de Versailles en 2013 n'est pas en difficulté. Elle dispose d'une démarche ITIL® solide depuis 2006, d'un outil de Service Desk déployé, de SLA contractuels avec ses fournisseurs, et d'indicateurs en nombre. Le problème est précisément là.
Les SLA sont toujours à 100 %. Les KPIs sont trop nombreux pour être véritablement suivis. Et surtout, aucun indicateur ne répond à la question fondamentale : est-ce que la production informatique fonctionne de façon efficiente, ou est-ce qu'elle livre le bon résultat final en se battant en permanence contre elle-même ?
Avant de pouvoir s'améliorer, il faut repérer les bonnes et mauvaises pratiques tant de soi-même que chez les homologues. Autrement dit, comme indiqué au fronton du temple de Delphes, il faut se connaître soi-même.
— Jacky Galicher, CIO-Online, octobre 2013Cette distinction entre résultat final et efficience du processus est au cœur du problème. Mesurer que 98 % des incidents sont résolus dans les délais contractuels ne dit rien du coût humain pour y parvenir, des gaspillages qui rongent la capacité à livrer, ni des signaux faibles qui précèdent les vraies crises. On mesure la sortie de chaîne. On ne mesure pas la chaîne.
(enquête CRIP, sept. 2014)
(même enquête)
(même enquête)
Ce qu'est vraiment le TRS — et pourquoi la formule est brutale
Le Taux de Rendement Synthétique est né dans l'industrie manufacturière, dans le sillage du Toyota Production System. Son principe : mesurer l'efficacité globale d'un équipement de production en combinant trois dimensions en un seul indicateur sans grandeur.
vs temps théorique
vs cadence nominale
vs pièces produites
La force de cet indicateur tient à sa brutalité mathématique. Si chaque taux atteint individuellement 95 %, le TRS global plafonne à 86 %. Si chacun est à 90 %, le TRS tombe à 73 %. L'indicateur rend visible ce que les mesures en silo masquent : les pertes s'accumulent à chaque étape.
C'est précisément ce que les SLA ne font pas. Un SLA mesure si la sortie est conforme au contrat. Le TRS mesure si le processus qui produit cette sortie fonctionne bien — ou s'il le fait en se battant, en gaspillant, en compensant en permanence des défauts structurels.
La distinction fondamentale : un SLA demande « avons-nous livré dans les délais ? ». Le TRS demande « à quel coût organisationnel, et où se trouvent les gaspillages qui nous empêchent de faire mieux ? »
La transposition IT : même logique, nouveau vocabulaire
Transposer le TRS à l'informatique ne consiste pas à changer les étiquettes. C'est un travail sémantique et organisationnel à refaire pour chaque processus ciblé — et c'est l'étape la plus longue et la plus féconde : contraindre les équipes à s'accorder sur ce que signifient concrètement Disponibilité, Performance et Qualité dans leur contexte.
Pour la gestion des incidents à Versailles : Disponibilité = disponibilité des outils et équipes (Help Desk, monitoring, self-service) ; Performance = respect des SLA de prise en charge ; Qualité = délai de résolution et taux de satisfaction utilisateur.
Pour le Service Desk, nous avons ajouté une double lecture : la perception utilisateur (qualité de l'accueil, compréhension du besoin, qualité de la réponse) et le niveau opérationnel (taux d'appels décrochés, disponibilité de l'infrastructure, taux de résolution dans les temps).
Pour la gestion des mises en production : dates de MEP (Disponibilité), surcharge et retards (Performance), niveau de service et d'exploitabilité des livrables (Qualité).
Notre parcours à Versailles : 2013–2019
Premiers travaux sur les critères de calcul du TRS. Diagnostic clair : tableaux de bord trop nombreux, peu consultés, incapables de révéler l'efficience réelle. Objectif managérial aussi : inciter les équipes à lever le nez du guidon.
Annick Creissent et Jean-Philippe Charlier définissent les critères, produisent les premières mesures manuellement et les présentent à la gouvernance de la DSI.
Les encadrants de l'assistance participent à l'identification des gaspillages et des leviers. La mesure devient un outil collectif de progrès, pas de contrôle.
Présentation du retour d'expérience. En décembre, nouvelle présentation aux académies utilisatrices d'EasyVista. La démarche commence à essaimer.
Co-construction avec EasyVista d'un module APPS de calcul semi-automatisé. Le TRS devient visible depuis le portail ITSM. Juin 2015 : institutionnalisation officielle.
Affiché chaque mois sur l'intranet académique. Alliancy salue la démarche comme « exemplaire » en 2018 : « la confiance et la transparence sont les fondamentaux d'une transformation numérique au service des usagers. »
À mon départ pour l'Académie de Normandie, le TRS mesuré via EasyVista et la dynamique DevOps ne survivent pas. EasyVista est résilié. La mesure d'efficience disparaît avec l'outil.
Ce que le TRS révèle que les autres indicateurs cachent
La valeur du TRS ne tient pas seulement à son caractère synthétique — elle tient à ce qu'il révèle : les gaspillages. Le Think Tank Automic a développé un arbre des gaspillages qui catégorise les pertes selon leur nature. Côté Qualité : défauts de savoir-faire, variabilité des composants. Côté Disponibilité : pannes techniques, capacité, planning, synchronisation, approvisionnements, arrêts humains, attentes. Côté Performance : vitesse, agilité, productivité, surconsommation, procédures, méthodes, facteur humain.
Cet arbre transforme un indicateur en programme d'action. Quand le TRS baisse, il indique dans quelle branche chercher la cause. C'est la différence entre un thermomètre et un diagnostic.
Un tel indicateur sert aussi à éviter une réponse systématique du type « achetez tel logiciel pour résoudre tel problème » alors que la solution est souvent organisationnelle.
— Jacky Galicher, CIO-Online, octobre 2013Cette remarque, formulée en 2013, n'a pas pris une ride. En 2026, le réflexe « achetez de l'IA pour résoudre le problème » est exactement du même ordre. Le TRS oblige à regarder d'abord le processus avant l'outil.
Les conditions de réussite — et les pièges à éviter
Ce qui fait réussir
- Un sponsor DSI explicite et visible. Pas un chef de projet — le DSI lui-même, qui endosse publiquement la démarche.
- Un périmètre restreint pour commencer. Les premières mesures seront imparfaites — c'est normal, elles créent le choc salutaire qui mobilise.
- L'implication des équipes dans la définition des indicateurs. Si les encadrants de terrain ne se reconnaissent pas dans les critères, le TRS reste un outil imposé d'en haut.
- Une communauté de pairs. Le Think Tank Automic a permis de partager définitions, écueils et résultats sans refaire les erreurs des autres.
Ce qui fait échouer
- La bande passante insuffisante. Le TRS demande du temps managérial pour les revues mensuelles et l'animation de l'arbre des gaspillages.
- La mobilisation sans mandat. Demander aux équipes de mesurer sans dire pourquoi ni ce qu'on fera des résultats.
- Ne pas ancrer institutionnellement la démarche. Un outil que vous seul défendez est un outil fragile — je l'ai appris à mes dépens.
La méthode en dix étapes
Ce que je retiens, dix ans après
Le TRS m'a appris une chose que je n'aurais pas formulée ainsi en 2013 : la mesure est un acte de management avant d'être un acte technique. Décider de mesurer l'efficience de la production, c'est décider de regarder en face ce qui ne fonctionne pas — et d'en parler collectivement, sans masque de SLA toujours conformes.
Ce que j'ai publié sur l'intranet de Versailles en 2016, en affichant le TRS chaque mois, n'était pas un acte de transparence anodine. C'était une façon de dire à toute la DSI : nous nous jugeons sur l'efficience réelle, pas sur la conformité contractuelle.
Pour tout DSI qui se demande par où commencer : choisissez un processus, réunissez l'équipe, et demandez-lui de définir ce que signifient Disponibilité, Performance et Qualité dans son contexte. Vous en apprendrez plus en deux heures qu'avec six mois de reporting classique.
Un retour d'expérience honnête doit dire aussi ce qui n'a pas survécu. Le TRS mesuré via EasyVista et la démarche DevOps ont été abandonnés après mon départ de l'Académie de Versailles fin 2019. Ce mécanisme — des outils de gouvernance qui meurent au départ du DSI qui les portait — n'est pas propre à Versailles. Je l'analyse en détail dans un article dédié.
Pourquoi les outils de gouvernance dépendent trop des individus qui les portent, et ce que DSI et éditeurs peuvent faire pour l'éviter.
→ jgconsultants.fr