Que se passe-t-il quand on ne pratique aucune gestion des incidents ? Pas une mauvaise gestion des incidents, non. Pas de gestion des incidents, tout court.

De l’intérieur, ça ne se voit pas. On a l’impression de bosser dur, de tenir bon, de sauver la mise tous les jours. On confond l’agitation avec le travail. Il faut prendre du recul pour comprendre que ce qu’on prend pour de l’engagement n’est en réalité que du chaos bien porté.

Le mode pompier permanent

Voilà à quoi ça ressemble, une équipe sans pratique des incidents.

Tout arrive en même temps, et tout est urgent. Un mail ici, un message direct là, un collègue qui passe la tête par la porte, un appel du métier qui court-circuite tout le reste. Aucun point d’entrée unique, aucun SPOC, aucun canal par lequel tout passe et où tout se voit. Les sollicitations entrent par toutes les portes à la fois, et personne n’a de vue d’ensemble sur ce qui brûle vraiment.

Du coup, on ne priorise pas. Ou plutôt, on priorise au feeling, à la voix la plus forte, au dernier qui a parlé. Faute de grille, l’urgence se décrète au volume sonore. Le ticket d’un directeur passe devant une panne qui bloque cinquante personnes, simplement parce qu’il a su se faire entendre. La priorité, c’est censé être le croisement de deux choses : l’impact, c’est-à-dire combien de monde et combien d’argent sont touchés, et l’urgence, c’est-à-dire la vitesse à laquelle ça empire. Sans ce croisement posé noir sur blanc, on décide à l’instinct. Et l’instinct, sous pression, fait prendre les mauvaises décisions.

Quand un incident est enfin résolu, sa solution n’est documentée nulle part. Elle reste dans la tête de celui qui l’a trouvée. C’est ce qu’on appelle la connaissance tribale : ce que l’équipe « sait » sans que ce soit écrit nulle part. Tant que la bonne personne est là, ça tient. Mais ça veut dire qu’on dépend d’individus, pas de systèmes. On parle parfois de bus factor : le nombre de personnes qui doivent passer sous un bus pour que tout s’écroule. Dans ces équipes-là, il est souvent de un. Un départ, des vacances, un arrêt maladie, et un pan entier du fonctionnement s’effondre, parce qu’il ne reposait que sur une mémoire.

Et puis on mélange tout. L’incident, le problème, le changement. Or ce sont trois choses distinctes. L’incident, c’est l’interruption ou la dégradation visible du service, celle que subit l’utilisateur. Le problème, c’est la cause, réelle ou potentielle, derrière un ou plusieurs incidents. Le changement, c’est ce qu’on ajoute, modifie ou supprime pour traiter cette cause. Quand on confond les trois, on bricole un correctif dans l’urgence, en croyant résoudre, et on rouvre une faille ailleurs. Les régressions tournent en boucle. On répare la même chose deux fois, trois fois, et on appelle ça « la routine ».

Ce qu’une telle équipe ne peut pas faire

Le problème, ce n’est pas que cette équipe travaille mal. C’est qu’il y a des choses qu’elle ne peut structurellement pas faire bien, par manque de cadre.

Elle ne peut pas restaurer le service de façon fiable. L’objectif d’un incident, c’est de remettre le système en état de fonctionnement le plus vite possible : pas forcément de régler la cause profonde, mais de rétablir. Sans procédure, ce rétablissement dépend entièrement de qui prend le ticket. Le même incident sera traité de trois manières différentes selon la personne qui le traite. Ce qui marche un jour ne marche pas le lendemain, parce que rien n’est reproductible.

Elle ne peut pas escalader correctement. Sans matrice d’escalade, personne ne sait qui solliciter, ni quand, ni à partir de quel niveau de gravité. Alors on hésite. Soit on dérange l’expert pour rien, et on grille du capital humain, soit on n’ose pas le déranger et on laisse pourrir une panne qu’un appel aurait réglée en dix minutes. Les deux erreurs coûtent cher.

Elle ne peut pas communiquer. Pendant qu’un incident est en cours, le reste de l’organisation est dans le brouillard. Personne ne sait où on en est, combien de temps ça va durer, si c’est sous contrôle. L’absence de remontée laisse un vide, et le vide se remplit d’inquiétude et de coups de téléphone, qui mobilisent encore un peu plus ceux qui essaient justement de résoudre.

Et surtout, elle ne peut pas apprendre. Sans clôture formelle, sans retour sur ce qui s’est passé, l’incident s’évapore dès qu’il est éteint. On ne garde aucune trace, aucune leçon. Alors il revient. Le même, encore et encore. Cette équipe ne progresse pas : elle subit. Elle court après le présent sans jamais capitaliser sur le passé, et cela jusqu’à l’épuisement. Le burnout est déjà endémique dans l’IT : 73 % des professionnels européens du secteur déclarent en souffrir, selon l’ISACA. Et les équipes de RUN, en première ligne, y sont particulièrement exposées.

