Rapport annuel DevOps Azure

Rapport Enterprise DevOps

2020-21
Rapport Enterprise DevOps 2020-21 2

Table des matières

Résumé 3

Présentation d'Enterprise DevOps 6

L'indice de rapidité de développement (IRD) 9

Gestion des produits 11

Équipes distribuées et télétravail 17

Gouvernance 23

Qualité 30

Sécurité 38

Conformité 45

Conclusion 50

Auteurs 52

Méthodes de recherche, Références supplémentaires 53

Rapport Enterprise DevOps 2020-21
Résumé
De nombreuses entreprises en pleine transformation
numérique adoptent DevOps comme nouveau
modèle opérationnel informatique, car leurs services
informatiques existants se sont révélés incapables de
s'adapter aux besoins opérationnels et à ceux des clients.
Microsoft définit DevOps comme «  l’association de
personnes, de processus et de technologie qui permet de
proposer une plus-value en continu aux clients ».
DevOps réunit le développement logiciel (Dev) et les
opérations informatiques (Ops) en équipes alignées sur
les besoins des entreprises, des produits et des clients. Il
s'agit d'un changement majeur par rapport aux pratiques
informatiques traditionnelles, qui reposent sur le fait
que les spécialistes techniques (développeurs, testeurs,
administrateurs de base de données et de systèmes)
sont considérés comme des silos fonctionnant de
manière indépendante. L’objectif ultime de DevOps est
de permettre aux entreprises de mettre plus rapidement
leurs idées de produits sur le marché, sans sacrifier la
stabilité ou la sécurité de leurs systèmes de production.
3
Les origines de DevOps remontent à des entreprises
axées sur la technologie et natives du numérique, comme
Netflix, Spotify et Facebook, et ses pratiques ont évolué
avec leurs architectures techniques et leurs conceptions
organisationnelles au fur et à mesure que ces entreprises
se développaient. Toutefois, la plupart des entreprises
doivent transformer leurs collaborateurs, leurs processus
et leurs technologies existants pour adopter DevOps.
En avril 2020, McKinsey, cherchant alors à trouver des
moyens concrets d’évaluer la façon dont les principaux
indicateurs de performance ont été améliorés grâce
à  l’innovation en matière de développement logiciel, a
créé le concept d'indice de rapidité de développement
(IRD)1. L'IRD est un indicateur qui « identifie les facteurs les
plus critiques (concernant la technologie, les pratiques de
travail et la capacité organisationnelle) pour atteindre la
rapidité de développement souhaitée ». Parvenir à cette
rapidité de développement ne consiste pas seulement
à augmenter la rapidité de livraison, mais aussi à laisser
libre cours à l’ingéniosité des développeurs pour résoudre
des problèmes commerciaux complexes, à l’aide de
nouvelles technologies et méthodes de travail pour créer
des logiciels qui répondent aux besoins des clients de
l’entreprise, tout en atteignant les objectifs commerciaux
visés. L'IRD est un indicateur composite de 46 facteurs
clés qui influent la rapidité de développement.
Rapport Enterprise DevOps 2020-21 4

Les informations clés tirées de l’étude IRD sont les suivantes :

• L’indice de vélocité de développement (IRD) est en forte corrélation avec la réussite de l’entreprise.
Les entreprises dont le score IRD se situe dans le quartile supérieur surpassent de 4 à 5 fois plus les
entreprises du quartile inférieur.
• Les outils de développement, qui comprennent la collaboration, le développement, DevOps et les outils
de planification, ont la plus grande importance relative dans la conduite des indicateurs de performance
des entreprises.
• Les cultures de gestion de produit dont les philosophies reposent sur le trio « sécurité psychologique/
échec rapide et apprentissage », renforcées par des équipes axées sur les produits, obtiennent des scores
IRD élevés. Seuls ~20 % des cadres estiment que leur entreprise met en œuvre cette pratique culturelle.
• Les fonctionnalités Open source et l’adoption sont le facteur de différenciation le plus déterminant pour
les entreprises les plus performantes qui tentent de promouvoir l’innovation et la satisfaction
des développeurs.
• La qualité est en péril dans les entreprises qui adoptent lentement des pratiques d'automatisation
des tests et lorsqu'elles pensent que la « qualité » ne concerne que les tests.
• La sécurité est une préoccupation majeure. 17 % des entreprises déclarent qu’elles ne testent les failles
de sécurité qu'à l'occasion d'une « version majeure » ou « uniquement lors de la mise en production ».
• La conformité dans les entreprises est un défi majeur. 59 % des personnes interrogées déclarent
qu’elles peuvent prendre « de plusieurs jours à plusieurs mois » pour évaluer leur état actuel
de conformité réglementaire.

Une fois l'IRD établi, Microsoft, en tandem avec Sogeti, a mené une étude basée sur les commentaires et les entretiens
avec les praticiens de Sogeti responsables de plus de 250 implémentations Cloud et DevOps dans des entreprises. Les
conclusions de l’étude IRD ont été combinées aux recherches de Sogeti pour identifier six domaines clés de l’informatique
à l’échelle de l’entreprise qui font face à des défis importants dans le cadre de la transformation Enterprise DevOps :

Gestion des produits Qualité

Équipes distribuées
Sécurité
et télétravail

Gouvernance informatique Conformité

Rapport Enterprise DevOps 2020-21 5

Dans ces six domaines à l’échelle de l’entreprise, les meilleurs acteurs de l’espace DevOps relèvent les
défis grâce aux pratiques et solutions suivantes :

• Passer d'un modèle de livraison centralisé «  centré
sur le projet  » à un modèle décentralisé «  centré
sur le produit », où les équipes produit DevOps
s'approprient pleinement le cycle de bout en bout
d'un produit ou d'un service, tout en mettant en
œuvre des processus budgétaires itératifs au lieu de
budgets annuels à grande échelle.
• Les équipes s’appuient sur les bonnes pratiques des
projets open source et adoptent une méthodologie
InnerSource. Ces équipes partagent des architectures,
du code d’application et du code d’infrastructure de
référence, ainsi que des composants communs pour
rationaliser et optimiser leurs flux de travail.
• Les équipes sont habilitées à «  coder, livrer et
collaborer de n’importe où  » en adoptant des
plateformes de collaboration basées sur le Cloud, des
chaînes d'outils DevOps et des systèmes de contrôle
de version distribués.
• Les entreprises adoptent des modèles de gouvernance
fondés sur des principes, dans lesquels les équipes
de gouvernance et d'architecture définissent des
principes fondamentaux et précisent comment ils
seront évalués. Ces entreprises font en sorte que faire
la bonne chose, faire ce qui est facile et se conformer
à la gouvernance devienne une habitude.
• Les praticiens de DevOps créent, exécutent et gèrent
leurs applications sur des plateformes Cloud en
libre-service et assurent la sécurité, la conformité et
la qualité de tous leurs produits.
• Les organisations adoptent un modèle «  tout en
code », où non seulement les applications, mais aussi
les réseaux, l’infrastructure de calcul, la politique
de sécurité, les pipelines de build et de lancement,
etc... sont écrits «  en code  » et stockés dans un
référentiel de code source. Cette pratique permet
une amélioration continue en mettant à jour le code
source, en favorisant une meilleure réutilisation au
sein de l'entreprise et une plus grande transparence.
• Les préoccupations à l’échelle de l’entreprise, telles
que la qualité, la sécurité et la conformité, passent
d’un « modèle d’audit » à un « modèle continu » (CI/
CD), de la même façon dont le modèle d’intégration
continue/de déploiement continu a transformé le
développement logiciel. La qualité, la sécurité et
la conformité sont continuellement évaluées, par
rapport aux normes et aux références convenues, et
les écarts sont corrigés soit par l’automatisation, soit
par une intervention humaine directe.

Les entreprises qui cherchent à évoluer vers un modèle de livraison Enterprise DevOps peuvent utiliser ces
modèles d'application et pratiques professionnelles pour leur évolution. Ce rapport développera chacune de
ces bonnes pratique set proposera de nombreux autres enseignements et solutions clés mis en œuvre par les
meilleurs utilisateurs de DevOps.
Rapport Enterprise DevOps 2020-21
Présentation d'Enterprise DevOps
Microsoft définit DevOps comme « ...l’association de personnes, de processus et
de technologie qui permet de proposer une plus-value en continu aux clients ».
Il est important de commencer par reconnaître que
les objectifs de DevOps restent les mêmes, qu'il soit
mis en œuvre par une entreprise traditionnelle ou par
une organisation native du numérique. Ces deux types
d'organisation aspirent à se déployer en production
plus rapidement et plus fréquemment, et à fournir des
services hautement disponibles à leurs clients dans des
environnements stables et sécurisés.
Les premiers utilisateurs natifs du numérique ont
développé leurs principes DevOps en suivant une
voie évolutive  : au fur et à mesure de leur croissance
commerciale jusqu'à leur échelle actuelle, leurs pratiques
DevOps ont été contraintes d'évoluer parallèlement à leur
architecture d'application. En revanche, de nombreuses
entreprises existantes sont coincées avec des années, voire
des décennies d’applications et de processus dépassés
qui peinent à rester cohérents et pertinents, tout en
offrant des rendements décroissants. Ces entreprises sont
confrontées à une évolution DevOps transformationnelle,
et pour réussir dans un paysage technologique aussi
dynamique et en constante évolution, elles doivent
commencer par renforcer leurs services informatiques.
6
L’évolution de DevOps a été grandement freinée par
la façon dont les entreprises perçoivent leurs services
informatiques.
Pour beaucoup, leur informatique n'est plus adaptée. Donc,
si la direction souhaite que ses services informatiques
restent pertinents, en fournissant des prestations rapides
et flexibles, elle doit fondamentalement transformer sa
conception de l’informatique en tant que centre de coûts,
et la reconnaître comme un outil stratégique essentiel au
succès de l’entreprise dans son ensemble.
Le paysage technologique s’est complètement transformé
et va continuer à évoluer rapidement dans les années
à venir. DevOps est la solution la plus flexible et la plus
adaptée pour permettre aux entreprises de suivre et
d’anticiper l'informatique nouvelle génération. Mais,
comme le montrent les résultats de notre étude, l’adoption
et la transformation d'Enterprise DevOps s’accompagnent
d’une multitude de défis qui leur sont propres.
Rapport Enterprise DevOps 2020-21
Défis de la transformation Enterprise DevOps
Gestion des produits
Presque toutes les entreprises disposent de portefeuilles
de produits ou d’applications existants, dont la majorité
est toujours hébergée sur site. Le support de ces logiciels
est dispersé entre des équipes, des unités commerciales
et des organisations fragmentées, ce qui entraîne un
manque d'appropriation, une duplication coûteuse des
systèmes et des efforts, et un support client disjoint.
Au sein de ces portefeuilles de produits disparates,
les entreprises ont souvent, par nécessité et dans la
précipitation, mis en œuvre des solutions disparates de
logiciels professionnels variés qui sont incompatibles
entre eux. Cela crée une culture qui encourage l'obtention
de résultats rapides, mais qui finit souvent par causer des
problèmes catastrophiques par la suite. Ces échecs se
résument souvent à des chefs de produit et des membres
d'équipe surchargés et sous-formés qui ne se sentent pas
à l'aise à l'idée de prendre des risques afin de résoudre des
problèmes systémiques.
Équipes distribuées et télétravail
Ces dernières années, il est devenu de plus en plus
important de permettre la mise en place d'équipes
distribuées et du télétravail, en particulier dans le sillage
de la pandémie de coronavirus de 2020. Néanmoins, les
défis précédents concernant la manière de permettre
aux développeurs de coder, déployer et collaborer
depuis n’importe où demeurent une constante. Les
équipes DevOps doivent être dotées des outils de
collaboration appropriés, d'un accès réseau à haut débit
et du matériel informatique adéquat, tout en conservant
des environnements sécurisés. La création et le maintien
d'équipes à distance performantes nécessitent une
combinaison de solutions culturelles et technologiques.
7
Gouvernance
La création d'un cadre de gouvernance efficace au rythme
de DevOps est un obstacle majeur pour les entreprises,
en particulier face à la diversité de leurs portefeuilles de
produits et de leurs équipes distribuées. Les modèles de
gouvernance existants, en mettant l’accent sur le contrôle
des coûts et l’efficacité, sont souvent contre-productifs
lorsqu’ils sont appliqués à un modèle DevOps, qui se
concentre davantage sur la création de la valeur et sur
le délai de mise sur le marché. L’instauration des bonnes
cultures au sein d’une entreprise pour faire en sorte que
faire la bonne chose soit facile, est primordiale pour
résoudre un grand nombre de ces problèmes, où les
pratiques culturelles et les objectifs professionnels sont
clairement définis, avec des mesures claires pour suivre
l’état de santé des deux.
Qualité
Veiller à ce que la qualité soit maintenue à mesure que
la fréquence des mises à jour de logiciels augmente
est une priorité pour les équipes Enterprise DevOps.
Cette pratique exige une ingénierie de qualité continue
et une attention particulière à la manière d’équilibrer
besoin de rapidité et exigence de qualité. Comment faire
passer vos équipes DevOps du « comptage des bugs » à
l'amélioration réelle de la qualité d'un produit ? Quelles
sont les interdépendances du cycle de développement
logiciel (SDLC) dont vous devez être conscient pour
garantir la qualité, et comment acquérir ces informations,
en particulier dans l'environnement open source actuel ?
Briser les murs entre les différentes équipes DevOps,
normaliser leur façon de travailler avec les politiques et les
infrastructures, intégrer la qualité dans les pipelines CI/CD,
et utiliser l'automatisation pour libérer les professionnels
de l'assurance qualité et les équipes de test sont autant
d'éléments qui font partie intégrante du traitement de la
qualité dans les entreprises.
Rapport Enterprise DevOps 2020-21
Sécurité
La responsabilité de la sécurité ne peut être confiée
à une seule équipe au sein de l'entreprise si les équipes
DevOps autonomes et distribuées sont
à créer et à faire fonctionner leurs propres applications,
et à publier les modifications effectuées à leur propre
rythme. De nombreuses entreprises ont même du mal
à comprendre les vulnérabilités de leur code open source
et n’ont pas la capacité de sécuriser leurs environnements
Cloud. Les entreprises sont en mesure d’éliminer un grand
nombre de bogs potentiels avant même de valider le
code sur le terrain en adhérant à des principes du SDLC
sécurisé et en automatisant les processus. Pour ce faire, les
entreprises ont besoin d’approches clairement définies en
matière de sécurité, et de bénéficier de l’investissement et
de la supervision appropriés de la part de la direction.
UNE NOTE AU LECTEUR
Le rapport suivant explique plus en détail chacun
des défis susmentionnés, tout en offrant des
informations utiles et des stratégies mises en œuvre
par les entreprises les plus performantes pour aider
à combattre chacun de ces obstacles. En examinant
soigneusement votre entreprise et en mettant en
œuvre les bonnes pratiques et les technologies
adaptées à la structure et aux besoins de votre
organisation, nous espérons que chaque entreprise,
quel que soit son stade d’adoption de DevOps,
constatera une amélioration de ses principaux
indicateurs de performance, ainsi qu'une plus grande
satisfaction de ses clients.
8
Conformité
Les entreprises sont toutes soumises à un contrôle
réglementaire externe d'un type ou d'un autre, par
habilitées exemple la SEC, le RGPD, etc., ainsi qu'à leurs propres
fonctions de conformité internes. Veiller à ce que
la conformité soit définie, maintenue, améliorée et
constamment et systématiquement contrôlée est une
préoccupation et un défi majeurs pour les entreprises
d’aujourd’hui.
Nous suggérons à tous les lecteurs d'examiner
l'ensemble du rapport, mais si votre entreprise
doit relever immédiatement des défis flagrants
ou pertinents, nous vous encourageons à passer
directement à ces sections avant de revenir en arrière
et de lire les autres. Bien que le document s’appuie
sur lui-même et que des sections renvoient parfois
les unes aux autres, nous avons délibérément conçu
chaque section de manière à ce qu'elle puisse être
lue indépendamment.
Rapport Enterprise DevOps 2020-21
L'indice de rapidité de
développement (IRD)
Pour réussir dans le développement logiciel, les entreprises
doivent donner aux développeurs les moyens de créer de
manière productive, de collaborer à l'échelle mondiale en
toute sécurité, et de mettre l'innovation à l'échelle. Les
leaders du secteur ont récemment appelé ceci la rapidité
de développement (RD). Cela va au-delà de la définition
traditionnelle «  agile  » de la rapidité, car il ne s’agit
pas seulement de la rapidité, mais de la créativité des
développeurs pour générer des résultats commerciaux.
Tout comme la vitesse en physique, il s'agit de rapidité
avec une direction.
Avec de nombreux leviers d’amélioration potentiels et peu
d’analyses quantitatives, les organisations ont souvent
du mal à déterminer les priorités et les pratiques de
développement les plus efficaces.
L’analyse de corrélation entre les 46  facteurs qui influent
sur la rapidité de développement (comme illustré dans le
diagramme ci-dessous) et les indicateurs de performance
de l’entreprise a révélé des conclusions frappantes sur les
facteurs critiques :
1. Seul un groupe relativement restreint de
facteurs critiques a réellement fait augmenter
la rapidité de développement
2. De nombreux facteurs perçus et les bonnes
pratiques se sont révélés moins importants que
ce que de nombreux dirigeants pensaient.
LES MEILLEURES ENTREPRISES EN TERMES DE RAPIDITÉ DE DÉVELOPPEMENT ONT UN AVANTAGE EN MATIÈRE D'INNOVATION
Corrélation entre l’indice de rapidité de développement (IRD) et les principaux indicateurs
de performance des entreprises
Globalité
Innovation
Satisfaction des clients
Perception de la marque
Gestion des talents
2
McKinsey « Developer Velocity: How software excellence fuels business performance », 2020
9
Lorsque les chercheurs ont comparé les entreprises ayant
des scores IRD dans le premier quartile à celles en ayant
dans le dernier quartile, ils ont constaté une amélioration
de quatre à cinq fois le taux de croissance annuel composé
(TCAC)2. Au-delà de la simple croissance des revenus, les
entreprises dont l'IRD se trouve dans le quartile supérieur
ont surpassé celles du quartile inférieur de 60 % en termes
de croissance du rendement total pour les actionnaires
(RTA), et ont enregistré une marge d’exploitation 20  %
plus élevée.
Au-delà des mesures purement financières, l'IRD est
également fortement corrélé avec d’autres indicateurs de
performance de pointe, en particulier l’innovation (voir la
figure 2). L’accent mis sur les performances de l’entreprise,
plutôt que sur les performances opérationnelles, est une
distinction importante pour les besoins de ce rapport.
Cela suggère que les entreprises se situant dans le
quartile supérieur de l'IRD reconnaissent la relation
entre les personnes, les processus et les technologies de
la combinaison de DevOps comme étant un facteur clé
du succès de l’entreprise, plutôt que de se concentrer
uniquement sur les indicateurs de performance
technologiques traditionnels, tels que le coût total
de possession (TCO), la disponibilité des systèmes ou
le taux d’échec des changements. L’alignement de la
transformation DevOps sur de bons résultats commerciaux
est le moteur des changements culturels, techniques et
organisationnels reflétés dans ce rapport.
FIGURE 1
Indice de rapidité de développement
0,6
Intensité de l'innovation
0,6
0,5
0,5
0,4
État d'Enterprise DevOps 2020 10

