DevOps, indispensable pour la mise en œuvre de la transformation digitale, va aussi s’imposer progressivement dans les DSI traditionnelles car il améliore simultanément la qualité, la réactivité et la productivité de l’informatique d’entreprise. Voyons par analogie avec quelques expériences courantes, comment DevOps améliore la productivité.
La voiture
Chaque année, les jours où les parisiens se précipitent pour rejoindre les stations de skis, la préfecture des Hautes Alpes retient les voitures en bas des routes d’accès. Nous en connaissons la raison : lorsque le trafic augmente au-delà d’un certain seuil, la circulation se congestionne et nous nous retrouvons bloqués. Pour éviter cette situation, les autorités tentent par des ralentissements de limiter le flux en amont des sections critiques.
En effet, lorsque la route est vide, les voitures roulent à vitesse élevée. L’ajout de voitures augmente le débit de la route de façon linéaire jusqu’à ce que l’on s’approche du débit maximal. L’insertion dans le trafic de quelques véhicules supplémentaires augmente encore un peu le débit, mais s’accompagne d’une diminution de la vitesse du flux de voitures et d’une augmentation de la densité du trafic. Passé ce seuil, un nouvel afflux de voitures entraîne la baisse brutale de la vitesse et du débit ainsi que l’augmentation de la densité des véhicules sur la chaussée : bref un bouchon.
A l’approche du basculement du fonctionnement fluide vers la congestion, le comportement du flux serait optimal s’il n’était instable. Il suffit qu’un conducteur ralentisse une fraction de seconde en pensant voir un radar, pour que ses successeurs amplifient cette variation. Chacun conduisait au même rythme soutenu, à la limite de ce que la vitesse et l’espace libéré à chaque instant par son prédécesseur lui permettait de faire. Un éternuement, un écart de conduite et c’est la congestion.
La lettre
Autre expérience. Malgré Internet, il arrive parfois de mettre sous pli et timbrer un nombre important de feuilles A4. Comment s’y prendre au mieux si vous êtes seul ? Allez vous plier toutes les feuilles, en faire une pile, les mettre ensuite sous pli dans une nouvelle pile pour finalement tout timbrer d’un coup, ou bien vous organiser lettre par lettre ? Bien que contre-intuitif, le comportement le plus efficace consiste à ne pas faire de pile mais à enchaîner toutes les actions pour une seule feuille. Vous gagnerez jusqu’à 30 % du temps. Si vous êtes plusieurs, répartissez-vous les feuilles et les enveloppes : votre efficacité sera semblable à la précédente et vous irez d’autant plus vite que vous êtes plus nombreux. Si vous ne travaillez pas feuille par feuille et affectez une personne à chaque tâche par ailleurs plus ou moins longue, le transfert des piles de l’un à l’autre et l’inaction initiale des derniers contributeurs ralentira encore l’ensemble.
Delivery pipeline et one piece flow
Le « delivery pipeline » est le tuyau de DevOps, dont il convient d’organiser les activités successives sans piles au profit d’un écoulement stable et sans congestion.
DevOps fonctionne au mieux lorsque le pipeline voit s’écouler rapidement les solutions aux besoins successifs du métier. Ces solutions apportent de nouvelles « capabilités » fonctionnelles ou techniques. La « capability», c’est une « capacité de faire » reposant sur le système d’information dont le métier souhaite disposer. Par exemple, tenir la charge de la pointe de trafic de Noël ou proposer de nouvelles prestations. Pour éviter la congestion, les parties prenantes vont chercher à déterminer pour chaque besoin prioritaire, la capability la plus petite dont l’activation en production a, à elle seule, du sens pour le métier. Le logiciel est alors modifié en conséquence, installé en production et cette nouvelle aptitude enfin activée de concert avec le métier. La capability activable élémentaire constitue un « Epic » au sens Scrum et une carte Kanban au sens Lean : la limitation du nombre de capabilities en cours de développement évite les encombrements.
Pour atteindre un « débit » maximum de l’IT, et satisfaire ainsi le plus grand nombre de besoins dans un temps et un budget donné, le cycle des capabilities élémentaires sera effectué à la plus grande vitesse possible.
Cette grande vitesse est atteinte sans pile, ce qui suppose que, plutôt que de répartir les moyens par activités, donnant lieu à autant d’équipes taylorisées et de piles, une seule équipe applicative travaille de façon intégrée sur la « pièce » que constitue la capability attendue. La polyvalence de chaque ingénieur en contact direct avec le métier garantit l’utilisation optimale des ressources, pendant que la disponibilité infinie de l’outillage stabilise le processus par l’automatisation des gestes techniques répétitifs tels que les tests de non régression ou les installations en production. Cette performance des tâches avales évite la répercussion de bouchons vers l’amont.Ainsi, avec DevOps, les pratiques performantes des sociétés internet rejoignent-elles la théorie du lean manufacturing autour du Graal que constitue le pièce à pièce (one piece flow), synthèse des flux tirés, de la maille la plus petite, de la vitesse la plus grande et de l’organisation en unités autonomes de production. Le Lean IT, tout d’abord consacré au Lean Software Development, devient avec DevOps le Lean IT 2.0 focalisé sur l’IT Capability Management.