Développer une culture DevSecOps : des mises en œuvre concrètes

Tout au long du parcours de mise en œuvre et de maturation d’un modèle DevSecOps, partager les réussites et les enseignements tirés peut aider chacun à progresser. Voici des exemples d’organisations qui ont adopté le DevSecOps et se sont attachées à atteindre des niveaux de maturité supérieurs.

DevSecOps chez Auth0

• Créer une expérience « sans friction » pour les développeurs cloud

• Tirer parti de l’analyse des données

• Prioriser les risques dès le début du cycle de vie du développement logiciel (SDL)

• Favoriser la collaboration et adopter des pratiques de développement flexibles

Depuis ses débuts, Auth0 s’appuie largement sur l’infrastructure cloud AWS pour proposer des solutions de gestion des identités à ses clients. Sa croissance rapide, tant en taille qu’en offre de services, l’a amenée à relever le défi de sécuriser son infrastructure cloud. Duncan Godfrey, directeur principal de la sécurité et de la conformité, est récemment intervenu dans le podcast The Secure Developer pour présenter la stratégie mise en place afin de sécuriser cet environnement.

Au sein d’Auth0, une équipe dédiée à la sécurité cloud est chargée de sécuriser l’environnement AWS. Pour éviter qu’elle n’adopte une approche SecOps traditionnelle, l’automatisation axée sur la surveillance a été essentielle. Comme l’explique Godfrey : « Le mandat de cette équipe est de veiller à collecter des données dans chaque recoin d’AWS, sous tous les angles possibles, puis de les analyser. » Résultat : l’équipe échange régulièrement avec les équipes de développement qui travaillent selon un modèle DevOps. Cette collaboration avec les équipes DevOps lui permet d’obtenir une visibilité globale accrue. 

Pour Auth0 et son équipe de sécurité cloud, il est essentiel de proposer aux développeurs une expérience « sans friction ». L’intégration de la sécurité commence tôt dans le SDL, avec un court formulaire qui aide à déterminer le niveau de collaboration nécessaire avec l’équipe de sécurité. Les fonctionnalités à haut risque, comme l’exposition de points de terminaison publics, nécessitent une implication plus importante de la sécurité. « Nous les accompagnons pour mettre en place dès le départ les exigences et les contrôles adaptés, afin de produire des logiciels sécurisés, puis nous effectuons des tests supplémentaires à la fin », explique Godfrey.

La culture d’Auth0 repose clairement sur la collaboration et l’accompagnement. Les développeurs peuvent créer des logiciels selon des méthodes adaptées à leurs besoins, tout en faisant preuve de maturité dans leurs pratiques de sécurité. Auth0 peut ainsi continuer à tirer parti des nouvelles technologies tout en maintenant une posture de sécurité solide.

DevSecOps chez Segment

• Se mettre à la place des développeurs

• Adopter l’infrastructure as code pour favoriser le DevSecOps

• Veiller à ce que les nouveaux outils soient faciles à utiliser pour les développeurs

• Des ressources intégrées aux équipes et issues de différentes fonctions

Lors d’un récent épisode du podcast The Secure Developer, Leif Dreizler et Eric Ellett ont évoqué l’importance que le fournisseur de plateforme de données client Segment accorde à la collaboration entre les équipes de développement, de sécurité et d’exploitation. Segment ne fonctionne pas en sprints à l’échelle de l’organisation : les équipes travaillent de façon autonome. Toutefois, grâce à une approche de conseil, l’équipe de sécurité intervient tôt dans le processus de développement pour contribuer à la modélisation des menaces et à l’examen de la conception.

Chez Segment, l’empathie fait partie intégrante de la culture de l’équipe de sécurité. Au sein de l’équipe, Segment a adopté le principe suivant : « Se mettre à la place des développeurs ». Ellett explique que l’équipe de sécurité s’efforce de comprendre l’incidence de ses processus sur les autres services de l’organisation. Par exemple, lorsque Segment a voulu déployer l’authentification multifacteur, Dreizler a passé un trimestre au sein de l’équipe de développement. L’équipe de sécurité a ainsi pu mieux comprendre les difficultés rencontrées par les développeurs et les éléments qu’ils cherchent à protéger.