FACTEURS D'IMPORTANCE RELATIVE SUR LES INDICATEURS DE PERFORMANCE DES ENTREPRISES FIGURE 2

Moteurs principaux

Architecture Architecture logicielle 1,045 %

T ECHNOLOG IE

Architecture des données 0,586 %

Infrastructure et plateforme Adoption du Cloud public (IaaS et PaaS) 2,533 %

Infrastructure en tant que code 0,802 %

Test Automatisation des tests 1,548 %

Développement piloté par test 0,324 %

Sécurité et conformité Sécurité 1,801 %

Conformité 2,887 %

Outils Outils de collaboration 5,369 %

développement ;
des outils de
Outils de développement 5,334 %

Outils DevOps 4,565 %

Outils de planification 6,167 %

Low code / pas de code 1,307 %

Assistance en matière d'IA 1,024 %

CI/CD Pratiques en matière de CI/CD 0,655 %

PRATIQUES DE TRAVAIL

Pratiques d'ingénierie Gestion de la dette technologique 1,73 %

Directives en matière de code 0,857 %

RÉVISIONS DU CODE 0,671 %

Open source/source intérieure Open source 0,693 %

source intérieure 0,432 %

Pratiques d'équipe agiles Gestion des WIP 0,56 %

Définition de « terminé » 0,336 %

Cérémonies 0,46 %

Caractéristiques de l'équipe Portée autonome 1,558 %

H AB IL ITAT ION ORGANISATIONNEL L E

Changement de contexte limité 1,053 %

Co-implantation 0,493 %

Équipe interfonctionnelle 0,514 %

Gestion des produits (PM) Fonctionnalités PM 6,432 %

Télémétrie de produit 2,777 %

Stratégie de liaison et indicateurs de l'équipe 1,217 %

Vision et exigences du produit 1,247 %

Prototypage rapide 0,559 %

Agilité organisationnelle Gestion des dépendances 1,691 %

Modèle de financement 0,736 %

Gestion de portefeuilles 0,588 %

Culture Sécurité psychologique/« échouer 7,489 %

rapidement et apprendre rapidement »
Collaboration et partage des connaissances 4,367 %
Culture

Amélioration continue 3,774 %

Chef de service 3,69 %

Obsession du client 1,937 %

Gestion des talents Gestion des performances 4,331 %

Gestion des talents

Gestion de la santé de l'équipe 2,883 %

Renforcement de la capacité 3,348 %

Recrutement 2,951 %

Proposition de valeur des collaborateurs 2,442 %

Parcours professionnel 2,238 %

0 1 2 3 4 5 6 7 8 9 10
Rapport Enterprise DevOps 2020-21 11

Gestion des produits

L'enquête 2020 McKinsey sur la rapidité Le passage du « projet » au « produit » permet de concentrer
l’attention et les efforts d’une équipe sur les objectifs
de développement a montré que de
du produit, qui doivent être des résultats mesurables
fortes capacités des chefs/responsables
visant à apporter une plus-value au client. Les objectifs
de produit sont l'un des quatre principaux
et les arriérés de travail sont gérés de manière proactive
facteurs corrélés avec un indice de rapidité afin de garantir que chaque produit offre une valeur
de développement (IRD) élevé, comme maximale (efficacité) tout en conservant un faible coût de
nous l'avons vu précédemment. Mais propriété (efficience). Cela favorise un esprit dynamique
pourquoi une approche centrée sur le et collaboratif où les équipes assument la responsabilité
produit est-elle importante pour réussir collective de la réussite. Les développeurs sont plus
avec Enterprise DevOps ? susceptibles de s’assurer que leur code est conforme aux
normes s’ils travaillent en étroite collaboration avec leurs
collègues des opérations qui seront directement touchés
DevOps préconise la formation d’équipes
par les problèmes qu’ils causent. En outre, l'efficacité est
multidisciplinaires de longue durée qui s'alignent sur
améliorée grâce à une prise de décision conjointe et à des
la création de valeur pour l’entreprise (flux de valeur).
boucles de commentaires rapides, ce qui permet d'éviter
La pratique la plus importante est peut-être de créer
le cycle fastidieux d'escalade vécu par les équipes qui ont
des équipes alignées sur les produits afin de rationaliser
un niveau élevé de dépendance à l'égard d'autres équipes.
l’efficacité et de créer une responsabilisation au niveau
du produit. Ces équipes produit pluridisciplinaires,
Au fil du temps, les équipes à longue durée de vie
comprenant à la fois des développeurs et des opérateurs,
acquièrent un savoir-faire approfondi et des connaissances
assument l'entière responsabilité de l'ensemble du cycle
contextuelles sur leur domaine de produits, qui peuvent
de vie des produits, depuis leur création jusqu'à leur
être utilisées pour améliorer et optimiser continuellement
retrait. Cela contraste avec l'approche plus fragmentée
leurs produits au profit de l’entreprise et de ses clients.
de l'informatique traditionnelle, axée sur les projets,
qui exige que les équipes et les individus n'assument la
responsabilité que d'un segment étroitement défini du
cycle de vie du produit, de la conception à la mise en
service. Ils transmettent ensuite la livraison à une équipe
d’opérateurs distincte pour le cycle de vie opérationnel
du service. La conséquence de cette mentalité de projet,
par opposition à une mentalité de produit, est un manque
de responsabilité globale, qui entrave les performances
à long terme.
Rapport Enterprise DevOps 2020-21
Quels sont les défis ?
Les résultats de l’enquête IRD permettent de mieux
comprendre les facteurs d'habilitation organisationnelle
qui déterminent les indicateurs de performance clés.
Toutefois, pour commencer, il est important de se pencher
sur les résultats de la gestion de la culture et des talents et
sur le rôle que jouent les équipes alignées sur les produits
dans l'obtention de résultats commerciaux.
Confiance et sécurité psychologique
L’une des principales conclusions culturelles concerne
la contribution de la «  sécurité psychologique  » aux
performances des entreprises. Amy Edmondson,
professeure à Harvard, la définit comme «  une croyance
partagée par les membres d’une équipe selon laquelle
l'équipe est sûre pour la prise de risques interpersonnels ».
L'équipe est inhérente à ce concept, et avec des équipes
Enterprise DevOps à la longue durée de vie, polyvalentes
et alignées sur les produits, il y a la marge nécessaire
pour prendre des risques et innover. La longévité de ces
équipes permet d'entretenir et de développer la confiance
entre les membres de l'équipe. La confiance au sein des
équipes et entre elles, et la confiance dans un produit,
aident les individus à se sentir assez en sécurité pour
innover, améliorer et optimiser tout en tirant les leçons de
leurs échecs.
DES CAPACITÉS SOLIDES ET ÉQUILIBRÉES DE CHEF/RESPONSABLE DE PRODUIT SONT ESSENTIELLES À LA RÉUSSITE DE L’ENTREPRISE
FOR CE DE L A CORRÉL AT ION E NTRE LE S CA PACITÉ S D E S CHE FS/RESPONSABLES DE PRODUIT ET LES PERFORMANCES DE L’ENTREPRISE
Score moyen pour toutes les capacités de PM
Ancrage de l'expérience client
(par exemple, cartographie du parcours client,
conception UI/UX)
Compétences techniques
(par exemple, connaissances de la pile technologique,
définition des exigences technologiques)
Compétences humaines
(par exemple, influencer, renforcer l’équipe)
Orientation du marché
(p. ex. tendances du marché, concurrence)
Sens des affaires
(par exemple, stratégie GTM, hiérarchisation des
feuilles de route)
0,0
12
La section de l'enquête sur l'IRD consacrée à la culture
et à la gestion des défis a également révélé que la
collaboration et le partage des connaissances sont
difficiles sans un contexte clairement délimité concernant
les responsabilités et les obligations des membres de
l'équipe. De même, la gestion des performances est
plus complexe si l'équipe ne peut pas voir clairement les
contributions de chaque membre aux objectifs communs,
et si les membres de l'équipe ne se sentent pas liés et
responsables du travail qu'ils font.
Le manque de chefs de produit
Lorsque l'on examine les cinq principales compétences
d'un «  chef/responsable de produit solide et équilibré  »,
comme le montrent les résultats de l'enquête, on constate
qu'être un bon chef de produit n'est pas une mince
affaire. Cela nécessite un équilibre entre l’intelligence
émotionnelle et les compétences relationnelles, telles que
l'esprit d'équipe et une forte orientation client. Cela doit
être complété par de bonnes compétences techniques
pour être en mesure de définir les exigences techniques,
ainsi qu'un sens aigu des affaires et l’orientation vers
le marché nécessaire pour créer les bons produits
susceptibles de réussir sur le marché.
FIGURE 3
0,7
0,5
0,5
0,5
0,4
0,4
0,2 0,4 0,6 0,8 1,0
Rapport Enterprise DevOps 2020-21
Ainsi, une fois les caractéristiques d'un bon chef de produit
définies, ne devrait-il pas être facile de constituer une
équipe axée sur le produit autour d'une gestion solide du
produit  ? Malheureusement, ce n’est pas le cas. L'un des
plus grands défis pour Enterprise DevOps est qu'il n'y a
pas assez de bons chefs de produit pour tout le monde. En
fait, « les PDG et les dirigeants du secteur technologiques
identifient souvent le rôle de chef de produit comme l’une
de leurs principales priorités en matière de talents ».
Étant donné qu’il n’y a pas assez de bons chefs de produit
pour diriger la création de solutions logicielles innovantes
développées en interne, beaucoup se sont tournés vers des
logiciels commerciaux (COTS) pour combler cette lacune.
Là encore, malheureusement, si la mise en œuvre de
solutions COTS peut créer une base solide pour répondre
aux besoins commerciaux des entreprises, elles nécessitent
normalement une personnalisation et un développement
sur mesure pour les adapter aux exigences et aux besoins
organisationnels. Ainsi commence le cercle vicieux, car
ce défi d'intégration et de personnalisation soulève la
nécessité d'une bonne gestion des produits.
3
McKinsey, Insights- The Product Management Talent Dilemma (Le dilemme des talents en gestion de produit), 2020
4
Martin Fowler, Guide sur les microservices, 2020
13
Faire face à la dette technique
L’une des difficultés les plus fréquemment citées dans les
entretiens Sogeti était le concept de « dette technique ».
Il s’agit de l’accumulation de décisions techniques
sous-optimales prises pendant la durée de vie d’une
application informatique, ce qui crée des situations où
il devient plus difficile d'apporter des changements
significatifs. Ce problème est souvent le «  grain de sable
3
dans les engrenages » qui provoque l’arrêt des initiatives
informatiques. De nombreuses entreprises ont accumulé
de grandes quantités de dettes techniques, dont le coût
du remboursement peut se chiffrer en dizaines ou en
centaines de millions de dollars. Les équipes axées sur les
produits, dans le cadre de l’adoption d'Enterprise DevOps,
parallèlement à la migration vers le Cloud, sont contraintes
de faire face à cette accumulation et au remboursement
ultérieur de la dette technique.
Plus précisément, le démêlage de l'architecture
des applications héritées, le modèle d'application
monolithique, est l'un des principaux obstacles à la
création de petites équipes produit. Cela a entraîné la
popularité croissante des architectures de micro-services4
permettant de décomposer des applications colossales
en composants plus petits, plus faciles à gérer et mieux
adaptés à une approche d'équipe produit. Il est important
de noter que bien que la dette technique soit un fléau
pour les applications, elle affecte également les processus
et les procédures. La transformation Enterprise DevOps
et l’adoption de modèles axés sur les produits offrent aux
entreprises la possibilité de reconcevoir les flux de travail
pour rationaliser et accélérer la livraison de services.
Rapport Enterprise DevOps 2020-21
Relever les défis
Créer un portefeuille de produits
La première étape de la mise en œuvre d'une gestion
de produit de classe entreprise dans le cadre d'une
transformation DevOps consiste à évaluer en profondeur
votre portefeuille d'applications existant et à identifier les
bons candidats pour une adoption rapide de l'approche
axée sur le produit. Ce faisant, les entreprises les plus
performantes choisissent généralement des produits
qui dépendent moins d'autres produits. Ils commencent
aussi généralement par de plus petits produits et
progressent ensuite. Il sera important de commencer
par limiter la taille des équipes produit, et les recherches
sur les performances des équipes recommandent une
taille d'équipe de 7 ± 2. Commencer petit permet aux
responsables de la transformation de contourner une
grande partie de la complexité organisationnelle, tout en
aidant à définir les attentes pour les équipes et les rôles.
Lorsque vous choisissez de créer une nouvelle équipe
produit, veillez à choisir des produits qui ont une valeur
mesurable. Visualisez la valeur du produit (efficacité)
et les coûts (efficience) pour le cycle de vie du produit
choisi, et créez une matrice de valeur commerciale pour
hiérarchiser les domaines dans lesquels votre équipe
passe son temps. Il convient de mentionner que vous
n’avez pas besoin d’évaluer de manière exhaustive
chaque application et service dans votre portefeuille
informatique avant de commencer votre transition vers
un modèle axé sur le produit. Il est généralement possible
d’identifier rapidement les alignements de produits/
d'équipes existants qui peuvent générer des gains rapides
pour stimuler votre transformation à mesure que vous
développez continuellement le portefeuille de produits.
Financer votre portefeuille de produits
Dans de nombreuses entreprises, la façon dont les budgets
informatiques sont alloués renforce intrinsèquement
les divisions entre les développeurs et les opérateurs.
Souvent, la première mesure consiste à diviser l’argent
en un budget de «  changement  » alloué aux projets
et un budget de «  fonctionnement  », qui est alloué au
support et à la maintenance des services existants, des
licences logicielles et d’autres dépenses opérationnelles
récurrentes. Les budgets de fonctionnement reçoivent
traditionnellement environ deux tiers des dépenses
informatiques annuelles, ce qui laisse les produits sous-
financés et insuffisamment soutenus.
14
En outre, la budgétisation est généralement un processus
annuel, le financement étant alloué à l’avance pour les
12 prochains mois. Cela laisse souvent peu de place
à l'innovation et empêche de répondre de manière agile
aux nouveaux besoins des clients. Certaines entreprises,
menées par le mouvement Beyond Budgeting, sont
allées jusqu’à abandonner complètement le processus
budgétaire annuel au profit de méthodes de budgétisation
plus souples et adaptables.
Les modèles de financement qui se concentrent sur le
produit et l’équipe produit gagnent en popularité. Dans
ces cas, le financement est alloué à un produit et, à son
tour, le propriétaire du produit décide comment allouer
ce financement pour soutenir les équipes produit dans
la création et le fonctionnement du produit.
D’autres entreprises ont adopté des modèles alternatifs
de financement de portefeuille basés sur le financement
par capital-risque (CR). Dans le modèle de financement
par CR, l'investissement est aligné sur les étapes clés du
développement du produit, à savoir le financement initial
pour créer un prototype et évaluer l’adéquation initiale
produit/marché, le financement de série  A pour faire
évoluer l’idée, etc... Tout comme dans une entreprise de
CR typique, un comité d’investissement doit se réunir
régulièrement, généralement toutes les deux semaines,
pour examiner les nouvelles propositions d’investissement
des chefs de produit et évaluer les performances des
produits existants dans le portefeuille.
Soutenir les produits avec des plateformes en libre-
service
Dès qu'une entreprise dépasse une petite poignée
d'équipes produit, il est avantageux de commencer
à introduire des plateformes en libre-service avec
des fonctionnalités de base. Avec plusieurs équipes
autonomes, il est facile de réinventer inutilement les
systèmes de base, tels que les chaînes d'outils CI/CD, ce qui
fait perdre un temps précieux qui aurait pu être consacré
à l'innovation. Le travail de ces équipes de plateforme est
d’empêcher les équipes produit distinctes de réinventer
la roue, et de fournir des fonctionnalités qui les aident
à faire leur travail.
Rapport Enterprise DevOps 2020-21 15

