Etape 1 - rationaliser les activités Dev-Ops

3.2 Etape numéro 1 : rationaliser les activités Dev-Ops

3.2.1 Concilier le « pas forcément inconciliable » : méthodologie projet etITIL®

Traditionnellement, les activités projets sont régentées par une méthodologie projet qui prend mal en compte les activités plus liées à l’exploitation (déploiement d’une version définitive dans l’environnement de production par ex.).

D’autre part, en examinant de près le référentiel ITIL®, on s’aperçoit que les termes « développement » ou « projet » sont très peu cités dans la documentation. ITIL® présente très bien les activités d’exploitation (historiquement, ITIL® vient du monde de l’exploitation) mais est peu loquace dès lors qu’il s'agit d'évoquer des activités de projet.

En réalité, toutes les méthodologies projets et le référentiel ITIL® parlent de bonnes pratiques mais selon des points de vue différents. Sur le fond donc, tous les référentiels parlent de la même chose et ne sont pas contradictoires.

Si on veut avoir un processus global incluant à la fois le développement et l’exploitation, il faut travailler sur la forme et être créatif pour surmonter les différences de vocabulaire et de terminologie.

Mais cela se fait très bien car tous les référentiels parlent de la même chose.

3.2.2 Le fondement de la démarche : le processus ITIL® de gestion des changements

Tout va partir du processus ITIL® de gestion des changements tel qu’il a été présenté précédemment.

C’est sur cette structure en activités jalons que vont venir se greffer toutes les activités de la méthodologie projet, des processus ITIL® de transition des services (notamment la gestion des mises en production et des déploiements) mais aussi les processus ITIL® de conception des services (en fait, les parties de processus qui sont de nature de transition).

Dans une première approche, on peut citer :

  • le processus de gestion des changements

  • la partie transition de la méthodogie projet

  • le processus de validation et des tests de service

  • le processus de gestion des déploiements et des mises en production

  • la partie transition du processus de gestion du catalogue de services

  • la partie transition du processus de gestion des niveaux de service

  • la partie transition du processus de gestion des fournisseurs (sous-traitants impliqués dans le projet)

Il serait aussi possible d’impliquer certaines parties des processus de conception des services suivants :

  • gestion de la disponibilité

  • gestion de la capacité

  • gestion de la sécurité

  • gestion de la continuité des services informatiques

Ceci demande un niveau de maturité plus important et n’est pas nécessaire dans un premier temps.

3.2.3 Deux parties distinctes : traiter la demande de changement et traiter le changement

Traiter la demande de changement consiste à évaluer la demande et à produire un dossier suffisamment complet pour être présenté à une autorité (très souvent, le fameux CAB ou comité consultatif sur les changements) afin qu’il puisse prendre une décision sur la suite à donner à la demande :

  • rejeter la demande

  • autoriser la demande mais la mettre en attente pour réalisation ultérieure (par ex. : il s’agit d’une demande pertinente mais il faudra attendre l’année prochaine faute de budget dans l’immédiat)

  • autoriser la demande et lancer la réalisation dans la foulée

Ceci amènera à intégrer dans la démarche le processus ITIL® d’évaluation des changements et dans une méthodologie projet, la partie « avant-projet » ou « pré-étude » (ou autre « étude d’opportunité ») selon le vocabulaire méthodologique employé.

Traiter le changement consiste à transformer l’idée de service ou d’évolution de service en un produit fonctionnel, installé, opérationnel et exploitable. L’exploitabilité est la possibilité de fournir le service selon les niveaux de service convenus avec les ressources présentes dans la partie exploitation (ressources techniques et humaines et contrats de sous-traitance notamment) et dans le respect des contraintes budgétaires.

Dans cette partie, nous allons retrouver les phases classiques d’un projet : conception, réalisation (développement et/ou paramétrage), tests, mise en production et pilote.

3.2.4 Ranger toutes les activités des processus impliqués dans des cases

Pour l’ensemble des parties de processus impliqués, il est impératif de ranger les activités en séquence dans chaque phase du changement (ou du projet).

Une fois réalisé, il est donc possible de dessiner un macro-processus dont une structure simplifiée est la suivante (tous les processus n’ont pas été représentés) :



