ITIL (Information Technology Infrastructure Library), aujourd’hui dans sa version 4, fournit des bases pratiques et flexibles pour soutenir les organisations dans leur parcours vers la transformation numérique, en les aidant à aligner leurs ressources numériques et physiques. Cette version d’ITIL est basée sur l’aspect organisationnel et technologique et sur la manière dont le référentiel s’intègre avec Agile, une méthode basée sur l’utilisation d’un cadre méthodologique léger centré sur l’humain et la communication. Elle préconise une planification adaptative, un développement évolutif, une livraison précoce et une amélioration continue, et elle encourage des réponses flexibles au changement.
Nicolas Jeanpierre, facilitateur Agile chez Inside certifié ITIL, nous explique comment le cadre « rigoureux » d’ITIL peut parfaitement se marier avec la méthode « flexible » Agile.
Pouvez-vous commencer par nous rappeler en quelques mots les principes Agile et les pratiques ITIL ?
Selon moi ITIL est un guide de bonnes pratiques, ce n’est pas une méthode. Le but est de posséder un cadre au quotidien pour améliorer le système d’information (SI) de l’organisation, augmenter la qualité de service et diminuer les risques. Côté Agile, nous avons les 4 piliers suivants :
- Les individus et les interactions plus que les processus et les outils
- Des produits opérationnels plus qu’une documentation exhaustive
- La collaboration avec les clients plus que la négociation contractuelle
- L’adaptation au changement plus que l’exécution d’un plan
Le premier principe Agile est essentiel, car il hiérarchise les deux valeurs au lieu de les opposer : les individus et les interactions en premier lieu (Agilité), les processus et les outils ensuite (ITIL). Il s’agit donc juste d’une différence de temporalité. Il faut d’ailleurs préciser que des notions d’agilité sont déjà intégrées dans ITIL depuis la V4.
ITIL semble rigide, et Agile flexible : comment faire de l’ITIL dans un monde Agile ?
Il suffit de s’attacher à cette démarche simple : qu’est-ce que veut mon client (en interne ou en externe), qu’est-ce qui ferait plaisir à l’utilisateur final, qu’est-ce qui lui rend service et de quoi a-t-il besoin ? Et de cette réflexion il faut extraire un processus, avec une volonté d’amélioration continue. En se penchant sur le deuxième principe Agile « des produits opérationnels plus qu’une documentation exhaustive » : il est clair qu’il n’est pas question de se débarrasser de toute documentation lorsqu’on fait de l’agilité. Cette deuxième valeur est complètement centrée sur le « comment », et requiert un déphasage entre le référentiel ITIL qui fait plus de 1000 pages et le scrum guide qui en fait 15.
Le troisième principe Agile « La collaboration avec les clients plus que la négociation contractuelle » indique simplement qu’il faut engager une relation avec le client au quotidien et au long cours plutôt que de s’attacher à un planning figé issu d’un contrat rigide. ITIL définit un SLA comme un accord documenté entre un prestataire de services et un client qui identifie les services requis et le niveau de service prévu. Or l’agilité utilise plus des OKRs que des KPIs. Pour rappel les OKRs regroupent à la fois un objectif et les résultats permettant de mesurer si cet objectif a été atteint ou non (et si c’est le cas, dans quelle mesure). Ainsi les KPIs et ITIL ignorent le contexte changeant d’un product owner, qui peut être très disponible et motivé par exemple. Ce qui va pourtant créer une proximité plus forte et une meilleure dynamique qu’un contrat figé, ce qui est pris en compte dans l’agilité.
Enfin pour le dernier principe de l’adaptation au changement, ITIL aura plus tendance à s’appuyer sur les processus et « laisser filer », parce que la bonne pratique est reconnue et fonctionne même s’il y a des irritants (de l’administratif par exemple). Alors que l’agilité va se centrer sur l’utilisateur pour se demander comment faire pour diminuer au maximum les irritants. Ainsi, pour faire de l’ITIL dans un monde Agile, il faut faire de « l’ITIL light » : au lieu de suivre toutes les pratiques d’ITIL à la lettre, il est préférable de choisir celles qui sont les plus pertinentes pour l’organisation et les adapter au contexte Agile.
Pouvez-vous nous donner des conseils concrets pour introduire de l’ITIL dans une équipe Agile ?
Prenons l’exemple d’une équipe type start-ups qui s’est rapidement développée autour de productions sans avoir vraiment eu le temps de se pencher sur la structuration de processus. Je leur conseillerai donc de créer une petite équipe Agile, sensible à cet état d’esprit et cette façon de travailler, et de faire en sorte qu’elle prenne à sa charge la création d’un service projet qui sera à l’origine de processus ITIL. Typiquement cela amènera à prendre plus de précautions et se focaliser sur autre chose que la date du délivrable ? Cela permettra également d’ajouter de la traçabilité, de la gestion d’incidents, de gestion de Mise en Production (MEP) (utilisée pour décrire les changements applicatifs) … Et au fur et à mesure d’apporter un cadre en mode Agile. Ce qui démontrera (et quantifiera) aux clients un certain nombre de points positifs comme des mises en production sans incident, ou une QS de haut niveau par exemple. Il faut donc voire Agile et ITIL comme une double connaissance cumulable et non opposable.
Echangeons autour de la qualité mesurée et perçue de votre support et de vos process IT !
