Rapport Accelerate sur l'état du DevOps en 2021

Le rapport annuel Accelerate sur l'état du DevOps réalisé par l'équipe DORA (DevOps Research and Assessment) de Google Cloud compile sept années de recherche et de données provenant de plus de 32 000 professionnels du monde entier.

Notre étude passe en revue les capacités et les pratiques qui favorisent la livraison de logiciels ainsi que les performances opérationnelles et organisationnelles. Nous exploitons des techniques statistiques rigoureuses afin d'analyser les facteurs d'excellence en termes de livraison de technologies et de résultats commerciaux. Dans cette optique, nous présentons des insights fondés sur les données qui révèlent les moyens les plus efficaces pour développer et livrer des technologies.

Notre étude conforte l'idée que l'excellence en matière de livraison de logiciels et de performances opérationnelles stimule les performances organisationnelles dans un contexte de transformation technologique. Pour permettre aux équipes de se comparer à d'autres acteurs du secteur, nous utilisons l'analyse par clusters. Elle permet de créer des catégories de performance significatives, telles que des performances faibles, moyennes, élevées ou exceptionnelles. Une fois que vos équipes ont une idée de leurs performances actuelles par rapport à d'autres acteurs du secteur, vous pouvez vous servir des conclusions de notre analyse prédictive pour cibler certaines pratiques et capacités qui améliorent des résultats clés et éventuellement votre positionnement relatif. Cette année, nous mettons l'accent sur l'importance d'atteindre certains objectifs en termes de fiabilité, d'intégrer la sécurité tout au long de la chaîne d'approvisionnement logicielle, de créer une documentation interne de qualité et d'exploiter tout le potentiel du cloud. Nous déterminons également si une culture d'équipe positive peut atténuer les effets du télétravail, suite à la pandémie de COVID-19.

Pour une amélioration significative des performances, les équipes doivent adopter une culture d'amélioration continue. Utilisez les benchmarks pour évaluer l'état actuel de votre organisation, identifier vos contraintes en fonction des capacités présentées dans le cadre de l'étude et tester des améliorations qui vous libèrent de ces contraintes. Lors de ces tests, vous rencontrerez à la fois des succès et des échecs. Dans les deux cas, vous en tirerez des enseignements qui permettront aux équipes de prendre des mesures efficaces.

De plus en plus d'équipes atteignent un niveau de performances exceptionnel, et cette tendance ne cesse de croître.

Les équipes les plus performantes représentent maintenant 26 % des participants à notre étude, et ont réduit leurs délais de livraison de modifications en production. Le secteur est en pleine croissance, ce qui avantage les équipes de façon significative.

L'ingénierie SRE et les pratiques DevOps sont des philosophies complémentaires.

Les équipes qui exploitent les pratiques opérationnelles modernes décrites par nos partenaires en ingénierie en fiabilité des sites (SRE) enregistrent des performances opérationnelles supérieures. Les équipes qui priorisent la livraison et l'excellence opérationnelle enregistrent les performances organisationnelles les plus élevées.

De plus en plus d'équipes utilisent le cloud et en tirent des bénéfices considérables.

Les équipes poursuivent la migration de leurs charges de travail vers le cloud. Celles qui exploitent les cinq fonctionnalités du cloud constatent une hausse des performances dans la livraison de logiciels et les opérations (également appelées performances SDO), ainsi que des performances organisationnelles. L'adoption de services multicloud, en plein essor, permet aux équipes de profiter des capacités propres à chaque fournisseur.

Une chaîne d'approvisionnement logicielle sécurisée est essentielle et améliore les performances.

Compte tenu de l'augmentation significative des attaques malveillantes ces dernières années, les organisations doivent abandonner les pratiques réactives au profit de mesures proactives et de diagnostics. Les équipes qui intègrent des pratiques de sécurité tout au long de leur chaîne d'approvisionnement logicielle accélèrent la livraison des logiciels, de manière fiable et sécurisée.

Une documentation de qualité est fondamentale pour réussir la mise en œuvre des fonctionnalités DevOps.

Pour la première fois, nous avons évalué la qualité de la documentation interne et les facteurs d'excellence en la matière. Les équipes disposant d'une documentation de haute qualité sont mieux à même de mener des initiatives techniques, et atteignent généralement de meilleures performances globales.

Une culture d'équipe positive permet de limiter le surmenage dans des situations difficiles.

La culture d'équipe fait une grande différence dans la capacité à livrer des logiciels et à atteindre ou dépasser les objectifs organisationnels. Lors de la pandémie de COVID-19, les équipes inclusives présentant une culture générative^1,2 ont été moins sujettes au surmenage.

____________________________

1. D'après la typologie de la culture organisationnelle de Westrum, une culture d'équipe générative décrit les équipes qui font preuve d'une grande coopération, décloisonnent les données, tirent des enseignements de leurs échecs et partagent les risques associés aux prises de décisions.

2. Westrum, R. (2004). “A typology of organizational cultures.” BMJ Quality & Safety, 13(suppl 2), ii22-ii27.

Nous regardons comment les équipes développent, livrent et exploitent des systèmes logiciels. Nous répartissons ensuite les personnes interrogées en quatre clusters de performance : exceptionnelles, élevées, moyennes et faibles. En comparant les performances de votre équipe à celle de chaque cluster, vous pouvez déterminer votre situation actuelle par rapport aux résultats décrits tout au long de ce report.

Performances de livraison de logiciels et opérationnelles

Pour répondre aux besoins d'un secteur en constante évolution, les entreprises doivent livrer et exploiter les logiciels de façon rapide et fiable. Plus vite vos équipes sont capables de modifier votre logiciel, plus tôt vous pourrez apporter de la valeur à vos clients, effectuer des tests et recevoir de précieux commentaires. En nous appuyant sur sept années de collecte de données et de recherche, nous avons développé et validé quatre métriques qui mesurent les performances en livraison de logiciels. Depuis 2018, nous avons inclus une cinquième métrique pour identifier les capacités d'exploitation.

Les équipes qui excellent dans l'ensemble de ces cinq indicateurs démontrent des performances organisationnelles exceptionnelles. Nous appelons ces cinq mesures : performances en livraison de logiciels et opérationnelles (SDO). Veuillez noter que ces métriques s'intéressent aux objectifs au niveau du système, ce qui permet d'éviter les problèmes les plus courants des métriques logicielles, comme opposer les fonctions les unes aux autres et procéder à des optimisations locales au détriment des résultats globaux.