Il est possible de voir dans ce schéma un début de cadencement tel qu’il est décrit dans les principes Lean (mais on en est pour l’instant très éloigné).

Ce cadencement est piloté par le processus de gestion des changements au travers des activités de pilotage qui consiste essentiellement à valider le déroulement de la phase précédente (tous processus confondus) et à autoriser la réalisation de la phase suivante.

Nous voyons aussi que les activités de développement (Dev) et les activités d’exploitation (Ops) sont gérées de la même manière ainsi que les activités de conception des services (catalogue de services, niveaux de services, fournisseurs pour ne citer que ceux-là).

Nous sommes donc la en présence du macro-processus Dev-Ops (enfin, une fois que le détail de chaque case processus x phase aura été détaillé avec l’exhaustivité des processus impliqués).

3.2.5 Formaliser (ou reformaliser) les processus ITIL® impliqués dans Dev-Ops

Pour la partie des processus ITIL® impliqués dans un cycle Dev-Ops, il faut revoir leur conception et restructurer ces flux de traitement en les inscrivant dans chaque des phases Dev-Ops.

J’ai réalisé ce travail chez des clients en partant des processus théoriques ITIL® de gestion du catalogue de services, des niveaux de services et des fournisseurs et il n’y a pas de contradiction entre ITIL® et Dev-Ops.

Prenons, par exemple, le processus de gestion des niveaux de service. La partie du processus impliquée dans Dev-Ops est la partie la plus connue de négociation et de mise en place des SLAs, OLAs et contrats de sous-traitance lié à la mise en place d’un nouveau service :



Voici, de manière plus détaillée (attention : toutes les activités ne sont pas représentées) ce que cela donne au niveau du processus Dev-Ops :



Les flèches reliant les activités jalons du processus de gestion des changements et les activités dans les autres processus n’ont pas été représentées.

Le schéma positionne les différentes activités du flux de travail classique de la gestion des niveaux de service dans les différentes phases du processus de Dev-Ops.

Les flèches en blanc sont ce qui est présenté de manière traditionnelle dans chacun des processus ITIL®, pouvant donner l’impression d’un référentiel en silos de processus, chacun des processus vivant sa vie indépendamment de celle des autres processus.

L’intégration du processus de gestion des niveaux de service dans le processus Dev-Ops permet aussi de préciser trois grands déclencheurs de ce flux de travail de gestion opérationnelle des niveaux de service (les trois cercles rouges avec un numéro) :

  1. Planifier la mise en œuvre du catalogue et des niveaux de service : il s’agit de la composante d’un projet ITIL® classique où il faut documenter (et éventuellement mettre en place) les niveaux de service pour des services déjà en production ; le flux de travail s’exécute en dehors de tout processus Dev-Ops ; ce flux sera aussi cadencé avec des activités des processus de gestion des fournisseurs et de gestion du catalogue de services

  2. Analyser l’impact et les risques du changement : le processus est déclenché par la gestion des changements afin de travailler sur les aspects niveaux de service de ce qui sera mis en production

  3. Revoir les accords de niveau de service : boucle traditionnelle interne au processus de gestion des niveaux de service, elle consiste à relancer le flux de travail sur un SLA à réviser au bout d’un certain délai si aucune évolution (demande de changement) n’a été réalisée entretemps (ce qui aurait « obligé » une révision des niveaux de service)

    Il faut aussi remarquer qu’à l’intérieur d’une phase, il est possible pour un flux de travail d’avoir un système de boucle fini sans perturber la globalité du processus Dev-Ops.

    Ici, par exemple, lorsqu’il s’agit de négocier simultanément les accords de niveau de service, les accords de niveau d’opérations et les contrats de sous-traitance, il y aura plusieurs ajustements successifs afin de contenter toutes les parties prenantes (sans oublier l’omniprésent processus de gestion financière).

    3.2.6 Introduire l’agilité dans le processus Dev-Ops

    Ce principe de boucle fini peut être étendu à la mise en place d’agilité dans le processus global.

    Ces boucles vont bousculer la structure des différentes phases Dev-Ops, ce qui nécessitera des réajustements dans les processus ITIL® impliqués.

    Mais cela ne change pas l’approche globale.