En fonction de vos besoins, vous pouvez avoir des
équipes de plateforme dont la mission couvre : la livraison
continue, la surveillance et l’observabilité, la sécurité et
la conformité, l’infrastructure Cloud, l’automatisation des
tests et les données.
En effet, les équipes de plateforme ne sont que des
équipes produit qui fournissent un produit à des clients
internes. Il est important de considérer les équipes de
livraison de produits comme des clients, car les équipes
de plateforme ne doivent pas, de manière générale, avoir
pour mission de contrôler ce que font les équipes produit.
Ce message est renforcé par les propres expériences de
Microsoft. Microsoft a été l’un des premiers à adopter le
modèle d’équipe de plateforme, formant l’équipe One
Engineering System (1ES) en 2014. La mission de la 1ES
était de responsabiliser chaque ingénieur de l’entreprise
en s'appuyant sur les meilleurs outils disponibles. L’équipe
1ES a partagé les enseignements tirés de son étude de cas
DevOps et de son livre blanc sur les 5 étapes pour changer
de culture5.
InnerSource
Un autre élément clé du modèle d’équipes produit et de
plateforme est le modèle InnerSource (aussi connu comme
source partagée d'entreprise).Dans leur guide pour
l'adoption d'InnerSource, Danese Cooper et Klaas-Jan Stol
définissent ce modèle comme «  Une façon collaborative
et responsabilisante d'impliquer les employés dans la prise
des décisions et leur mise en œuvre dans toute l'entreprise.
Il incarne une philosophie des relations humaines, une
approche des récompenses et des motivations, ainsi qu’un
ensemble d’outils et de pratiques souple et adaptable. »
Les entreprises dotées d’une grande base de développeurs
adoptent InnerSource en suivant les principes
fondamentaux de GitHub6. Nous observons de plus en
plus cette approche ouverte et transparente appliquée à
de nombreux autres domaines de l’informatique, comme
la gouvernance, l’architecture de référence, les normes de
sécurité et les bonnes pratiques, mais elle peut également
être appliquée dans de nombreuses autres circonstances.
Les avantages que les organisations tirent en fin de
compte de l’adoption d'InnerSource comprennent une
plus grande rapidité de livraison, une collaboration plus
fluide entre les groupes, un développement de meilleure
qualité et une meilleure documentation.
Les équipes de plateforme sont cruciales dans cette
entreprise, car elles assurent la transparence sur la
façon dont les plateformes en libre-service sont créées
et entretenues en partageant le code source via un
référentiel de code. Les équipes de plateforme doivent
agir en tant que responsables de ce référentiel, mais
n’importe qui peut y contribuer, et si l’équipe produit
constate qu’elle a besoin d’étendre les capacités de
quelque chose qu’une équipe de plateforme a créé, elle ne
devrait pas attendre que l’équipe de plateforme le fasse.
Reflétant le flux de travail des contributeurs des projets
open source, les équipes peuvent coder les modifications
qu'elles souhaitent, puis les soumettre à l'équipe de
plateforme sous la forme d'une demande de contribution.
Une fois examinée et approuvée, la modification peut
être fusionnée dans la base de code principale. En fin
de compte, l’ensemble du processus réduit le taux de
désabonnement, fait gagner un temps précieux et permet
aux collaborateurs d'être proactifs et de prendre des
risques.
Cultiver les talents de gestion de produit
Cultiver et développer de grands talents de gestion de
produit au sein de votre entreprise est primordial pour
réussir. Compte tenu de la concurrence sur le marché pour
les chefs de produit, la meilleure stratégie consiste à se
concentrer sur l’identification et le développement des
talents internes. Pour aider les entreprises à atteindre cet
objectif ambitieux, McKinsey a identifié quatre étapes clés
pour élaborer un programme de classe mondiale pour les
talents en gestion de produit7 :
1. Articuler le modèle de développement du leadership
de la gestion des produits pour l'entreprise.
2. Fournir aux chefs de produit des outils
organisationnels pour une croissance
et un apprentissage continus.
3. Tirer parti d’une « approche de terrain et de forum »
pour concevoir un parcours d’apprentissage de bout
en bout en associant la formation sur le lieu de travail
à l’apprentissage en classe ou en formation intensive.
4. Le recrutement des chefs de produit doit être
une priorité stratégique pour la direction.

5
Microsoft Azure, Five Steps to Culture Change (Cinq étapes pour un changement de culture), 2019
6
GitHub, Introduction to InnerSource (Introduction à InnerSource), 2020
7
McKinsey, Insights- The Product Management Talent Dilemma (Le dilemme des talents en gestion de produit), 2020
Rapport Enterprise DevOps 2020-21 16

ÉTUDE DE CAS SUR LA GESTION DE PRODUIT

Dans l'industrie de la mode, qui évolue rapidement, le
délai de mise sur le marché est essentiel. Mais pour un
détaillant de mode en ligne en pleine croissance, les
systèmes informatiques obsolètes et alambiqués ont
eu du mal à suivre le rythme de l'activité florissante de
l’entreprise.
Le détaillant vend plus de 80 000 produits de marque et
de sa propre marque via des expériences localisées sur le
mobile et le Web. Le développement et le maintien de
toutes les applications nécessaires à la prise en charge
de leur activité étaient devenus un obstacle majeur
à  l’innovation. L'informatique n'a pas été en mesure de
dépasser les 300 versions par an, ce qui a entraîné des
goulots d’étranglement importants dans les pipelines.
La maintenance a nécessité beaucoup de ressources,
tandis que les incohérences ont ralenti la livraison et
augmenté les risques.
Une approche Enterprise DevOps a été adoptée pour
remplacer la livraison logicielle complexe et manuelle par
de nouveaux outils et des méthodes de travail modernes.
Des équipes agiles alignées sur les produits ont été créées
en fonction des domaines fonctionnels du site, telles
que la recherche ou le panier d’achat, dans le but de
permettre à chaque équipe d’itérer et d’améliorer son
domaine de produit de manière aussi indépendante que
possible. Chaque équipe de développement a été migrée
individuellement vers un nouveau pipeline de livraison
continue, ce qui leur a permis de créer et de déployer leurs
produits à la demande, tout en continuant à innover et
à prendre des risques.
L'entreprise a maintenant plus de 80 équipes produit
agiles, qui publient plus de 3 000 versions par an, ce qui lui
a permis d'atteindre un TCAC de 23 % au cours des quatre
dernières années.

Le nombre d’équipes de développement est passé de

deux à 35 en peu de temps, travaillant sur le site Web de
distribution, les solutions de paiement, les commandes
et les systèmes de développement back-office. La
livraison des logiciels s'est faite par l'intermédiaire d'une
solution de déploiement complexe, avec une fonction de
déploiement et de mise en service centralisée. Ils avaient
désespérément besoin de moderniser leurs systèmes pour
augmenter rapidement la vitesse et la fréquence des mises
à jour de logiciels et des nouvelles fonctionnalités.

GESTION DES PRODUITS - RESSOURCES

POUR LA PROCHAINE ÉTAPE

Créer un portefeuille de produits

Passer du projet au produit
« Le processus de publication est
désormais cohérent du développement
Financer votre portefeuille de produits à la vie. Nous avons un taux de
En savoir plus sur Beyond Budgeting réussite beaucoup plus élevé et une
meilleure visibilité, et nous pouvons
InnerSource efficacement voir qui a apporté des changements
Consultez la fiche produit GitHub InnerSource et quand, et où les problèmes se
produisent. Nous ne pouvions pas faire
cela auparavant, et la direction est
Cultiver les talents de gestion de produit maintenant beaucoup plus confiante
Lisez le guide pour commencer la gestion des produits que tout est fait correctement. »

Chef de projet, détaillant de mode

Rapport Enterprise DevOps 2020-21
Équipes distribuées
et télétravail
Le télétravail distribué n’est pas un
concept nouveau pour les équipes de
développement : les entreprises ont des
bureaux dans le monde entier et doivent
offrir à leurs collaborateurs la possibilité
de travailler et d'assister leurs clients dans
tous les fuseaux horaires.
De nombreuses entreprises de ce type ont externalisé leur
travail afin d'accroître leur capacité de livraison, tout en
réduisant les coûts. Certaines entreprises offrent à leurs
collaborateurs la possibilité de travailler à domicile ou
en tout autre lieu, lorsque cela leur convient le mieux.
De nouveaux courants de collaboration commencent
à apparaître, à la fois dans les chaînes de valeur des
entreprises et dans le domaine social individuel des
collaborateurs. Dans le même temps, les plateformes de
collaboration SaaS mettent des outils de communication
et de partage de documents avancés à la portée
de chaque personne dans l'entreprise. Nous avons
notamment constaté des progrès majeurs dans les outils
de productivité des développeurs à distance.
Les plateformes de productivité des développeurs, comme
GitHub par exemple, permettent aux équipes distribuées
et aux travailleurs à distance de collaborer efficacement
pour atteindre leurs objectifs de développement logiciel.
Git, un système de contrôle de version distribué développé
à l’origine pour le projet Linux Kernel, permet aux
développeurs de travailler sur du code source déconnecté
des référentiels centralisés, puis de fusionner ensuite
facilement leurs modifications dans l’emplacement
central. Il est compréhensible que différents besoins de
collaboration nécessitent une prise en charge spécifique
pour fonctionner de manière optimale. De nombreux
développeurs ont une grande expérience du travail
à distance en raison de la composition unique de leur
secteur, ce qui les amène à collaborer au-delà des
frontières organisationnelles sur des projets open source
et InnerSource.
17
La pandémie de COVID-19 a introduit un besoin urgent
de faire la transition vers le télétravail, les gouvernements
demandant aux gens de rester chez eux et d’éviter d’aller
dans leurs bureaux. Cela a radicalement changé les façons
de travailler et de vivre. Les membres de l’équipe, à tous
les niveaux de responsabilité, dans les entreprises qui ne
sont pas considérées comme des services « essentiels » ou
« clés » ont dû télétravailler à un moment ou à un autre de
la crise.
Le télétravail imposé est très différent du travail à distance
en tant que choix stratégique ou opérationnel. La rapidité
avec laquelle les entreprises ont dû passer à un modèle de
travail entièrement à distance a été un choc et a provoqué
une frénésie au sein de nombreux services informatiques
qui n'ont pas eu le temps de se préparer. L'évolution
de l'environnement économique a obligé les modèles
commerciaux à s'adapter rapidement, et l'accent a été mis
sur l'efficacité et la réduction des coûts, tout en essayant
d'une manière ou d'une autre d'offrir la même valeur aux
clients qu'auparavant. Les feuilles de route existantes des
projets et des produits ont été très souvent mises de côté.
Les équipes informatiques se sont empressées de faire ce
qu'elles pouvaient, mettant en œuvre des fonctionnalités
de vidéoconférence, des signatures électroniques et des
réseaux de haute qualité, tout en fournissant du matériel et
des environnements de développement, le tout en veillant
à ce que les données de l'entreprise soient sécurisées.
Alors que nous continuons à nous débattre avec l'idée du
travail à distance obligatoire, nous avons l'occasion de
tirer les leçons des défis rencontrés et de nous concentrer
sur la croissance. Bien que nous ne puissions pas être sûrs
de la tournure que prendront les événements, plusieurs
défis doivent être relevés pour nous préparer au mieux
aux prochaines phases du COVID19 et à l'adoption
d'Enterprise DevOps.
Rapport Enterprise DevOps 2020-21 18

Quels sont les défis ?

Les organisations doivent simultanément adopter des
pratiques de travail à distance et s'adapter à un paysage
commercial radicalement modifié. Certaines entreprises
essaient simplement de survivre et se concentrent
fortement sur la réduction des coûts, tandis que
d’autres voient la demande de leurs services augmenter
considérablement et doivent trouver le moyen de
répondre à cette demande avec une main-d'œuvre
nouvellement distante.
Du point de vue des équipes DevOps, les défis liés à la
gestion d'équipes distribuées peuvent être classés en
trois catégories différentes :
Les défis liés à la capacité de télétravail
Comme l’indique l'enquête sur l'IRD, disposer des
bons outils de développement est l’un des facteurs de
performance de l'entreprise les plus importants, et les
outils de collaboration sont l’un des facteurs clés de cette
chaîne d'outils. Il est clair que de nombreuses entreprises
ont sous-investi dans la création de chaînes d'outils pour
soutenir le développement et la collaboration à distance,
ce qui a conduit à une ruée vers l'adoption de solutions
disparates qui auront des répercussions majeures par la
suite.

• Coder depuis n’importe où, pour permettre aux

développeurs de mettre en place et de maintenir
une capacité de travail à distance efficace
• Livrer depuis n’importe où pour créer, tester
et déployer des modifications au niveau des
applications tout en continuant à gérer les
systèmes de production, en toute sécurité
• Collaborer depuis n’importe où pour un
travail d’équipe distribuée efficace, y compris
le partage vocal, de code et de documents

LES FACTEURS D'IMPORTANCE REL ATIVE SUR LES INDICATEURS DE PERFORMANCE DES ENTREPRISES FIGURE 4

Architecture Architecture logicielle 1,045 %

T EC H NO LOG Y

Architecture des données 0,586 %

Infrastructure et plateforme Adoption du Cloud public (IaaS et PaaS) 2,533 %

Infrastructure en tant que code 0,802 %

Test Automatisation des tests 1,548 %

Développement piloté par test 0,324 %

Sécurité et conformité Sécurité 1,801 %

Conformité 2,887 %

Outils Outils de collaboration 5,369 %

développement ;
des outils de

Outils de développement 5,334 %

Outils DevOps 4,565 %

Outils de planification 6,167 %

Low code / pas de code 1,307 %

Rapport Enterprise DevOps 2020-21 19

La collaboration en équipe sur des actifs, depuis

n’importe où
50 % La collaboration en équipe ne consiste pas seulement
à attribuer des éléments de travail aux membres de
d'augmentation des bugs pour les
équipes distribuées et non colocalisées8
l’équipe. Pour innover, les membres de l’équipe doivent
pouvoir recueillir les commentaires des clients, partager
des idées, faire du brainstorming et résoudre des
problèmes ensemble, des tâches encore plus ardues avec
La création d’une chaîne d'outils efficace prend une main-d’œuvre entièrement distante. Les entreprises
généralement du temps et nécessite des investissements. doivent équiper les équipes des outils de collaboration
Toutefois, la pandémie de COVID-19 a conduit de à distance appropriés et les former à travailler efficacement
nombreuses entreprises à accélérer considérablement le dans les limites imposées par le télétravail.
déploiement de leur chaîne d'outils de développement
et de collaboration à distance, et elles en subissent déjà Déploiement en tout lieu
les conséquences en aval. Celles-ci vont de problèmes Les entreprises disposant d'un important portefeuille
apparemment minimes, comme le manque d’ordinateurs d'applications sur site, qui sont gérés par des outils de
et de bande passante, à des défis plus complexes et gestion sur site, sont confrontées à des défis importants
inquiétants, tels que les environnements physiques non maintenant que leurs administrateurs système sont
sécurisés qui ne conviennent pas au travail confidentiel ou obligés de travailler à distance. Pour maintenir et mettre
classifié, et une augmentation importante des bugs8. à jour ces systèmes sur site, une solution d'accès à distance
sécurisée doit être disponible, avec la capacité de gérer
le volume accru de travailleurs à distance. Généralement,
41 % la conception et la mise en œuvre d’une solution d’accès
à distance sécurisée, ou la mise à l’échelle de sa capacité,
pic des connexions de bureau
prend du temps que de nombreuses entreprises n’ont pas.
à distance exposées alors que
les équipes tentent d'accéder aux
environnements de travail à distance9

Permettre aux membres de l’équipe de travailler à distance

sans difficultés est un défi majeur. Ne pas pouvoir suivre
le travail, suivre les progrès, compiler du code, exécuter
des tests ou simplement faire le travail qui doit être fait
devient une lutte sans les bons outils et la possibilité de les
exécuter à distance.

La sécurité, lorsqu’elle fonctionne de manière distribuée,

comporte plusieurs couches  : les connexions réseau
doivent être sécurisées et chiffrées, tandis que l’accès
aux actifs de l’entreprise ou des clients doit également
être sécurisé. Dans de nombreuses organisations, les
données de l’entreprise ne sont même pas autorisées
dans les environnements personnels. La gestion des
outils de contrôle des sources tels que Git, les systèmes
de réplication de fichiers tels que OneDrive et d’autres
outils qui clonent et synchronisent les données semblent
offrir des solutions potentielles, mais soulèvent aussi une
multitude de problèmes qui leur sont propres.

8
McKinsey, A New Management Science for Technology Delivery (Une nouvelle science de la gestion pour
la fourniture de technologie), 2019
9
L'utilisation de ZDNet, RDP et VPN est montée en flèche depuis l'apparition du coronavirus, 2020
Rapport Enterprise DevOps 2020-21
Relever les défis
Plateformes de collaboration
Les outils de collaboration à distance, comme Microsoft®
Teams et Zoom, ont été rapidement adoptés par toutes les
entreprises qui adoptent un travail entièrement à distance.
Et, si les équipes DevOps existantes connaissaient déjà
très bien les outils de collaboration en ligne, d'autres ont
mis un certain temps à s'adapter. La plupart des équipes
DevOps connaissent bien les systèmes de contrôle de
version distribués, ce qui facilite la transition, mais pour
rester connectées, de nombreuses équipes ont mis en
place plusieurs points de contrôle pour maintenir une
forte participation de l’équipe.
Les équipes DevOps ont besoin de connexions informelles,
afin de reproduire un partage de connaissances et une
collaboration moins organisés. C'est pourquoi elles ont
mis en place des canaux de discussion dans Slack et
Microsoft Teams pour remplacer les visites au bureau et
les conversations dans les cafés. Les examens par les pairs,
les brainstormings de conception, etc. nécessitent des
approches différentes. Par exemple, les fonctionnalités
de collaboration de Git telles que les «  demandes de
contribution » et les fonctionnalités des outils de support
permettent aux développeurs d’ajouter facilement des
évaluations et des commentaires lorsqu'ils travaillent
à distance.
Pour les scénarios de formation et les explications
ponctuelles, les équipes et entreprises qui réussissent
adoptent Visual Studio Live Share, qui permet aux
développeurs de coder ensemble dans le même
environnement. Le même ensemble d’outils peut
être utilisé pour la formation, ou pour les entretiens
d’embauche, car il offre un espace de collaboration aux
développeurs qui peuvent travailler ensemble, côte à côte,
de manière virtuelle.
Le Cloud comme outil de travail à distance
Permettre aux équipes d’accéder en toute sécurité au
code et aux données a été l’un des plus grands obstacles
que les services informatiques ont dû surmonter à mesure
que la main-d’œuvre était forcée de passer au télétravail.
En particulier, de nombreux développeurs n’ont peut-être
pas accès au matériel informatique haute technologie
dont ils bénéficient dans leur environnement de bureau,
ni à l'accès sécurisé aux environnements et aux données
de développement.
10
Résultats de l’enquête interne Microsoft
20
Les solutions Cloud ont aidé les entreprises à surmonter
ce problème. Pour soulager les ordinateurs locaux peu
performants et non sécurisés, les entreprises les plus
performantes se sont tournées vers des solutions VDI
(Virtual Desktop Infrastructure) ou des machines virtuelles
(VM) dans le Cloud. Un environnement de développement
géré de manière centralisée et hébergé dans le Cloud peut
aider à résoudre de nombreux problèmes de configuration
de l’environnement que les développeurs rencontrent
fréquemment. En outre, les entreprises qui avaient déjà
adopté des plateformes DevOps SaaS, comme GitHub
ou Azure DevOps, avaient déjà relevés ces défis, et les
membres de leur équipe ont été en mesure de passer en
douceur au télétravail.
2 jours
temps que prennent généralement les
développeurs pour configurer un
environment10
Les entreprises qui tirent déjà parti des environnements
Cloud (par opposition aux environnements sur site) pour
les scénarios de test pourraient simplement continuer
à exécuter des cas de test. D’autre part, les équipes qui
n'avaient aucune capacité de test Cloud ont eu beaucoup
de mal à exécuter les tests et se sont tournées vers des
services comme Azure DevTest Labs pour y remédier.
En se basant sur le court sondage relatif à 250 projets
clients de Sogeti, nous avons déterminé que la maturité
de DevOps en soi n’a pas influé significativement sur
le passage au télétravail, bien qu’il y ait eu une petite
différence de facilité de transition pour les équipes plus
matures de DevOps. Toutefois, l’adoption de plateformes
Cloud et l’investissement dans ces dernières ont simplifié
la transition vers le travail à distance, en grande partie
grâce à leurs capacités de mise à l'échelle et au fait que
des solutions d'accès à distance sécurisées étaient déjà en
place. Autrement dit, ces entreprises pouvaient continuer
à travailler et à évoluer de manière fluide vers une
organisation plus distribuée.
Rapport Enterprise DevOps 2020-21
TÉLÉTRAVAIL DISTRIBUÉ : BONNES PRATIQUES DE MICROSOFT
Ce qui suit provient directement d'une communication interne de Microsoft qui définit des
domaines d'intérêt spécifiques pour permettre la productivité à distance de son personnel de
développement pendant la pandémie de COVID-19.
Encourager la culture d’équipe
Travailler à distance limite notre capacité à nous rendre
au bureau de quelqu'un, à parcourir les couloirs et à nous
réunir pour des déjeuners de groupe. Il est donc très
facile pour les membres de l'équipe de s'éloigner. Afin de
maintenir un environnement de travail collaboratif, nous
avons mis en place des pratiques d'équipe, notamment :
• Un canal de culture dans Microsoft Teams
à utiliser pour des discussions virtuelles
autour de la machine à café.
• Déjeuners et pauses café virtuels.
• Promenades en plein air lors d’appels
avec des coéquipiers.
• Un tableau de bingo de conférence
téléphonique, avec des choses comme « chien
qui aboie », « enfant qui interrompt », etc.
• L’utilisation du chat pour les questions et
les commentaires en direct et la cohésion
de l’équipe, en particulier lorsque certaines
personnes doivent couper leur micro en
raison de leur environnement de travail.
Rester informé
Tenir ses collaborateurs informés est un aspect essentiel
du télétravail.
• Notre équipe a créé une liste en ligne d'informations
utiles, allant des pointeurs de télétravail et des
conseils à l'échelle de l'entreprise au matériel
actuel, en passant par des conseils pour l'auto-
hébergement. Elle est mise à jour quotidiennement,
voire toutes les heures, avec les informations les plus
récentes au fur et à mesure que nous les recevons.
• Nous essayons également d’enregistrer des
événements virtuels et plus de réunions
quotidiennes en général, afin que les utilisateurs
puissent combler leur retard et regarder selon
leur propre emploi du temps ou fuseau horaire.
21
Configuration technique
Afin d'optimiser le télétravail pour nos ingénieurs, nous
commençons par leur configuration technique, en veillant
à ce qu’ils disposent du matériel approprié et des bonnes
connexions réseau. La plupart de nos ingénieurs disposent
déjà d’un ordinateur portable fourni par Microsoft pour
leur permettre d’effectuer leurs tâches à distance. Nous
avons également encouragé nos collaborateurs à apporter
des moniteurs, du matériel et des périphériques pour
reproduire leurs configurations de travail au bureau. Cela
est particulièrement important pour les développeurs qui
utilisent des configurations à deux ou trois moniteurs.
L’un des enseignements de l’accès à distance pour les
équipes de développement est, bien sûr, que les services
Cloud peuvent être une option d’infrastructure essentielle
pour permettre la productivité des développeurs
à  distance. Par exemple, GitHub Codespaces vous
permet de créer des environnements de développement
hébergés dans le Cloud, puis de vous y connecter à partir
des éditeurs de votre choix.
Même pour les développeurs qui travaillent exclusivement
sur des ordinateurs de bureau, le Cloud peut être d'une
grande aide. Ils peuvent utiliser des ordinateurs portables
d’entreprise avec une solution Windows Virtual Desktop
qui leur permet de se connecter à leur environnement de
développement qui fonctionne sur des machines virtuelles
puissantes dans le Cloud, et non plus localement sur leur
appareil.
Livraison
Ensuite, nous devons maintenir nos rythmes bien établis
pour la livraison des logiciels. Nos équipes d’ingénierie
s’appuient sur des réunions régulières de l’équipe et des
réunions en salle de livraison pour faire avancer tout
le monde. Ces réunions ne peuvent pas s'arrêter, et ne
s'arrêtent d'ailleurs pas.
Rapport Enterprise DevOps 2020-21 22

Nous les avons donc transférées exclusivement sur L'embauche

Microsoft Teams. En plus d’être la plateforme centralisée
pour les réunions à distance, Teams propose des
applications spécifiques au développement logiciel, telles
que Azure Boards pour la planification et le suivi du travail,
et le Microsoft Whiteboard, qui permet aux participants
de faire des esquisses de flux et de cartographier des
idées. Ces outils permettent de rassembler les membres
de notre équipe comme s'ils étaient au bureau.
L’embauche est un autre processus essentiel qui ne peut
pas être mis en attente pendant que nous travaillons
à  distance. Nous avons trouvé utile d’utiliser Live share
pour les entretiens techniques, ce qui nous permet
d’interagir et de communiquer avec les candidats à l’aide
d’outils avec lesquels ils sont déjà à l’aise.

Apprentissage par les pairs

Le télétravail peut être un défi pour les développeurs
qui participent à des examens par les pairs ou à la
programmation en binôme, où ils sont normalement
assis côte à côte et apprennent les uns des autres. Nos
développeurs utilisent Visual Studio Live Share pour les
sessions de débogage conjointes et l’apprentissage par
les pairs. Live Share permet aux développeurs de travailler
ensemble et indépendamment, et ressemble beaucoup
à la collaboration en personne.

ÉQUIPES DISTRIBUÉES ET TRAVAIL À DISTANCE - RESSOURCES POUR LA PROCHAINE ÉTAPE

Plateformes de collaboration
Débuter avec GitHub
Logiciel de discussion de groupe

Le Cloud comme outil de travail

Prise en main de Visual Studio LiveShare
Rapport Enterprise DevOps 2020-21 23

Gouvernance
La gouvernance informatique fait partie
de la stratégie globale de gouvernance de
l'entreprise et s'assure que les décisions
informatiques sont alignées sur la stratégie
Les start-ups et les petites entreprises agiles se prêtent
généralement bien à l'adoption et à la maturation des
pratiques DevOps. Elles ont souvent des processus de
gouvernance légers qui sont faciles à gérer et encore
plus faciles à automatiser. Les grandes entreprises dont

commerciale. La bonne gouvernance ne les processus de gouvernance sont profondément ancrés

consiste pas seulement à « faire les bonnes
choses », mais aussi à « faire les choses
bien ».
et qui ont des règles strictes prennent souvent plus de
temps, mais elles peuvent grandement tirer parti de
la simplification et de l'automatisation.
Si la gouvernance informatique détermine souvent

Il existe un large éventail de cadres de gouvernance la rapidité du changement, alors elle peut soit être une

informatique ; des plus courants comme COBIT 2019, aux force pour permettre un changement rapide, soit ralentir

normes internationales comme ISO38500. La plupart des la création de valeur.

cadres décrivent les rôles, les responsabilités, la structure

organisationnelle et les processus pour orienter la prise de
décision au sein des services informatiques.

La gouvernance influe sur la façon dont les objectifs sont

fixés et atteints par les services informatiques. En même
temps, la gouvernance est également en contradiction
avec l’indépendance souhaitée par les équipes DevOps.
Ces équipes doivent respecter les normes de l’entreprise
en matière d’architecture, de sécurité et de procédures,
mais elles les considèrent souvent comme des obstacles
à la livraison rapide. Bien qu'elles soient des directives
destinées à les soutenir, l'équipe les considère souvent
comme des inhibiteurs de l'innovation. Mais ces directives
peuvent également servir de base au partage des
connaissances pour aider les équipes et les individus
à se développer. Cette tension entre les restrictions
déroutantes des modèles de gouvernance traditionnels
et les avantages plus larges qu'une bonne gouvernance
peut apporter est au cœur du défi de la gouvernance du
DevOps.
Rapport Enterprise DevOps 2020-21
Quels sont les défis ?
L'informatique comme centre de coûts plutôt que
comme outil stratégique
De nombreuses mises en œuvre de gouvernance
existantes sont basées sur le modèle «  informatique
en tant que centre de coûts  » et, par conséquent, leur
principal objectif est la rentabilité. DevOps, en revanche,
est basé sur un modèle «  informatique en tant qu'outil
stratégique », avec une volonté d’accélérer l’innovation et
le délai de mise sur le marché. La lenteur des processus de
gouvernance existants non DevOps entrave l’innovation
et donne souvent l'impression que l'informatique est plus
un obstacle qu'un atout.
Une grande société de services financiers que nous avons
interrogée prend au minimum deux mois et 23 transferts
pour faire approuver un bon de commande. Dans un autre
exemple, un fournisseur de télécommunications mondial
prend au minimum quatre semaines pour faire approuver
une proposition pour le développement de nouveaux
logiciels, cinq semaines pour obtenir un environnement,
deux à trois semaines pour faire un changement de
pare-feu, et quatre à six semaines pour les tests de bout
en bout. Chacune de ces étapes est nécessaire pour faire
valider les processus d'approbation de la gouvernance par
l'intermédiaire de tickets de service. Ces processus sont
censés être mis en place pour « économiser de l’argent ».
Une gouvernance trop normative
Les cadres de gouvernance très normatifs fondés sur
des règles s'effondrent à l'échelle de l'entreprise. Dans
le paysage technologique d’une entreprise, avec des
systèmes d'exploitation différents, des mises en œuvre
de logiciels polyglottes et des attitudes diverses face au
risques, le nombre de fois où une exception aux règles est
nécessaire finit par faire que tout devient une exception,
ce qui sape complètement les objectifs d'une bonne
gouvernance.
24
Les mises en œuvre de gouvernance obsolète peinent
grandement à s'adapter à l'évolution rapide de la
technologie. Par exemple, si nous examinons l’évolution
de l’hébergement des applications (des serveurs physiques
aux serveurs virtuels, en passant par les machines
virtuelles hébergées dans le Cloud, les conteneurs et le
sans serveur), chaque étape de l'évolution nécessite des
règles de gouvernance. Le rythme de l’évolution de la
technologie rend pratiquement impossible d’essayer de
prescrire une gouvernance à un niveau de détail lié à la
mise en œuvre de la technologie, tout en veillant à ce
qu’elle reste appropriée.
Plus que de l'informatique
Une perception répandue est que DevOps est un
«  truc informatique  » ou une «  boîte à outils pour les
développeurs  », comme l’était Agile avant lui. En réalité,
bien que DevOps soit un modèle opérationnel plus
récent pour l'informatique, il est intrinsèquement lié à la
transformation numérique de l’ensemble de l’organisation
et le cadre de gouvernance doit englober toute
l’entreprise, et pas seulement l'informatique. Toutefois,
le modèle DevOps lui-même pose des problèmes de
gouvernance. Trop souvent, les méthodes de travail
DevOps, notamment la liberté et l’autonomie accordées
aux équipes, ont été mal interprétées par certaines équipes
comme une absence de processus ou de gouvernance
formelle, une idée fausse qui doit être prise en compte
lors de la mise en œuvre.
Le besoin d'informations en temps réel
Enfin, sans commentaire efficace, idéalement en
temps réel, il peut être difficile d’atteindre des niveaux
de gouvernance appropriés. Les environnements
d'application dynamiques, la publication rapide de
nouvelles fonctionnalités et l'adoption plus rapide
des nouvelles technologies ne font qu'augmenter
l'importance des informations stratégiques en temps réel
qui sous-tendent le modèle de gouvernance.
Rapport Enterprise DevOps 2020-21 25

Relever les défis

Faites en sorte que faire la bonne chose soit facile
Les équipes de gouvernance qui réussissent doivent
s'efforcer de travailler à un principe de gouvernance
global qui fait que faire la bonne chose, c'est facile. De
cette manière, le respect de la gouvernance devient la
voie de la moindre résistance, plutôt qu’une entrave ou
d’un obstacle à surmonter.
La fonction de gouvernance peut soutenir les équipes
DevOps en publiant des bonnes pratiques qui fournissent
des conseils utiles et réalisables. La création d’une culture
de partage des connaissances peut également rendre
l’ensemble de l’entreprise plus efficace et aider les équipes
et les individus à développer leur expérience et leurs
capacités.
Des principes, pas des règles
Tichaona Zororo, directeur de l'ISACA, l'organisation
qui publie le cadre de gouvernance COBIT, souligne un
principe clé lorsqu'il déclare que « La gouvernance devrait
être basée sur des principes et des résultats et non sur des
règles ».
Un excellent exemple de cette approche est la norme de
service numérique du gouvernement britannique, conçue
pour améliorer la prestation des services numériques par
les organismes du secteur public britannique. La norme
énonce 14 principes de haut niveau qui régissent le cycle
de vie complet d’un service numérique : voir The Service
Standard helps teams to create and run great public
services (La norme de service aide les équipes à créer et à
gérer de grands services publics).
Avant qu'un service donné ne soit mis en service, les
équipes doivent démontrer que leur service est conforme
aux normes définies, même si les spécificités de la mise
en œuvre de chaque équipe peuvent varier. Par exemple,
la norme n°  7 stipule «  Utiliser des méthodes de travail
agiles », mais n'impose pas les méthodes Scrum, DSDM,
Kanban ou toute autre méthode agile particulière. Les
méthodes de mise en œuvre sont laissées au choix de
chaque équipe, même si ce que l'équipe choisit doit
s'aligner sur les orientations plus détaillées.

La gouvernance ne consiste pas à adopter un état d’esprit

de commandement et de contrôle qui vise à imposer des
règles rigides pour contrôler la prestation de services
informatiques dans un monde informatique en évolution
rapide. Il s'agit plutôt de définir un ensemble de principes
fondamentaux ou de résultats auxquels les équipes et les
produits sont censés adhérer. Les équipes de gouvernance
doivent fournir des modèles, des cadres et des outils
communs qui aident les équipes à respecter ces normes,
tout en définissant clairement les attentes. Cela donne aux
équipes la possibilité de concevoir leurs propres mises en
œuvre, à condition qu'elles s'alignent sur les principes et
les résultats convenus.
Rapport Enterprise DevOps 2020-21 26

ADOPTER UN MODÈLE INNERSOURCE

Selon les principes fondamentaux de GitHub d'InnerSource11, la mise en œuvre
réussie de la gouvernance doit se fonder sur ces cinq principes clés :

Ouvrir
Démocratiser l'accès, créer des conditions équitables pour le partage ouvert du
travail, des idées et des réactions, et assurer un alignement culturel et stratégique.

Transparente
Veiller à ce que le processus et le produit soient visibles, principalement
en dissociant les communications du temps et de l’espace.

Participation
Partager le travail et permettre aux autres de le découvrir,
de l'utiliser et d'y contribuer facilement.

Collaboration
Travailler ensemble pour augmenter progressivement la qualité,
la distribution des connaissances et la vitesse d’expédition.

Gouvernance
Diriger, orienter et soutenir la communauté logicielle, à l’aide de
normes, de modèles, de rôles et de parrainage de cadres.

La gouvernance doit être considérée moins comme un Les lignes directrices et les artefacts de gouvernance
processus externe imposé aux équipes et plus comme un gérés via un modèle InnerSource apportent une propriété
ensemble de bonnes pratiques partagées qui rendent le partagée aux équipes et une volonté accrue d'utiliser et
travail meilleur et plus efficace. de suivre les directives de gouvernance.

Sur un plan très pratique, le fait de s'assurer que tout (du

code source des applications et des modèles architecturaux
aux normes de sécurité et aux méthodologies de
développement) est à la fois ouvert et transparent montre
clairement que chacun a la possibilité de contester ces
normes et de contribuer à leur amélioration.