Les quatre métriques évaluant les performances de la livraison de logiciels peuvent être envisagées sur le plan du débit et de la stabilité. Nous mesurons le débit en étudiant le délai de livraison des modifications du code (c'est-à-dire, la durée entre la validation du code et la mise en production), et la fréquence de déploiement. Nous mesurons la stabilité grâce au délai de restauration du service après un incident et au taux d'échec sur l'implémentation de modifications.

Une fois encore, l'analyse par clusters des quatre métriques de livraison de logiciels révèle quatre profils différents en matière de performances (exceptionnelles, élevées, moyennes et faibles) présentant des différences statistiquement pertinentes en termes de débit et de mesures de la stabilité. Comme pour les années précédentes, les éléments les plus performants obtiennent des résultats bien meilleurs pour les quatre mesures, tandis que les entreprises peu performantes s'en sortent beaucoup plus mal dans tous les domaines.

La cinquième métrique représente les performances opérationnelles et permet de mesurer les pratiques opérationnelles modernes. La principale métrique de performance opérationnelle est la fiabilité, qui indique dans quelle mesure une équipe peut tenir ses promesses et ses affirmations concernant le logiciel qu'elle exploite. Nous mesurions traditionnellement la disponibilité plutôt que la fiabilité. Cependant, comme la disponibilité constitue un aspect spécifique de l'ingénierie SRE, nous avons étendu notre mesure à la fiabilité afin que la disponibilité, la latence, les performances et l'évolutivité soient plus largement représentées. Nous avons notamment demandé aux personnes interrogées d'évaluer leur capacité à atteindre ou dépasser leurs objectifs en matière de fiabilité. Nous avons constaté que les équipes dont les performances en livraison de logiciels varient enregistrent de meilleurs résultats lorsqu'elles hiérarchisent également les performances opérationnelles.

Comme dans les précédents rapports, nous avons comparé les entreprises les plus performantes à celles qui le sont le moins pour illustrer l'impact de capacités spécifiques. Toutefois, cette année, nous avons cherché à tenir compte de l'influence des performances opérationnelles. Pour toutes les catégories de performances de livraison (de faibles à exceptionnelles), nous avons constaté des bénéfices considérables sur de multiples résultats pour les équipes qui ont donné la priorité à la réalisation ou au dépassement de leurs objectifs de fiabilité.

Année après année, nous sommes témoins de l'évolution du secteur et de l'accélération de sa capacité à livrer des logiciels plus rapidement et avec une stabilité accrue. Pour la première fois, les entreprises aux performances élevées ou exceptionnelles représentent deux tiers des personnes interrogées. De plus, cette année, les entreprises réalisant des performances exceptionnelles ont à nouveau élevé le niveau en abaissant leur délai de livraison des modifications par rapport aux évaluations précédentes (de moins d'un jour en 2019 à moins d'une heure en 2021). Par ailleurs, cette même catégorie d'entreprises est parvenue à limiter pour la première fois son taux d'échec de la modification comparé aux années passées où les entreprises présentant des performances élevées ou moyennes atteignaient le même résultat.

Débit

Fréquence de déploiement

Dans la continuité des années précédentes, le groupe aux performances exceptionnelles a indiqué effectuer régulièrement des déploiements à la demande et exécuter plusieurs déploiements par jour. En comparaison, les entreprises les moins performantes ont déclaré qu'elles réalisaient des déploiements moins d'une fois tous les six mois (moins de deux par an), ce qui représente à nouveau une baisse des performances par rapport à 2019. Les chiffres des déploiements annuels normalisés sont compris entre 1 460 déploiements par an (le produit de quatre déploiements par jour multiplié par 365 jours) pour les entreprises les plus performantes et 1,5 déploiement par an pour les moins performantes (la moyenne obtenue entre un et deux déploiements). Cette analyse estime que les entreprises les plus performantes déploient du code 973 fois plus fréquemment que les organisations les moins performantes.

Délai d'implémentation des modifications

Les entreprises les plus performantes signalent une amélioration du délai de livraison des modifications par rapport à 2019, qui se situe désormais à moins d'une heure. Celui-ci représente le délai nécessaire pour passer du code validé au déploiement effectif en production. Cela marque donc une amélioration des performances comparé à 2019, quand les meilleurs éléments indiquaient un délai de livraison des modifications de moins d'un jour. À l'inverse de cette catégorie, les entreprises les moins performantes nécessitent des délais de livraison supérieurs à six mois. Avec des délais de livraison d'une heure pour les entreprises les plus performantes (une estimation prudente parmi les valeurs supérieures de la plage "moins d'une heure") et de 6 570 heures pour les moins performantes (obtenues en calculant la moyenne de 8 760 heures par an et de 4 380 heures sur six mois), les meilleurs éléments proposent des délais de livraison des modifications 6 570 fois plus rapides que les organisations les moins performantes.

Stabilité

Délai de restauration du service

Le groupe le plus performant signale un délai de restauration du service de moins d'une heure, tandis que les organisations les moins performantes ont indiqué un temps supérieur à six mois. Pour ce calcul, nous avons pris en compte des estimations prudentes : une heure pour les entreprises les plus performantes et la moyenne entre un an (8 760 heures) et six mois (4 380 heures) pour les moins performantes. D'après ces chiffres, les meilleurs éléments présentent un délai de restauration du service 6 570 fois plus rapide que les entreprises les moins performantes. Les performances de délai de restauration du service se sont maintenues pour les entreprises les plus performantes et ont augmenté pour les moins performantes par rapport à 2019.

Taux d'échec sur l'implémentation des modifications

Les entreprises les plus performantes ont signalé un taux d'échec de la modification compris entre 0 et 15 %, tandis que les moins performantes ont indiqué des pourcentages compris entre 16 et 30 %. La moyenne entre ces deux intervalles donne un taux d'échec de la modification de 7,5 % pour les meilleurs éléments et de 23 % pour les moins bons. Les taux d'échec de la modification des entreprises les plus performantes sont trois fois meilleurs que ceux des organisations les moins performantes. Cette année, les taux d'échec de la modification sont restés identiques pour les entreprises les plus performantes et se sont améliorés pour les moins performantes comparé à 2019. Cependant, les performances se sont détériorées pour les groupes intermédiaires.

En comparant les entreprises les plus performantes à celles qui le sont le moins, nous constatons pour le premier groupe :

• Des déploiements de code 973 fois plus fréquents
• Des délais de livraison 6 570 fois plus rapides de la validation au déploiement
• Un taux d'échec des modifications 3 fois plus faible (elles ont 3 fois moins de chances d'échouer)
• Des délais de reprises après incident 6 570 fois plus rapides

Comment améliorer vos performances de SDO et organisationnelles ? Notre étude permet de formuler des conseils étayés par des faits pour vous aider à vous concentrer sur les fonctionnalités qui stimulent les performances.

Le rapport de cette année s'est intéressé à l'impact du cloud, de l'ingénierie SRE, de la sécurité, des pratiques techniques et de la culture. Tout au long de cette section, nous vous présentons chacune de ces fonctionnalités et examinons leur impact sur différents résultats. Pour les personnes qui connaissent les modèles de recherche sur l'état du DevOps du programme DORA, nous avons conçu une ressource en ligne qui héberge le modèle de cette année ainsi que tous les précédents.³

^{____________________________}

3. https://devops-research.com/models.htm

____________________________

Conformément à l'étude Accelerate sur l'état du DevOps en 2019, un nombre croissant d'entreprises optent pour des solutions de cloud hybride et multicloud. Lors de notre enquête, nous avons demandé aux personnes interrogées où était hébergé(e) leur application ou service principal. Il en ressort une hausse de l'utilisation du cloud public. Parmi les sondés, 56 % ont déclaré avoir recours à un cloud public (voire plusieurs clouds publics), soit une augmentation de 5 % par rapport à 2019. Cette année, nous avons également posé des questions ciblées sur l'utilisation des services multicloud, et 21 % des personnes ont indiqué effectuer des déploiements vers plusieurs clouds publics. Une proportion de 21 % des participants à l'étude a déclaré ne pas utiliser le cloud et privilégier à la place un centre de données ou une solution sur site. Enfin, 34 % des individus ont indiqué recourir au cloud hybride, et 29 % au cloud privé.

Accélérer les résultats commerciaux grâce aux services hybrides et multicloud.

Cette année, nous assistons à une utilisation croissante des services hybrides et multicloud, avec un impact considérable sur les résultats jugés essentiels par les entreprises. Les personnes interrogées utilisant le cloud hybride ou multicloud étaient 1,6 fois plus susceptibles de dépasser leurs objectifs de performances organisationnelles que celles qui n'y ont pas recours. Nous avons également constaté de forts effets sur les performances SDO. En effet, les utilisateurs du cloud hybride et multicloud ont 1,4 fois plus de chances d'exceller en termes de fréquence de déploiement, de délai de livraison des modifications, de délai de reprise, de taux d'échec de la modification et de fiabilité.

Pourquoi opter pour le multicloud ?

Comme lors de notre évaluation de 2018, nous avons demandé aux personnes interrogées pourquoi elles ont recours à plusieurs fournisseurs de cloud public. Au lieu d'avoir à sélectionner toutes les réponses applicables, nous leur avons demandé d'indiquer cette fois la raison principale pour laquelle elles ont recours à de multiples fournisseurs. Plus d'un quart (26 %) des participants signalent l'avoir fait pour profiter des avantages uniques offerts par chaque fournisseur cloud. Cela suggère que lorsque ces individus choisissent un fournisseur supplémentaire, ils s'intéressent aux différences entre leur fournisseur actuel et les autres. Le deuxième motif principal de passer au multicloud était la disponibilité (22 %). Sans surprise, les personnes interrogées qui ont adopté plusieurs fournisseurs cloud avaient 1,5 fois plus de chances de réaliser ou de dépasser leurs objectifs en matière de fiabilité.

Raison principale de l'utilisation de plusieurs fournisseurs

Changements de benchmarks

La façon dont vous mettez en œuvre l'infrastructure cloud est importante

