
Pourquoi la mise en œuvre de DevOps échoue souvent (et comment y remédier)
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.


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.
Chief Executive Officer, Chairman, and Co-Founder

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émoChief 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.


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.

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.

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émoChief 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.
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
Chief Executive Officer, Chairman, and Co-Founder

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échargerRessources pour vous aider à démarrer
Sujets et contenus de formation sur le code sécurisé
Notre contenu de pointe évolue constamment pour s'adapter à l'évolution constante du paysage du développement de logiciels tout en tenant compte de votre rôle. Des sujets couvrant tout, de l'IA à l'injection XQuery, proposés pour une variété de postes, allant des architectes aux ingénieurs en passant par les chefs de produit et l'assurance qualité. Découvrez un aperçu de ce que notre catalogue de contenu a à offrir par sujet et par rôle.
Threat Modeling with AI: Turning Every Developer into a Threat Modeler
Walk away better equipped to help developers combine threat modeling ideas and techniques with the AI tools they're already using to strengthen security, improve collaboration, and build more resilient software from the start.
Ressources pour vous aider à démarrer
Cybermon est de retour : les missions d'IA Beat the Boss sont désormais disponibles à la demande
Cybermon 2025 Beat the Boss est désormais disponible toute l'année dans SCW. Déployez des défis de sécurité avancés liés à l'IA et au LLM pour renforcer le développement sécurisé de l'IA à grande échelle.
Explication de la loi sur la cyberrésilience : ce que cela signifie pour le développement de logiciels sécurisés dès la conception
Découvrez ce que la loi européenne sur la cyberrésilience (CRA) exige, à qui elle s'applique et comment les équipes d'ingénieurs peuvent se préparer grâce à des pratiques de sécurité dès la conception, à la prévention des vulnérabilités et au renforcement des capacités des développeurs.
Facilitateur 1 : Critères de réussite définis et mesurables
Enabler 1 donne le coup d'envoi de notre série en 10 parties intitulée Enablers of Success en montrant comment associer le codage sécurisé à des résultats commerciaux tels que la réduction des risques et la rapidité pour assurer la maturité à long terme des programmes.




%20(1).avif)
.avif)