11
GitHub, InnerSource, 2019
Rapport Enterprise DevOps 2020-21
Plateformes et architectures de référence exécutables
Les organisations les plus performantes créent des
plateformes technologiques en libre-service, étayées par
une documentation complète qui permet aux utilisateurs
de tirer parti de ces plateformes pour créer de meilleurs
produits. Ces plateformes partagées permettent aux
entreprises d’intégrer et de faciliter la gouvernance, tout
en permettant aux équipes de faire facilement la bonne
chose.
Une plateforme d’entreprise peut inclure la sécurité,
l’identité, la cohérence, la gestion des coûts et
l’automatisation du déploiement en tant que services
clés fournis. Chacune de ces plateformes en libre-service
aura une gouvernance «  intégrée  », de sorte que les
équipes qui utilisent la plateforme héritent des bonnes
pratiques de gouvernance au prix de peu ou pas d'effort.
À titre d’exemple, l’une des façons de s’assurer que les
coûts sont suivis avec précision et attribués aux produits
ou départements appropriés est d'utiliser des étiquettes
de ressources. L’utilisation de ces fonctions de gestion
des coûts peut être obligatoire dans la plateforme de
l’entreprise.
La DIAGRAMME
cohérence D’ÉTIQUETAGE
à l’échelle de
DESl’entreprise est souvent
RESSOURCES SOGETI un
INTERNES
réutilisation | normalisation
conception
mettre en
de l'architecture
œuvre créer
du cas commercial
qualité continue | sécurité | indicateurs | rapport
organisation | conformité | gouvernance
27
défi de gouvernance. Les entreprises peuvent avoir des
centaines de développeurs travaillant en équipes auto-
organisées, il est donc important d’avoir des pratiques de
mise en œuvre cohérentes dans l’ensemble du paysage
informatique. Presque toutes les entreprises utilisent des
architectures de référence avec des conseils sur les bonnes
pratiques pour créer et exécuter des applications, ainsi que
sur la façon d’intégrer la gouvernance et la sécurité. L’une
des pratiques de gouvernance les plus matures consiste à
rendre cette architecture de référence exécutable via des
ensembles de modèles, de scripts et d’outils, et à traduire
les architectures de référence au-delà des diagrammes
Visio et des documents Word en code lorsqu’elles sont
combinées avec des outils DevOps tels que l’infrastructure
en tant que code et la configuration en tant que code.
Combinées aux modèles d'application InnerSourcing
mentionnés précédemment, les équipes peuvent
contribuer à la création et à l'itération constante de ces
architectures de référence en tant que code, contribuant
ainsi à garantir un système de gouvernance dynamique et
efficace.
FIGURE 5
gestion du secret
déploiement continu Exécuter | Opérer
intégration continue
Durée d’exécution | Plateforme
observabilité | IA
Rapport Enterprise DevOps 2020-21
Gouvernance continue
Les approches traditionnelles de la gouvernance ont
largement reposé sur un processus d'inspection ou un
contrôle de la qualité avant la production/la publication,
ce qui n'est pas faisable à l'échelle et au rythme actuels.
En conséquence, les entreprises les plus performantes
adoptent des modèles de livraison continue pour la
gouvernance, afin de pouvoir offrir plus rapidement de
la valeur aux clients grâce à la publication fréquente de
nouvelles fonctionnalités logicielles.
Pour lutter contre la lourdeur des pratiques de
gouvernance, les entreprises s'orientent également vers
l'automatisation de leur gouvernance, ce qui réduit la
charge des services informatiques qui n'ont plus besoin
d'exécuter des flux d'approbation et de validation lents. Au
cœur de cette approche continue se trouvent les pipelines
CICD avec des étapes de gouvernance intégrées à chaque
pipeline, qui permettent la diffusion fréquente de produits
sûrs et de haute qualité aux clients. La gouvernance
continue définit les principes qui peuvent être mis en
œuvre grâce à des contrôles logiciels automatisés qui
favorisent le code d’une étape du pipeline à l’autre.
28
Obtenir des commentaires et des informations
Il a toujours été difficile d'obtenir une visibilité sur l'état
actuel de l'adhésion d'une organisation à ses principes de
gouvernance. Il a également été difficile de mesurer les
avantages organisationnels de cette gouvernance.
L’adoption d’Enterprise DevOps résout ce problème. L'un
des principes clés de DevOps est de créer des boucles de
rétroaction efficaces  : plus le cycle de commentaires est
rapide, plus une organisation peut apprendre rapidement
ce qui fonctionne et s'adapter en conséquence.
Les entreprises se tournent de plus en plus vers l'IA et les
plateformes de Machine Learning pour relever ce défi.
Les équipes de gouvernance utilisent cette technologie
pour filtrer et corréler les données afin de transformer
le volume important de données généré par les chaînes
d'outils DevOps et les plateformes Cloud en informations
exploitables qu’elles peuvent utiliser pour optimiser leurs
processus de gouvernance. En filtrant et en corrélant les
données, les équipes peuvent se concentrer sur la prise
des mesures correctives nécessaires sans être embourbées
dans la quantité de données qui ont été collectées.
Rapport Enterprise DevOps 2020-21
ÉTUDE DE CAS DE GOUVERNANCE
Pour une grande compagnie d’assurance européenne, la
bonne gouvernance est essentielle pour éviter ce qu’elle
appelle «  le chaos et les problèmes de sécurité  » dans
plus de 20 technologies et courants de développement
différents, chacun ayant ses propres architectures de
domaine et ses propres équipes DevOps. Avec plus de
700 professionnels DevOps actifs, une gouvernance
efficace garantit que ces équipes fonctionnent de manière
cohérente, tout en se conformant aux exigences de
l’entreprise et de la réglementation, le tout sans entraver
la rapidité du développement.
Pour intégrer la bonne gouvernance, l’assureur a mis
en place une équipe centrale qui surveille et soutient
l’adhésion aux chaînes d'outils de développement. À leur
tour, ces chaînes d'outils ont été rationalisées avec l’aide
d’architectes d’entreprise et d’architectes de domaine
pour apporter plus de contrôle et d’efficacité, et toute
perturbation, tout problème de sécurité ou toute
utilisation non autorisée d’outils peuvent être rapidement
corrigés.
GOUVERNANCE - RESSOURCES POUR LA PROCHAINE ÉTAPE
Faites en sorte que faire la bonne chose soit facile
En savoir plus que le cadre d’adoption du Cloud
Cadre d’adoption du Cloud - Outil de
référence pour la gouvernance
Des principes, pas des règles
En savoir plus sur la norme de service Digital
by Default (numérique par défaut)
Adopter un modèle InnerSource
En savoir plus sur l’introduction de GitHub à InnerSource
Plateformes et architectures de référence exécutables
Microsoft Azure Well-Architected Review
Gouvernance continue
Comment Azure aborde l’automatisation de la gouvernance
Obtenir des commentaires et des informations
En savoir plus sur les outils de surveillance du Cloud
29
Comme DevOps concerne autant les personnes que
les technologies habilitantes, la communication est
essentielle dans l'approche de la gouvernance de
l'entreprise. Un portail de services informatiques
fournit des informations sur les offres et les services
destinés aux équipes, ainsi qu’un ensemble complet de
tutoriels et d’autres documents pertinents. L'équipe de
communication supervise les événements en cours et
les plans futurs, tandis qu'un forum de communication
est utilisé pour le partage des connaissances entre les
membres de l'équipe, ce qui réduit considérablement les
frictions et les interruptions de travail.
Cette équipe de gouvernance est très active et maintient
son élan via un canal de notifications et de mises à jour,
ainsi qu’à des listes de diffusion régulières. Pour l'assureur,
cet engagement à respecter les bonnes pratiques grâce
à la gouvernance garantit que ses équipes DevOps
travaillent en tandem pour soutenir les objectifs de
l'entreprise de manière efficace et conforme.
« Nous sommes passés d'une "équipe" à
une "équipe sans friction", tandis que la
bonne gouvernance nous aide également
à maîtriser les coûts de développement. »
Chef d'équipe
Équipe de support du Cloud DevOps
Rapport Enterprise DevOps 2020-21 30

