ITIL signifie Information Technology Infrastructure Library.
Ce qui se traduit par bibliothèque pour l’infrastructure des technologies de l’information. Pas très vendeur, même pour un informaticien ! 😉
Loin de moi l’idée de passer en revue tout le processus ITIL. Nous allons juste en effleurer la surface en évoquant, très succinctement, la gestion : des incidents, des problèmes et des changements.
Un incident, selon ITIL, désigne tout ce qui sort de l’attendu ou du fonctionnement normal d’un système. Par exemple, un site web qui devient injoignable, un serveur qui rame ou un virus qui infecte un ordinateur.
À force de survenir encore et encore, le même incident finit par devenir un problème selon ITIL.
S’engage alors la recherche de la « root cause » (ou cause racine) pour résoudre ce que ITIL considère comme la source des incidents : le problème.
Rien de bien compliqué. C’est même assez logique en fait, mais il fallait y penser !
ITIL est né dans les années 1980, mais dans les faits, en France, il a fallu attendre les années 2000 pour le voir réellement émerger. Aujourd’hui dans sa version 4, il reste considéré comme une référence en matière de gestion des incidents et des problèmes en informatique.
Le parallèle avec la systémie stratégique
Lors de ma formation en systémique stratégique, j’ai lu « Change. Principles of Problem Formation and Problem Resolution » dans lequel, en 1974, Paul Watzlawick, John Weakland et Robert Fisch (3 des plus grands contributeurs au modèle systémique stratégique de Palo Alto) écrivaient déjà :
« Life is one damned thing after another, a difficulty is the same damned thing coming over and over. »
(La vie est une fichue chose après une autre, une difficulté est la même chose qui se répète encore et encore).
C’est presque mot pour mot ce que postule ITIL entre les incidents et les problèmes !
Pas si étonnant à bien y réfléchir, car l’informatique et la systémique stratégique sont toutes les deux fondées sur des principes mathématiques.
Certaines sciences sont parfois plus proches qu’on ne l’imagine...
Probablement, parce qu’en fin de compte, tout ça reste un processus interactionnel majoritairement humain. On a d’ailleurs coutume de dire en informatique que la plupart du temps, le problème se situe entre la chaise et le clavier !
Et bien sûr, l’analogie ne s’arrête pas là
Avec ITIL, les changements sont passés au crible par un comité appelé CAB (Change Advisory Board) afin d’analyser les risques.
Or en systémique stratégique, le thérapeute ou coach va toujours valider auprès du client qu’il a bien pris en compte les risques et les impacts du changement qu’il souhaite entreprendre.
On pourrait probablement continuer le parallèle. Mais je crois que l’objectif est déjà atteint : démontrer que la résolution systémique stratégique de problèmes repose sur des fondements solides.
Les mêmes sur lesquels s’appuient encore aujourd’hui les meilleurs standards de production informatique. De quoi convaincre les plus rationnels d’entre nous il me semble. 😉
Bien entendu, la méthode systémique de Palo Alto n’est pas la seule piste intéressante pour résoudre un problème délicat. On peut aussi mobiliser l’intelligence collective d’un groupe, par exemple lors de séances de co-développement.