Traditionnellement, nous constatons que toutes les personnes interrogées n'adoptent pas le cloud de la même manière. Il en résulte une adoption du cloud plus ou moins efficace pour l'amélioration des résultats commerciaux. Pour remédier à cette limitation, nous nous sommes concentrés sur les caractéristiques essentielles du cloud computing, telles que définies par le National Institute of Standards and Technology (NIST), et nous nous en sommes inspirés. À l'aide de la définition du cloud computing du NIST, nous avons étudié l'impact des pratiques essentielles sur les performances de SDO plutôt que de nous contenter d'étudier l'impact de l'adoption du cloud sur ces performances.

Pour la troisième fois, nous constatons que l'élément déterminant ne réside pas seulement dans le fait d'avoir recours aux technologies cloud, mais dans la façon dont les équipes mettent en œuvre leurs services cloud. Les entreprises les plus performantes étaient 3,5 fois plus susceptibles d'avoir rempli toutes les caractéristiques essentielles du cloud computing identifiées par le NIST. Seulement 32 % des personnes qui ont déclaré utiliser une infrastructure cloud sont d'accord ou fortement d'accord pour dire que leur infrastructure répond aux cinq caractéristiques de cloud computing décrites par le NIST, soit une hausse de 3 % par rapport à 2019. D'une manière générale, l'utilisation des caractéristiques du cloud computing formulées par le NIST a augmenté de 14 à 19 %, avec l'élasticité rapide présentant la plus forte augmentation.

Libre-service à la demande

Les consommateurs peuvent provisionner automatiquement des ressources informatiques selon les besoins, sans aucune intervention humaine nécessaire de la part du fournisseur.

73 % des personnes interrogées ont utilisé le libre-service à la demande, soit une augmentation de 16 % par rapport à 2019.

Accès réseau étendu

Les fonctionnalités sont facilement accessibles via divers clients comme les téléphones mobiles, les tablettes, les ordinateurs portables et les stations de travail.

74 % des personnes interrogées avaient recours à l'accès réseau étendu, une hausse de 14 % par rapport à 2019.

Pooling des ressources

Les ressources du fournisseur sont regroupées dans un modèle mutualisé, et les ressources physiques et virtuelles sont attribuées dynamiquement et réattribuées à la demande. Le client n'a généralement aucun contrôle direct sur l'emplacement exact des ressources fournies, mais il peut spécifier l'emplacement à un niveau d'abstraction plus élevé, comme le pays, l'état ou le centre de données.

73 % des personnes interrogées ont eu recours au pooling des ressources, soit une augmentation de 15 % par rapport à 2019.

Élasticité rapide

Les fonctionnalités peuvent être provisionnées et libérées de manière flexible afin d'évoluer rapidement à la hausse ou à la baisse selon la demande. Les fonctionnalités consommateur disponibles au provisionnement sont virtuellement illimitées et leur quantité peut être ajustée à tout moment.

77 % des personnes interrogées ont utilisé l'élasticité rapide, soit une augmentation de 18 % par rapport à 2019.

Service sur mesure

Les systèmes cloud contrôlent et optimisent automatiquement l'utilisation des ressources en exploitant une capacité de mesure à un niveau d'abstraction approprié au type de service, comme le stockage, le traitement, la bande passante et les comptes utilisateur actifs. Pour plus de transparence, l'utilisation des ressources peut être surveillée, contrôlée et signalée.

78 % des personnes interrogées ont utilisé un service sur mesure, soit une augmentation de 16 % par rapport à 2019.

Tandis que la communauté DevOps faisait son apparition dans les conférences publiques et les conversations, un mouvement semblable se formait au sein de Google : l'ingénierie en fiabilité des sites (SRE). L'ingénierie SRE et des approches similaires, comme la discipline d'ingénierie de production de Facebook, reprennent un grand nombre des objectifs et des techniques qui motivent le DevOps. En 2016, l'ingénierie SRE pénètre officiellement dans la sphère publique lors de la publication du premier ouvrage⁴ sur l'ingénierie en fiabilité des sites. Depuis, le mouvement a pris de l'ampleur et de nos jours, une communauté internationale d'adeptes de l'ingénierie SRE collabore sur des bonnes pratiques pour les opérations techniques.

Peut-être inévitablement, une confusion est apparue. Quelle est la différence entre l'ingénierie SRE et le DevOps ? Dois-je opter pour l'une ou pour l'autre ? Quelle est la meilleure option ? En réalité, il n'y a aucun conflit. L'ingénierie SRE et le DevOps sont très complémentaires, et notre recherche démontre leur alignement. L'ingénierie SRE est une discipline d'apprentissage qui donne la priorité à la communication pluridisciplinaire et à la sécurité psychologique, les mêmes valeurs qui sont au cœur de la culture générative axée sur la performance typique des équipes DevOps d'élite. À partir de ses principes fondamentaux, l'ingénierie SRE fournit des techniques pratiques, notamment le framework de métriques SLI/SLO (indicateurs de niveau de service/objectifs de niveau de service). De la même manière que le framework léger pour les produits spécifie la manière de réaliser des cycles de rétroaction rapides auprès des clients, comme le démontre notre recherche, le framework SRE offre une définition des pratiques et des outils qui peuvent rendre une équipe plus apte à tenir en permanence ses promesses envers ses utilisateurs.

En 2021, nous avons élargi notre enquête aux opérations, passant d'une analyse de la disponibilité du service à la catégorie plus générale de la fiabilité. L'étude de cette année a introduit plusieurs éléments inspirés des pratiques SRE, afin d'évaluer dans quelle mesure les équipes :

• définissent la fiabilité en termes de comportement des utilisateurs ;
• emploient le framework de métriques SLI/SLO pour hiérarchiser le travail selon les marges d'erreur ;
• utilisent l'automatisation pour réduire le travail manuel et les alertes perturbatrices ;
• définissent des protocoles et des exercices de préparation pour la réponse aux incidents ;
• incluent les principes de fiabilité tout au long du cycle de vie de la livraison de logiciels (accent sur la fiabilité en amont).

En analysant les résultats, nous avons constaté que les équipes qui excellent dans ces pratiques opérationnelles modernes sont 1,4 fois plus susceptibles de faire état de meilleures performances SDO, et 1,8 fois plus à même d'enregistrer de meilleurs résultats commerciaux.

La majorité des équipes participant à notre étude ont adopté les pratiques SRE : 52 % des personnes interrogées ont déclaré utiliser ces pratiques dans une certaine mesure, bien que le niveau d'adoption varie notablement entre les équipes. Les données montrent que l'utilisation de ces méthodes permet de prédire une plus grande fiabilité et de meilleures performances SDO globales : les pratiques SRE sous-tendent la réussite du DevOps.

En outre, nous avons constaté qu'un modèle opérationnel à responsabilité partagée, reflété par la mesure dans laquelle développeurs et opérateurs sont conjointement habilités à contribuer à la fiabilité, permet également de prédire de meilleurs résultats en matière de fiabilité.

Au-delà de l'amélioration des mesures objectives des performances, l'ingénierie SRE améliore l'expérience de travail des techniciens. En général, les personnes chargées d'un grand nombre de tâches opérationnelles sont sujettes au surmenage, mais l'ingénierie SRE entraîne un effet positif. D'après nous, plus une équipe met en œuvre les principes SRE, moins ses membres risquent de connaître le surmenage. L'ingénierie SRE permettrait également d'optimiser les ressources : les équipes qui remplissent leurs objectifs de fiabilité grâce à l'application des pratiques SRE indiquent passer plus de temps à écrire du code que celles qui n'y ont pas recours.

Notre étude révèle que, quel que soit leur niveau de performances SDO (de faibles à exceptionnelles), les équipes sont susceptibles de tirer des bénéfices de l'utilisation accrue des pratiques SRE. Plus une équipe réalise de bonnes performances, plus il est probable qu'elle emploie des modes d'opérations modernes : les entreprises les plus performantes ont 2,1 fois plus de chances de faire état de pratiques SRE que leurs homologues moins performantes. Mais même les meilleures équipes peuvent encore progresser : seulement 10 % des entreprises les plus performantes interrogées ont indiqué que leurs équipes avaient pleinement mis en œuvre chaque pratique SRE que nous avons étudiée. Tandis que les performances SDO continuent de croître dans tous les secteurs, l'approche des opérations adoptée par chaque équipe constitue un moteur critique de l'amélioration continue du DevOps.

____________________________