Mais la collaboration ne s’arrête pas là. Ellett explique que des initiatives similaires sont prévues dans l’autre sens : des personnes d’autres services viendront travailler avec l’équipe de sécurité pour comprendre également son quotidien. Dreizler déclare : « Je pense que c’est l’objectif du DevSecOps. Comme avec le DevOps, où des équipes d’exploitation apprennent à coder, aujourd’hui, chez Segment, toute l’infrastructure est définie sous forme de code. »

Segment croit aussi fermement à la création d’une « voie balisée ». L’un des principes directeurs de l’équipe de sécurité est le suivant : « Les développeurs utiliseront-ils cet outil ? » Autrement dit, l’accent est mis sur la facilité d’utilisation pour favoriser l’adoption des contrôles de sécurité. Selon Dreizler, l’objectif est avant tout de « faire en sorte qu’il soit aussi facile que possible pour chacun de faire ce qu’il faut ».

Grâce à cette approche collaborative et empathique, Segment a pu développer une forte culture de la collaboration au sein de l’organisation. C’est un exemple de la manière dont le DevSecOps peut tenir ses promesses, en veillant à ce que toutes les fonctions partagent l’objectif d’agir dans l’intérêt de l’organisation.

10X Banking adopte le DevSecOps

• Transparence sur les vulnérabilités de sécurité dans toute l’organisation

• Des réunions quotidiennes interfonctionnelles rassemblent tout le monde

• Automatiser le déploiement de code sécurisé

• Utiliser un jeu de cartes sur la modélisation des menaces pour impliquer les parties prenantes

Neil Drennan, de 10x Future Technologies, a rejoint Guy Podjarny dans un épisode récent du podcast The Secure Developer. Il a expliqué comment l’organisation s’appuie sur des stratégies de communication clés pour favoriser l’engagement dans les pratiques de sécurité, tout en créant la première plateforme bancaire cloud native. De la transparence et d’une communication efficace à la collaboration au quotidien et aux mesures de sécurité proactives, 10x s’attache à faire de la sécurité la responsabilité de chacun.

Au cours de leur échange, Guy et Neil ont commencé à explorer la manière dont 10x favorise la collaboration entre les équipes de sécurité externes et les équipes internes chargées de la plateforme. Neil explique que chez 10x, chacun peut consulter l’état actuel des vulnérabilités suivies par les outils déployés dans l’environnement. « Lorsque nous utilisons des outils et signalons les vulnérabilités détectées, les informations sont transparentes et accessibles à tous. Chaque membre de l’équipe peut consulter l’état des vulnérabilités dans toute l’organisation », explique Drennan. Cette transparence est essentielle pour que toutes les équipes comprennent leur rôle dans la responsabilité partagée de la création de logiciels sécurisés.

Mais la collaboration ne se limite pas à la visibilité sur les vulnérabilités actuelles. Grâce à des réunions quotidiennes réunissant des membres de différentes équipes de l’entreprise, 10x veille à prendre en compte divers points de vue lors des discussions sur les vulnérabilités. Neil explique : « Nous examinons [les vulnérabilités actuelles] lors de notre réunion quotidienne, avec toutes les équipes. Il ne s’agit donc pas seulement de la livraison fonctionnelle : les aspects fonctionnels, non fonctionnels et de sécurité sont tous abordés ensemble chaque matin. » Selon Drennan, cette approche est particulièrement importante pour faire face à un paysage des menaces de plus en plus dynamique.

Drennan souligne l’efficacité de ces échanges : « Je pense que cela aide vraiment les équipes à être plus efficaces. Il est extrêmement important de maintenir une communication ouverte entre elles. » Cette approche renforce aussi le principe de responsabilité partagée en matière de logiciels sécurisés, en l’ancrant dans la culture de l’organisation. C’est un excellent moyen pour 10x de développer l’empathie et la compréhension entre les différents rôles de l’entreprise.

Neil explique également comment 10x intègre la sécurité en amont du pipeline de livraison grâce à la modélisation des menaces. Dans son rapport State of DevOps 2019, Puppet a montré que les efforts collaboratifs de modélisation des menaces ont un impact considérable sur la posture de sécurité globale d’une organisation. Pour impliquer efficacement les parties prenantes dans cette activité essentielle, 10x utilise des jeux de cartes sur la modélisation des menaces afin d’identifier les menaces selon le modèle STRIDE. « Réunir les équipes autour d’un jeu de cartes et leur faire explorer différents scénarios de vulnérabilités est une façon très ludique de les sensibiliser à la sécurité et de les aider à garder les bons réflexes », explique Drennan.

