Ce document explicatif a pour but d’éclairer les techs & non-techs dans leur compréhension du DevSecOps.
Quels sont les enjeux majeurs auxquels répondent les pratiques DevSecOps ? Quels sont les mots-clefs et les concepts qu’il faut comprendre ? Comment en sommes-nous arrivés là ? Voilà le genre de questions que nous allons essayer de traiter, et y apporter des réponses pertinentes et aussi complètes que possibles.
La méthodologie DevSecOps n’a pas émergé du néant. Avant ça, de nombreuses étapes sont arrivées les unes après les autres et ont mené son émergence. Reprenons depuis le début.
Les premiers logiciels informatiques sont arrivés avec la démocratisation du numérique dans les années 60 et 70. À ce moment-là, les logiciels ont un cycle de développement assez long et dit en cascade. Grossièrement, on commence par dresser un cahier des charges, puis le logiciel est développé, et enfin mis en service et distribué au grand public.
Comme internet n’existe pas encore à cette époque, la distribution se fait via des CD-ROMs, des disquettes, et autres supports physiques. Lorsqu’on veut mettre à jour un logiciel, il faut donc reprendre le processus depuis le début et le distribuer à nouveau à travers le monde. C’est assez lourd, et les logiciels reçoivent donc peu de mises à jour au fur et à mesure de leur cycle de vie.
Avançons dans le temps, spécifiquement au début des années 90, et à l’émergence d’internet. Avec cette ultra-connexion qui se crée, les logiciels peuvent désormais être distribués “à travers les câbles”, et ceci renverse complètement la manière dont sont conçus les logiciels. On peut désormais déployer des mises à jour beaucoup plus rapidement puisqu’il n’y a plus besoin de redistribuer de supports physiques.
Eric Raymond raconte toute cette transition dans son essai La cathédrale et le bazar (1998) dont on peut retenir le concept suivant :
Release early, release often : mieux vaut publier un logiciel fonctionnel mais imparfait, dynamique et pouvant bénéficier des contributions de chacun (bazar) que d'attendre un stade de développement avancé (cathédrale).
Plus tard, ce concept est poussé encore plus loin et la communauté délivre Le manifeste pour le développement Agile de logiciels (2001) qui contient 12 principes pour guider les équipes de développement dans leur manière de travailler.
Ce document est une réelle révolution, et c’est de lui que découlent toutes les méthodes de développement actuelles. Il marque un tournant dans la manière dont sont conçus les logiciels, et c’est grâce à lui si la DevOps, et plus spécifiquement la DevSecOps, existe aujourd’hui.
Laissons passer une décennie, jusqu’à la fin des années 2000. La notion de service est de plus en plus populaire, et les entreprises tournent de plus en plus vers un modèle où les clients deviennent des consommateurs d’un service mis à leur disposition. Les logiciels, les applications, tout devient un service.
Amazon voit clair dans cette transition, et commence à proposer des composants matériels & logiciels comme des services. On peut désormais louer un serveur, une base de données, et les consommer comme des services.
Ceci permet de retirer aux éditeurs de logiciels la charge de maintenir des infrastructures physiques, des data-centers, et de laisser des entreprises s’occuper spécifiquement de ces thématiques, et en échange les rendre disponible à la consommation par leurs clients.