4. Betsy Beyer et al., eds., Site Reliability Engineering (O’Reilly Media, 2016).

____________________________

Documentation

Cette année, nous nous sommes intéressés à la qualité de la documentation interne, c'est-à-dire aux documents (comme les manuels, les fichiers README et même les commentaires sur le code) portant sur les services et applications sur lesquels travaille une équipe. Nous avons estimé la qualité de la documentation en évaluant dans quelle mesure celle-ci :

• aide les lecteurs à réaliser leurs objectifs ;
• contient des informations précises, à jour et exhaustives ;
• est facile à trouver, bien organisée et claire.⁵

L'enregistrement et l'accès aux informations sur les systèmes internes constituent une partie essentielle du travail technique d'une équipe. Nous avons découvert que 25 % des personnes interrogées possédaient une documentation de bonne qualité, et l'impact de ces ressources sur le travail est évident : les équipes bénéficiant des documents les plus qualitatifs sont 2,4 fois plus susceptibles d'enregistrer des performances opérationnelles et de livraison de logiciels (SDO) supérieures. Les équipes dotées d'une documentation de qualité livrent plus rapidement des logiciels et de manière plus fiable que ceux dont la documentation est peu aboutie. Il n'est pas nécessaire que les ressources soient irréprochables. Notre étude indique que toute amélioration de la qualité des documents entraîne un impact direct positif sur les performances.

L'environnement technologique actuel dispose de systèmes de plus en plus complexes, ainsi que d'experts et de rôles spécialisés permettant de couvrir différents aspects de ces systèmes. De la sécurité à la phase de tests, la documentation joue un rôle essentiel dans le partage de connaissances et de conseils spécialisés à la fois entre ces sous-équipes spécialisées et au sein de l'équipe plus étendue.

Selon nous, la qualité de la documentation détermine la réussite des équipes dans la mise en œuvre de pratiques techniques. À leur tour, ces dernières jouent un rôle dans l'amélioration des capacités techniques des systèmes, comme l'observabilité, les tests en continu et l'automatisation des déploiements. Nous avons découvert que les équipes bénéficiant d'une documentation de qualité sont :

• 3,8 fois plus susceptibles de mettre en œuvre des pratiques de sécurité ;
• 2,4 fois plus à même d'atteindre ou de dépasser leurs objectifs de fiabilité ;
• 3,5 fois plus susceptibles d'appliquer des pratiques d'ingénierie en fiabilité des sites (SRE) ;
• 2,5 fois plus à même de tirer pleinement parti du cloud.

Comment améliorer la qualité de la documentation

Le travail technique nécessite de trouver et d'utiliser des informations, mais une documentation de qualité repose sur des personnes qui rédigent et actualisent le contenu. En 2019, notre étude a révélé que l'accès à des sources d'informations internes et externes encourageait la productivité. Cette année, nous poussons nos recherches encore plus loin en examinant la qualité de la documentation disponible et les pratiques déterminantes quant à cet aspect.

D'après nos recherches, les pratiques suivantes entraînent un impact positif considérable sur la qualité des documents :

Documenter les cas d'utilisation critiques de vos produits et services. Ce que vous documentez à propos d'un système est important, et les cas d'utilisation permettent à vos lecteurs de mettre en pratique les informations et vos systèmes.

Formuler des consignes claires pour l'actualisation et la modification de la documentation existante. Une grande partie du travail de documentation consiste à garantir la pertinence du contenu existant. Lorsque les membres de votre équipe savent comment effectuer des mises à jour ou supprimer des informations inexactes ou obsolètes, ils peuvent préserver la qualité de la documentation même si le système évolue au fil du temps.

Définir les propriétaires des ressources. Les équipes disposant d'une documentation de qualité sont plus susceptibles d'avoir établi clairement la propriété de leurs documents. La propriété permet de définir des responsabilités explicites pour la rédaction de nouveaux contenus et la mise à jour ou la vérification des modifications apportées aux contenus existants. Les équipes qui bénéficient d'une documentation de qualité sont plus enclines à déclarer que la documentation est rédigée pour toutes les principales fonctionnalités des applications sur lesquelles elles travaillent. De plus, la clarté de la propriété contribue à créer cette couverture étendue.

Inclure la documentation dans les processus de développement de logiciels. Les équipes qui ont créé une documentation et l'ont actualisée au fur et à mesure de l'évolution du système présentent une documentation de meilleure qualité. Tout comme les tests, la création et la maintenance de la documentation font partie intégrante d'un processus de développement de logiciels performant.

Reconnaître le travail de documentation lors des évaluations de performance et des promotions. La reconnaissance peut être mise en corrélation avec la qualité globale de la documentation. L'écriture et la maintenance des documents constituent une partie intégrante du travail d'ingénierie logicielle, et les traiter comme telles en améliore la qualité.

D'autres ressources que nous avons trouvées en faveur d'une documentation de qualité incluent :

• une formation pour apprendre à écrire et actualiser la documentation ;
• l'exécution de tests automatiques pour les exemples de code ou les documents incomplets ;
• la formulation de consignes telles que les guides de style portant sur la documentation et les guides de rédaction destinés à un public général.

La documentation est fondamentale pour réussir la mise en œuvre des fonctionnalités DevOps. Une documentation de qualité supérieure multiplie les résultats des investissements dans les capacités DevOps individuelles comme la sécurité et la fiabilité, tout en tirant pleinement parti du cloud. Mettre en œuvre des pratiques favorisant une documentation de qualité s'avère payant grâce au renforcement des capacités techniques et à l'augmentation des performances de SDO.

____________________________

5. Mesures de la qualité d'après des recherches existantes sur la documentation technique, telles que :

Aghajani, E. et al. Software Documentation Issues Unveiled. Proceedings of the 2019 IEEE/ACM 41st International Conference on Software Engineering, 1199-1210. https://doi.org/10.1109/ICSE.2019.00122

Plösch, R., Dautovic, A., & Saft, M. (2014). The Value of Software Documentation Quality. Proceedings of the International Conference on Quality Software, 333-342. https://doi.org/10.1109/QSIC.2014.22

Zhi, J. et al. Cost benefits and quality of software development documentation: A systematic mapping. Journal of Systems and Software, 99(C), 175-198. https://doi.org/10.1016/j.jss.2014.09.042

____________________________

Sécurité

[Anticipation] et intégration de bout en bout

À mesure que les équipes technologiques continuent de progresser et d'évoluer, il en va de même pour la quantité et la sophistication des menaces de sécurité. En 2020, plus de 22 milliards de dossiers contenant des informations personnelles confidentielles ou des données commerciales ont été exposés, selon le rapport 2020 Threat Landscape Retrospective Report (Rapport rétrospectif sur le paysage des menaces) de Tenable.⁶ La sécurité ne peut pas être prise en compte après coup ou lors de l'étape finale avant la livraison. Elle doit être intégrée à tout le processus de développement logiciel.

Afin de livrer des logiciels en toute sécurité, les pratiques de sécurité doivent évoluer plus rapidement que les techniques utilisées par les acteurs malveillants. En 2020, lors des attaques sur la chaîne d'approvisionnement de SolarWinds et Codecov, les pirates informatiques ont compromis le système de compilation de SolarWinds et le script Bash Uploader de Codecov⁷ pour s'infiltrer secrètement dans l'infrastructure de milliers de clients de ces entreprises. Compte tenu de l'impact généralisé de ces attaques, le secteur doit passer d'une approche préventive à une approche diagnostique, où les équipes logicielles doivent partir du principe que leurs systèmes sont déjà compromis et intégrer la sécurité à leur chaîne d'approvisionnement.

Tout comme dans les rapports précédents, nous avons trouvé que les entreprises les plus performantes excellent dans la mise en œuvre de pratiques de sécurité. Cette année, les meilleurs éléments qui ont atteint ou dépassé leurs objectifs de fiabilité étaient deux fois plus susceptibles d'avoir intégré la sécurité à leur processus de développement logiciel. Cela indique que les équipes qui ont accéléré la livraison tout en préservant leurs critères de fiabilité ont trouvé le moyen d'intégrer les contrôles et pratiques de sécurité sans compromettre leur capacité à livrer des logiciels de façon rapide et fiable.

