Préambule

Pour ceux d'entre nous qui entendent de plus en plus les termes Transformation Digitale, API, DevOps, Cloud Native, CI/CD, Repo, Containers, Kuberteness, SAST, SCA, DAST, CNAPP, ZeroTrust, CNCF, j'en passe et des meilleurs, et qui ne comprennent pas toujours de quoi on parle, cet article a pour objectif de démythifier un peu tous ces termes jargoneux pour essayer de comprendre - de façon non technique - les raisons d'un tel engouement.
Nous commencerons par un peu d'histoire, pour mieux comprendre notre présent et essayer d'anticiper l'avenir, sans pour autant devenir nous-mêmes des informaticiens.

Introduction

Quand on se promène dans les couloirs d'une entreprise (même pas besoin d'être en présence de développeurs), ou qu'on participe à une visioconférence en ligne, on entend souvent les phrases un peu absonces du genre: "C'est prévu dans notre plan de transformation digitale", "DevOps, c'est fait pour les entreprises Cloud Native et Agiles", ou encore "You Build it, You Run it", voire même "il faut qu'on Shifte Left notre approche".

On constate par ailleurs que toute personne en lien de près ou de loin avec l'informatique est devenue un XXXX_OPS (devops engineer, secops leader, devsecops architect, etctera....). Même les gens du marketing s'y mettent. Si vous ne me croyez pas, consultez les profils sur Linkedin, de moins en moins de Digital Marketing Specialists et de plus en plus de MarketingOps Specialists! Incroyable!

Que s'est-il donc passé? Et en quoi ça change la donne?

Le cloud comme génèse

Il y a une vingtaine d'années (+ ou -), le Cloud a débarqué dans nos vies privées et professionnelles. Aujourd'hui, tout est dans le Cloud! Même un bon vieux Datacenter d'une banque avec ses bons vieux Mainframes est devenu un Cloud Privé! On est même actuellement à l'ère du MultiClouds hybride (la classe)!

Grâce à la virtualisation (et 2 ou 3 autres trucs), on a pu allouer des ressources informatiques à des développeurs (au début de la CPU/RAM/Stockage/Network) en quelques cliques seulement. Et ça franchement, c'était vraiment cool car jusqu'alors les développeurs devaient faire une demande au service informatique et au bout de plusieurs semaines (dans le meilleur des cas) on leur disait "le serveur (physique) est livré"... ce n'était pas fini pour autant car il fallait encore passer pas mal d'heures à configurer cette machine, la connecter au réseau, et donner les bons droits d'accès!

Autrement dit, d'un seul coup, les développeurs ont eu accès à de la ressource informatique d'infrastructure en quelques secondes, et ils/elles pouvaient la reconfigurer en quelques secondes également. Pour un développeur, c'était un pas de géant!

Mais jusque-là, cette petite révolution ne concernait que les services informatiques encore divisés en 4 grands pôles bien silotés qu'on appelait "Developpement, Test, Intégration, Production", et les projets informatiques continuaient de suivre des cycles infernaux dits de "Waterfall" ou "cycle en V", avec ces 8 phases incontourbables:

1- on décrit notre besoin
2- on spécifie fonctionnellement la solution
3- on en fait des spécifications techniques adossées à un joli schéma d'architecture voire d'urbanisme
4- on code/développe
5- on teste techniquement et fonctionnellement
6- on prend un sous-groupe d'utilisateurs pour avoir leur retour d'expérience et on se fait matraquer la tête car on a rien compris à leur besoin et que ça ne marche pas comme ça devrait
7- on recommence...
8-...et au bout d'un certain temps, après avoir refait plusieurs petits tours de manège dans ce "cycle en V" puis finalement passé avec plus ou moins de succcès les fourches caudines de l'intégration, et celles du service de sécurité du SI, on met en production...Alléluhia!

Certains se sont dits, "ça ne peut pas durer!"...alors on a inventé les méthodes agiles...c'était mieux, mais ça prenait encore pas mal de temps car on sortait d'une approche monolithique au profit d'une approche itérative plus courte et efficace. Pour autant, ça ne réglait pas tous les problèmes puisqu'on butait encore sur le temps de mise en production. L'infra allait plus vite, le développement aussi, mais pas tellement la capacité à "releaser" de nouvelles applications beaucoup plus vite, car les environnements de Dev, Test, Intégration, Prod restaient encore bien séparés et il y avait toujours des différences - souvent importantes - entre ces environnements. Du coup, on avait des phénomènes du type “ça marche bien en intégration mais pas en pré-prod”