En s’appuyant sur les piliers que sont les personnes, les processus et les technologies, 10x a mis en place des pratiques originales qui ont fait de la sécurité un élément central de la livraison logicielle. Son approche montre comment ces trois piliers peuvent se combiner de manière collaborative pour permettre à 10x de fournir des logiciels performants, fiables et sécurisés.

Faire évoluer la culture DevSecOps chez Datadog

• Supprimer les obstacles et intégrer la sécurité aux différentes étapes du pipeline de livraison

• Intégrer des spécialistes de la sécurité au développement pour favoriser l’empathie et la responsabilité partagée

• Faire de la sécurité un contributeur à part entière à l’automatisation du pipeline

DataDog montre comment la volonté d’automatiser et d’intégrer la sécurité au pipeline peut se concrétiser en commençant par s’attaquer aux enjeux humains. L’entreprise a mis en place un programme visant à favoriser l’empathie entre les équipes cloisonnées et à renforcer la collaboration. Elle a également fait de l’équipe de sécurité un contributeur actif à l’automatisation et aux outils du pipeline. À l’époque de son intervention dans le podcast The Secure Developer, Douglas DePerry était directeur de la sécurité des produits chez Datadog. Il nous a présenté quelques approches novatrices mises en œuvre pour relever ces défis clés du DevSecOps.

Vouloir développer des logiciels plus rapidement et plus efficacement ne suffit pas toujours. Quand vous déployez en production des dizaines de fois par jour, impossible de tout examiner. Datadog a intégré des ingénieurs en sécurité aux équipes de développement, parfois pour quelques semaines, parfois pour plusieurs mois. Pour eux, la sensibilisation est une priorité. Il s’agit aussi de montrer que la sécurité est la responsabilité de tous : « Laissez-moi vous aider à corriger certains de ces petits problèmes faciles à résoudre, ou ces bogues de sécurité », tout en transmettant des connaissances et en apprenant au fil du processus.

Selon DePerry, « L’équipe de sécurité doit écrire davantage de code. Il faut plus d’automatisation. C’est ainsi que vous obtiendrez un effet multiplicateur et pourrez suivre le rythme de déploiement du code. » Datadog a notamment créé un outil adapté à ses besoins, qui permet à son équipe de sécurité de fournir aux équipes de développement des recommandations concrètes et des tâches de correction en fonction du code qu’elles écrivent.

Datadog avait auparavant investi dans un outil d’analyse statique de sécurité (SAST). Initialement mis en place pour démontrer la conformité, il ne répondait malheureusement pas à ses besoins et ne s’intégrait pas correctement à son pipeline DevOps. L’entreprise a donc innové en développant son propre outil pour effectuer des analyses SAST et d’analyse de la composition logicielle (SCA). DePerry raconte : « Sans faire preuve de beaucoup d’imagination, nous l’avons appelé Middleware. C’était essentiellement un framework auquel nous pouvions ajouter des plug-ins. Nous avions ainsi un plug-in d’analyse statique et un plug-in d’analyse des vulnérabilités des dépendances. »

DePerry nous a également expliqué : « Il faut se concentrer sur ce qui risque de vous atteindre en premier ; mais comment le déterminer vraiment ? Je pense que plus vous pouvez le faire, même s’il est difficile de mesurer certaines choses aujourd’hui — ce qui complique vraiment la tâche et augmente le risque d’erreur —, plus les prévisions, lorsqu’elles sont bien faites, peuvent vous aider. »

Culture cloud native chez Pivotal

• L’importance de faire de la sécurité un changement culturel dans les transformations cloud native

• Créer des garde-fous plutôt que des barrières pour orienter les développeurs vers des pratiques sécurisées

• Mettre les développeurs et les spécialistes de la sécurité en binôme pour favoriser l’empathie et la responsabilité partagée

L’adoption du DevSecOps et la transformation vers les technologies cloud native vont souvent de pair. Pour permettre à l’organisation de s’adapter à ces nouveaux paradigmes sans compromettre la sécurité, une transformation culturelle est également nécessaire. De son côté, la sécurité doit abandonner l’idée d’imposer des contrôles sous forme de barrières dans le pipeline de livraison. Il est possible d’y parvenir en grande partie en développant l’empathie et la responsabilité partagée entre les développeurs et les spécialistes de la sécurité.

