SCW Icons
hero bg no divider
Blog

Pourquoi la mise en œuvre de DevOps échoue souvent (et comment y remédier)

Pieter Danhieux
Published Jan 01, 2020
Last updated on Mar 06, 2026

Cet article a été initialement publié sur DevOps.com. Il a été mis à jour et modifié.

Tout comme « blockchain », « big data » et « disruption numérique », le terme « DevOps » est un autre mot à la mode actuellement utilisé dans les services informatiques des grandes entreprises.

Beaucoup ont (correctement) identifié la nécessité d'accélérer le cycle de vie du développement logiciel ; un processus plus précis, étroitement aligné sur les objectifs commerciaux, permettant un flux de travail plus clair et une collaboration entre les équipes chargées du développement et des opérations. DevOps est essentiellement un développement « agile », développé et prêt à répondre aux besoins en constante innovation et en déploiement rapide des entreprises modernes. Pour les professionnels de la sécurité, c'est une initiative fantastique : nous pouvons intégrer la sécurité dans le processus bien plus tôt, ce qui réduit le coût de la correction des bogues et évite toute catastrophe potentielle en cours de route.

Le problème est que peu d'entreprises réussissent réellement à mettre en œuvre DevOps. Sans le soutien, les encouragements et la compréhension appropriés au sein de l'entreprise, celle-ci peut rapidement devenir un éléphant blanc... vous savez, l'un de ces projets « ne parlez pas de la guerre ».

Alors, quel est le problème ? C'est une discussion intéressante, et il existe plusieurs manières d'aborder DevOps qui, je pense, faciliteront la navigation. Un programme efficace ne se limite pas à quelques nouveaux outils, titres et réunions d'équipe sophistiqués. Ce ne sera pas toujours facile, mais prendre le temps de corriger une stratégie défaillante (ou de la mettre en œuvre de la bonne façon au début) sera beaucoup moins pénible à long terme. En fin de compte, cela se traduira par des logiciels de meilleure qualité et plus sécurisés.

Décomposons-le :

Lâchez les cordons du tablier « Agile ».

Il existe une idée fausse selon laquelle une organisation doit choisir entre Agile ou DevOps, en se fixant une voie ou une autre, pour ne jamais revenir en arrière.

Le fait est que le processus de développement fonctionne mieux lorsque les deux sont considérés et mis en œuvre comme un seul. DevOps c'est pas une réinvention du développement Agile ; il s'agit plutôt d'une extension de celui-ci. Les roues ont tendance à tomber lorsque l'on s'attend à ce que le processus soit exactement comme Agile, ou complètement différent de Agile.

Agile soutient le principe des équipes interfonctionnelles, en réunissant les concepteurs, les testeurs et les développeurs dès le début et en s'engageant à ouvrir des lignes de communication tout au long d'un projet. Son objectif est de mettre fin à la livraison cloisonnée et de réduire la double gestion, deux avantages du processus DevOps. Cependant, DevOps va encore plus loin en intégrant les systèmes, la sécurité et les opérations dans le mix afin d'offrir un ensemble de compétences robustes de bout en bout dont l'objectif ultime est de fournir des logiciels complets et fonctionnels au client.

Lors des inévitables difficultés liées au passage à un processus davantage centré sur DevOps, le risque d'un développement cloisonné peut réapparaître. Il arrive souvent que l'équipe Agile d'origine travaille ensemble, alors que les éléments supplémentaires liés à la sécurité et aux opérations trouvent toujours leur place dans la machine ; personne ne sait vraiment comment les inclure, ce qu'ils doivent faire et quels sont leurs objectifs généraux.

DevOps ne fonctionne pas sans des objectifs clairement définis, une intégration interfonctionnelle et une communication directe avec toutes les parties. Il y aura une période d'adaptation qui exigera une gestion minutieuse du changement, bien sûr, mais mettre tout le monde sur la même longueur d'onde grâce aux améliorations apportées par les fonctionnalités DevOps représente la moitié de la bataille.

De plus en plus (Dieu merci), DevOps met également l'accent sur les meilleures pratiques de sécurité dans le cadre du processus, démystifiant cette étape et comblant le fossé entre l'équipe de sécurité et, enfin, les autres. Comme je l'ai déjà dit, nous avons encore un long chemin à parcourir pour permettre aux développeurs de coder en toute sécurité dès le départ, mais la mise en œuvre réussie des méthodologies DevOps constitue une excellente base sur laquelle les compétences en matière de sécurité peuvent être renforcées au sein de l'équipe de développement.