Et puis, il y a moins de 15 ans, avec l'essor d'Internet comme notre nouveau bureau personnel et professionnel, tout le monde a commencé à faire de la Transformation Digitale. C'est peut-être une des expressions encore aujourd'hui les plus utilisées dans les entreprises.

Pour soutenir cette transformation, les départements informatiques ont été jugés bien trop lents et trop chers, et les grands hyperscalers américians (AWS, GCP, AZURE) et d’autres éditeurs dits de SaaS/PaaS/IaaS, ont été jugés bien plus performants à tous points de vue. Aujourd’hui, c’est le règne du Cloud pour soutenir la transformation digitale ! C’est même le règne du Multi-Clouds!

Au fait, c'est quoi exactement la transformation digitale?

L'idée est super simple et l'objectif - comme souvent - se mesure en $.

Jusqu'à la fin des années 1990, presque tout le business d'une entreprise reposait sur des relations physiques avec son ecosystème. La vente se faisait essentiellement en magasin pour les particuliers, des commerciaux se déplaçaient chez leurs clients professionnels pour leur présenter puis vendre leurs produits et services, les logiciels dont on avait de plus en plus besoin dans nos processus métiers étaient installés dans nos datacenters en propre (on-premise). Certes, il y avait déjà les premiers magasins en ligne tels Amazon, PriceMinister, CDiscount et quelques autres commençaient à faire parler d'eux mais les grandes banques, assurances, les retailers, les CPG, les telco, les industriels, et surtout les professionnels de plus en plus nombreux de l'informatique ne parlaient pas de transformation digitale ni de Cloud. La première fois qu'on a pu consulter ses comptes bancaires en ligne sur Internet remonte à 1995 (banque directe), et presque toutes les banques proposaient ce service dès l'an 2000! Pourtant, les banques ont été les plus précurseurs sur le sujet, ce qui nous rappelle à quel point tout ceci est encore assez récent!

Beaucoup ont laissé passer le train de l'internet, puis de l'internet mobile. Et tout le monde, quelque soit son métier, s'est réveillé en même temps, avec le même mot d'ordre "si l'on ne fait rien, on va se faire ubériser par des nouveaux entrants, puis on va disparaître". C'est la célèbre phrase prononcée par Maurice Levy, patron de Publicis, qui expliquait lors d'un entretien "Tout le monde a peur de se faire ubériser".

La transformation digitale et son déferlement numérique étaient nés et avec eux des investissement massifs dans tous les domaines d'activités pour transformer l'entreprise en "Digital Company" afin d'exploiter les opportunités infinies qu'offrait Internet.

Ainsi, le Cloud est devenu la règle et avec lui, de nouvelles compétences en tous genres étaient requises. Un exemple: les API (vous savez le "bout" de code réutilisable pour permettre à une application de s'exposer à d'autres applications). En effet, il fallait bien trouver un moyen (sur Internet) de connecter des applications internes et externes avec les autres applications et services utilisés, sachant que tout ce petit beau monde n'avait pas été conçu pour discuter ensemble. Et puis, les API, c'est génial pour écrire un petit service informatique qu'on peut réutiliser autant de fois qu'on veut dans de plus gros services informatiques. Oui, mais, pour mettre en place des API SOAP puis REST (et maintenant Graph QL), il était nécessaire de réécrire un bout des applications existantes pour les "APIser" et pour cela il fallait encore plus de développeurs.

Bon, à ce stade, les bases étaient posées, Devops n'existait pas encore mais avec le Cloud son avènement devenait inéluctable !

La nouvelle mentalité "Fast & Furious"

On aurait pu en rester là, mais nous sommes alors entrés dans l'ère des réseaux sociaux, où tout va vite, beaucoup plus vite. A l’instar de l’information (une actualité chasse l’autre), une application chasse l’autre. C’est une course contre la montre pour développer et produire des services (presque toujours web) toujours plus rapidement, en continu, avec l’idée que - dans un monde digitalisé et pressé - la vitesse (le Time To Market pour les initiés) est devenue le critère absolu.