Steve White, CISO terrain chez Pivotal (désormais une filiale de VMWare), a récemment été invité au podcast Secure Developer. Dans cet épisode, il a partagé ses réflexions sur la transformation cloud, le rôle de la sécurité dans le pipeline DevSecOps et la manière dont le rapprochement entre les équipes sécurité et développement peut favoriser la réussite. Steve consacre beaucoup de temps à accompagner les responsables et les dirigeants de la sécurité dans la conception d’architectures de sécurité. Il anime des ateliers pratiques avec des représentants des différentes disciplines du DevSecOps afin de les sensibiliser aux réalités de la sécurité cloud native.

Pour transformer une organisation grâce à l’adoption du DevSecOps, il est essentiel de ne pas se limiter aux outils. « Le premier principe du changement dans ce domaine, c’est qu’il ne s’agit pas simplement d’un changement technologique, même si certaines évolutions technologiques sont nécessaires. C’est un changement de culture et de perspective qui constitue, en définitive, le principal enjeu pour la sécurité de l’information, comme cela a été le cas dans le reste de l’entreprise », explique White. Cela montre que la sécurité doit elle aussi rattraper les nombreux changements culturels impulsés par le DevOps.

L’une des perspectives que les spécialistes de la sécurité ont eu du mal à adopter consiste à intégrer les pratiques de sécurité au pipeline. White explique : « J’aime parler du passage des barrières aux garde-fous. À l’avenir, le rôle de la sécurité dans l’entreprise devrait être de fournir ces garde-fous — comme un filet de sécurité, avec des limites supérieure et inférieure qui vous empêchent de dépasser des seuils vraiment dangereux, tout en vous laissant évoluer à l’intérieur. » Cette approche met en lumière un enjeu essentiel : permettre à la sécurité d’adhérer au mouvement DevOps de façon crédible et, surtout, compatible avec ses principes.

Pour renforcer la crédibilité de la sécurité auprès des développeurs qui participent à la livraison logicielle, il est également important de développer l’empathie. Le travail quotidien en commun des spécialistes de la sécurité et des développeurs peut établir la crédibilité et favoriser la reconnaissance du travail de chacun. White précise : « Quand je parle de travail en binôme, j’aimerais qu’il s’agisse vraiment de programmation en binôme : deux personnes devant un même écran, qui résolvent ensemble un problème. Si l’une est ingénieure en sécurité et l’autre développeuse de fonctionnalités, elles apprennent beaucoup toutes les deux et enrichissent considérablement la discussion. »

Dans l’ensemble, White aborde plusieurs principes essentiels à toute culture DevSecOps. Le cloud native peut parfois favoriser l’adoption du DevSecOps, tandis que dans d’autres cas, c’est l’adoption du DevSecOps qui entraîne la transformation cloud. Il est facile de comprendre pourquoi ces deux démarches vont de pair. Les organisations doivent être conscientes de leur lien et se préparer à les adopter toutes les deux dans le cadre d’une transformation majeure de leur culture, afin d’en tirer une valeur commerciale.

DevSecOps chez Cisco/Duo

• « Aller à la rencontre des équipes là où elles travaillent » pour intégrer la sécurité au pipeline

• Intervenir en amont pour définir les principes de sécurité dès l’identification de nouvelles possibilités technologiques

• Des indicateurs plus élaborés, axés sur l’amélioration continue

La culture DevSecOps repose sur l’efficacité à chaque étape du pipeline. Elle permet aux développeurs de passer du backlog au déploiement aussi efficacement que possible. Pour que la sécurité fasse véritablement partie du pipeline, les pratiques sécurisées doivent s’y intégrer sans friction. Pour y parvenir, il est utile d’intervenir en amont afin de définir les principes de sécurité le plus tôt possible, et ainsi faciliter le travail des développeurs lorsqu’ils commencent à coder les fonctionnalités souhaitées. Toutefois, s’il est impossible de mesurer efficacement l’incidence de ces pratiques sur votre posture de sécurité, il devient extrêmement difficile de justifier leur intégration au pipeline.