Qualité
Sogeti définit la qualité comme Les entreprises, plus que jamais auparavant, ont un besoin
urgent de mettre en œuvre l'assurance qualité dans leurs
« l'ensemble des traits et caractéristiques
systèmes, leur ingénierie et leur environnement afin
d’un produit ou d’un service qui influent d'assurer la qualité de manière constante et continue.
sur son aptitude à satisfaire des besoins Dans l'état actuel des choses, de nombreuses entreprises
déclarés ou implicites13 ». attendent une «  qualité rapide  », mais ne vérifient les
défauts qu'avant le déploiement du code.
Parvenir à cet objectif nécessite l’ingénierie de la qualité en
tant que discipline, ce qui permet aux équipes DevOps de
fournir une valeur commerciale de haute qualité en offrant
un ensemble de principes et de pratiques qui assurent la
qualité des produits et des services. Les entreprises les
plus performantes demandent à leurs équipes DevOps de
générer cette valeur, avec la bonne qualité, à des cadences
régulières et continues. En d’autres termes, elles mettent en
œuvre une qualité continue dans le cadre d'une prestation
continue.

THÈMES D'ASSURANCE ET DE TEST DE LA QUALITÉ ET ACTIVITÉS DEVOPS FIGURE 6

ts | Responsabilité et rôles | Surveillance et contrôle | Gestion des anomalies | Génération

t de tes de
ité e rap
qual po
rts
de et
ie ale
ég
at r
de test et d’analyse des risques de qualité | Critères d’acceptation | Mesures de qualité | Rév
te
r
St

gie
s
isio
traté ns
S

P L ANIFIER DÉPLOYER
R
RE
G
SU
RV
EI
LL
ER

ti o n
Con

TÉ
IN

lu a
cep

CO DE E X ÉC UTER
va
ti o

té
n

es
se

t
d

te ta
sts ul
| G ré s
e sti o les
n d es données des tests | Automatisation des tests | Exécution des tests | Enqu ê te s ur

Estimation | Planification | Infrastructure | Outils | Indicateurs | Amélioration continue

Organiser les thèmes Exécuter les thèmes Activités DevOps

12
OCDE, Definition of Quality- ISO (Définition de la qualité - ISO), 2020
13
Sogeti et Capgemini, Quality for DevOps teams (Qualité pour les équipes DevOps), 2019
Rapport Enterprise DevOps 2020-21 31

SUR UNE ÉCHELLE DE 1 À 10, COMMENT ÉVALUERIEZ-VOUS LA MATURITÉ DE VOTRE PROJET SUR LA QUALITÉ CLOUD ET DEVOPS ? FIGURE 7

19,3 %

14 % 14 % 14 %
11,9 %
10,5 %

7%
5,2 %
3,5 %

0%
1 2 3 4 5 6 7 8 9 10

À l'inverse, les principales organisations DevOps sont
axées sur la «  qualité de bout en bout  ». Bien qu’elles
continuent à le faire grâce à des procédures de vérification
de code approfondies, elles sont également en mesure de
valider la qualité de ce qui est livré avant, pendant et après
le déploiement.
La qualité doit être intégrée à chaque processus afin
que les fonctions et les caractéristiques d’un produit
fonctionnent parfaitement dès le début. La qualité
à  l’échelle de l’entreprise va bien au-delà des tests
continus et de l’automatisation des tests, car l’ingénierie
de qualité doit également se concentrer sur la livraison,
le comportement, les pratiques et de nombreuses autres
activités d'assurance qualité et de test. Le cadre des
activités d'assurance qualité de Sogeti montre certains des
éléments clés de cette approche (Figure 6).
L’enquête de Sogeti auprès des praticiens du Cloud et de
DevOps a révélé un problème de « maturité de la qualité »
dans le secteur (Figure  7). Comme de nombreuses
entreprises sont passées d’équipes informatiques
cloisonnées à plusieurs équipes DevOps avec des champs
d'action définis, nos enquêtes nous montrent que les
divergences entre les pratiques de qualité de chaque
équipe sont très variables, et qu’il est nécessaire de garantir
la cohérence. Lorsqu'on a demandé aux professionnels
de l'informatique d'évaluer leur maturité en matière
de DevOps et de Cloud, leurs réponses ont montré une
grande divergence dans les niveaux de maturité, comme
l'illustre le diagramme ci-dessus. En coordonnant nos
recherches et en nous inspirant de certains enseignements
clés tirés du livre de Sogeti « Quality for DevOps teams »
(La qualité pour les équipes DevOps), nous voyons
clairement qu'un certain nombre de défis freinent la
maturité des organisations.
Rapport Enterprise DevOps 2020-21
Quels sont les défis ?
Trouver l'équilibre entre rapidité et qualité
Il a toujours été difficile de trouver le bon équilibre entre
qualité et rapidité de livraison, comme en témoignent
les conclusions de l'étude McKinsey Developer Velocity
Index. Alors que la moitié des entreprises signalent
que l’obtention d’un examen par les pairs est une étape
importante du processus de qualité, seulement 7 % des
personnes interrogées déclarent pouvoir obtenir des
résultats d’examen par les pairs en moins d’une journée.
Et 38  % ont déclaré qu’ils doivent attendre entre trois
et cinq  jours, des délais apparemment insignifiants,
mais qui entravent considérablement la rapidité de
développement. Les entreprises veulent la bonne qualité
au bon moment et ne veulent pas attendre avant de
le livrer. Pour atteindre cet équilibre, de nombreuses
entreprises se sont tournées vers l’automatisation.
L’automatisation des tests est souvent utilisée comme
solution tout-en-un pour tenir compte du dilemme
rapidité/qualité, mais elle ne résout pas le fait que
tout ne peut pas être automatisé, de la planification
à la production. Nous avons besoin de solutions plus
complètes et plus étendues.
EN GÉNÉRAL, COMBIEN DE TEMPS FAUT-IL AUX DÉVELOPPEURS POUR RÉCUPÉRER LE RÉSULTAT DE L’EXAMEN PAR LES PAIRS ?
Moins d'un jour 1 à 2 jours 3 à 5 jours
7 31 35
R É V I S I O N S D U CO D E
32
Rechercher une maturité cohérente et l'appliquer
Un facteur clé de la gestion de la qualité est de veiller
à ce que les équipes interfonctionnelles appliquent les
pratiques d'assurance qualité de manière cohérente dans
toute l'entreprise. Les entreprises prospères optimisent
l’efficacité de plusieurs équipes auto-organisées en
réutilisant les connaissances, tout en les faisant adhérer
à des cadres de test et à des chaînes d'outils convenus.
Cependant, l'application de la cohérence est un problème,
non seulement dans le processus de test mais aussi
dans tous les principes de conception, les normes et les
meilleures pratiques pour la création d’architectures
DevOps et Cloud.
Interdépendances complexes
Les produits, les applications et les systèmes ont
généralement de nombreuses interdépendances, ce
qui rend le lancement de nouvelles fonctionnalités à la
fois difficile et lent. Dans de nombreuses entreprises, les
propriétaires de produits ne peuvent pas simplement
se concentrer sur leur propre produit car une petite
modification (par exemple, une mise à jour réglementaire)
peut nécessiter des changements en aval de tous les
autres produits, systèmes et applications qui dépendent
de leur produit. Il en résulte que ce qui devrait être un
simple changement devient une mise à jour complexe,
impliquant plusieurs équipes et plusieurs produits. Toute
cette complexité ralentit le cycle de lancement. Ces
interdépendances ne sont pas seulement entre les équipes
DevOps, mais aussi avec les systèmes et les produits en
dehors du cercle d’influence de l’entreprise, comme le
SaaS ou le COTS, qui rendent encore plus difficile pour
DevOps de livrer aux vitesses requises par l'entreprise.
FIGURE 8
6 à 7 jours Plus d'une semaine
18 6
Rapport Enterprise DevOps 2020-21 33

PROCÉDURES DU SYSTÈME DE CONTRÔLE AUTOMATISÉ FIGURE 9

E N G É N É R A L , À Q U E L L E F R É Q U E N C E L E S P R O C É D U R E S D E T E S T S U I VA N T E S S O N T - E L L E S E N T I È R E M E N T AU TO M AT I S É E S E T I M P L I Q U E N T - E L L E S D E S AC T I V I T É S
MANUELLES MINIMALES

Presque jamais Parfois De temps en temps Souvent Presque toujours

Tests unitaires

1 8 21 47 23
Test d'intégration

1 7 20 41 31
Test d'acceptation

3 5 20 41 30
Tests de performances

2 4 15 38 41
0 20 40 60 80 100

Manque d'automatisation des tests Le développement piloté par les tests (Test Driven
Le manque d'automatisation des tests n'est certainement Development, TDD) permet d'automatiser les tests et
pas un nouveau défi et reste un obstacle à long terme d'évaluer en permanence la qualité fonctionnelle du code.
à l'obtention de la qualité dans DevOps. Nos recherches Le TDD peut également offrir des avantages importants
montrent que seul un tiers des entreprises déclarent pour la qualité, car il oblige les équipes à clarifier les
automatiser «  occasionnellement  » ou «  parfois  » exigences avant de commencer le développement.
automatiser leurs processus de test, ce qui signifie que de Pourtant, nos recherches montrent que 31 % des
nombreuses entreprises laissent des lacunes importantes entreprises n’ont pas systématiquement adopté une
en matière de qualité et/ou s'appuient sur des tests approche TDD. En outre, elles effectuent des tests unitaires
manuels lents et inefficaces. avant le développement moins de 40 % du temps.

Les tests de performances étant pratiquement impossibles

à effectuer manuellement, il n’est pas surprenant
que les entreprises soient deux fois plus susceptibles
d’automatiser leurs tests de performances que les tests
unitaires. Si un niveau élevé d’automatisation doit être un
objectif pour les tests unitaires, un certain niveau de test
manuel n’est pas un problème.
Rapport Enterprise DevOps 2020-21
Réaliser un changement culturel et définir le succès
Les développeurs, en général, n’aiment pas les tests, bien
que les bons développeurs fournissent des tests rigoureux.
Les entreprises doivent mettre en place des politiques qui
permettent aux développeurs de fournir de la qualité,
sans avoir à faire partie d'une phase de test discrète et
distincte. La qualité exige un changement de culture,
avec des directives claires selon lesquelles les tests sont la
responsabilité de chacun, et des indicateurs pour mesurer
le succès. L’idée selon laquelle « ce qui est mesuré est fait »
s’applique à de nombreuses équipes de développeurs.
Sans mesures concrètes et sans vision, les équipes ne se
concentreront pas sur la qualité ou essaieront de mettre
en place des contrôles de qualité aux mauvais endroits.
34
Ces dernières années, les entretiens menés par Sogeti
ont révélé que les équipes informatiques ont constaté
une augmentation constante de la rapidité, mais aussi
une augmentation du temps nécessaire pour se remettre
des erreurs et mettre en œuvre de nouvelles solutions  :
les entreprises doivent passer de la vitesse à la stabilité.
La qualité doit être intégrée à chaque processus et aux
attitudes des développeurs. Le simple fait de connaître
le nombre de bugs ouverts ne suffit pas à informer
les équipes sur la qualité d'un produit développé par
l'équipe DevOps. Dans de nombreux cas, le rapport sur
les niveaux de qualité représente un défi en lui-même. Au
lieu de simplement signaler le nombre de bugs ouverts,
nous devons voir comment les tests et les systèmes se
comportent au fil du temps. La qualité doit tenir compte
de ce que ressent votre équipe DevOps à chaque étape
du développement et du pipeline de lancement, depuis
la conception jusqu'à l'exécution. Si votre organisation ne
dispose pas de bons indicateurs sur la qualité du système,
vos équipes seront toujours inefficaces et vos produits
instables.
Rapport Enterprise DevOps 2020-21 35