En plus d'assurer des performances de livraisons de logiciels et opérationnelles élevées, les équipes qui intègrent des pratiques de sécurité tout au long de leur processus de développement ont 1,6 fois plus de chances d'atteindre ou de dépasser leurs objectifs organisationnels. Les équipes de développement qui adoptent ces pratiques de sécurité constatent qu'une valeur significative est apportée à l'entreprise.

____________________________

6. https://www.tenable.com/cyber-exposure/2020-threat-landscape-retrospective

7. https://www.cybersecuritydive.com/news/codecov-breach-solarwinds-software-supply-chain/598950/

____________________________

Comment ne pas commettre d'erreurs

Il est facile de souligner l'importance de la sécurité et de conseiller aux équipes d'y mettre l'accent, mais cela exige d'opérer plusieurs changements par rapport aux méthodes classiques de sécurité des informations. Vous pouvez intégrer la sécurité, améliorer les performances de livraison de logiciels et opérationnelles, et stimuler les performances organisationnelles en tirant parti des pratiques suivantes :

Tester la sécurité. Intégrez les exigences de sécurité dans le processus de tests automatisés, y compris dans les domaines qui imposent l'utilisation d'un code préapprouvé.

Intégrer un examen de sécurité à chaque phase. Associez la sécurité des informations (InfoSec) au travail quotidien sur l'ensemble du cycle de livraison des logiciels. Cela implique que l'équipe Infosec apporte sa contribution lors des phases de conception et d'architecture de l'application, assiste aux démonstrations de logiciels et transmette ses commentaires lors des démonstrations.

Réaliser des examens de sécurité. Effectuez un examen de sécurité pour toutes les fonctionnalités principales. Créer un code préapprouvé. Demandez à l'équipe InfoSec de créer des bibliothèques, des packages, des chaînes d'outils et des processus préapprouvés faciles d'utilisation que les développeurs et les agents informatiques pourront utiliser dans leur travail. Impliquer l'équipe InfoSec plus tôt et plus souvent. Incluez l'équipe InfoSec lors de la planification et de toutes les phases ultérieures du développement de l'application, afin qu'elle puisse repérer rapidement les faiblesses liées à la sécurité et donner à l'équipe suffisamment de temps pour les corriger.

Créer un code préapprouvé. Demandez à l'équipe InfoSec de créer des bibliothèques, des packages, des chaînes d'outils et des processus préapprouvés faciles d'utilisation que les développeurs et les agents informatiques pourront utiliser dans leur travail.

Impliquer l'équipe InfoSec plus tôt et plus souvent. Incluez l'équipe InfoSec lors de la planification et de toutes les phases ultérieures du développement de l'application, afin qu'elle puisse repérer rapidement les faiblesses liées à la sécurité et donner à l'équipe suffisamment de temps pour les corriger.

Comme nous l'avons précédemment mentionné, une documentation de haute qualité favorise la réussite d'un certain nombre de capacités, et la sécurité ne fait pas exception. Nous avons découvert que les équipes bénéficiant d'une documentation hautement qualitative étaient 3,8 fois plus susceptibles d'intégrer la sécurité tout au long de leur processus de développement. Tous les employés d'une entreprise ne possèdent pas une expérience en cryptographie. C'est pourquoi des pratiques de sécurité documentées permettent de mieux transmettre l'expertise des personnes qui s'y connaissent au sein de l'organisation.

Notre étude indique que les organisations qui entreprennent une transformation DevOps en adoptant la livraison continue sont plus susceptibles de disposer de procédures rentables, hautement qualitatives et à faible risque.

Nous avons mesuré en particulier les pratiques techniques suivantes :

• Architecture faiblement couplée.
• Développement à branche unique
• Tests continus
• Intégration continue
• Utilisation de technologies Open Source
• Pratiques de surveillance et d'observabilité
• Gestion des modifications des bases de données
• Automatisation des déploiements

Nous avons découvert que si toutes ces pratiques améliorent la livraison continue, l'architecture faiblement couplée et les tests continus génèrent le plus grand impact. Par exemple, cette année, nous avons constaté que les entreprises les plus performantes qui atteignent leurs objectifs de fiabilité sont trois fois plus susceptibles d'utiliser une architecture faiblement couplée que leurs homologues moins performantes.

Architecture faiblement couplée

Nos recherches continuent de montrer que vous pouvez améliorer les performances informatiques en vous efforçant de réduire les dépendances étroites entre les services et les équipes. En fait, il s'agit de l'un des meilleurs indicateurs de réussite de la livraison continue. En ayant recours à une architecture faiblement couplée, les équipes peuvent évoluer, connaître des échecs, conduire des tests et effectuer des déploiements indépendamment les unes des autres. Elles sont capables d'avancer à leur propre rythme, de fractionner leur travail, d'accumuler moins de dettes techniques et de se remettre plus rapidement des échecs.

Tests et intégration continus

Comme les années précédentes, nous avons déterminé que les tests continus représentent un bon indicateur de réussite de la livraison continue. Les entreprises les plus performantes qui atteignent leurs objectifs de fiabilité sont 3,7 fois plus susceptibles de tirer parti des tests continus. En intégrant les tests tôt et à intervalles réguliers dans l'ensemble du processus de livraison, et en faisant travailler les testeurs aux côtés des développeurs de bout en bout, les équipes peuvent itérer et modifier leur produit, service ou application plus rapidement. Vous pouvez utiliser cette boucle de rétroaction pour proposer de la valeur à vos clients tout en intégrant facilement des pratiques telles que les tests automatiques et l'intégration continue.

L'intégration continue améliore également la livraison continue. Les entreprises les plus performantes qui atteignent leurs objectifs de fiabilité sont 5,8 fois plus à même d'exploiter l'intégration continue. Lors de l'intégration continue, chaque commit déclenche une compilation du logiciel et exécute une série de tests automatiques qui permettent de recueillir des commentaires en quelques minutes. Avec l'intégration continue, vous dépendez moins de la coordination manuelle souvent complexe nécessaire à une intégration réussie.

L'intégration continue, telle que définie par Kent Beck et la communauté d'Extreme Programming à l'origine du terme, inclut également la pratique du développement à branche unique décrite ci-dessous.⁷

Développement à branche unique

Notre recherche a plusieurs fois démontré que les entreprises les plus performantes sont plus susceptibles d'avoir mis en œuvre un développement à branche unique, lors duquel les développeurs travaillent par petits lots et fusionnent fréquemment leur travail avec une branche principale partagée. De fait, les entreprises les plus performantes qui atteignent leurs objectifs de fiabilité sont 2,3 fois plus enclines à avoir recours au développement à branche unique. Leurs homologues les moins performantes utilisent plutôt des branches de longue durée et retardent les fusions.

Les équipes devraient fusionner leur travail au moins une fois par jour (plusieurs fois si possible). Le développement à branche unique est étroitement lié à l'intégration continue. Par conséquent, nous vous conseillons de mettre en œuvre ces deux pratiques techniques simultanément, car elles sont plus efficaces lorsqu'elles sont utilisées ensemble.

Automatisation des déploiements

Dans un environnement de travail idéal, les ordinateurs exécutent des tâches répétitives tandis que les humains se concentrent sur la résolution de problèmes. Mettre en œuvre l'automatisation des déploiements aide vos équipes à se rapprocher de cet objectif.

Lorsque vous faites passer un logiciel de la phase de test à celle de production de manière automatisée, vous réduisez le délai de livraison en permettant des déploiements plus rapides et efficaces. Vous limitez également le risque d'erreurs de déploiement, qui surviennent plus fréquemment lors des déploiements manuels. Quand vos équipes ont recours à l'automatisation des déploiements, elles reçoivent des commentaires immédiats qui peuvent vous aider à améliorer votre service ou produit beaucoup plus vite. Bien que vous ne soyez pas tenu d'implémenter les tests continus, l'intégration continue et l'automatisation des déploiements simultanément, vous devriez bénéficier d'améliorations plus importantes si vous combinez ces trois pratiques.

Gestion du changement des bases de données

Effectuer le suivi des modifications grâce au contrôle des versions constitue un élément essentiel de l'écriture et de la gestion du code, tout comme de celle des bases de données. Notre étude indique que les entreprises les plus performantes qui atteignent leurs objectifs de fiabilité sont 3,4 fois plus susceptibles d'assurer la gestion du changement des bases de données que leurs homologues moins performantes. De plus, une bonne gestion du changement des bases de données réside dans la collaboration, la communication et la transparence entre toutes les équipes concernées. Même si vous pouvez choisir de mettre en œuvre diverses approches disponibles, nous vous conseillons, lorsque vous devez apporter des modifications à votre base de données, de vous réunir en équipe et de passer en revue les modifications ensemble avant de mettre à jour la base.

