Tribunes

DevOps : la voiture, la lettre et le tuyau

Alain Sacquet est l'auteur de « Mettre en oeuvre DevOps » publié chez Dunod.

Culture et Automatisation ne doivent pas masquer la dimension Lean de DevOps qui prend la forme d'un "one capability flow" selon Alain Sacquet.

PublicitéDevOps, indispensable pour la mise en oeuvre 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é.
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. De même, nous nous sommes tous arrêtés un jour ou l'autre à un feu rouge limitant l'entrée des autoroutes urbaines aux heures de pointe. 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. Le phénomène précisément étudié par des comptages facilement répétés tous les ans ou tous les jours, se présente de la façon suivante : lorsque la route est vide, les voitures roulent à vitesse élevée.

Naissance des bouchons

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 entraine 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.

Une réalité qui peut être contre-intuitive

Autre expérience. Malgré Internet, la vie associative conduit parfois à 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. Il reste toutefois à convaincre vos partenaires de travailler lettre par lettre, sans pile.

PublicitéAssurer l'écoulement optimal des tâches

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.

Eviter les bouchons

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.

Article rédigé par

Alain Sacquet, Consultant et auteur
Alain Sacquet est ingénieur de l'école Centrale Lille et a consacré sa carrière à la direction de programmes et à l'architecture d'entreprise. Il crée avec Jérôme Gautier le cabinet Marte Conseil en 2000 pour combiner les meilleures expertises de transformation organisationnelle et de management avec l'ingénierie la plus pointue. Il travaille aujourd'hui chez Timspirit.

Alain Sacquet est l'auteur de « Mettre en oeuvre DevOps » publié chez Dunod.