Il fallait donc trouver un moyen d’accélérer encore. Et c’est donc ça DevOps, un ensemble de méthodes, pratiques et outils pour développer et produire des services informatiques très vite et en continu grâce à une automisation toujours plus grande.

Pour cela, il fallait que les développeurs puissent presque tout faire tout seul, et comme ce sont des développeurs, il fallait que tout soit sous forme de code, même la création des infrastructures sous-jacentes à l'exécution du code applicatif métier. On est entré dans l’ère du « You Build it, You Run it ». C’est le « Shift Left » accompagné de son automatisation la plus aboutie (Pipelines CI/CD). Le développeur peut tout faire tout seul. Adieu, les silo Dev/Test/Intégration/Production, vous n'êtes plus adaptés à notre Time-to-Market!

Ainsi, il fallait définitivement casser les silos Développement/Production.

On a tous vu cette magnifique illustration de DevOps. Une boucle qui automatise le cycle de développement logiciels en traversant toutes les étapes de création, tests, intégration, déploiement et pilotage d’applications

En général, quand on utilise le symbole de l’infini (le fameux lemniscate), j’ai toujours le sentiment qu’on me « vend » un truc automatisé de bout en bout, un peu comme une chaîne de fabrication industrielle parfaitement huilée avec un minimum d’interventions humaines. Ca a l'air magique !

En réalité, ce n’est pas si simple (il fallait s’y attendre) et pas magique du tout !

Prenons, par exemple, le sujet de la sécurité dont nous n'avons pas encore parlé, et dont tout le monde comprend qu’il est essentiel compte tenu du contexte réglementaire croissant et plus largement de l’explosion de cybermenaces en tous genres sur Internet.

Donc, la sécurité en question…

Jusqu’à alors, on avait un(e) RSSI (responsable de la sécurité des systèmes d’information) qui – dans une approche souvent top down, un peu autoritaire mais très salutaire – essayait, avec ses équipes, d’imposer des bonnes pratiques aussi bien au niveau de l’infra, du code, de l’accès à toutes ces ressources ou encore de la nature des communications permises entre les services (réseau). Il/Elle était souvent perçu(e) comme l’empêcheur de tourner en rond, le gardien du temple qui met des bâtons dans les roues de ses petits collègues notamment les développeurs. C’était déjà assez compliqué comme cela, mais comme les équipes travaillaient en silos, il y avait encore moyen d’imposer des règles d’hygiène élémentaires de sécurité, d'autant que les COMEX avaient commencé à comprendre que la sécurité était un vrai sujet sérieux. Quand un développeur demandait - à travers un catalogue de services - un serveur (souvent une machine virtuelle), avec une version spécifique d’un système d’exploitation, et une base de données quelconque, il/elle ouvrait un ticket et sa demande passait par les fourches caudines des équipes d’infrastructure. Ce qui était livré – souvent de manière automatique et instantanée - incluait des petits programmes appelés agents dont la majorité permettait de forcer ou a minima surveiller les processus qui s’exécutaient sur le serveur, les flux de communication, etcetera. Du point de vue de la sécurité, c’était encore gérable.

On a compris que grâce à DevOps, les développeurs deviennent les maîtres du royaume de l’IT, puisqu’ils sont maintenant en charge de toute la chaîne de développement jusqu’à la mise en production.

Pour bien comprendre ce changement de paradigme, j’ai récupéré une illustration réalisée par la société Snyk, éditeur de logiciels bien connu des spécialistes dits de sécurité des applications cloud

Cette image illustre assez bien ce changement. Dans l’ère du Cloud et du DevOps, qu’on appelle aussi Cloud Native, on comprend que dorénavant les décisions de sécurité appartiennent d'abord aux développeurs !

Il faut donc fournir aux développeurs (dont on rappelle que la principale préoccupation est de livrer du code de qualité le plus vite posssible) un ensemble de méthodes et outils pour leur permettre de gérer seuls la sécurité du tout. Il est rare qu’un développeur ne soit pas conscient des enjeux sécuritaires, mais il est encore plus rare qu'il soit un spécialiste de la sécurité du SI.