____________________________

8. Beck, K. (2000). Extreme programming explained: Embrace change. Addison-Wesley Professional

____________________________

Surveillance et observabilité

Comme les années précédentes, nous avons découvert que les pratiques de surveillance et d'observabilité favorisent la livraison continue. Les entreprises les plus performantes qui atteignent leurs objectifs de fiabilité sont 4,1 fois plus susceptibles de posséder des solutions qui intègrent l'observabilité à l'état global du système. Les pratiques d'observabilité offrent à vos équipes une meilleure compréhension de vos systèmes, ce qui limite alors le temps nécessaire pour identifier et résoudre les problèmes. Notre recherche indique également que les équipes qui ont mis en place des pratiques d'observabilité efficaces passent plus de temps à coder. Cela tient peut-être dans le fait que la mise en œuvre de pratiques d'observabilité aide les développeurs à passer moins de temps à rechercher l'origine des problèmes afin d'en consacrer plus à leur résolution et, pour finir, au codage.

Technologies Open Source

De nombreux développeurs tirent déjà parti des technologies Open Source, et leur familiarité avec ces outils constitue un avantage pour l'entreprise. L'une des principales faiblesses des technologies provenant de sources fermées réside dans le fait qu'elles limitent votre capacité à transférer les connaissances à l'intérieur et à l'extérieur de l'organisation. Par exemple, vous ne pouvez pas recruter une personne qui connaît déjà les outils de votre entreprise, et les développeurs ne peuvent pas transférer les connaissances qu'ils ont accumulées à d'autres organisations. À l'inverse, la plupart des technologies Open Source possèdent une communauté spécialisée vers laquelle les développeurs peuvent se tourner pour obtenir de l'aide. Les technologies Open Source sont plus largement accessibles, relativement économiques et personnalisables. Les entreprises les plus performantes qui atteignent leurs objectifs de fiabilité sont 2,4 fois plus susceptibles d'exploiter les technologies Open Source. Nous vous conseillons d'utiliser davantage les logiciels Open Source à mesure que vous mettez en œuvre votre transformation DevOps.

Pour plus d'informations sur les capacités techniques du DevOps, consultez les capacités DORA sur la page https://cloud.google.com/devops/capabilities

COVID-19

Cette année, nous avons étudié les facteurs qui ont influencé les performances des équipes pendant la pandémie de COVID-19. Plus particulièrement : la pandémie de COVID-19 a-t-elle nui aux performances de livraison de logiciels et opérationnelles (SDO) ? Les équipes sont-elles davantage surmenées en conséquence ? Enfin, quels sont les facteurs prometteurs permettant d'atténuer le surmenage ?

Pour commencer, nous avons cherché à comprendre l'impact de la pandémie sur les performances de livraison de logiciels et opérationnelles. De nombreuses entreprises ont privilégié la modernisation afin de s'adapter aux changements drastiques du marché (par exemple, le passage des achats physiques aux achats en ligne). Dans le chapitre "Quelles sont vos performances ?", nous examinons comment les performances de l'industrie logicielle se sont accélérées et continuent de croître. Les équipes les plus performantes représentent maintenant la majorité de notre échantillon, et ces bons éléments continuent à élever le niveau. En effet, ils déploient plus souvent avec des délais de livraison plus courts, des délais de restauration plus rapides et des taux d'échecs après modification améliorés. De même, une étude conduite par les chercheurs GitHub a révélé une augmentation de l'activité des développeurs (c'est-à-dire, les transferts, les demandes d'extraction, les demandes d'extraction examinées et les requêtes commentées par les utilisateurs⁹) au cours de l'année 2020. On peut conclure que le secteur a continué à se développer malgré la pandémie, plutôt qu'à cause d'elle, mais il convient de noter que nous n'avons pas observé de tendance à la baisse des performances SDO pendant cette période compliquée.

La pandémie a changé notre manière de travailler, et pour beaucoup, notre lieu de travail. C'est pourquoi nous nous sommes intéressés à l'impact du télétravail en tant que conséquence de la pandémie. Nous avons découvert que 89 % des personnes interrogées ont télétravaillé en raison de la pandémie. Seulement 20 % déclarent avoir déjà travaillé de chez elles avant la pandémie. Le passage à un environnement de travail à distance a eu des répercussions importantes sur notre façon de développer des logiciels, de gérer nos entreprises et de travailler ensemble. Pour beaucoup, le télétravail nous a par exemple empêchés de pouvoir échanger lors de conversations impromptues dans les couloirs ou de collaborer en personne.

____________________________

9. https://octoverse.github.com/

____________________________

Qu'est-ce qui a permis d'atténuer le surmenage ?

Malgré cela, nous avons identifié un facteur qui influençait considérablement le fait qu'une équipe soit confrontée ou non au surmenage en raison du travail à distance : la culture. Les équipes présentant une culture d'équipe générative, composées de personnes éprouvant un sentiment d'inclusion et d'appartenance, étaient deux fois moins susceptibles d'être confrontées au surmenage pendant la pandémie. Cette constatation renforce l'importance de donner la priorité à l'équipe et à la culture. Les équipes qui s'en sortent mieux sont à même de surmonter des périodes plus difficiles qui fragilisent à la fois le collectif et les individus.

Culture

De manière générale, la culture est un processus sous-jacent inéluctable qui met en relation les personnes au sein de chaque organisation. Elle rassemble tout ce qui peut influencer la pensée, le ressenti et le comportement des employés envers l'entreprise et les uns les autres. Toutes les structures possèdent leur propre culture unique, et nos recherches démontrent invariablement qu'elle constitue l'un des principaux moteurs des performances organisationnelles et informatiques. Pour rentrer dans les détails, nos analyses indiquent qu'une culture générative (mesurée à l'aide de la typologie de la culture organisationnelle de Westrum et du sentiment d'appartenance et d'inclusion des personnes au sein de l'entreprise) entraîne des performances opérationnelles et de livraison de logiciels (SDO) supérieures. Par exemple, nous avons découvert que les entreprises les plus performantes qui répondent à leurs objectifs de fiabilité sont 2,9 fois plus susceptibles de posséder une culture d'équipe générative que leurs homologues moins performantes. De même, une culture générative génère de meilleures performances organisationnelles et un taux de surmenage inférieur. En résumé, la culture est très importante. Heureusement, la culture évolue, prend plusieurs formes et se trouve toujours en mouvement. C'est donc un élément que vous pouvez modifier.

Pour que votre entreprise réussisse l'exécution du DevOps, vos équipes doivent travailler en collaboration avec d'autres départements. En 2018, nous avons découvert que les entreprises aux performances élevées étaient deux fois plus à même de développer et de livrer un logiciel si elles travaillent dans une équipe pluridisciplinaire unique. Cela permet de réaffirmer l'importance capitale de la collaboration et la coopération dans la réussite de n'importe quelle entreprise. Une question essentielle se pose : quels facteurs contribuent à la création d'un environnement qui favorise et récompense la collaboration pluridisciplinaire ?

Au fil des années, nous avons essayé de rendre le concept de culture tangible et de fournir à la communauté DevOps une meilleure compréhension de son impact sur les performances organisationnelles et informatiques. Pour commencer dans cette démarche, nous avons défini la culture en termes d'opérations, à l'aide de la typologie de la culture organisationnelle de Westrum. Il a identifié trois types d'entreprises : les organisations orientées vers le pouvoir, les règles et les performances. Nous nous sommes basés sur ce framework pour notre propre recherche et avons déterminé qu'une culture organisationnelle orientée vers les performances qui optimise le flux d'informations, la confiance, l'innovation et le partage des risques favorise des performances SDO élevées.

À mesure que notre compréhension de la culture et du DevOps évolue, nous œuvrons pour élargir notre définition initiale afin d'inclure d'autres facteurs psychosociaux comme la sécurité psychologique. Les entreprises aux performances élevées sont plus susceptibles de posséder une culture qui encourage les employés à prendre des risques calculés et modérés sans craindre de conséquences négatives.

Sentiment d'appartenance et inclusion