Michael Hanley, CISO de Cisco et ancien responsable de Duo Security, a participé au podcast Secure Developer, où il a présenté certaines approches adoptées par Cisco/Duo pour répondre précisément à ces enjeux. Michael a rejoint Cisco lors de l’acquisition de Duo en 2018, puis a dirigé les initiatives de sécurité de l’entreprise pendant cinq ans. Ses réflexions sur l’intégration de la sécurité aux outils de développement existants, l’intervention en amont pour anticiper la conception de la sécurité et la définition d’indicateurs pertinents s’appuient sur cette expérience considérable.

Lorsqu’elles développent une culture DevSecOps, de nombreuses organisations réfléchissent aux outils nécessaires pour accélérer le pipeline. Aux débuts du mouvement DevOps, l’objectif était d’automatiser tout ce qui pouvait l’être : les commits de code déclenchaient des builds automatisés, la promotion du code lançait des tests de régression automatisés, etc. La sécurité a toutefois souvent eu du mal à proposer des processus et des outils adaptés à ce modèle, ce qui a fini par créer davantage de friction.

Cette friction est source de frustration pour les développeurs et peut freiner l’adoption des pratiques sécurisées. Hanley explique qu’au sein de Duo, l’accent était mis sur l’intégration aux outils existants. Il nous a confié : « … nous allons là où nos ingénieurs travaillent le plus facilement pour échanger avec eux. Par exemple, nous utilisons les mêmes systèmes de tickets que pour le contrôle de version et le suivi du travail de nos équipes d’ingénierie, et nous collaborons beaucoup avec ces équipes dans ces mêmes outils pour leur simplifier la tâche. » Aller à la rencontre des équipes là où elles travaillent et s’intégrer aux outils qu’elles connaissent déjà est une approche efficace pour instaurer une véritable culture DevSecOps.

Hanley a également évoqué un autre principe important pour intégrer la sécurité au pipeline : intervenir en amont. Si cette idée n’est pas nouvelle, les équipes de sécurité doivent le faire de plus en plus tôt dans une culture DevSecOps. Hanley explique : « … si je devais situer cela dans le cycle de développement logiciel de Duo, je dirais que tout à gauche, au tout début, se trouve l’équipe des laboratoires. Elle participe à l’identification stratégique de nouvelles possibilités technologiques, mais aussi à la définition précoce des paramètres d’une bonne conception sécurisée… »

Cette approche est importante et très novatrice. En définissant les principes de sécurité avant même qu’une user story n’entre dans le backlog, les organisations peuvent s’assurer que les développeurs disposent d’exigences de sécurité documentées dès les toutes premières étapes du pipeline. Ainsi, le travail de conception de la sécurité ne nuit pas à la rapidité de livraison du code. La sécurité devient un levier : les développeurs peuvent passer plus rapidement de ces principes à la programmation. Ils n’ont pas non plus à craindre d’oublier des éléments de sécurité qui deviendraient des failles à corriger lors de sprints ultérieurs.

Comment une organisation peut-elle savoir si ces approches produisent les résultats attendus ? C’est là que les indicateurs sont essentiels. Hanley explique : « J’ai toujours eu beaucoup de mal avec les indicateurs de sécurité et le simple décompte du volume de bugs… Ils ne sont pas assez élaborés pour décrire de nombreux programmes, et en particulier le nôtre. » C’est un véritable défi pour beaucoup d’organisations. Un simple décompte des bugs ouverts ne donne aucun contexte. Combien de mises en production ont généré ces vulnérabilités ? Si leur nombre est faible, est-ce parce que la sécurité s’est améliorée ou parce que l’application n’a pas été testée depuis longtemps ? Les programmes de mesure doivent tenir compte de davantage de facteurs.

Hanley explique que Cisco/Duo utilise un modèle de maturité pour mesurer la réussite de son programme. « Le modèle de maturité que nous utilisons chez Duo est un mélange du BSIMM et du SAMM… Nous essayons de déterminer les indicateurs clés qui en découlent, ainsi que le pourcentage d’activités couvertes au moins partiellement et le pourcentage de celles qui le sont entièrement », précise Hanley.

Il a également évoqué un autre aspect essentiel des indicateurs à prendre en compte : l’approche de Duo les a amenés à privilégier un modèle d’amélioration continue. De nombreuses initiatives de sécurité échouent parce qu’elles visent des objectifs démesurés et irréalistes. En axant plutôt nos objectifs sur le progrès que sur l’atteinte d’un résultat prédéfini, nous faisons place aux erreurs, à l’adaptation et à l’innovation. Au final, la valeur commerciale des pratiques de sécurité peut être démontrée plus facilement.