L'automatisation n'est pas tout (et ce n'est pas la solution la plus sûre).

Une autre caractéristique de la méthodologie DevOps est, dans une certaine mesure, l'automatisation du processus de développement logiciel. Les principes d'intégration continue et de livraison continue (CI/CD) sont les pierres angulaires de ce concept et, comme vous pouvez probablement le deviner, dépendent largement des outils.

Les outils sont géniaux, ils le sont vraiment. Ils peuvent apporter une rapidité sans précédent au processus de livraison des logiciels, en gérant le référentiel de code, les tests, la maintenance et les éléments de stockage avec une facilité relativement fluide.

Cependant, bien que les robots puissent prendre tous nos emplois et nous emprisonner un jour, ils n'y sont certainement pas encore. La forte dépendance à l'égard des outils et de l'automatisation laisse la porte ouverte aux erreurs. Les scans et les tests peuvent ne pas tout détecter, le code peut ne pas être vérifié, ce qui entraîne d'énormes problèmes de qualité (sans parler de sécurité) à terme. Un attaquant n'a besoin que d'une seule porte dérobée à exploiter pour voler des données, et le fait de renoncer à l'élément humain dans le contrôle de la qualité et de la sécurité peut avoir des conséquences désastreuses.

Le « juste milieu » consiste à vous assurer d'avoir un équilibre entre les personnes et outils. Les outils doivent servir d'assistants à une équipe en qui vous avez confiance pour atteindre les objectifs du projet. Vous devez :

  • Prévoyez suffisamment de temps pour que les utilisateurs se familiarisent avec la chaîne d'outils DevOps choisie
  • Concentrez-vous sur une collaboration efficace (et sur la manière dont les outils peuvent y contribuer)
  • Comblez toutes les lacunes du processus, qu'elles soient liées aux compétences, aux connaissances ou aux outils.

Bref, ne vous contentez pas de « vous outiller » et d'espérer que tout ira pour le mieux.

DevOps n'est pas un mot à la mode, c'est une culture. Est-ce que vous cultivez le vôtre ?

La gestion du changement est difficile dans le meilleur des cas. La peur de l'inconnu peut empêcher même les membres les plus brillants de l'équipe de développer leurs compétences et d'élargir leurs horizons.

Vous voyez, le simple fait de dire « Faisons DevOps » et de faire déplacer les bureaux de l'équipe des opérations ne suffira pas à mettre en œuvre un processus réussi comme par magie. Beaucoup seront confus et les membres de longue date de l'équipe seront mécontents. La communication des attentes est cruciale, tout comme le fait de « marcher sur les actes ». DevOps représente un mouvement culturel tout autant qu'une méthodologie de développement, et une équipe doit vivre et respirer un état d'esprit interfonctionnel et collaboratif.

À quoi ressemble une bonne culture DevOps ?

  • Les individus sont habilités à apporter leur expertise à un processus, et pas seulement aux dirigeants
  • Communication ouverte, honnête et respectueuse entre les équipes
  • Chaque personne assume la responsabilité de l'objectif global qui consiste à intégrer la qualité et la sécurité dans le processus de développement
  • Tout le monde est sur la même longueur d'onde en ce qui concerne la définition du DevOps dans l'entreprise, la feuille de route et le comment/quoi/pourquoi du rôle de chacun.

Cela fait des années que je souligne l'importance de créer une culture de sécurité positive au sein des équipes de développement, et DevOps ne fait pas exception à la règle.

Les outils, les connaissances et le support appropriés sont essentiels pour appliquer les meilleures pratiques en matière de sécurité, constater une diminution des vulnérabilités découvertes et faire comprendre à l'équipe l'importance de protéger nos données. Avec DevOps, vous devez jeter les bases culturelles d'un changement positif : vous assurer que chacun comprend son rôle, sa valeur et ses attentes, les objectifs généraux du projet et les étapes du processus.

L'avez-vous maîtrisé ? Génial. Maintenant, changeons les choses, améliorons l'aspect sécurité et faisons de DevSecOps le plan ultime en matière d'excellence logicielle.

Afficher la ressource
Afficher la ressource

Peu d'entreprises réussissent réellement à mettre en œuvre DevOps. Cependant, un soutien, une prise en charge et une compréhension appropriés au sein de l'entreprise peuvent transformer votre processus.

Vous souhaitez en savoir plus ?

Chief Executive Officer, Chairman, and Co-Founder

learn more

Secure Code Warrior est là pour aider votre organisation à sécuriser le code tout au long du cycle de développement logiciel et à créer une culture dans laquelle la cybersécurité est une priorité. Que vous soyez responsable de la sécurité des applications, développeur, responsable de la sécurité informatique ou toute autre personne impliquée dans la sécurité, nous pouvons aider votre organisation à réduire les risques associés à un code non sécurisé.

Réservez une démo
Partagez sur :
linkedin brandsSocialx logo
Auteur
Pieter Danhieux
Published Jan 01, 2020

Chief Executive Officer, Chairman, and Co-Founder

Pieter Danhieux is a globally recognized security expert, with over 12 years experience as a security consultant and 8 years as a Principal Instructor for SANS teaching offensive techniques on how to target and assess organizations, systems and individuals for security weaknesses. In 2016, he was recognized as one of the Coolest Tech people in Australia (Business Insider), awarded Cyber Security Professional of the Year (AISA - Australian Information Security Association) and holds GSE, CISSP, GCIH, GCFA, GSEC, GPEN, GWAPT, GCIA certifications.

Partagez sur :
linkedin brandsSocialx logo

Cet article a été initialement publié sur DevOps.com. Il a été mis à jour et modifié.

Tout comme « blockchain », « big data » et « disruption numérique », le terme « DevOps » est un autre mot à la mode actuellement utilisé dans les services informatiques des grandes entreprises.

Beaucoup ont (correctement) identifié la nécessité d'accélérer le cycle de vie du développement logiciel ; un processus plus précis, étroitement aligné sur les objectifs commerciaux, permettant un flux de travail plus clair et une collaboration entre les équipes chargées du développement et des opérations. DevOps est essentiellement un développement « agile », développé et prêt à répondre aux besoins en constante innovation et en déploiement rapide des entreprises modernes. Pour les professionnels de la sécurité, c'est une initiative fantastique : nous pouvons intégrer la sécurité dans le processus bien plus tôt, ce qui réduit le coût de la correction des bogues et évite toute catastrophe potentielle en cours de route.

Le problème est que peu d'entreprises réussissent réellement à mettre en œuvre DevOps. Sans le soutien, les encouragements et la compréhension appropriés au sein de l'entreprise, celle-ci peut rapidement devenir un éléphant blanc... vous savez, l'un de ces projets « ne parlez pas de la guerre ».

Alors, quel est le problème ? C'est une discussion intéressante, et il existe plusieurs manières d'aborder DevOps qui, je pense, faciliteront la navigation. Un programme efficace ne se limite pas à quelques nouveaux outils, titres et réunions d'équipe sophistiqués. Ce ne sera pas toujours facile, mais prendre le temps de corriger une stratégie défaillante (ou de la mettre en œuvre de la bonne façon au début) sera beaucoup moins pénible à long terme. En fin de compte, cela se traduira par des logiciels de meilleure qualité et plus sécurisés.

Décomposons-le :

Lâchez les cordons du tablier « Agile ».

Il existe une idée fausse selon laquelle une organisation doit choisir entre Agile ou DevOps, en se fixant une voie ou une autre, pour ne jamais revenir en arrière.

Le fait est que le processus de développement fonctionne mieux lorsque les deux sont considérés et mis en œuvre comme un seul. DevOps c'est pas une réinvention du développement Agile ; il s'agit plutôt d'une extension de celui-ci. Les roues ont tendance à tomber lorsque l'on s'attend à ce que le processus soit exactement comme Agile, ou complètement différent de Agile.

Agile soutient le principe des équipes interfonctionnelles, en réunissant les concepteurs, les testeurs et les développeurs dès le début et en s'engageant à ouvrir des lignes de communication tout au long d'un projet. Son objectif est de mettre fin à la livraison cloisonnée et de réduire la double gestion, deux avantages du processus DevOps. Cependant, DevOps va encore plus loin en intégrant les systèmes, la sécurité et les opérations dans le mix afin d'offrir un ensemble de compétences robustes de bout en bout dont l'objectif ultime est de fournir des logiciels complets et fonctionnels au client.

Lors des inévitables difficultés liées au passage à un processus davantage centré sur DevOps, le risque d'un développement cloisonné peut réapparaître. Il arrive souvent que l'équipe Agile d'origine travaille ensemble, alors que les éléments supplémentaires liés à la sécurité et aux opérations trouvent toujours leur place dans la machine ; personne ne sait vraiment comment les inclure, ce qu'ils doivent faire et quels sont leurs objectifs généraux.

DevOps ne fonctionne pas sans des objectifs clairement définis, une intégration interfonctionnelle et une communication directe avec toutes les parties. Il y aura une période d'adaptation qui exigera une gestion minutieuse du changement, bien sûr, mais mettre tout le monde sur la même longueur d'onde grâce aux améliorations apportées par les fonctionnalités DevOps représente la moitié de la bataille.

De plus en plus (Dieu merci), DevOps met également l'accent sur les meilleures pratiques de sécurité dans le cadre du processus, démystifiant cette étape et comblant le fossé entre l'équipe de sécurité et, enfin, les autres. Comme je l'ai déjà dit, nous avons encore un long chemin à parcourir pour permettre aux développeurs de coder en toute sécurité dès le départ, mais la mise en œuvre réussie des méthodologies DevOps constitue une excellente base sur laquelle les compétences en matière de sécurité peuvent être renforcées au sein de l'équipe de développement.

L'automatisation n'est pas tout (et ce n'est pas la solution la plus sûre).

Une autre caractéristique de la méthodologie DevOps est, dans une certaine mesure, l'automatisation du processus de développement logiciel. Les principes d'intégration continue et de livraison continue (CI/CD) sont les pierres angulaires de ce concept et, comme vous pouvez probablement le deviner, dépendent largement des outils.

Les outils sont géniaux, ils le sont vraiment. Ils peuvent apporter une rapidité sans précédent au processus de livraison des logiciels, en gérant le référentiel de code, les tests, la maintenance et les éléments de stockage avec une facilité relativement fluide.

Cependant, bien que les robots puissent prendre tous nos emplois et nous emprisonner un jour, ils n'y sont certainement pas encore. La forte dépendance à l'égard des outils et de l'automatisation laisse la porte ouverte aux erreurs. Les scans et les tests peuvent ne pas tout détecter, le code peut ne pas être vérifié, ce qui entraîne d'énormes problèmes de qualité (sans parler de sécurité) à terme. Un attaquant n'a besoin que d'une seule porte dérobée à exploiter pour voler des données, et le fait de renoncer à l'élément humain dans le contrôle de la qualité et de la sécurité peut avoir des conséquences désastreuses.

Le « juste milieu » consiste à vous assurer d'avoir un équilibre entre les personnes et outils. Les outils doivent servir d'assistants à une équipe en qui vous avez confiance pour atteindre les objectifs du projet. Vous devez :

  • Prévoyez suffisamment de temps pour que les utilisateurs se familiarisent avec la chaîne d'outils DevOps choisie
  • Concentrez-vous sur une collaboration efficace (et sur la manière dont les outils peuvent y contribuer)
  • Comblez toutes les lacunes du processus, qu'elles soient liées aux compétences, aux connaissances ou aux outils.

Bref, ne vous contentez pas de « vous outiller » et d'espérer que tout ira pour le mieux.

DevOps n'est pas un mot à la mode, c'est une culture. Est-ce que vous cultivez le vôtre ?

La gestion du changement est difficile dans le meilleur des cas. La peur de l'inconnu peut empêcher même les membres les plus brillants de l'équipe de développer leurs compétences et d'élargir leurs horizons.

Vous voyez, le simple fait de dire « Faisons DevOps » et de faire déplacer les bureaux de l'équipe des opérations ne suffira pas à mettre en œuvre un processus réussi comme par magie. Beaucoup seront confus et les membres de longue date de l'équipe seront mécontents. La communication des attentes est cruciale, tout comme le fait de « marcher sur les actes ». DevOps représente un mouvement culturel tout autant qu'une méthodologie de développement, et une équipe doit vivre et respirer un état d'esprit interfonctionnel et collaboratif.

À quoi ressemble une bonne culture DevOps ?

  • Les individus sont habilités à apporter leur expertise à un processus, et pas seulement aux dirigeants
  • Communication ouverte, honnête et respectueuse entre les équipes
  • Chaque personne assume la responsabilité de l'objectif global qui consiste à intégrer la qualité et la sécurité dans le processus de développement
  • Tout le monde est sur la même longueur d'onde en ce qui concerne la définition du DevOps dans l'entreprise, la feuille de route et le comment/quoi/pourquoi du rôle de chacun.

Cela fait des années que je souligne l'importance de créer une culture de sécurité positive au sein des équipes de développement, et DevOps ne fait pas exception à la règle.

Les outils, les connaissances et le support appropriés sont essentiels pour appliquer les meilleures pratiques en matière de sécurité, constater une diminution des vulnérabilités découvertes et faire comprendre à l'équipe l'importance de protéger nos données. Avec DevOps, vous devez jeter les bases culturelles d'un changement positif : vous assurer que chacun comprend son rôle, sa valeur et ses attentes, les objectifs généraux du projet et les étapes du processus.

L'avez-vous maîtrisé ? Génial. Maintenant, changeons les choses, améliorons l'aspect sécurité et faisons de DevSecOps le plan ultime en matière d'excellence logicielle.

Afficher la ressource
Afficher la ressource

Remplissez le formulaire ci-dessous pour télécharger le rapport

Nous aimerions avoir votre autorisation pour vous envoyer des informations sur nos produits et/ou sur des sujets liés au codage sécurisé. Nous traiterons toujours vos données personnelles avec le plus grand soin et ne les vendrons jamais à d'autres entreprises à des fins de marketing.

Soumettre
scw success icon
scw error icon
Pour soumettre le formulaire, veuillez activer les cookies « Analytics ». N'hésitez pas à les désactiver à nouveau une fois que vous aurez terminé.

Cet article a été initialement publié sur DevOps.com. Il a été mis à jour et modifié.

Tout comme « blockchain », « big data » et « disruption numérique », le terme « DevOps » est un autre mot à la mode actuellement utilisé dans les services informatiques des grandes entreprises.

Beaucoup ont (correctement) identifié la nécessité d'accélérer le cycle de vie du développement logiciel ; un processus plus précis, étroitement aligné sur les objectifs commerciaux, permettant un flux de travail plus clair et une collaboration entre les équipes chargées du développement et des opérations. DevOps est essentiellement un développement « agile », développé et prêt à répondre aux besoins en constante innovation et en déploiement rapide des entreprises modernes. Pour les professionnels de la sécurité, c'est une initiative fantastique : nous pouvons intégrer la sécurité dans le processus bien plus tôt, ce qui réduit le coût de la correction des bogues et évite toute catastrophe potentielle en cours de route.

Le problème est que peu d'entreprises réussissent réellement à mettre en œuvre DevOps. Sans le soutien, les encouragements et la compréhension appropriés au sein de l'entreprise, celle-ci peut rapidement devenir un éléphant blanc... vous savez, l'un de ces projets « ne parlez pas de la guerre ».

Alors, quel est le problème ? C'est une discussion intéressante, et il existe plusieurs manières d'aborder DevOps qui, je pense, faciliteront la navigation. Un programme efficace ne se limite pas à quelques nouveaux outils, titres et réunions d'équipe sophistiqués. Ce ne sera pas toujours facile, mais prendre le temps de corriger une stratégie défaillante (ou de la mettre en œuvre de la bonne façon au début) sera beaucoup moins pénible à long terme. En fin de compte, cela se traduira par des logiciels de meilleure qualité et plus sécurisés.

Décomposons-le :

Lâchez les cordons du tablier « Agile ».

Il existe une idée fausse selon laquelle une organisation doit choisir entre Agile ou DevOps, en se fixant une voie ou une autre, pour ne jamais revenir en arrière.

Le fait est que le processus de développement fonctionne mieux lorsque les deux sont considérés et mis en œuvre comme un seul. DevOps c'est pas une réinvention du développement Agile ; il s'agit plutôt d'une extension de celui-ci. Les roues ont tendance à tomber lorsque l'on s'attend à ce que le processus soit exactement comme Agile, ou complètement différent de Agile.

Agile soutient le principe des équipes interfonctionnelles, en réunissant les concepteurs, les testeurs et les développeurs dès le début et en s'engageant à ouvrir des lignes de communication tout au long d'un projet. Son objectif est de mettre fin à la livraison cloisonnée et de réduire la double gestion, deux avantages du processus DevOps. Cependant, DevOps va encore plus loin en intégrant les systèmes, la sécurité et les opérations dans le mix afin d'offrir un ensemble de compétences robustes de bout en bout dont l'objectif ultime est de fournir des logiciels complets et fonctionnels au client.

Lors des inévitables difficultés liées au passage à un processus davantage centré sur DevOps, le risque d'un développement cloisonné peut réapparaître. Il arrive souvent que l'équipe Agile d'origine travaille ensemble, alors que les éléments supplémentaires liés à la sécurité et aux opérations trouvent toujours leur place dans la machine ; personne ne sait vraiment comment les inclure, ce qu'ils doivent faire et quels sont leurs objectifs généraux.

DevOps ne fonctionne pas sans des objectifs clairement définis, une intégration interfonctionnelle et une communication directe avec toutes les parties. Il y aura une période d'adaptation qui exigera une gestion minutieuse du changement, bien sûr, mais mettre tout le monde sur la même longueur d'onde grâce aux améliorations apportées par les fonctionnalités DevOps représente la moitié de la bataille.

De plus en plus (Dieu merci), DevOps met également l'accent sur les meilleures pratiques de sécurité dans le cadre du processus, démystifiant cette étape et comblant le fossé entre l'équipe de sécurité et, enfin, les autres. Comme je l'ai déjà dit, nous avons encore un long chemin à parcourir pour permettre aux développeurs de coder en toute sécurité dès le départ, mais la mise en œuvre réussie des méthodologies DevOps constitue une excellente base sur laquelle les compétences en matière de sécurité peuvent être renforcées au sein de l'équipe de développement.

L'automatisation n'est pas tout (et ce n'est pas la solution la plus sûre).

Une autre caractéristique de la méthodologie DevOps est, dans une certaine mesure, l'automatisation du processus de développement logiciel. Les principes d'intégration continue et de livraison continue (CI/CD) sont les pierres angulaires de ce concept et, comme vous pouvez probablement le deviner, dépendent largement des outils.

Les outils sont géniaux, ils le sont vraiment. Ils peuvent apporter une rapidité sans précédent au processus de livraison des logiciels, en gérant le référentiel de code, les tests, la maintenance et les éléments de stockage avec une facilité relativement fluide.

Cependant, bien que les robots puissent prendre tous nos emplois et nous emprisonner un jour, ils n'y sont certainement pas encore. La forte dépendance à l'égard des outils et de l'automatisation laisse la porte ouverte aux erreurs. Les scans et les tests peuvent ne pas tout détecter, le code peut ne pas être vérifié, ce qui entraîne d'énormes problèmes de qualité (sans parler de sécurité) à terme. Un attaquant n'a besoin que d'une seule porte dérobée à exploiter pour voler des données, et le fait de renoncer à l'élément humain dans le contrôle de la qualité et de la sécurité peut avoir des conséquences désastreuses.

Le « juste milieu » consiste à vous assurer d'avoir un équilibre entre les personnes et outils. Les outils doivent servir d'assistants à une équipe en qui vous avez confiance pour atteindre les objectifs du projet. Vous devez :

  • Prévoyez suffisamment de temps pour que les utilisateurs se familiarisent avec la chaîne d'outils DevOps choisie
  • Concentrez-vous sur une collaboration efficace (et sur la manière dont les outils peuvent y contribuer)
  • Comblez toutes les lacunes du processus, qu'elles soient liées aux compétences, aux connaissances ou aux outils.

Bref, ne vous contentez pas de « vous outiller » et d'espérer que tout ira pour le mieux.

DevOps n'est pas un mot à la mode, c'est une culture. Est-ce que vous cultivez le vôtre ?

La gestion du changement est difficile dans le meilleur des cas. La peur de l'inconnu peut empêcher même les membres les plus brillants de l'équipe de développer leurs compétences et d'élargir leurs horizons.

Vous voyez, le simple fait de dire « Faisons DevOps » et de faire déplacer les bureaux de l'équipe des opérations ne suffira pas à mettre en œuvre un processus réussi comme par magie. Beaucoup seront confus et les membres de longue date de l'équipe seront mécontents. La communication des attentes est cruciale, tout comme le fait de « marcher sur les actes ». DevOps représente un mouvement culturel tout autant qu'une méthodologie de développement, et une équipe doit vivre et respirer un état d'esprit interfonctionnel et collaboratif.

À quoi ressemble une bonne culture DevOps ?

  • Les individus sont habilités à apporter leur expertise à un processus, et pas seulement aux dirigeants
  • Communication ouverte, honnête et respectueuse entre les équipes
  • Chaque personne assume la responsabilité de l'objectif global qui consiste à intégrer la qualité et la sécurité dans le processus de développement
  • Tout le monde est sur la même longueur d'onde en ce qui concerne la définition du DevOps dans l'entreprise, la feuille de route et le comment/quoi/pourquoi du rôle de chacun.

Cela fait des années que je souligne l'importance de créer une culture de sécurité positive au sein des équipes de développement, et DevOps ne fait pas exception à la règle.

Les outils, les connaissances et le support appropriés sont essentiels pour appliquer les meilleures pratiques en matière de sécurité, constater une diminution des vulnérabilités découvertes et faire comprendre à l'équipe l'importance de protéger nos données. Avec DevOps, vous devez jeter les bases culturelles d'un changement positif : vous assurer que chacun comprend son rôle, sa valeur et ses attentes, les objectifs généraux du projet et les étapes du processus.

L'avez-vous maîtrisé ? Génial. Maintenant, changeons les choses, améliorons l'aspect sécurité et faisons de DevSecOps le plan ultime en matière d'excellence logicielle.

Afficher le webinaire
Commencez
learn more

Cliquez sur le lien ci-dessous et téléchargez le PDF de cette ressource.

Secure Code Warrior est là pour aider votre organisation à sécuriser le code tout au long du cycle de développement logiciel et à créer une culture dans laquelle la cybersécurité est une priorité. Que vous soyez responsable de la sécurité des applications, développeur, responsable de la sécurité informatique ou toute autre personne impliquée dans la sécurité, nous pouvons aider votre organisation à réduire les risques associés à un code non sécurisé.

Afficher le rapportRéservez une démo
Télécharger le PDF
Afficher la ressource
Partagez sur :
linkedin brandsSocialx logo
Vous souhaitez en savoir plus ?

Partagez sur :
linkedin brandsSocialx logo
Auteur
Pieter Danhieux
Published Jan 01, 2020

Chief Executive Officer, Chairman, and Co-Founder

Pieter Danhieux is a globally recognized security expert, with over 12 years experience as a security consultant and 8 years as a Principal Instructor for SANS teaching offensive techniques on how to target and assess organizations, systems and individuals for security weaknesses. In 2016, he was recognized as one of the Coolest Tech people in Australia (Business Insider), awarded Cyber Security Professional of the Year (AISA - Australian Information Security Association) and holds GSE, CISSP, GCIH, GCFA, GSEC, GPEN, GWAPT, GCIA certifications.

Partagez sur :
linkedin brandsSocialx logo

Cet article a été initialement publié sur DevOps.com. Il a été mis à jour et modifié.

Tout comme « blockchain », « big data » et « disruption numérique », le terme « DevOps » est un autre mot à la mode actuellement utilisé dans les services informatiques des grandes entreprises.

Beaucoup ont (correctement) identifié la nécessité d'accélérer le cycle de vie du développement logiciel ; un processus plus précis, étroitement aligné sur les objectifs commerciaux, permettant un flux de travail plus clair et une collaboration entre les équipes chargées du développement et des opérations. DevOps est essentiellement un développement « agile », développé et prêt à répondre aux besoins en constante innovation et en déploiement rapide des entreprises modernes. Pour les professionnels de la sécurité, c'est une initiative fantastique : nous pouvons intégrer la sécurité dans le processus bien plus tôt, ce qui réduit le coût de la correction des bogues et évite toute catastrophe potentielle en cours de route.

Le problème est que peu d'entreprises réussissent réellement à mettre en œuvre DevOps. Sans le soutien, les encouragements et la compréhension appropriés au sein de l'entreprise, celle-ci peut rapidement devenir un éléphant blanc... vous savez, l'un de ces projets « ne parlez pas de la guerre ».

Alors, quel est le problème ? C'est une discussion intéressante, et il existe plusieurs manières d'aborder DevOps qui, je pense, faciliteront la navigation. Un programme efficace ne se limite pas à quelques nouveaux outils, titres et réunions d'équipe sophistiqués. Ce ne sera pas toujours facile, mais prendre le temps de corriger une stratégie défaillante (ou de la mettre en œuvre de la bonne façon au début) sera beaucoup moins pénible à long terme. En fin de compte, cela se traduira par des logiciels de meilleure qualité et plus sécurisés.

Décomposons-le :

Lâchez les cordons du tablier « Agile ».

Il existe une idée fausse selon laquelle une organisation doit choisir entre Agile ou DevOps, en se fixant une voie ou une autre, pour ne jamais revenir en arrière.

Le fait est que le processus de développement fonctionne mieux lorsque les deux sont considérés et mis en œuvre comme un seul. DevOps c'est pas une réinvention du développement Agile ; il s'agit plutôt d'une extension de celui-ci. Les roues ont tendance à tomber lorsque l'on s'attend à ce que le processus soit exactement comme Agile, ou complètement différent de Agile.

Agile soutient le principe des équipes interfonctionnelles, en réunissant les concepteurs, les testeurs et les développeurs dès le début et en s'engageant à ouvrir des lignes de communication tout au long d'un projet. Son objectif est de mettre fin à la livraison cloisonnée et de réduire la double gestion, deux avantages du processus DevOps. Cependant, DevOps va encore plus loin en intégrant les systèmes, la sécurité et les opérations dans le mix afin d'offrir un ensemble de compétences robustes de bout en bout dont l'objectif ultime est de fournir des logiciels complets et fonctionnels au client.

Lors des inévitables difficultés liées au passage à un processus davantage centré sur DevOps, le risque d'un développement cloisonné peut réapparaître. Il arrive souvent que l'équipe Agile d'origine travaille ensemble, alors que les éléments supplémentaires liés à la sécurité et aux opérations trouvent toujours leur place dans la machine ; personne ne sait vraiment comment les inclure, ce qu'ils doivent faire et quels sont leurs objectifs généraux.

DevOps ne fonctionne pas sans des objectifs clairement définis, une intégration interfonctionnelle et une communication directe avec toutes les parties. Il y aura une période d'adaptation qui exigera une gestion minutieuse du changement, bien sûr, mais mettre tout le monde sur la même longueur d'onde grâce aux améliorations apportées par les fonctionnalités DevOps représente la moitié de la bataille.

De plus en plus (Dieu merci), DevOps met également l'accent sur les meilleures pratiques de sécurité dans le cadre du processus, démystifiant cette étape et comblant le fossé entre l'équipe de sécurité et, enfin, les autres. Comme je l'ai déjà dit, nous avons encore un long chemin à parcourir pour permettre aux développeurs de coder en toute sécurité dès le départ, mais la mise en œuvre réussie des méthodologies DevOps constitue une excellente base sur laquelle les compétences en matière de sécurité peuvent être renforcées au sein de l'équipe de développement.

L'automatisation n'est pas tout (et ce n'est pas la solution la plus sûre).

Une autre caractéristique de la méthodologie DevOps est, dans une certaine mesure, l'automatisation du processus de développement logiciel. Les principes d'intégration continue et de livraison continue (CI/CD) sont les pierres angulaires de ce concept et, comme vous pouvez probablement le deviner, dépendent largement des outils.

Les outils sont géniaux, ils le sont vraiment. Ils peuvent apporter une rapidité sans précédent au processus de livraison des logiciels, en gérant le référentiel de code, les tests, la maintenance et les éléments de stockage avec une facilité relativement fluide.

Cependant, bien que les robots puissent prendre tous nos emplois et nous emprisonner un jour, ils n'y sont certainement pas encore. La forte dépendance à l'égard des outils et de l'automatisation laisse la porte ouverte aux erreurs. Les scans et les tests peuvent ne pas tout détecter, le code peut ne pas être vérifié, ce qui entraîne d'énormes problèmes de qualité (sans parler de sécurité) à terme. Un attaquant n'a besoin que d'une seule porte dérobée à exploiter pour voler des données, et le fait de renoncer à l'élément humain dans le contrôle de la qualité et de la sécurité peut avoir des conséquences désastreuses.

Le « juste milieu » consiste à vous assurer d'avoir un équilibre entre les personnes et outils. Les outils doivent servir d'assistants à une équipe en qui vous avez confiance pour atteindre les objectifs du projet. Vous devez :

  • Prévoyez suffisamment de temps pour que les utilisateurs se familiarisent avec la chaîne d'outils DevOps choisie
  • Concentrez-vous sur une collaboration efficace (et sur la manière dont les outils peuvent y contribuer)
  • Comblez toutes les lacunes du processus, qu'elles soient liées aux compétences, aux connaissances ou aux outils.

Bref, ne vous contentez pas de « vous outiller » et d'espérer que tout ira pour le mieux.

DevOps n'est pas un mot à la mode, c'est une culture. Est-ce que vous cultivez le vôtre ?

La gestion du changement est difficile dans le meilleur des cas. La peur de l'inconnu peut empêcher même les membres les plus brillants de l'équipe de développer leurs compétences et d'élargir leurs horizons.

Vous voyez, le simple fait de dire « Faisons DevOps » et de faire déplacer les bureaux de l'équipe des opérations ne suffira pas à mettre en œuvre un processus réussi comme par magie. Beaucoup seront confus et les membres de longue date de l'équipe seront mécontents. La communication des attentes est cruciale, tout comme le fait de « marcher sur les actes ». DevOps représente un mouvement culturel tout autant qu'une méthodologie de développement, et une équipe doit vivre et respirer un état d'esprit interfonctionnel et collaboratif.

À quoi ressemble une bonne culture DevOps ?

  • Les individus sont habilités à apporter leur expertise à un processus, et pas seulement aux dirigeants
  • Communication ouverte, honnête et respectueuse entre les équipes
  • Chaque personne assume la responsabilité de l'objectif global qui consiste à intégrer la qualité et la sécurité dans le processus de développement
  • Tout le monde est sur la même longueur d'onde en ce qui concerne la définition du DevOps dans l'entreprise, la feuille de route et le comment/quoi/pourquoi du rôle de chacun.

Cela fait des années que je souligne l'importance de créer une culture de sécurité positive au sein des équipes de développement, et DevOps ne fait pas exception à la règle.

Les outils, les connaissances et le support appropriés sont essentiels pour appliquer les meilleures pratiques en matière de sécurité, constater une diminution des vulnérabilités découvertes et faire comprendre à l'équipe l'importance de protéger nos données. Avec DevOps, vous devez jeter les bases culturelles d'un changement positif : vous assurer que chacun comprend son rôle, sa valeur et ses attentes, les objectifs généraux du projet et les étapes du processus.

L'avez-vous maîtrisé ? Génial. Maintenant, changeons les choses, améliorons l'aspect sécurité et faisons de DevSecOps le plan ultime en matière d'excellence logicielle.

Table des matières

Télécharger le PDF
Afficher la ressource
Vous souhaitez en savoir plus ?

Chief Executive Officer, Chairman, and Co-Founder

learn more

Secure Code Warrior est là pour aider votre organisation à sécuriser le code tout au long du cycle de développement logiciel et à créer une culture dans laquelle la cybersécurité est une priorité. Que vous soyez responsable de la sécurité des applications, développeur, responsable de la sécurité informatique ou toute autre personne impliquée dans la sécurité, nous pouvons aider votre organisation à réduire les risques associés à un code non sécurisé.

Réservez une démoTélécharger
Partagez sur :
linkedin brandsSocialx logo
Centre de ressources

Ressources pour vous aider à démarrer

Plus de posts
Centre de ressources

Ressources pour vous aider à démarrer

Plus de posts