Pourquoi les implémentations DevOps échouent souvent (et comment y remédier)

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

Tout comme la « blockchain », le « big data » ou la « disruption numérique », le terme « DevOps » est un mot à la mode qui circule actuellement dans les départements informatiques des grandes organisations.

Beaucoup ont (à juste titre) identifié le besoin de cycles de développement logiciel plus rapides ; un processus plus précis, étroitement aligné sur les objectifs commerciaux, permettant une meilleure fluidité des flux de travail et une collaboration accrue entre les équipes de développement et d'exploitation. Le DevOps est essentiellement le développement « Agile », arrivé à maturité et prêt à répondre aux besoins d'innovation constante et de 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 beaucoup plus tôt, réduisant ainsi le coût de correction des bugs et évitant des catastrophes potentielles par la suite.

Le problème est que peu d'entreprises réussissent réellement leur implémentation DevOps. Sans le soutien, l'accompagnement et la compréhension nécessaires à travers toute l'entreprise, cela peut rapidement devenir un projet inutile et coûteux... vous savez, l'un de ces sujets dont on préfère ne pas parler.

Alors, quel est le problème ? C'est une discussion intéressante, et je pense qu'il existe plusieurs façons d'aborder le DevOps pour une transition beaucoup plus fluide. Un programme efficace va au-delà de quelques nouveaux outils sophistiqués, de nouveaux titres de postes et de réunions d'équipe. Ce ne sera pas toujours facile, mais prendre le temps de corriger une stratégie défaillante (ou de l'implémenter correctement dès le départ) sera bien moins douloureux à long terme. Et, en fin de compte, cela se traduira par un logiciel de meilleure qualité et plus sécurisé.

Analysons cela :

Affranchissez-vous de la dépendance à l'« Agile ».

Il existe une certaine idée reçue selon laquelle une organisation doit choisir entre Agile ou DevOps, s'engageant sur une voie sans retour possible.

La réalité est que le processus de développement fonctionne mieux lorsque les deux sont envisagés et mis en œuvre comme un tout. Le DevOps n'est pas une réinvention du développement Agile ; c'est plutôt son prolongement. Les choses commencent à dérailler lorsqu'on s'attend à ce que le processus soit exactement identique à l'Agile, ou complètement différent de l'Agile.

L'Agile soutient le principe des équipes pluridisciplinaires, réunissant concepteurs, testeurs et développeurs dès le début et s'engageant à maintenir des lignes de communication ouvertes tout au long d'un projet. Son objectif est de mettre fin au travail en silos et de réduire les tâches redondantes, deux avantages que l'on retrouve également dans le processus DevOps. Cependant, le DevOps va plus loin en intégrant les systèmes, la sécurité et les opérations pour offrir un ensemble de compétences robuste et complet, dont le but ultime est la livraison d'un logiciel pleinement fonctionnel au client.

Lors des inévitables difficultés liées au passage à un processus plus centré sur le DevOps, le risque de voir réapparaître des silos de développement peut survenir. Il arrive souvent que l'équipe Agile initiale travaille ensemble, tandis que les nouveaux venus de la sécurité et des opérations cherchent encore leur place dans la machine ; personne ne sait vraiment comment les intégrer, ce qu'ils doivent faire ni quels sont leurs objectifs globaux.

Le DevOps ne fonctionne pas sans objectifs clairement définis, une intégration pluridisciplinaire et une communication directe avec toutes les parties prenantes. Il y aura une période d'ajustement nécessitant une gestion du changement minutieuse, certes, mais mettre tout le monde sur la même longueur d'onde concernant les améliorations qu'apportera le DevOps est déjà la moitié du chemin parcouru.

De plus en plus (et heureusement), le DevOps met 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, eh bien, tout le monde. Comme je l'ai déjà dit, nous avons encore un long chemin à parcourir pour permettre aux développeurs de coder de manière sécurisée dès le départ, mais la mise en œuvre réussie des méthodologies DevOps constitue une excellente base sur laquelle renforcer les compétences en sécurité au sein de l'équipe de développement.

L'automatisation ne fait pas tout (et ce n'est pas ce qu'il y a de plus sûr).

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, ils dépendent fortement des outils.

Les outils sont formidables, vraiment. Ils peuvent apporter une vitesse sans précédent au processus de livraison de logiciels, en gérant le dépôt de code, les tests, la maintenance et les éléments de stockage avec une facilité relativement déconcertante.

Cependant, même si les robots finiront peut-être par prendre tous nos emplois et nous emprisonner un jour, nous n'en sommes certainement pas encore là. Une dépendance excessive aux outils et à l'automatisation laisse une porte grande ouverte aux erreurs. Les analyses 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 la sécurité) par la suite. Un attaquant n'a besoin que d'une seule porte dérobée à exploiter pour voler des données, et négliger 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 à assurer un équilibre entre les personnes et les outils. Les outils doivent servir d'assistants à une équipe en laquelle vous avez confiance pour atteindre les objectifs du projet. Vous devriez :

• Allouer suffisamment de temps aux collaborateurs pour qu'ils se familiarisent avec la chaîne d'outils DevOps choisie
• Mettre l'accent sur une collaboration efficace (et sur la manière dont les outils peuvent la soutenir)
• Combler toute lacune dans le processus, qu'elle soit liée aux compétences, aux connaissances ou aux outils.

En résumé, ne vous contentez pas d'acheter des outils en espérant que tout se passe bien.

DevOps n'est pas qu'un mot à la mode, c'est une culture. Cultivez-vous la vôtre ?

La gestion du changement est toujours délicate. La peur de l'inconnu peut freiner même les membres les plus brillants d'une équipe dans leur montée en compétences et leur ouverture d'esprit.

En effet, décréter le passage au DevOps et déplacer les bureaux de l'équipe opérationnelle ne suffira pas à instaurer un processus efficace. Beaucoup seront désorientés et les collaborateurs de longue date risquent de se sentir frustrés. Il est crucial de communiquer clairement les attentes et de montrer l'exemple. Le DevOps est autant un mouvement culturel qu'une méthodologie de développement ; l'équipe doit incarner un état d'esprit collaboratif et transversal.

À quoi ressemble une excellente culture DevOps ?

• Chacun est encouragé à apporter son expertise au processus, pas seulement les leaders
• Une communication ouverte, honnête et respectueuse entre les équipes
• Chacun se sent responsable de l'objectif global : intégrer la qualité et la sécurité dès le développement
• Tout le monde partage la même vision du DevOps dans l'entreprise, de la feuille de route et du rôle de chacun.

Depuis des années, je souligne l'importance de bâtir des cultures de sécurité positives au sein des équipes de développement, et le DevOps ne fait pas exception.

Les bons outils, les connaissances et le soutien sont indispensables pour atteindre les meilleures pratiques de sécurité, réduire les vulnérabilités et sensibiliser l'équipe à la protection des données. Avec le DevOps, vous devez poser les bases culturelles du changement : assurez-vous que chacun comprenne son rôle, sa valeur, les attentes, les objectifs du projet et les étapes du processus.

C'est acquis ? Parfait. Passons maintenant à l'étape supérieure : renforçons la sécurité pour faire du DevSecOps votre référence en matière d'excellence logicielle.