Les idées partagées par Hanley, issues de son expérience chez Duo, répondent aux besoins de toute organisation souhaitant mettre en place une culture DevSecOps.

Sécurité cloud avec 2nd Sight Lab

• Donner aux développeurs les moyens d’agir en leur enseignant les bonnes pratiques de sécurité cloud

• Développer l’empathie entre les développeurs et les spécialistes de la sécurité

• La gouvernance, un élément essentiel de la sécurité cloud

Alors que la transformation cloud est au cœur des stratégies informatiques de la plupart des organisations, les défis liés à la sécurisation de ces environnements prennent de l’ampleur. Permettre aux développeurs de tirer parti des technologies cloud native tout en préservant la sécurité peut s’avérer difficile. Il est également essentiel que les différentes équipes de l’organisation collaborent et comprennent les enjeux dans leur ensemble pour sécuriser des environnements cloud complexes. Enfin, surveiller notre programme et tirer les leçons de nos erreurs est primordial lors d’une transformation de cette ampleur.

Guy Podjarny a rencontré Teri Radichel, PDG de 2nd Sight Lab et auteure de Cybersecurity for Executives in the Age of Cloud. Teri a raconté comment elle s’est lancée dans la sécurité cloud après avoir subi une faille de sécurité dans son ancienne entreprise de développement et d’hébergement d’applications web. 2nd Sight Lab est une société de formation et de conseil spécialisée dans la sécurité cloud. Une grande partie des propos de Teri ne portait pas sur la mise en œuvre de technologies cloud au sein d’une seule organisation, mais plutôt sur son travail de conseil auprès de plusieurs organisations.

Quand on parle du cloud et de sa transformation, une question fondamentale se pose : que signifie exactement le cloud ? Selon Teri : « Certains disent que ce n’est que l’ordinateur de quelqu’un d’autre, mais je dis toujours que c’est plus que cela, car quand je travaillais dans un centre d’hébergement géré, le matériel appartenait déjà à quelqu’un d’autre, n’est-ce pas ? » Pour certaines organisations, l’utilisation de solutions SaaS (Software as a Service) peut également faire partie de leur stratégie cloud.

Comprendre ce qu’est le cloud est déjà complexe. La nature dynamique des technologies cloud native confie donc aux développeurs une grande responsabilité en matière de sécurité. Teri souligne cette complexité : « Si vous êtes développeur et qu’on vous demande maintenant de créer des réseaux, de configurer des buckets S3, des équilibreurs de charge ou des CDN, vous devez vraiment vous renseigner sur les bonnes pratiques. » Elle conseille aux développeurs : « Il existe les CIS Benchmarks, qui présentent les bonnes pratiques pour les trois principaux fournisseurs de cloud. »

Bien sûr, une autre clé pour répondre à la complexité de la sécurité cloud consiste à faire travailler ensemble les développeurs et les experts en sécurité afin qu’ils partagent leurs connaissances, comprennent le travail de chacun et poursuivent un objectif commun : créer des logiciels sécurisés. Radichel a souligné que la sécurité devait jouer un rôle actif à cet égard. « Je pense que la sécurité a une fonction très importante qui ne se fait pas les mains sur le clavier. Il ne s’agit pas de sécurité des applications ni de vérifier que votre code ne comporte pas de faille de type cross-site scripting. La sécurité, c’est la gestion des risques », a-t-elle expliqué.

Enfin, dans toute transformation de grande ampleur, il est également essentiel de veiller à ce que les processus et procédures définis soient systématiquement suivis et à tirer les leçons de nos erreurs. Radichel le reconnaît : « Mais les gens font aussi des erreurs. Il faut donc réfléchir à votre gouvernance globale, à votre organisation et à la façon dont vous allez la structurer pour empêcher les gens de commettre ces erreurs, n’est-ce pas ? »

En définitive, s’appuyer sur le modèle de responsabilité partagée propre à une véritable culture DevSecOps favorise de meilleures pratiques tout au long de la transformation cloud. Les observations et les principales recommandations de Radichel soulignent l’importance de la collaboration entre toutes les équipes impliquées dans le pipeline de livraison, du partage des connaissances et de la poursuite d’un objectif commun.