DevOps : une autre gestion du risque… et de la productivité

Durcir les processus d’approbation du code ne réduit pas forcément les risques.

Google Cloud établit ce constat dans l’édition 2019 de son étude « State of DevOps » (PDF, 82 pages).

La branche cloud du groupe américain s’appuie sur des données recueillies auprès d’environ 31 000 employés :

• basés pour l’essentiel en Amérique du Nord (50 %) et dans l’UE (29 %) ;
• travaillant principalement dans le développement et l’ingénierie (30 %) ;
• ayant pour près de moitié (48 %) plus de 16 ans d’expérience.

Pour mesurer l’efficacité des pratiques de développement logiciel dans leurs organisations, quatre indicateurs ont été définis :

• délai de mise en application d’un changement (de l’ajout du code à son déploiement en production) ;
• fréquence des déploiements de code en production ou à destination des utilisateurs finaux ;
• délai de rétablissement du service en cas d’incident touchant les utilisateurs ;
• taux de modifications occasionnant une perturbation de service et nécessitant remédiation.

DevOps : la preuve par quatre

Chacun des participants a été interrogé à propos de la principale application sur laquelle il travaillait. Il en résulte quatre catégories d’organisations. Elles figurent dans le tableau ci-dessous.

Entre les plus et les moins efficaces (respectivement « Elite » et « Low »), l’écart se creuse tout particulièrement en ce qui concerne la fréquence de déploiement*. Google Cloud y impute la complexification des environnements IT.

Les organisations de plus de 5 000 employés affichent globalement de moins bonnes performances. Précisément dans ce contexte de complexification des architectures, mais aussi des processus associés.

Sur la question du risque, Google Cloud établit une corrélation entre les méthodes « traditionnelles » d’approbation de code et l’augmentation des taux de dysfonctionnements.
Raison invoquée : voulus plus robustes, les cycles de validation en deviennent aussi plus longs. L’écart s’accroît entre les releases et avec lui, les chances de rencontrer des problèmes lors du passage en production.

La productivité par le risque

Qu’en est-il dans les chiffres ? Les organisations qui utilisent des méthodes « traditionnelles » ont « 2,6 fois plus de chances de se trouver dans la catégorie « Low ».
Et Google Cloud de recommander deux leviers :

• l’automatisation ;
• confier l’approbation du code à des membres de la même équipe plutôt qu’à des collaborateurs extérieurs.

Ce dernier point implique un nouveau rôle pour les collaborateurs en question. Un rôle plus stratégique qui suppose des décisions de plus haut niveau, par exemple sur l’équilibre entre risque business et time to market (« de gardien du temple à architecte », pour reprendre les termes de l’étude).

En toile de fond, des politiques plus larges de gestion du changement. Avec, parmi les objectifs, celui d’insuffler une culture de la prise de risque.

Cet élément doit contribuer au développement de la productivité telle que la définit Google Cloud : la « capacité à réaliser des tâches complexes et chronophages avec un minimum de désagréments ».

Le schéma ci-dessus présente d’autres leviers censés favoriser la productivité. Parmi eux, la gestion de la « dette technique ». C’est-à-dire les bugs connus mais non corrigés, le code obsolète, les migrations incomplètes ou encore la documentation manquante.

* La moyenne est de 7 déploiements par an dans la catégorie « Low ». Elle s’élève à 1 460 (soit 4 par jours) chez les « Elite ».
Le délai d’application des changements s’échelonne de 24 h en moyenne chez les plus réactifs à 2 555 h pour les « moins bons élèves ».

Photo d’illustration via Pexels