Sortir du chaos, par paliers

La bonne nouvelle, c’est qu’on n’a pas à tout changer d’un coup. La gestion des incidents se construit par paliers, chacun s’appuyant sur le précédent. C’est aussi l’esprit d’ITIL : pas une refonte à imposer du jour au lendemain, mais un cap vers lequel faire progresser l’équipe pas à pas, en partant de là où elle en est.

Palier 1 : poser les fondations.

  • Installer un outil de ticketing : ce qui n’est pas tracé n’existe pas.
  • Créer un point d’entrée unique (SPOC) par lequel tout passe (Jira Service Management est un bon point de départ).
  • Définir une grille de priorité à quatre niveaux, fondée sur le croisement de l’impact et de l’urgence, pas sur le volume sonore.
  • Former l’équipe à qualifier un incident avant de le traiter.

Qualifier avant d’agir : avant d’intervenir, prendre le temps d’identifier ce que l’incident est, qui il touche, et quelle priorité lui donner. C’est ce qui remplace la réaction par la décision.

Palier 2 : structurer le cycle de vie.

  • Définir les états par lesquels passe un ticket, de l’ouverture à la clôture.
  • Établir une matrice d’escalade claire : N1, N2, N3, avec des règles qui disent qui intervient et à quel moment.
  • Poser des SLA par priorité, des engagements de délai d’autant plus courts que l’incident est grave.
  • Mettre en place un dashboard temps réel : incidents ouverts, priorités, états, SLA en cours. L’équipe voit enfin ce qu’elle est en train de vivre, sans avoir à se le demander.

Palier 3 : capitaliser et améliorer.

  • Rédiger des procédures pour les incidents récurrents, pour que la solution sorte enfin des têtes et entre dans une base de connaissances.
  • Instaurer des postmortems blameless sur les P1 et P2.
  • Connecter la gestion des incidents à la gestion des problèmes.
  • Mesurer et publier chaque mois les métriques clés : le MTTR, le volume par catégorie, le respect des SLA, la récurrence des incidents, le nombre de problèmes en attente de correction.

Sur les postmortems : l’idée vient des équipes SRE de Google. On cherche les causes systémiques, pas un coupable. Le postulat est simple : chacun a fait au mieux avec ce qu’il savait sur le moment. On ne blâme pas les gens, on corrige les systèmes qui les ont laissés dans le noir. C’est à ce prix qu’on dit la vérité sur un incident, au lieu de la cacher par peur des représailles.

Un mot sur le MTTR : l’acronyme est trompeur. Il peut désigner le temps moyen pour réparer, restaurer, répondre ou résoudre. Peu importe lequel on choisit, du moment qu’on le précise et qu’on s’y tient. Une métrique qu’on ne définit pas est une métrique qui ment.

Ce que ça change vraiment

Tout cet effort n’a de sens que par ce qu’il produit. Et ce qu’il produit se mesure.

La qualité de service monte, parce que les incidents sont traités de façon reproductible plutôt qu’au petit bonheur. La satisfaction suit, qu’il s’agisse d’utilisateurs internes ou de clients externes : être tenu au courant, c’est déjà être pris au sérieux.

L’équipe respire. Moins de multitasking subi, des escalades qui tombent juste, une charge qu’on voit venir au lieu de la prendre en pleine figure. On arrête de dépendre des experts : la connaissance est dans une base, plus seulement dans une tête, et un départ cesse d’être une catastrophe.

Le pilotage devient possible. Avec des données fiables, on sait enfin où sont les vraies douleurs, on priorise les investissements sur du concret, et on peut justifier des ressources sans tordre la réalité, chiffres à l’appui.

Et au bout, il y a la résilience. La boucle se referme : l’incident remonte vers le problème, le problème vers le changement, et les incidents récurrents finissent par disparaître pour de bon, au lieu de revenir sans cesse. C’est ça, le vrai gain : non pas mieux éteindre les feux, mais en allumer beaucoup moins.

L’invisible, rendu visible

On peut se dire que tout cela, c’est de l’administratif. Des tickets à remplir, des cases à cocher, qui ralentissent ceux qui traitent les incidents.

Une bonne gestion des incidents ne crée pas de la paperasse pour la paperasse. Elle rend visible ce qui était invisible. Tant que le chaos reste dans les têtes et dans les couloirs, on ne peut ni le piloter, ni l’améliorer, ni même le constater. Le formaliser, c’est le sortir de l’ombre. C’est transformer un flux réactif et subi en un flux maîtrisé, où chaque incident est capté, qualifié, traité et clôturé de façon reproductible.

Le chaos ne disparaît pas parce qu’on travaille plus dur. Il disparaît parce qu’on accepte enfin de le regarder en face.

Sources