Relever les défis

Réaliser le changement culturel avec des objectifs de Parallèlement à ces défis tiers, les interdépendances
qualité clairs et en toute transparence s’étendent également aux équipes DevOps internes des
Si vos collaborateurs savent ce qu'on attend d'eux, il entreprises. Historiquement, les équipes ont eu tendance à
leur sera plus facile de faire évoluer la culture vers une se pencher uniquement sur leur propre produit, en prenant
approche de la qualité de bout en bout dans Enterprise soin de sa qualité et en ne pensant pas au processus
DevOps. Selon l’enquête Sogeti, les entreprises qui d’intégration et aux systèmes dépendants dans lesquels
décrivent clairement et avec succès les caractéristiques de il sera mis en cascade. L’une des façons d’y parvenir
qualité requises des systèmes sont beaucoup plus efficaces consiste à mettre en place des pratiques spécifiques, des
dans l'automatisation des tests, et ont une qualité globale infrastructures et des équipes indépendantes de test de
des systèmes plus élevée et plus prévisible. régression de bout en bout, parallèlement à vos stratégies
de déploiement, afin de s'assurer que le système global
prend en charge chacun des petits services déployés.
Nous savons que les entreprises s'appuient sur des
normes et des réglementations du secteur, comme
Déterminer qui prend la responsabilité de la qualité
la norme ISO 25010, pour la qualité des produits et
d’un système entier, par opposition à un produit
la qualité d'utilisation, mais au niveau culturel, elles
unique, reste un défi majeur. Les organisations les plus
doivent aller au-delà de ces normes externes. De
performantes mettent souvent en place une équipe
nombreuses entreprises très performantes indiquent
distincte dont l'unique responsabilité est d'effectuer
clairement à leurs équipes produit que la qualité est
des tests de régression de bout en bout. Ces équipes
une pratique collaborative, et en rendant des équipes
horizontales assurent l'approvisionnement automatisé
entières responsables, le temps passé à assurer la
des environnements et des tests, tout en prenant la
qualité est considéré comme une nécessité plutôt qu'un
responsabilité de l'intégration de produits tels que les
inconvénient.
applications COTS ou les services SaaS qui ne nécessitent
pas l'utilisation d'une équipe DevOps complète.
La qualité doit être un objectif que les entreprises et les
employés s'efforcent d'atteindre. Elle doit être enracinée
Les entreprises qui sont plus avancées dans leurs pratiques
dans les processus et les attentes du comportement
DevOps doivent envisager de s’attaquer à l’intégration
professionnel, plutôt que d’être considérée comme un
de plusieurs produits interdépendants en adoptant des
cerceau à franchir.
architectures et une stratégie de lancement correspondante
spécifiquement conçue pour soutenir le déploiement
Comprendre votre chaîne d'approvisionnement et l’intégration de nouvelles fonctionnalités. Cela peut
logicielle inclure des versions canari et des déploiements en anneau
90  % des systèmes informatiques utilisent actuellement vers des sous-sections plus petites de clients (versions
du code open source. il est donc essentiel pour les bêta) avec une exécution de test hautement automatisée
entreprises de valider la qualité des logiciels fournis pour agréger les commentaires sans diffuser largement les
par les chaînes d’approvisionnement logicielles tierces. mises à jour instables.
En l’absence d’informations sur la qualité des chaînes
d’approvisionnement, il est impossible de rendre compte
pleinement de la qualité globale d’un produit livré. La
gestion de la qualité du code emprunté à l’intérieur
de votre chaîne d’approvisionnement logicielle peut
être atténuée à l’aide d’une nomenclature logicielle,
un document qui fournit une liste complète de tous les
composants d’un logiciel donné.
Rapport Enterprise DevOps 2020-21
Assurer la cohérence avec une politique de qualité
claire
La qualité doit être cohérente. Et le pont entre l'ensemble
de l'entreprise et les équipes DevOps est grandement
amélioré lorsque les principes et les politiques sur la qualité
de la prestation sont spécifiés au niveau organisationnel.
Les entreprises doivent être animées par une mission, une
vision et une stratégie, et les équipes DevOps doivent les
mettre en œuvre dans des processus qui sont intégrés dans
les produits logiciels et soutenus par ceux-ci. La politique
de qualité et de test d'une entreprise traduit la mission, la
vision et la stratégie commerciale en principes, approches
et objectifs qui décrivent comment l'entreprise traite les
personnes, les ressources et les méthodes impliquées dans
le processus de qualité et de test.
En établissant ces principes et ces politiques généraux
de qualité, les entreprises peuvent ouvrir la voie pour
permettre aux équipes DevOps de faire la bonne chose,
facilement. Cela rendra également les membres de
l’équipe plus heureux et plus performants, et garantira
que l'entreprise génère de la valeur commerciale grâce
à un alignement entre les équipes.
Ces principes et politiques de
également couvrir l’utilisation des chaînes d'outils et
des infrastructures de test. Nous savons que certaines
entreprises donnent aux équipes DevOps la liberté de
choisir les outils et les infrastructures qu’elles préfèrent,
mais cela n'est viable que si elles respectent les principes
acceptés qui ont été clairement établis. Lorsqu'elles ont
trop de liberté, les équipes deviennent souvent inefficaces,
ce qui entraîne une qualité imprévisible. Ce dont toutes
les entreprises ont plutôt besoin, ce sont des modèles
standardisés pour les ressources et l'automatisation du
Cloud, conçus pour fournir des systèmes cohérents prêts
à l'emploi.
14
Capgemini, World Quality Report 2019 (Rapport mondial sur la qualité 2019), 2019
36
Équilibrez rapidité et qualité avec efficacité grâce à
l'automatisation de vos tests
Si la rapidité et la qualité de l'automatisation des tests
sont indéniables dans le cycle DevOps, de nombreuses
entreprises ont du mal à adopter un système qui
s'adapte correctement. Le dernier rapport de Sogeti et
Capgemini sur les tests continus a révélé que seulement
24 % des cas de tests fonctionnels et de performance
sont automatisés, alors que seulement 22 % des cas
de tests sont automatisés dans les sprints. Pour lutter
contre ce phénomène, les équipes doivent être prêtes
à passer de la simple automatisation d’un script de test
fonctionnel avec une case à cocher, à un positionnement
de la qualité et de l'automatisation au cœur même du
cycle de développement. Le principal obstacle est ici de
savoir comment supprimer le goulot d'étranglement que
constituent les tests, et en faire une pratique allégée.
Le dernier rapport mondial sur la qualité de Sogeti et
Capgemini recommande14 la conception d'infrastructures
automatisées intelligentes pour prendre en charge le cycle
de développement. Le rapport ajoute que l'automatisation
intelligente est appelée à faire une différence significative
dans les tests en trouvant et en corrigeant rapidement
qualité doivent les problèmes, tandis qu'aider les équipes combinées de
test et de développement à décider quelles modifications
donneront les résultats les plus rapides et les meilleurs,
sera primordial pour obtenir des résultats de qualité.
Rapport Enterprise DevOps 2020-21 37

ÉTUDE DE CAS SUR LA QUALITÉ

La qualité était une priorité essentielle pour une grande
entreprise du secteur des transports qui voulait migrer
d'un système monolithique hérité vers des systèmes
modernes distribués. La technologie existante devenant
obsolète et de plus en plus difficile à prendre en charge,
l'objectif de l'entreprise était de se moderniser tout en
veillant à ce que les nouveaux systèmes offrent la même
valeur commerciale (ou plus) que le système existant.
Le nouveau modèle distribué signifiait que de nombreuses
équipes DevOps travaillaient sur une série de systèmes
différents. La direction de l'entreprise a donc cherché à
garder une vue d'ensemble des progrès de la migration
afin de s'assurer que les activités en cours ne seraient pas
affectées par les changements.
Sogeti, partenaire de services technologiques à long
terme, a créé un «  moniteur de confiance  » pour
l'entreprise. Grâce à des outils comme un tableau de bord
automatisé en temps réel, toutes les équipes (plus de 10,
principalement DevOps et Scrum) ont régulièrement
publié leurs informations sur la qualité et les risques des
nouveaux systèmes.
Sur la base de ces informations, Sogeti a analysé une
série d'indicateurs mesurés, comprenant à la fois des
données matérielles (telles que des informations sur les
installations réussies, les fonctionnalités, les performances
et la continuité des activités) et des données logicielles
(telles qu'un questionnaire périodique adressé à l'équipe
opérationnelle et aux utilisateurs finaux). Les données
ont été compilées en un seul «  indice de confiance  ».
Cela a montré à quel point les équipes de livraison de
la migration étaient confiantes dans la robustesse et
la qualité des différents systèmes. Cela a également
permis d'identifier les domaines dans lesquels des efforts
supplémentaires étaient nécessaires et a montré quels
systèmes fonctionnaient comme prévu.
Chaque mois, pendant plusieurs années, cet indice de
confiance a été communiqué à la direction de l'entreprise
et est devenu une boussole fiable pour orienter la
transition globale de l'entreprise vers un paysage
informatique moderne.

QUALITÉ - RESSOURCES POUR LA PROCHAINE ÉTAPE

Réaliser le changement culturel avec des objectifs

de qualité clairs et en toute transparence
En savoir plus sur le Rapport sur les tests continus

Comprendre comment votre chaîne d'approvisionnement

et les équipes DevOps s'interconnectent
Découvrez comment GitHub sécurise les logiciels open source

Assurer la cohérence avec une politique de qualité claire

Comment Sogeti définit des politiques
claires en matière de qualité

Équilibrez rapidité et qualité avec efficacité grâce

