Pour gérer vos consentements :
Categories: DéveloppeursProjets

DevOps et performance : une corrélation évidente selon Google

« Avant, le lien était bien plus clair. » Après bientôt dix ans à publier ses rapports sur le DevOps, Google dispose d’une matière qui lui permet une telle démarche comparative.

Appliquée à la 9e édition, tout juste publiée, elle fait ressortir un certain nombre d’éléments contre-intuitifs ou tout du moins inattendus au regard des données historiques.

Cette année, l’échantillon comprend « plus de 1350 » répondants. Répartis comme suit (métier et taille de l’organisation).

Au-delà des contradictions qu’il soulève, le rapport a pour but premier de révéler des corrélations entre pratiques DevOps et performance.

Performance sur trois points :

– Livraison logicielle (delivery)
Avec quatre indicateurs : fréquence de déploiement, délai de mise en œuvre des changements (du commit à la prod), taux d’échec et temps de rétablissement.

– Performance opérationnelle
Un indicateur : la fiabilité. C’est-à-dire la capacité à répondre aux attentes des utilisateurs, essentiellement en termes de disponibilité et de performance.

– Performance organisationnelle (capacité à atteindre les objectifs de performance et de profitabilité)

Architectures découplées : dure limite ?

Depuis 2018, l’étude catégorise les organisations en « clusters », selon les critères de delivery.

L’an dernier, il y en avait quatre. Cette année, il n’y en a plus que trois, faute d’un écart suffisant entre les deux catégories les plus « avancées ». Hypothèse : une diminution de l’innovation dans le développement logiciel, autant sur les pratiques que l’outillage.

À périmètre constant, la performance en livraison logicielle augmente : le premier cluster de 2022 est entre le premier et le deuxième de 2021 ; le troisième de 2022 est entre le troisième et le quatrième de 2021.

Dans ce contexte, un deuxième classement a été réalisé cette année. Il inclut la performance opérationnelle. À la clé, quatre clusters.

Le cluster « Flowing » présente plusieurs caractéristiques parmi lesquelles des équipes indépendantes du point de vue architectural, une flexibilité par rapport aux conditions de travail, ainsi l’usage de l’intégration et de la livraison continues (CI/CD).

Le fameux « lien bien plus clair » susmentionné unit la performance en livraison logicielle à la performance organisationnelle. Ou plutôt unissait : cette année, la première a tendance à ne pas bénéficier à la seconde aussi longtemps que la performance opérationnelle n’est pas élevée.

Des contradictions, il y en a aussi sur les architectures découplées. En particulier, le taux de burn-out est plus élevé dans les équipes qui sont sur ce modèle. Le rapport formule une hypothèse : dans les organisations concernées, la sécurité n’est peut-être pas du ressort des équipes responsables des applications. Le découplage de leurs travaux peut donc s’avérer plus complexe.

La tendance se retrouve pour le développement basé sur le tronc, comme pour CI et CD. Ressort une autre hypothèse, liée à une donnée mesurable : le niveau moyen d’expérience dans l’échantillon ayant baissé, on a peut-être interrogé plus d’implémenteurs que de superviseurs.

Du CI au SRE : l’effet « courbe en J »

Le potentiel effet négatif des architectures découplées se fait aussi ressentir lorsqu’on les combine à la livraison continue. Google évoque ici un phénomène de « courbe en J », où les premiers gains sont rapides, mais où on ne récolte les fruits ultérieurs qu’à partir d’un certain stade de maturité. C’est ce qui se passe aussi avec le SRE (cf. schéma). Même dynamique pour le développement sur la base du tronc, alors que depuis 2014, on avait systématiquement constaté l’inverse.

Le SRE, justement, semble lui aussi avoir ses effets négatifs, en l’occurrence sur le delivery. Cela tient peut-être, nous explique-t-on, au fait que certaines organisations se concentrent sur la partie fiabilité (cluster « Retiring »).

Élément pas directement en contradiction avec des données historiques, mais à noter tout de même : les utilisateurs du cloud connaissent des taux d’échec plus importants. Cloud hybride et multicloud, en particulier, ont un impact négatif sur l’essentiel des critères de delivery… sauf si la performance opérationnelle est bonne.


Illustration principale © everything possible – Shutterstock

Recent Posts

Vanessa Cugniere, nouvelle Country Manager de OneTrust en France

OneTrust nomme Vanessa Cugniere au poste de Country Manager pour la France.

15 heures ago

Les recettes d’Apple pour entraîner des LLM multimodaux

Apple donne un aperçu supplémentaire de ses travaux LLM multimodaux avec un article consacré à…

15 heures ago

Luc Julia : « L’IA générative n’est pas une révolution des IA, mais une révolution des usages »

Pour Luc Julia, inventeur de Siri, l’essor des IA génératives n’est pas une révolution qui…

18 heures ago

Grok est-il vraiment un LLM « ouvert » ?

Un LLM dont on publie poids et code d'inférence est-il « open source » ?…

19 heures ago

Les 5 start-up retenues pour le programme PROQCIMA

Avec PROQCIMA, L'État vise le développement d'ordinateurs quantiques à destination des armées. Il a sollicité…

22 heures ago

Les frais de sortie en voie d’extinction chez les hyperscalers

Dans la lignée de Google Cloud et d'AWS, Microsoft met fin aux frais de sortie…

4 jours ago