Étant donné l'influence forte et constante de la culture sur les performances, nous avons élargi notre modèle cette année afin de déterminer si le sentiment d'appartenance et d'inclusion des employés contribue à l'effet positif de la culture sur les performances.

Des recherches psychologiques ont montré que les gens sont intrinsèquement motivés à former et à entretenir des relations fortes et stables avec les autres^10. Nous souhaitons nous sentir liés aux autres et acceptés par les différents groupes auxquels nous appartenons. Le sentiment d'appartenance entraîne un large éventail de réponses physiques et psychologiques positives. Notre recherche indique par exemple que le sentiment d'appartenance affecte positivement la motivation et favorise l'amélioration des résultats scolaires¹¹.

L'une des composantes de ce sentiment d'adhésion est l'idée selon laquelle les individus doivent se sentir autorisés à être eux-mêmes au travail, et que leurs expériences ainsi que leurs parcours personnels doivent être valorisés et reconnus^12. Chercher à créer des cultures d'appartenance inclusives au sein des entreprises donne naissance à une main-d'œuvre prospère, diverse et motivée.

Nos résultats indiquent que les entreprises orientées vers la performance qui se préoccupent du sentiment d'appartenance et de l'inclusion sont plus susceptibles de présenter de faibles niveaux de surmenage que celles démontrant une culture organisationnelle moins positive.

Compte tenu des preuves montrant la manière dont les facteurs psychosociaux affectent les performances SDO et les niveaux de surmenage des employés, nous vous recommandons, si vous cherchez à réussir votre transformation DevOps, d'investir dans la résolution des problèmes liés à la culture dans le cadre de vos efforts de transformation.

____________________________

10. Baumeister & Leary, 1995. The need to belong: Desire for interpersonal attachments as a fundamental human motivation. Psychological Bulletin, 117(3), 497–529. https://doi.org/10.1037/0033-2909.117.3.497

11. Walton et al., 2012. Mere belonging: the power of social connections. Journal of Personality and Social Psychology, 102(3):513-32. https://doi.org/10.1037/a0025731

12. Mor Barak & Daya, 2014; Managing diversity: Toward a globally inclusive workplace. Sage. Shore, Cleveland, & Sanchez, 2018; Inclusive workplaces: A review and model, Human Resources Review. https://doi.org/10.1016/j.hrmr.2017.07.003

Basé sur sept ans de recherches et plus de 32 000 réponses recueillies auprès de professionnels du secteur, le rapport Accelerate sur l'état du DevOps en 2021 décrit les pratiques de développement logiciel et de DevOps qui favorisent la réussite des équipes et des entreprises. 

Cette année, 1 200 professionnels de divers secteurs à travers le monde ont partagé leurs expériences pour nous aider à mieux comprendre les facteurs à l'origine de meilleures performances. En résumé, la représentation tirée des diverses données démographiques et sur les entreprises est restée remarquablement cohérente.

Comme les années précédentes, nous avons recueilli les données démographiques de chaque personne qui a répondu à l'étude. Les catégories sont les suivantes : le genre, le handicap et les groupes sous-représentés.

Données sur les entreprises et démographiques

Cette année, nous avons constaté une représentation cohérente avec les rapports précédents dans les catégories se rapportant à l'entreprise, comme la taille, le secteur d'activité et la région. À nouveau, plus de 60 % des personnes interrogées occupent des postes d'ingénieurs ou de responsables, et un tiers travaillent dans le secteur de la technologie. En outre, les secteurs des services financiers, du commerce et des entreprises industrielles et manufacturières sont représentés. 

____________________________

13. https://www.washingtongroup-disability.com/question-sets/wg-short-set-on-functioning-wg-ss/

____________________________

Genre

Comme pour les enquêtes précédentes, l'échantillon de cette année se compose de 83 % d'hommes, 12 % de femmes et 1 % de personnes non binaires. Les individus interrogés ont déclaré que les femmes représentaient environ 25 % de leurs équipes, soit une forte hausse par rapport à 2019 (16 %), et équivalent à 2018 (25 %).

Handicap

Le handicap est identifié selon six aspects correspondant aux directives du Washington Group Short Set¹³. C'est la troisième année que nous posons des questions sur le handicap. Le pourcentage de personnes ayant un handicap était cohérent avec notre rapport de 2019, soit 9 %.

Groupes sous-représentés

S'identifier comme membre d'un groupe sous-représenté peut faire référence au groupe ethnique, au sexe ou à une autre caractéristique. Nous posons des questions sur la sous-représentation pour la quatrième année. Le pourcentage d'individus qui s'identifient comme sous-représentés a légèrement augmenté, passant de 13,7 % en 2019 à 17 % en 2021.

Années d'expérience

Les personnes qui ont participé à l'enquête cette année bénéficient d'une grande expérience (41 % d'entre eux possèdent au moins 16 ans d'expérience). Plus de 85 % des personnes interrogées avaient au moins 6 ans d'expérience.

Services

Les personnes interrogées regroupent principalement des individus travaillant dans des équipes de développement ou d'ingénierie (23 %), des équipes DevOps ou SRE (21 %), des responsables (18 %), ainsi que des équipes chargées des opérations informatiques ou de l'infrastructure (9 %). Nous avons constaté une baisse de la représentation des consultants (4 % en 2019 contre 2 %) et une hausse de celle des cadres dirigeants (4 % en 2019 contre 9 %). 

Secteur d'activité

Comme dans les rapports Accelerate sur l'état du DevOps précédents, nous constatons que la plupart des personnes interrogées travaillent dans le secteur de la technologie, suivi par les services financiers, le commerce, puis d'autres.

Employés

Tout comme dans les précédents rapports Accelerate sur l'état du DevOps, les personnes interrogées sont issues d'entreprises de tailles diverses. Environ 22 % d'entre elles travaillent dans des organisations de plus de 10 000 employés et 7 % dans des entreprises possédant entre 5 000 et 9 999 employés. Par ailleurs, 15 % des personnes interrogées travaillent dans des organisations comptant entre 2 000 et 4 999 employés. Nous avons également constaté une bonne représentation de personnes d'organisations de 500 à 1 999 employés (13 %), 100 à 499 employés (15 %) et 20 à 99 employés (15 %). 

Taille des équipes

Plus de la moitié des personnes interrogées (62 %) travaillent dans des équipes composées de 10 membres ou moins (28 % pour la tranche 6–10, 27 % pour la tranche 2–5 et 6 % pour les équipes d'une personne). De plus, 19 % d'entre eux font partie d'une équipe de 11 à 20 membres.

Régions

Dans l'enquête de cette année, nous constatons une diminution des réponses provenant d'Amérique du Nord (50 % en 2019 contre 39 % en 2021). À l'inverse, la représentation a augmenté en Europe (29 % 2019 contre 32 % en 2021), en Asie (9 % en 2019 contre 13 % en 2021), en Océanie (4 % en 2019 contre 6 % en 2021) et en Amérique du Sud (2 % en 2019 contre 4 % en 2021).

Systèmes d'exploitation

La répartition des systèmes d'exploitation était également cohérente avec celle décrite dans les précédents rapports sur l'état du DevOps. Nous saluons et remercions aussi les personnes qui nous ont signalé que notre liste de systèmes d'exploitation avait besoin d'être actualisée. 

Cette année, nous avons étudié l'emplacement où les personnes interrogées déploient le service ou l'application principale sur lequel ou laquelle elles travaillent. Nous avons été surpris de constater qu'une grande partie d'entre elles ont recours aux conteneurs (64 %), avec 48 % qui utilisent des machines virtuelles (VM). Cela pourrait refléter une évolution du secteur vers des technologies de cibles de déploiement plus modernes. Nous avons comparé les différences entre les entreprises de diverses tailles et n'avons pas trouvé de variations significatives entre les cibles de déploiement.

Les équipes qui adoptent les principes et fonctionnalités du DevOps peuvent livrer des logiciels de façon plus rapide et fiable, tout en apportant directement de la valeur à leur entreprise. Cette année, nous avons observé les effets des pratiques SRE, d'une chaîne d'approvisionnement logicielle sécurisée et d'une documentation de qualité. De plus, nous avons réexaminé notre étude de l'exploitation du cloud. Chaque domaine permet aux individus et aux équipes de gagner en efficacité. Nous nous sommes concentrés sur l'importance de structurer des solutions qui correspondent aux individus tirant parti de ces capacités, plutôt que d'adapter les gens à la solution.

Nous remercions toutes les personnes qui ont contribué à l'enquête de cette année et espérons que nos recherches vous aideront ainsi que votre entreprise à créer des équipes et des logiciels plus performants (tout en préservant l'équilibre travail-vie personnelle).