à l'automatisation de vos tests
Plus d'informations dans le Rapport
mondial sur la qualité Capgemini
Rapport Enterprise DevOps 2020-21
Sécurité
Enterprise DevOps et, avec lui, l'adoption
du Cloud à grande échelle, représentent
un changement radical pour les équipes
de sécurité de l'information.
Les experts en sécurité de l’information ont accès à
des fonctionnalités dont ils ne pouvaient que rêver
auparavant. Par exemple, nous avons maintenant la
possibilité de retracer n'importe quel morceau de code
depuis le déploiement en production jusqu'au cycle de vie
du développement logiciel, de comprendre les validations
qui ont eu lieu à chaque étape, jusqu'à l'archivage initial
du code. Toutefois, nous vivons également dans un monde
où de nombreuses équipes procèdent à de multiples
déploiements de code par jour, chacun d'entre eux ayant
le potentiel d'introduire une vulnérabilité exploitable si les
principes de sécurité ne sont pas intégrés dans l'ensemble
du cycle de vie et de l'organisation DevOps.
Bien entendu, la sécurité de l'information est une discipline
plus large que le seul exemple de code d'application cité
plus haut. Comme l'indique la norme ISO 27002 (Code
de bonne pratique pour le management de la sécurité
de l'information) ; « La participation de tous les salariés
d’un organisme est indispensable à une bonne gestion de
la sécurité de l’information ». La sécurité a également un
impact réel sur l’entreprise, car les recherches sur l'IRD ont
clairement montré que la sécurité et la conformité étaient
le deuxième facteur pondéré le plus important (23 %)
sur la différence entre les performances des entreprises
des premier et deuxième quartiles. La sécurité n’est pas
seulement un coût, elle est également un facteur de
performance.
38
DevOps aide les entreprises à publier des logiciels plus
rapidement, mais il peut également aider à répondre aux
besoins en matière de sécurité lors du développement
de solutions logicielles, puis de leur exécution en
production. Lorsque la sécurité est intégrée à l’ensemble
de l’entreprise, elle contribue à accélérer et à sécuriser la
livraison de logiciels et à assurer une gouvernance et un
contrôle cohérents. Comme pour la gouvernance, lorsque
les équipes se sentent responsables de leurs produits,
et que la sécurité est un objectif commun, les produits
sont beaucoup plus susceptibles d'être sécurisés, et les
contributeurs DevOps l'intégreront dans leurs systèmes
et leur code. La sécurité doit être intégrée au cycle de vie
complet des systèmes et des équipes, et les entreprises
les plus performantes se tournent de plus en plus souvent
vers l’automatisation pour atteindre cette cohérence de
manière rentable.
Malheureusement, il n’existe pas d’approche «  unique  »
de la sécurité. Chaque application a plutôt ses propres
exigences et contraintes, de sorte que les pratiques
doivent être adaptées à ses processus, exigences de
sécurité et procédures opérationnelles. Les entreprises ont
besoin d’un ensemble de principes et de réglementations
qui guident leur mise en œuvre de la sécurité tout au long
du cycle de développement logiciel complet (SDLC).
Rapport Enterprise DevOps 2020-21
Quels sont les défis ?
TAU X D E CROIS S AN CE COM POSÉ A NNUEL DES REVENUS, 2 0 14-2 01 8 FIGURE 11
2%
1% 1%
Quatrième quartile Troisième quartile Deuxième quartile
Absence d'une approche globale de la sécurité
17 % des entreprises interrogées pour le rapport sur l'IRD
ont déclaré les vulnérabilités de sécurité que «  pour une
version majeure  » ou «  uniquement lors de la mise en
production », et seulement 46 % des entreprises intègrent
des outils de sécurité dans leurs pipelines DevOps. Alors
que 68 % des personnes interrogées ont déclaré que
«  la sécurité était l'affaire de tous  », seuls 40  % environ
intégraient des exigences de sécurité au cours de la phase
de conception, collaboraient sur des modèles de menaces
et établissaient des priorités en matière d'exigences de
sécurité dans le cadre de leurs retards de développement.
PARMI LES PRATIQUES DE SÉCURITÉ SUIVANTES, QUELLES SONT CELLES QUI S'APPLIQUENT ACTUELLEMENT À VOTRE ORGANISATION ?
68 %
La sécurité est la responsabilité de tous (par exemple,
il y a une équipe de sécurité centralisée ; des experts en
sécurité qualifiés sont présents dans presque toutes les
équipes ;
Chaque développeur est responsable de la sécurisation
de son code
47 %
Nous disposons d’une équipe centralisée pour gérer la
sécurité du code et du package open source utilisés par
notre entreprise
46 %
Les outils de sécurité sont intégrés dans le pipeline
d’intégration de développement
39
Pris collectivement, il est clair que les entreprises
n'adoptent pas l'approche globale et systémique de la
5% sécurité nécessaire pour mettre en œuvre un modèle
DevOps rapide en toute sécurité. Cela est renforcé par
les résultats de l’enquête concernant le temps de réponse
pour résoudre les violations majeures de sécurité. 6 %
des personnes interrogées ont déclaré qu’il faudrait des
«  semaines  », 17  % ont indiqué avoir besoin d'«  entre
3 jours et une semaine » pour résoudre le problème. Seuls
7 % ont déclaré avoir la capacité de résoudre une violation
majeure en moins d’une heure.
Sécuriser l'open source
L'écart entre l'adoption de l'open source et la capacité
Premier quartile
des entreprises à utiliser leur code open source en toute
sécurité est l'une des autres informations fascinantes qui
ressortent des recherches sur l'IRD. Bien que 65 % des
entreprises déclarent qu'elles «  tirent parti souvent ou
presque toujours de l'open source pour le développement
de produits », moins de 20 % analysent automatiquement
ces composants à la recherche de vulnérabilités et
y remédient avant leur déploiement.
Le déploiement de code dont les vulnérabilités sont
connues rend les entreprises vulnérables aux attaques.
De récentes recherches publiées dans le rapport sur
L'état des vulnérabilités de sécurité de l'open source ont
montré que le nombre de vulnérabilités des logiciels open
source est passé de 4 100 en 2018 à 6 100 en 2019, soit une
augmentation de 50 % d'une année sur l'autre.
FIGURE 10
44 % 41 %
Le personnel de sécurité examine et approuve le Les exigences de sécurité sont traitées comme des
changement de code avant le déploiement contraintes de conception et les propriétaires de
produits font appel à des experts en sécurité dès la
définition des exigences et la phase de conception
34 %
Nous disposons d’une équipe centralisée de chercheurs
en sécurité
40 %
Les exigences de sécurité sont prioritaires dans le cadre
du backlog de produit
42 %
Les équipes de sécurité et de développement collaborent
sur les modèles de menaces 30 %
Les développeurs peuvent fournir une sécurité du code
et du package open source utilisés par notre entreprise
Rapport Enterprise DevOps 2020-21 40

Si l'adoption de l'open source offre d'énormes avantages Manque de contrôle et d'investissement au niveau de
aux entreprises, elle pose également des problèmes de la direction
sécurité majeurs. Les entreprises doivent comprendre Alors que l'augmentation des réglementations fédérales
où l’open source est utilisé dans leurs applications et et multinationales sur les données a entraîné une forte
respecter strictement les bonnes pratiques de sécurité de hausse des initiatives de sécurité des données des
l'open source tout au long du cycle de développement entreprises, les principaux obstacles ont été l’absence
logiciel. de mise en place organisationnelle sur la sécurité et le
financement insuffisant des initiatives de sécurité. Près de
Le défi de la sécurité dans le Cloud la moitié des entreprises ont la cybersécurité à l’ordre du
jour de leur direction au moins une fois par trimestre, selon
Malgré les efforts des fournisseurs de Cloud, de
l'enquête de Deloitte sur l'avenir de la cybersécurité15.
nombreuses entreprises semblent avoir du mal à
Toutefois, seulement 4 % des personnes interrogées
sécuriser leurs environnements Cloud. Il y a eu de
déclarent que la cybersécurité est à l’ordre du jour de
nombreux cas très médiatisés de violations de la sécurité
leur direction une fois par mois, malgré les pressions
dans les environnements Cloud, en raison d’une erreur
réglementaires croissantes qui rendent les dirigeants des
humaine qui a entraîné des systèmes mal configurés,
entreprises personnellement responsables de la sécurité
d'un manque de compétences clés, de négligence ou
des données.
d'initiés de l’entreprise ayant des intentions malveillantes.
De nombreuses entreprises éprouvent des difficultés
à passer du modèle traditionnel de centre de données
de type «  sécurité du périmètre (réseau)  » à l’approche
multicouche de « défense en profondeur » recommandée
dans les environnements Cloud. Les professionnels de
la sécurité doivent acquérir de nouvelles compétences
et de nouvelles approches afin d'assurer une sécurité
Cloud efficace. Pour de nombreuses entreprises, cette
transformation est en retard par rapport à leur adoption
du Cloud, ce qui crée une faille de sécurité qui les rend
vulnérables.

15
Deloitte, The Future of Cyber Security 2019 (L’avenir de la cybersécurité 2019), 2019
Rapport Enterprise DevOps 2020-21
Relever les défis
L’adoption de DevOps, qui met l'accent sur
l'automatisation et le partage des responsabilités, peut
aboutir à des systèmes sécurisés conformes aux directives
de sécurité et capables de résister aux menaces de sécurité
existantes, s’ils sont mis en œuvre correctement.
Relever les défis de la sécurité dans le cadre d’une
transformation Enterprise DevOps nécessite une
combinaison de principes clés, d’architectures normalisées
(autrement appelées «  plateformes  »), de conception
organisationnelle et d’automatisation.
Adopter le modèle Zero Trust
Le changement d’état d’esprit fondamental, en particulier
pour les entreprises qui sont passées de l’hébergement
sur site à un modèle axé sur le Cloud dans le cadre de
leur adoption DevOps, est le modèle Zero Trust. Microsoft
définit Zero Trust comme suit : « Au lieu de supposer que
tout ce qui se trouve derrière le pare-feu de l’entreprise est
sécurisé, le modèle Zero Trust suppose une violation de
sécurité et vérifie chaque requête comme si elle provenait
d’un réseau ouvert... Zero Trust nous apprend à ne jamais
faire confiance et à toujours vérifier ».
Les lignes directrices de Zero Trust sont les suivantes :
• Vérification explicite. Les opérations
d’authentification et d’autorisation sont
systématiquement effectuées en fonction de
l’intégralité des points de données disponibles,
notamment l’identité de l’utilisateur, son
emplacement, l’intégrité de l’appareil
utilisé, le service ou la charge de travail, la
classification des données et les anomalies.
• Accès basé sur les privilèges minimum. Les
utilisateurs se voient accorder des droits d’accès
strictement nécessaire et juste-à-temps (JIT/JEA).
Il convient d’appliquer des stratégies adaptées aux
risques potentiels, mais aussi de prendre des mesures
visant à protéger les données et la productivité.
• Anticipation des violations. Grâce à la
segmentation de l’accès par réseau, utilisateur,
appareil et application, les répercussions
d’une violation potentielle sont réduites, et les
mouvements latéraux évités. Chiffrement de toutes
les sessions de bout en bout. Vous pouvez analyser
les données pour gagner en visibilité, assurer la
détection des menaces et renforcer vos défenses.
Pour en savoir plus sur la façon dont votre entreprise peut
adopter un modèle Zero Trust, cliquez ici.
41
Sécuriser le cycle de vie du développement et décaler
à gauche
Depuis le célèbre mémo de Bill Gate sur l'informatique
sécurisée en 2002, le rôle des développeurs de logiciels
dans la sécurité et l’importance de l’intégration de la
sécurité dans le cycle de développement logiciel16 font
partie des bonnes pratiques acceptées du secteur.
Les entreprises doivent mettre en place des pratiques de
sécurité optimales dans la façon dont elles conçoivent,
écrivent, construisent et testent leurs applications afin
de réduire considérablement le nombre de vulnérabilités
exploitables qui parviennent jusqu'à la phase de
production. La première étape consiste à définir des
normes de sécurité claires et à les intégrer aux pratiques
opérationnelles et de développement quotidiennes, tout
en les intégrant aux plateformes utilisées par les équipes.
Cela supprimera la dépendance excessive à l’égard des
équipes de sécurité centralisées qui sont si souvent
submergées par les demandes dues au rythme rapide de
l'évolution DevOps.
Les recherches de Sogeti montrent que les entreprises
les plus performantes mettent en place des contrôles
de sécurité à toutes les étapes du cycle de vie logiciel  :
planification, développement, construction, test,
publication, livraison, déploiement, exploitation et
surveillance. La sécurité des applications doit s’accélérer
pour suivre le rythme des opérations en renforçant les
contrôles de sécurité et le contrôle à l’intérieur même
du pipeline CI/CD. Les tests et la sécurité doivent être
«  décalés vers la gauche  » grâce aux tests unitaires,
fonctionnels, d’intégration et de sécurité automatisés. Il
s’agit là d’un facteur de différenciation essentiel puisque
la sécurité et les capacités fonctionnelles sont testées et
construites simultanément.
Rapport Enterprise DevOps 2020-21 42

Sécuriser les composants de code réutilisables Les entreprises prospères adoptent des architectures de
La création de composants de code réutilisables et référence DevOps, un modèle qui documente l’ensemble
sécurisés, et leur utilisation généralisée via votre stratégie des activités, étapes, pratiques et technologies d’un
InnerSource, est également essentielle pour résoudre le système qui sont utilisées lors de la création d’une
problème de la sécurité Enterprise DevOps. application ou d’une technologie. Avec toutes les étapes
idéales, de la construction à la surveillance, clairement
Les entreprises les plus performantes utilisent définies, les entreprises peuvent être sûres que les choses
systématiquement des composants réutilisables et tirent sont faites de la «  bonne  » manière, tout en répondant
parti de ce que l’on appelle le « principe DRY »17 (« Don’t à tous les objectifs de sécurité de l’entreprise en même
Repeat Yourself  », Ne vous répétez pas). DRY présente temps.
l'avantage supplémentaire de ne devoir corriger qu'une
seule fois une faille de sécurité identifiée dans votre Lorsqu'elles utilisent ces architectures de référence
module de code réutilisable pour la corriger pour tout organisationnelles, les équipes créent souvent ensuite
le monde, contre des centaines de fois si le code a été des plans DevOps, qui extraient les besoins exacts d'une
réutilisé en « copier-coller ». équipe à chaque étape de l'architecture de référence du
système. En déterminant exactement à quel stade du
cycle de développement logiciel les équipes devront
De toute évidence, les logiciels open source sont une
utiliser différentes technologies, les attentes sont claires.
source essentielle de composants réutilisables pour de
Cela garantit que les équipes DevOps savent exactement
nombreuses entreprises et l’amélioration de la sécurité
ce qu’elles doivent faire pour atteindre les objectifs
de ces composants est un objectif important du secteur.
commerciaux et de sécurité.
Les entreprises les plus performantes installent des
technologies de remédiation automatisée de la sécurité,
comme le Dependabot18 de GitHub, qui assure la sécurité Observabilité, SIEM et SOAR
et la visibilité dans la chaîne d’approvisionnement des Dans le monde traditionnel de la cybersécurité, les outils
logiciels open source. Dependabot extrait votre code de gestion des informations et des événements de sécurité
open source tiers et vérifie les exigences obsolètes ou non (SIEM) fournissent une plateforme analytique de sécurité
sécurisées. Il signale ensuite automatiquement les sections unifiée pour aider l'entreprise à identifier les menaces
qui ne sont plus à jour et vous permet d’effectuer les mises et les activités malveillantes dans toute l'entreprise. De
à jour nécessaires pour garantir que tout le code déployé plus en plus, les entreprises les plus performantes ont
est sûr et conforme. commencé à tirer parti de l’intelligence artificielle (IA)
pour donner un sens aux téraoctets de données collectées
Intégrer la sécurité aux architectures et plateformes par les outils de surveillance de la sécurité. L’IA peut vous
de référence aider à mieux comprendre ce qui se passe dans le cadre du
Les plateformes et les architectures de référence cycle de vie du développement sécurisé et à déterminer la
exécutables sont un excellent point de départ pour la meilleure réponse aux menaces de sécurité.
sécurité Enterprise DevOps. Les équipes centrales de
sécurité aident à définir un ensemble d'architectures de
référence sécurisées, idéalement définies en tant que
code, et qui sont ensuite partagées en utilisant le modèle
InnerSource évoqué précédemment. De solides exemples
de cette pratique sont disponibles dans le Centre
d’architecture Azure. Ces architectures de référence
sécurisées, idéalement accompagnées de pipelines de
lancement sécurisés, offrent un chemin de moindre
résistance, de sorte que faire les bonnes choses de manière
sécurisée soit le plus simple.
16
Microsoft, SDL Practices (Pratiques SDL), 2020
17
Microsoft, Patterns and Practices for Super DRY Development for ASP.NET Core (Modèles et pratiques pour le
développement super DRY pour ASP.NET Core), 2019
18
Dependabot
Rapport Enterprise DevOps 2020-21
Toutefois, afin d’agréger ces données de sécurité et de
performance, les applications et les systèmes doivent être
«  observables  ». Cela signifie que les systèmes doivent
être conçus pour exposer les données opérationnelles
importantes via la journalisation ou d’autres interfaces
afin que les entreprises puissent « voir à l’intérieur » pour
comprendre comment un système donné fonctionne.
Les exigences en matière d'observabilité doivent faire
partie intégrante de la conception de l'application, et
des paramètres clairs doivent être définis concernant les
données nécessaires pour comprendre l'intégrité d'une
application. Cela est d’une importance vitale car une
bonne observabilité nous permet d'établir une référence
de comportement d’une application dans des conditions
normales. La détection des anomalies peut ensuite être
utilisée pour repérer les comportements anormaux qui
pourraient être le résultat d’une activité malveillante.
Le fait de disposer d'un aperçu en temps quasi réel
de l'intégrité des applications et des infrastructures,
ainsi que des menaces de sécurité auxquelles elles
sont confrontées, permet de tirer parti des techniques
d'automatisation DevOps pour automatiser certaines des
réponses à ces attaques. Certaines entreprises utilisent
l’acronyme SOAR (Security Orchestration, Automation
and Response, Réponse, automatisation et orchestration
de la sécurité) pour décrire ce processus. Les applications
comme Azure Sentinel peuvent déclencher une réponse
automatisée lorsqu’un seuil d’alerte est atteint. Ces
playbooks automatisés peuvent traiter des attaques ou
des problèmes courants sans nécessiter d'intervention
humaine.
19
National Cyber Security Centre, Introduction to Cyber Security- Board Level Responsibility (Introduction
à la cybersécurité - Responsabilité au niveau de la direction), 2019
43
Faire de la sécurité une responsabilité au niveau de la
sécurité
La sécurité est trop souvent considérée comme un
problème informatique, mais la mise en place d'une culture
de prise de conscience des risques devrait commencer au
niveau de la direction. Ne pas investir dans la sécurité, et ne
pas s’assurer que les mesures de sécurité essentielles sont
en place, expose les entreprises à des poursuites. D’après
nos entretiens, il est évident que les entreprises doivent
introduire la sécurité en tant qu’élément de la check-list
mensuelle lors des réunions du conseil d’administration, et
définir une rubrique de conformité qui les aide à respecter
l’ensemble des politiques décidées.
Le National Cyber Security Center19 propose une longue
liste de questions que les conseils d’administration
et les PDG devraient constamment se poser. Plus
important encore, votre entreprise dispose-t-elle d’une
compréhension complète et précise des éléments
suivants :
• L'impact sur la réputation, le cours des actions
ou l'existence de l'entreprise en cas de perte
ou de vol d'informations sensibles, internes ou
relatives aux clients, détenues par l'entreprise ?
• L’impact sur l’entreprise en cas de
perturbation des services en ligne pendant
une période courte ou prolongée ?
Les conseils d’administration et les dirigeants doivent
toujours avoir une vision globale, et, bien qu'elles soient
largement «  invisibles  » pour les clients, les questions de
sécurité doivent toujours être une priorité absolue pour
éviter des défaillances de sécurité coûteuses.
Rapport Enterprise DevOps 2020-21 44

ÉTUDE DE CAS SUR LA SÉCURITÉ

La sécurité est une priorité pour le fournisseur d'électricité
et de gaz néerlandais Enexis. Son profil public indique qu'il
est un acteur clé de l'infrastructure énergétique des Pays-
Bas  : «  Nos quelque 4  500  employés dévoués travaillent
dur chaque jour pour garantir des réseaux stables et fiables
et pour assurer l'avenir de notre approvisionnement
énergétique.. »
Une capacité informatique évolutive et agile dans un
environnement public et natif du Cloud est essentielle
à cet égard, et la société a travaillé avec Sogeti pour mener
à terme les transformations nécessaires pour réussir. En
collaboration avec des partenaires, Sogeti a créé une
feuille de route et a transféré plus de 100 applications
existantes vers une plateforme d’application native du
Cloud, sur IaaS, PaaS ou SaaS.
La sécurité a été au cœur de ce processus, une partie du
succès étant la classification des risques des données et
des systèmes qui ont été transférés vers le Cloud. Au sein
d’une architecture de référence, Sogeti a défini les niveaux
de risque pour développer des capacités dans le Cloud,
avec des principes à la fois pour la sécurité et le Cloud.
Grâce à des mesures adaptées aux niveaux de risque
acceptables, les équipes Enexis Platform DevOps ont fourni
des services standard (par exemple, réseau, serveurs, etc.)
avec une sécurité intégrée et des correctifs automatiques.
Pour les équipes Platform DevOps et Apps DevOps qui
utilisent ces services standard, la stratégie de sécurité
basée sur cette classification des risques a été traduite en
exigences concrètes pour la plateforme Cloud. De cette
façon, les équipes pourraient facilement effectuer une
« évaluation de l’état de préparation au Cloud » avant le
déploiement en production.
Ce modèle Enterprise DevOps sécurisé a également été
facilité par la simplification de la mise en œuvre et de
l'intégration des applications au sein de l'exploitation
informatique grâce à l'intégration et au déploiement
continus (CI/CD). Les résultats ont été impressionnants.
La livraison des applications est passée de 6 à 12 semaines
à moins de 2 jours, avec l’approche « décalage à gauche »
qui permet d’identifier et de résoudre les problèmes de
sécurité dès le début du cycle afin de réduire les coûts
globaux du cycle de vie.

SÉCURITÉ - RESSOURCES POUR LA PROCHAINE ÉTAPE

Adopter le modèle Zero Trust Intégrer la sécurité aux architectures

En savoir plus sur le modèle Zero Trust
Découvrir comment Microsoft évalue
les stratégies Zero Trust
Sécuriser le cycle de vie du développement
et décaler à gauche
Découvrir comment intégrer la sécurité dans
votre cycle de vie de développement
et plateformes de référence
En savoir plus sur le Centre d’architecture Azure
Observabilité, SIEM et SOAR
Découvrir Microsoft Azure Sentinel
Lire l’Introduction à l’observabilité
Automatiser les réponses de sécurité avec les playbooks

Sécuriser les composants de code réutilisables

En savoir plus sur le principe DRY
Découvrez comment GitHub met en œuvre la sécurité
Rapport Enterprise DevOps 2020-21
Conformité
La conformité pose les mêmes défis que la
gouvernance, la sécurité et la qualité pour
Enterprise DevOps.
Toutefois, même si ces domaines sont principalement
déterminés au sein d’une organisation, la conformité
est essentiellement déterminée par la réglementation
externe, et les entreprises qui ne sont pas en mesure
de prouver qu'elles opèrent dans le respect des règles
peuvent faire face à des conséquences juridiques ou
financières importantes.
45
Les entreprises s’efforcent toujours de respecter
les réglementations, mais comme de plus en plus
d'applications émergent dans le paysage technologique
et offrent des services similaires à ceux des entreprises
existantes, les accréditations de conformité sont
extrêmement importantes pour les clients finaux lorsqu'ils
choisissent les services qu'ils utiliseront. Les clients, ainsi
que les entreprises elles-mêmes, veulent avoir la certitude
que leurs informations et leurs données sont sécurisées et
non compromises.
Naviguer dans le réseau complexe des réglementations
locales, mondiales et sectorielles dans un environnement
DevOps en constante évolution est un défi pour
de nombreuses entreprises. Ces défis s’inscrivent
dans deux  catégories  : premièrement, la création,
l’automatisation et l’exécution de systèmes conformes  ;
deuxièmement, la preuve de la conformité des systèmes
aux régulateurs.
Rapport Enterprise DevOps 2020-21 46

Quels sont les défis ?

Se conformer à quoi ?
Près de la moitié des cadres interrogés par Microsoft EN GÉNÉR AL , CO MB I EN DE TEMPS FAUT- I L PO UR
VÉR I F I ER L A CO NF O R MI TÉ R ÉGL EMENTAI R E ? FIGURE 12
ont déclaré ne pas être sûrs des normes de conformité
des données qu’ils devaient respecter. Ce nombre est
mois
susceptible d’augmenter à mesure que les entreprises
adoptent de nouveaux business models dans le cadre de 2
leurs transformations numériques. Par exemple, lorsque
semaines
de plus en plus d'entreprises commenceront à accepter
les paiements en ligne, elles relèveront pour la première 19
fois de la norme Payment Card Industry Data Security
jours
Standard (PCI DSS). D'autres secteurs sont confrontés à
38
une réglementation importante en matière de sécurité
des données, notamment la distribution (au moyen du heures
RGPD dans l'UE) et les soins de santé (HIPPA), entre autres.
32

Le défi du RGPD et de la sécurité des données minutes/instant

Le règlement général sur la protection des données 8

(RGPD) de l’UE, qui est entré en vigueur en mai  2018, a
entraîné des problèmes de conformité majeurs pour les 0 5 10 15 20 25 30 35 40

entreprises du monde entier. Le RGPD concerne toute

entreprise qui traite les données de citoyens de l’UE, quel
que soit le lieu où cette entreprise est constituée, ou le
lieu où les données sont traitées ou stockées. Le RGPD a
contraint de nombreux cadres supérieurs à se concentrer
sur la gouvernance en raison du risque d'amendes
considérables prévues par la nouvelle législation.
Cependant, lorsque les organisations adoptent DevOps,
il est très courant de voir des données répliquées à partir
de « systèmes d’enregistrement » centralisés traditionnels
dans des banques de données distribuées. Ces banques
de données peuvent également être déplacées d'un
environnement sur site vers un environnement hébergé
sur le Cloud ou utiliser de nouvelles technologies de
base de données que les processus de gouvernance
existants ne sont pas équipés pour gérer efficacement.
Cette complexité architecturale accrue peut créer des
défis pour les entreprises qui tentent de se conformer aux
réglementations en matière de sécurité des données.
La rapidité de la mise en conformité
Dans le cadre de l’enquête sur l'IRD, les recherches de
Microsoft ont révélé que 59 % des personnes interrogées
ont déclaré qu’il peut falloir des « jours ou des semaines »
pour évaluer leur état actuel en matière de conformité
réglementaire. Dans DevOps, où plusieurs versions
de nouvelles fonctions logicielles peuvent apparaître
quotidiennement dans des environnements Cloud en
constante évolution, le cycle de commentaires permettant
de comprendre votre état actuel de conformité doit être
beaucoup plus rapide. Il ne suffit plus de vérifier qu’une
application ou un environnement est sécurisé lorsqu’il est
déployé pour la première fois dans le cadre de sa version
initiale. Le problème de la « dérive de la configuration »,
où l’application et son infrastructure sous-jacente
«  s’éloignent  » de l'état de conformité défini à l’origine
à la suite de petites modifications progressives au fil du
temps, constitue un défi et une menace majeurs pour les
entreprises.
Rapport Enterprise DevOps 2020-21
Relever les défis
Comme nous l’avons mentionné précédemment, afin
de relever les défis de conformité dans le cadre de la
transformation Enterprise DevOps, les entreprises doivent
atteindre deux  objectifs. Tout d’abord, elles doivent
être conformes, et d’autre part, elles doivent être en
mesure de démontrer leur conformité à un organisme
de réglementation. DevOps, s’il est mis en œuvre et
mis à l’échelle correctement au sein des entreprises,
peut aider à répondre à ces deux  exigences, à un coût
total de possession bien inférieur à celui des modèles
d’exploitation précédents.
La plateforme conforme
Tout comme la sécurité, la conformité peut être
«  intégrée  » aux architectures de référence et aux
plateformes partagées, soulageant ainsi les équipes
DevOps alignées sur les produits d'une grande partie
du fardeau de la conformité. Par exemple, Microsoft
publie des architectures de référence pour les normes
de conformité communes, tout comme elle le fait pour
la sécurité. Ces architectures vont au-delà de simples
diagrammes Visio et documents Word pour inclure les
étapes d'automatisation DevOps nécessaires à la création
complète d'un environnement conforme dans le Cloud
Azure.
Les organisations conçoivent et construisent
plateformes «  conformes  » basées sur ces architectures
de référence, qui sont souvent maintenues à l'aide des
pratiques InnerSource. Ces plateformes de conformité
partagées peuvent être soit gérées de manière centralisée
en tant que zone de destination pour les applications
créées par les équipes DevOps, soit instanciées à la
demande par les équipes DevOps, en sachant qu’elles
respectent les normes de conformité.
47
Conformité continue sous forme de code
Enterprise DevOps peut aider à relever le défi de la « dérive
de la configuration  » grâce au concept de conformité
continue. Les méthodes d’automatisation DevOps telles
que l’infrastructure en tant que code et la configuration
sous forme de code créent un modèle de code indiquant
l'aspect que nous attendons de l'environnement de
calcul sous-jacent. De même, les pipelines CI/CD, avec
l’automatisation des tests intégrée, définissent la façon
dont les applications sont créées, déployées et comment
elles doivent se comporter. Une fois combinés, ils
donnent la possibilité d’appliquer en continu des normes
de conformité en comparant le modèle (exprimé sous
forme de code) avec la réalité telle qu'elle s'exécute en
production, et de corriger automatiquement toute dérive.
La clé pour y parvenir est un concept appelé
«  idempotence  ». Idempotence, dans le langage de
DevOps, fait référence à la capacité de redéployer
la même configuration ou le même modèle d'état
souhaité dans l’environnement existant, quel que soit
l’état actuel de cet environnement. Les modèles de
configuration idempotents permettent aux entreprises
d’utiliser la «  syntaxe déclarative  » pour décrire l'aspect
qu'elles souhaitent donner à leur environnement. En
d’autres termes, elles déclarent qu’elles veulent qu’il
des soit d’une certaine manière, et l'idempotence signifie
que, que ce soit la première ou la centième fois que
cette «  déclaration  » est émise, quel que soit son état
actuel, les outils feront ressembler l'environnement à ce
modèle. L'idempotence est particulièrement importante
en matière d'automatisation, car une entreprise peut
dire «  toutes les demi-heures, assurez-vous qu’un
environnement ressemble à ceci... ». Ensuite, chaque fois
que cette syntaxe déclarative est approuvée, vous savez
que lorsque vous exécutez une commande, tout sera
validé, rien ne sera dupliqué et vos environnements seront
conformes en continu.
Rapport Enterprise DevOps 2020-21
Contrôle et rapports de conformité
Toutefois, il ne suffit pas d’être conforme : vous devez être
en mesure de rendre compte et de documenter votre état
de conformité pour répondre aux besoins des équipes de
conformité internes et des audits externes réalisés par des
tiers ou des organismes de réglementation.
Les équipes DevOps qui ont adopté les modèles «  en
tant que code  » et de «  conformité continue  » ont un
avantage intrinsèque. Les configurations sous forme de
code font partie de la documentation de votre cadre de
conformité, et les rapports automatisés de votre processus
de conformité continue démontrent l'application et
l'exécution dudit cadre. De plus en plus fréquemment,
des auditeurs tiers à la pointe de la technologie évaluent
les cas où les entreprises ont tiré parti des modèles sous
forme de code certifiés par le secteur dans leur cadre de
conformité, et les entreprises qui peuvent rapidement
démontrer une conformité continue ont une expérience
d’audit plus fluide.
48
Les entreprises les plus performantes mettent en place
des tableaux de bord de conformité, semblables aux
solutions de surveillance que les équipes opérationnelles
utilisent depuis des années. L’objectif du tableau de bord
de conformité est de fournir aux équipes DevOps et aux
équipes de conformité centralisées des informations
en temps réel sur leur état de conformité. Par exemple,
l'Azure Security Center dispose d’un tableau de bord
de conformité réglementaire, comme illustré dans la
figure 13.
Ces tableaux de bord simplifient le processus de mesure
et d'établissement de rapports sur la conformité, tout
en offrant la possibilité d'approfondir de petits détails si
nécessaire.
Rapport Enterprise DevOps 2020-21 49

ÉTUDE DE CAS SUR LA CONFORMITÉ

La compagnie d'électricité Eneco avait l'ambition
audacieuse de rester en tête en matière d'innovation, de
durabilité et d'orientation vers le client, tout en devenant
plus internationale. Elle a reconnu que ses services
informatiques locaux existants devaient passer par une
transformation pour y parvenir. L’entreprise a décidé
de passer à une plateforme informatique centralisée
à l’échelle du groupe.
À mesure que l’architecture de référence exigeait des
méthodes innovantes, mais de nouvelles façons de
travailler, il était important d’appliquer son utilisation aux
équipes qui ne connaissent pas bien les principes et les
normes. Aujourd’hui, les propriétaires de produits DevOps
ont plus d’autonomie et de maîtrise dans les équipes
interfonctionnelles, mais ils opèrent toujours dans le cadre
de l'architecture de référence d'Eneco.

Mais comment Eneco pourrait-il assurer un contrôle
continu de ce nouveau paysage technologique mondialisé,
notamment au sein des services informatiques Cloud et
des équipes DevOps ? L'entreprise fonctionne toujours
avec quelques technologies héritées sur place, mais
prévoit de passer entièrement au Cloud d'ici 2022. Avec la
migration de plus en plus de personnes vers de nouveaux
rôles basés sur le Cloud, il fallait assurer un certain niveau
de cohérence dans l'ensemble de l'entreprise.
En collaboration avec Sogeti, Eneco a établi une
architecture Cloud de référence qui décrit les principes
et les normes de sécurité et de gestion du Cloud qui
doivent régir le paysage informatique. La conformité
à cette architecture de référence permettrait à Eneco de
gérer activement les risques, les informations (flux), la
conformité, les coûts et la qualité. Cette même architecture
de référence a joué un rôle majeur dans la réduction des
problèmes de conformité externe en régissant l'utilisation
et la sécurité des données et des applications dans le
processus DevOps, ainsi que des applications et des
services hébergés par les partenaires.
En outre, une base Cloud dotée d’une zone de destination
reposant sur Microsoft Azure fournit tous les services
génériques (y compris tous les services de sécurité de
base et avancés) dans le cadre d’une seule équipe de
services gérés DevOps, conformément à l'architecture
de référence. Cela a permis à toutes les autres équipes
DevOps de se concentrer sur la création de nouvelles
fonctions, de répondre à des événements immédiats et
d'augmenter (ou de diminuer) le nombre de machines
virtuelles en quelques minutes. Ils peuvent désormais
répondre à des besoins commerciaux inattendus sans
avoir à se soucier de savoir si les machines virtuelles sont
à jour avec toutes les exigences de conformité, comme
l'exigent les principes définis.

CONFORMITÉ - RESSOURCES POUR LA PROCHAINE ÉTAPE

Plateforme conforme
Rationalisez votre conformité

Conformité continue sous forme de code

Créer et gérer des stratégies pour appliquer la conformité

Contrôle et rapports de conformité

Gérer efficacement les défis réglementaires
Rapport Enterprise DevOps 2020-21 50

Conclusion

Nos recherches ont montré que la rapidité
de développement, mesurée par l'indice
de rapidité de développement (IRD), est
fortement corrélée avec l'amélioration
du rendement pour les actionnaires, ainsi
qu'à d'autres indicateurs de performance
des entreprises comme l'innovation, la
satisfaction des clients, la gestion de la
marque et des talents.
Il est clair que la transformation DevOps à l’échelle de
l’entreprise peut créer des défis, en particulier en ce qui
concerne la gestion des produits, le travail distribué et
à distance, la gouvernance, la qualité, la sécurité et la
conformité.
Toutefois, si l'on adopte une approche globale, on
constate que les entreprises les plus performantes suivent
des idéologies et des modèles communs pour relever ces
défis.

Les entreprises adoptent DevOps afin d'améliorer

la rapidité de développement et à permettre une
transformation numérique plus large. Alors que
ces transformations numériques se poursuivent,
les départements informatiques font face à une
transformation DevOps pour s’assurer qu’ils peuvent
répondre aux besoins changeants de l’entreprise et de
ses clients dans une économie numérique en évolution
rapide.
Rapport Enterprise DevOps 2020-21 51

LES ENTREPRISES LES PLUS PERFORMANTES :

Font la transition vers des équipes autonomes et alignées sur les produits
1 qui utilisent des pratiques de livraison continue, des chaînes d'outils
DevOps et l’hébergement sur le Cloud pour accélérer la livraison
de produits et améliorer la rapidité de développement.

Mettent en place des plateformes partagées en libre-service intégrant

2 la gouvernance, la conformité, la sécurité et la qualité nécessaires,
pour que faire la « bonne » chose soit « facile ».

Adoptent une mentalité InnerSource pour partager et réutiliser le code et les bonnes
pratiques à l’échelle de l’entreprise, mais aussi pour favoriser une éthique collaborative
3
d’amélioration continue avec un partage de la propriété et de la responsabilité.

Tirent parti de l’automatisation, dans la mesure du possible, pour réduire le temps

consacré aux tâches répétitives, libèrent les équipes pour qu'elles puissent se
4
concentrer sur la valeur commerciale et l’innovation, tout en évitant la surcharge
des opérateurs lorsqu'ils traitent des volumes massifs de données, des alertes, etc.

Conçoivent des architectures de référence normalisées autour de modèles communs

d’application et d’infrastructure Cloud, puis utilisent des tactiques d’automatisation
5 DevOps comme l’infrastructure en tant que code et la configuration sous forme
de code pour faire passer ces architectures de référence des diagrammes Visio
à des modèles de code réutilisables qui accélèrent l’adoption généralisée.

Éliminent les cloisonnements, non seulement entre le développement et les

opérations, mais aussi entre les équipes centralisées qui établissent les normes de
6 qualité, de sécurité et de gouvernance, et les équipes produits qui doivent ensuite
se conformer à ces normes. Les équipes qui ont contribué aux normes et aux
processus de gouvernance sont plus susceptibles de se conformer à celles-ci.

Mesure et apprentissage : l’observabilité est la clé du succès des entreprises.

Elle leur permet non seulement de mesurer la qualité et les performances,
7 mais aussi d'en rendre compte par l'intermédiaire de rapports, afin de
créer les boucles de commentaires qui permettent aux entreprises
d'apprendre, et d'améliorer et d'optimiser l’ensemble
de leurs processus et technologies.

Les recommandations contenues dans ce rapport peuvent servir de modèle pour relever les défis mis en
évidence et pour accélérer la transformation DevOps. Cela permettra à ceux qui transforment les entreprises
d'obtenir à la fois de meilleurs résultats pour les clients et un meilleur rendement pour les parties prenantes.
Rapport Enterprise DevOps 2020-21 52

Auteurs

Samit Jhaveri est directeur du marketing produit avec Microsoft Azure axé sur
le développement d’applications Cloud et DevOps avec Github. Il est responsable de la
gestion des produits, de la direction des ventes et des finances, ainsi que de la définition
et de l'exécution de la stratégie de mise sur le marché de bout en bout, y compris les prix
et les offres, et les plans d’exécution tels que les campagnes et les actions sur le terrain
et auprès des partenaires pour développer l'activité. Il est également responsable de la
proposition de valeur Azure pour le développement et les tests d’applications, y compris
le positionnement et la messagerie, le développement de contenu et la stratégie de
marque. Avant d'occuper son poste actuel, Samit dirigeait une équipe d'ingénieurs au
sein de la division Serveurs et outils de Microsoft et était responsable de la livraison de
plusieurs solutions B2B pour différents secteurs verticaux. Samit est titulaire d’un MBA
de l’Université de Washington et d’un master en systèmes d'information de gestion de
l'Université de l'Arizona.

Clemens Reijnen est le directeur technique mondial de Sogeti, responsable des

services de Cloud et de DevOps. Il s’est vu décerner la distinction Microsoft Most Valuable
Professional Award 10 ans de suite et est membre de SogetiLabs Technical. Il a co-écrit le
livre « Collaboration in the Cloud » (La collaboration dans le Cloud) avec Microsoft et écrit
fréquemment sur le Cloud et DevOps sur Sogeti.com. En tant que responsable mondial
de DevOps, il travaille en étroite collaboration avec les grandes entreprises clientes de
Sogeti pour s’assurer que leur adoption du Cloud et leurs programmes de transformation
Enterprise DevOps apportent de la valeur à l'entreprise.

Steve Thair est directeur technique et cofondateur de DevOpsGroup Ltd, une

entreprise de services Cloud et DevOps de pointe basée au Royaume-Uni. Fondé en 2013,
DevOpsGroup rend l'adoption de DevOps et du Cloud rapide, sécurisée et simple, aidant
ainsi les entreprises à prospérer dans la nouvelle économie numérique. En reconnaissance
de son leadership intellectuel et de ses contributions à la communauté DevOps, en
co-fondant www.winops.org, dédiée à la promotion des modèles et pratiques DevOps
dans les environnements technologiques Windows et Microsoft 2016, Steve Thair a rejoint
en 2016 le programme « Directeur régional » de Microsoft qui met en avant environ 180 des
meilleurs visionnaires technologiques au monde pour leurs compétences technique, leur
leadership communautaire et leur engagement envers les résultats commerciaux. Steve
rédige des articles de blog régulièrement sur des sujets liées à DevOps et au Cloud sur
www.devopsgroup.com/blog/.
Rapport Enterprise DevOps 2020-21 53

Méthodes de recherche

Rapidité de développement Recherches supplémentaires

Les recherches de McKinsey sur l'indice de rapidité de Des données supplémentaires ont été recueillies par
développement (IRD) prennent en compte 46 facteurs l'intermédiaire d'enquêtes et d'entretiens avec les
différents dans 13 domaines de capacité (démonstration). responsables de la pratique Cloud et DevOps de Sogeti.
Afin de mettre au point et de valider cette liste de Au total, ces chefs de pratique sont responsables de
conducteurs, ils ont mené des entretiens avec plus de plus de 250 implémentations de Cloud et de DevOps,
100 directeurs techniques, responsables des systèmes et leurs commentaires ont été utilisés pour fournir des
d’information et d’autres leaders de l’ingénierie. Ils ont recommandations et des informations supplémentaires
ensuite demandé aux directeurs de la technologie de sur les clients dans le rapport.
440 grandes entreprises dans 12 secteurs dans neuf pays
d'évaluer les performances de leur entreprise. Les scores
IRD sont calculés comme une moyenne pondérée
des différents facteurs, une importance égale étant
accordée aux trois grandes catégories  : technologie,
pratiques de travail et capacité organisationnelle.
Leur analyse a porté sur l’impact des scores IRD sur le
chiffre d’affaires, le rendement total des actionnaires
et la marge d'exploitation. Ils ont également examiné
quatre  indicateurs non financiers de performance des
entreprises  : l’innovation, la satisfaction des clients,
la perception de la marque et la gestion des talents.
Enfin, ils ont établi des corrélations statistiques entre les
performances des entreprises et les différentes dimensions
de la rapidité de développement. Ils ont ensuite utilisé
l’analyse des poids relatifs de Johnson pour quantifier
l’importance relative des facteurs corrélés des scores IRD.
Pour en savoir plus sur les recherches en matière d'IRD,
cliquez ici.

Exclusion de responsabilité

©2020 Microsoft Corporation. Tous droits réservés. Le présent document est fourni en l’état. Les informations
et les points de vue exprimés dans le document, y compris les URL et autres références à des sites Web,
sont susceptibles de changer sans préavis. Vous assumez les risques associés à leur utilisation.

Le présent document ne vous donne pas les droits juridiques propres à la propriété intellectuelle de tout produit Microsoft.
Vous pouvez copier et utiliser ce document pour un usage interne.