Donc, on reprend....la sécurité doit être embarquée dès les phases en amont de code/développement (le fameux shift left).

On ne rentrera pas dans le détail de ces solutions ici, mais sachez que les outils et méthodes sécuritaires utilisés auparavant sont devenus largement obsolètes. Cela a donné naissance à une série de solutions logicielles qu’on appelle SCA, SAST, DAST, CNAPP, et encore beaucoup d’autres acronymes qui rentrent tous dans la grande famille de l'« Application Security Solutions », la sécurité des applications cloud, et dont l’objectif est de sécuriser le code, ses dépendances et bien entendu son exécution dans les fameux containers (Docker étant le plus connu) eux-mêmes orchestrés par le non moins fameux Kubernetes, sans qui rien n’est possible.

Si on devait résumer, il faut tout protéger mais différemment car tout est devenu CODE, à la main et sous la responsabilité du développeur. Aujourd’hui, le déploiement d’une infrastructure et de ses configurations se fait de manière automatisée par des lignes de code (yaml par exemple), avec plusieurs solutions pour y parvenir, même si les plus utilisées restent Terraform et Ansible. C’est le fameux Infrastructure as code.

On peut - pour préparer mon prochain article - citer quelques solutions de sécurité devops (DevSecOps) qui ont pignon sur rue : Sysdig, Wiz, AccuKnox, Prisma Cloud, Snyk ou encore Veracode.

Rassurez-vous, je n'en dirai pas plus dans cet article destiné aux non-informaticiens, mais pour ceux que cela intéresse, je vais donc bientôt écrire un article un chouïa plus technique sur la myriade de solutions qui ont vu le jour autour de DevOps et DevSecOps.

A ce stade, certains d’entre vous - déjà un peu au fait du sujet - s’interrogeront sur l’absence d’acteurs majeurs dans cet article tels GitLab ou GitHub.

Ces derniers sont fondamentaux dans la chaîne DevOps et proposent des options de sécurité plus ou moins intégrées. En réalité, ils sont d’abord utilisés comme des Repositories, les fameux REPO, là où les développeurs déposent leurs codes, et toutes les sous-branches (un peu comme un arbre de versions de code). Et c’est au niveau du REPO que la sécurité commence. Il y a d’ailleurs 5 briques fondamentales de code à sécuriser : le code du développeur, le code open source et ses dépendances (souvent plus de 50% du code utilisé par les développeurs provient de codes sources libres de droits), les containers & l’orchestrateur, et enfin l’infrastructure as code, et le Pipeline CI/CD (qui a tous les droits ou presque)

Donc, tout démarre dans le REPO et tout recommence dans le REPO, y compris la sécurité... il est donc très important que ces derniers soient correctement protégés ! La presse spécialisée se fait régulièrement l'écho de codes sources subtilisés dans des REPO d’entreprise, car la gestion des accès est souvent très largement insuffisante.

Le REPO c’est le temple, c’est sacré ! On ne doit pas pouvoir rentrer n'importe comment dans un temple ! Il faut montrer patte blanche.

Conclusion

J’espère que ce petit tour d’horizon non technique, et très « high level » (comme on dit), permettra à certains de mieux comprendre les changements de paradigme profonds en cours au sein de l’informatique et plus largement au sein des entreprises. Il est à peine exagéré de dire que toutes les entreprises deviennent des entreprises digitales, dont la croissance, l’avenir et peut-être même la survie dépendent de plus en plus de leur capacité à délivrer de nouveaux services rapidement. DEVOPS, CLOUD SECURITY, et CLOUD NATIVE sont des termes que vous n’avez pas fini d’entendre et avec eux leur cortège de solutions en tous genres pour arriver à une seule destination : « You build it, You run it, Securely ».

A titre personnel, n’étant pas informaticien d’origine mais baignant dans le monde informatique depuis (trop) longtemps, il m’a fallu du temps pour comprendre ces sujets, et surtout comprendre d’où ils viennent et ainsi mieux anticiper ce qui arrive !

J'espère que cette lecture aura su conjuguer l'utile à l'agréable.

Nicolas Petroussenko