Le rapport de cette année a été rendu possible grâce à de nombreux participants passionnés. Nos collègues nous ont aidés à réaliser ce travail considérable notamment par l'élaboration des questions, l'analyse, la rédaction, la correction et la conception du rapport. Les auteurs aimeraient remercier toutes les personnes qui leur ont fait part de leurs commentaires et conseils sur le rapport tout au long de l'année. Tous les remerciements sont formulés par ordre alphabétique.

Dustin Smith

Dustin Smith est psychologue spécialisé dans les facteurs humains et responsable de recherche en expérience utilisateur chez Google. Il travaille sur le projet DORA depuis trois ans. Ces sept dernières années, il a étudié la manière dont les individus sont affectés par les systèmes et environnements qui les entourent dans différents contextes : l'ingénierie logicielle, le jeu gratuit, la santé et l'armée. Ses recherches chez Google identifient des domaines permettant aux développeurs de se sentir plus heureux et de gagner en productivité lors du développement. Il travaille sur le projet DORA depuis deux ans. Dustin est diplômé d'un doctorat en psychologie des facteurs humains de l'université d'État de Wichita.

Daniella Villalba

Daniella Villalba est chercheuse en expérience utilisateur et se consacre au projet DORA. Elle s'attache à comprendre les facteurs qui rendent les développeurs heureux et productifs. Avant de travailler pour Google, Daniella a étudié les avantages de la formation à la méditation, les facteurs psychosociaux qui affectent les expériences des étudiants, la mémoire des témoins oculaires et les faux aveux. Elle est docteure en psychologie expérimentale à l'université internationale de Floride. 

Michelle Irvine

Michelle Irvine est rédactrice technique chez Google, où elle cherche à rapprocher les outils pour les développeurs des personnes qui les utilisent. Avant de rejoindre Google, elle travaillait dans l'édition pédagogique et en tant que rédactrice technique pour des logiciels de simulation physique. Michelle possède une licence (BS) en sciences physiques, ainsi qu'une maîtrise (MA) en rhétorique et conception de la communication de l'université de Waterloo.

Dave Stanke

Dave Stanke est responsable des relations avec les développeurs chez Google où il conseille les clients sur les pratiques facilitant l'adoption du DevOps et de la SRE. Tout au long de sa carrière, il a porté de nombreuses casquettes, y compris directeur de la technologie d'une start-up, responsable produit, membre du service client, développeur logiciel, administrateur système et graphiste. Il est titulaire d'un master en gestion de la technologie de l'université de Columbia. 

Nathen Harvey

Nathen Harvey est responsable des relations avec les développeurs chez Google. Il a construit sa carrière en aidant les équipes à réaliser leur potentiel tout en alignant la technologie sur les résultats commerciaux. Nathen a eu la chance de travailler avec certaines des meilleures équipes et communautés Open Source, les accompagnant dans l'application des principes et pratiques du DevOps et de SRE. Nathen a co-édité et contribué à l'ouvrage "97 Things Every Cloud Engineer Should Know," O’Reilly 2020.

Conception de la recherche

Cette étude utilise une conception transversale, basée sur la théorie. Celle-ci est connue sous le nom de prédiction inférentielle. Il s'agit aujourd'hui de l'un des types de recherche les plus courants dans le domaine des entreprises et de la technologie. La conception inférentielle est utilisée lorsque la conception purement expérimentale n'est pas possible et que les expériences sur le terrain sont préférables.

Population cible et échantillonnage

Notre population cible pour cette enquête se compose d'utilisateurs et de responsables qui travaillent dans les secteurs de la technologie et des transformations (ou en lien étroit avec ceux-ci), et en particulier ceux qui connaissent le DevOps. Nous avons fait la promotion de l'enquête via des listes de diffusion, des promotions en ligne, un panel en ligne, les réseaux sociaux, et nous avons demandé aux gens de partager l'enquête avec leurs réseaux (échantillonnage en boule de neige).

Création de constructions latentes

Nous avons formulé nos hypothèses et idées à l'aide de constructions précédemment vérifiées lorsque cela était possible. Nous avons développé de nouvelles constructions basées sur la théorie, des définitions et des avis d'experts. Nous avons ensuite réalisé des étapes supplémentaires pour clarifier l'intention afin de nous assurer que les données recueillies grâce à l'enquête soient véritablement susceptibles d'être fiables et valables.¹⁴

Méthodes d'analyse statistique

Analyse par cluster. Nous avons utilisé l'analyse par cluster pour identifier nos profils de performance en livraison de logiciels selon la fréquence de déploiement, le délai de livraison, le délai de restauration du service et le taux d'échec de la modification. Nous avons eu recours à une analyse par classe latente¹⁵, car nous n'avions pas de raisons sectorielles ou théoriques d'utiliser un nombre prédéterminé de clusters. Nous avons donc opté pour le critère d'information bayésien16 afin de déterminer le nombre optimal de clusters.

Modèle de mesure. Avant d'effectuer l'analyse, nous avons identifié des constructions à l'aide d'une analyse factorielle exploratoire¹⁷. Nous avons confirmé les tests statistiques de validité et fiabilité convergentes et divergentes avec la variance moyenne extraite (AVE, Average Variance Extracted), la corrélation, le coefficient alpha de Cronbach¹⁸ et la fiabilité composite.

Modélisation par équation structurelle. Nous avons testé les modèles d'équation structurelle (SEM, Structural Equation Models) en utilisant l'analyse de régression par moindres carrés partiels, qui est un SEM basé sur la corrélation¹⁹.

^{________________________}

14. Churchill Jr, G. A. “A paradigm for developing better measures of marketing constructs,” Journal of Marketing Research 16:1, (1979), 64–73.

15. Hagenaars, J. A., & McCutcheon, A. L. (Eds.). (2002). Applied latent class analysis. Cambridge University Press.

16. Vrieze, S. I. (2012). Model selection and psychological theory: a discussion of the differences between the Akaike information criterion (AIC) and the Bayesian information criterion (BIC). Psychological methods, 17(2), 228.

17. Straub, D., Boudreau, M. C., & Gefen, D. (2004). Validation guidelines for IS positivist research. Communications of the Association for Information systems, 13(1), 24.

18. Nunnally, J.C. Psychometric Theory. New York: McGraw-Hill, 1978

19. Hair Jr, J. F., Hult, G. T. M., Ringle, C. M., & Sarstedt, M. (2021). “A primer on partial least squares structural equation modeling (PLS-SEM).” Sage publications

Obtenez plus d'informations sur les capacités DevOps sur la page https://cloud.google.com/devops/capabilities

Obtenez des ressources sur l'ingénierie en fiabilité des sites (SRE) sur la page :

https://sre.google

Participez à l'évaluation rapide DevOps :

https://www.devops-research.com/quickcheck.html

Découvrez le programme de recherche DevOps :

https://www.devops-research.com/research.html

Découvrez le programme de modernisation des applications de Google Cloud :

https://cloud.google.com/solutions/camp

Consultez le livre blanc "ROI de la transformation DevOps : comment quantifier l'impact de vos initiatives de modernisation" :

https://cloud.google.com/resources/roi-of-devops-transformation-whitepaper

Consultez les rapports précédents sur l'état du DevOps :

Rapport sur l'état du DevOps en 2014 : https://services.google.com/fh/files/misc/state-of-devops-2014.pdf

Rapport sur l'état du DevOps en 2015 : https://services.google.com/fh/files/misc/state-of-devops-2015.pdf

Rapport sur l'état du DevOps en 2016 : https://services.google.com/fh/files/misc/state-of-devops-2016.pdf

Rapport sur l'état du DevOps en 2017 : https://services.google.com/fh/files/misc/state-of-devops-2017.pdf

Rapport Accelerate sur l'état du DevOps en 2018 : https://services.google.com/fh/files/misc/state-of-devops-2018.pdf

Rapport Accelerate sur l'état du DevOps en 2019 :

https://services.google.com/fh/files/misc/state-of-devops-2019.pdf