Les dernières décennies n’ont cessé de voir fleurir de nombreuses pratiques de développement logiciel et organisationnelles vouées à diriger l’exécution des équipes au gré de contraintes techniques ou-bien financières. Avec elles se sont multipliés les acronymes, les titres, les concepts et services correspondants. Naturellement, de tout cela il nous faut prendre garde à toujours bien discerner à quels besoins répondent réellement les solutions qui s’offrent à nous au sein de ce vaste écosystème. Pour ce faire, il est indispensable de comprendre d’où proviennent les ramifications de nos environnements, au gré des contextes de travail et des évolutions technologiques/marchandes. C’est dans ce contexte, et sous le prisme de cette intention, qu’on réalise ici un tour d’horizon du DevSecOps au sein de l’industrie actuelle.
DevOps
Si nous avons tous abordé un jours le développement informatique par l’écriture (plus ou moins plaisante) de programmes C compilés à la main, et composés d’une poignée de fichiers aisément manipulables le temps d’un court projet ; nous en sommes à priori tous revenus à mesure que se sont complexifiés les systèmes visés, les architectures projet. C’est ce point de bascule là qu’il nous faut sentir dans l’exercice quotidien du développement informatique pour comprendre l’intérêt des notions d’automatisation et de reproductabilité au fondement même de la capacité de passage à l’échelle. Dans cette logique de progression, on cherche alors à documenter son travail, séparer les réponsabilités par la modularité de nos programmes, tout en garantissant un système fonctionnel et sûr. S’imposent alors à nous l’usage, plus ou moins natif, d’outils dédiés à la documentation, à la réalisation de tests unitaires, à la compilation, etc. Dans ce contexte, poignent les notions d’intégration continue et de déploiement continu, afin non plus de rédiger uniquement du code, mais bien d’orchestrer la programmation elle-même. Ce faisant, le programmeur n’est plus un maillon isolé, contingenté à un travail plus ou moins laborieux, mais gagne en aisance et intégration dans son écosystème de travail ; lequel s’étendant du terminal, jusqu’aux commerciaux qui recueillent le besoin client, et aux clients eux-mêmes qui éprouvent l’implémentation des fonctionnalités demandées.
Définition
Le DevOps est une approche d’ingénierie informatique vouée à unifier développement et opérations sous le joug d’objectifs communs, instillant cohérence systémique et pérénité à toutes les échelles du cycle de vie logiciel. En d’autres termes, il s’agit d’un ensemble de pratiques logicielles (e.g. automatisation, versionnage) et organisationnelles (e.g. partage des responsabilités, compréhension long-termiste) instruites pour garantir l’intégrité des produits de leur conception jusqu’à leur livraison.
Fondations et écosystème
Le pipeline CI/CD, pierre angulaire du DevOps
Un pipeline CI/CD (Continuous Integration / Continuous Delivery ou Deployment) est un processus automatisé qui transforme le code source en un livrable déployé1.
Il se décompose en deux grandes phases :
-
Intégration Continue
Dès qu’un développeur pousse du code, i.e. effectue un
git push remote originsur sa branche de développement, un pipeline se déclenche et exécute les actions prédéfinies en son sein. En l’occurence, il exécute la compilation du code source, l’analyse statique de ce dernier, les tests unitaires et d’intégration s’ils existent, la génération de rapports de couverture subséquent, et la construction d’artefacts (e.g. binaires, images Docker, paquets).
Info
L’objectif est de détecter les régressions au plus tôt, dans une logique de fail fast.
- Livraison/Déploiement Continu
- La livraison continue (Continuous Delivery) garantit que le livrable est toujours en état d’être déployé en production (c’est-à-dire chez le client), mais le déclenchement reste manuel.
- Le déploiement continu (Continuous Deployment) pousse automatiquement jusqu’en production, sans intervention humaine, à condition que tous les critères de qualité soient satisfaits.
Ce qui entoure le pipeline
Ces pipelines CI/CD prennent place au sein d’un écosystème DevOps qui vise à rendre l’ensemble des étapes propres à l’ingénierie logicielle automatisables ; et ce, afin de tirer parti de tous ces traitements délégués à des externalités, et de plus en plus réalisés dans le coud.
| Domaine | Outils typiques | Rôle |
|---|---|---|
| Gestion du code | GitLab, GitHub, Bitbucket | Versionning, MR/PR, code review |
| Gestionnaire d’artefacts | Nexus, JFrog Artifactory, Harbor | Stockage des binaires, images, dépendances |
| Analyse qualité | SonarQube, Coverity, Checkmarx | Qualité du code, sécurité (SAST/DAST) |
| Gestion des secrets | HashiCorp Vault, AWS Secrets Manager | Injection sécurisée de credentials |
| Notification & observabilité | Grafana, Prometheus, PagerDuty | Monitoring des pipelines eux-mêmes |
| Tests de performance | k6, Gatling, JMeter | Valider la tenue en charge |
Les critères de qualité (Quality Gates)
Définition
Les quality gates sont des points de passages essentiels dans le cycle de vie logiciel. Ils permettent la confrontation du code à des exigences prédéfinies, notamment sous le joug de contraintes client, de normes internationales ou encore assurantielles.
L’intégration des quality gates aux pipelines CI/CD assure de la conformité du code automatiquement et en continu.2 Ce faisant, on discrimine les pull request ne satisfaisant pas des critères de tels que la réduction de bugs, absence de vulnérabilités, ou encore la couverture satisfaisante du code par les tests ; c’est le principe du shift-left : ramener la détection d’anomalies le plus tôt possible dans le cycle.
Orchestration : conteneurs, clusters, on-prem et cloud
La conteneurisation comme unité de déploiement
Dans un soucis de modularité, et de séparation des responsabilités, la conteneurisation des services applicatifs s’impose comme solution la plus pertinente.
Définition
La conteneurisation octroie la possibilité faire coexister plusieurs espaces utilisateurs isolés au sein d’un même système d’exploitation.
En effet, conteneuriser un service revient à encapsuler ce dernier au sein d’un espace d’exécution capable d’être porté, en parallèle d’autres, par un système hôte. Ce faisant, on n’héberge plus un service sur une machine dédiée, mais bien plusieurs conteneurs de services variés au sein d’une même machine. Avec l’avénement de Docker et désormais son concurrent Podman, le conteneur Docker est devenu l’unité standard de packagind d’un service : il embarque le code, ses dépendances et sa configuration d’exécution dans une image reproductible.
À l’usage, les services sont conteneurisés en images Docker, lesquelles étant publiées dans un registres, puis tirées et déployées sur l’environnement cible. Les images sont versionnées (tags sémantiques ou SHA de commit), ce qui garantit une traçabilité bout en bout entre un commit Git et un déploiement en production.
Kubernetes (K8s) : L’orchestrateur de référence
Kubernetes permet de gérer les applications conteneurisées à grande échelle, en assurant les fonctions de routages, de distribution, et de mise à l’échelle horizontale. Avec lui, on organise nos services en clusters K8s afin d’opérer les actions de maintenance, de gérer les secrets et configurations, de façon centralisée.
GitOps
Progressivement, on voit poindre l’infrastructure de notre système, comme support de développement, ou objet même de ce dernier. Toutefois, assurer la cohérence et l’évolution de celle-ci sur un temps long, tout en tenant compte des risques inhérents à nos activités, impose l’adoption d’une approche basée sur l’utilisation de référentiels Git. Dès lors, en alliant la capacité à versionner du code, ainsi qu’à déclarer l’état souhaité de nos infrastructures — ce qu’on appelle l’infrastructure as code —, on parvient à versionner ses dernières.
Définition
Cela apporte :
- Traçabilité totale (qui a changé quoi, quand)
- Rollback trivial (revert Git)
- Auditabilité native (idéal pour les contextes critiques)
Infrastructure as Code (IaC)
L’infrastructure elle-même est versionnée et déployée via du code : Terraform (provisionnement cloud/on-prem), Ansible (configuration des machines), Pulumi (IaC en langage général). Le pipeline CI/CD traite l’IaC comme tout autre code : analyses statiques et dynamiques, tests, contrôles qualité, avec validation humaine sur les environnements sensibles.
On-Premises vs Cloud vs Hybride
| Modèle | Avantages | Contraintes |
|---|---|---|
| On-Prem | Maîtrise totale, souveraineté des données, latence maîtrisée | CapEx élevé, scalabilité limitée, maintenance infra |
| Cloud public (AWS EKS, Azure AKS, GCP GKE) | Élasticité, managed services, time-to-market | Dépendance fournisseur (vendor lock-in), coût à l’usage |
| Hybride / Edge | Flexibilité, continuité en cas de déconnexion réseau | Complexité opérationnelle accrue |
Dans l’industrie critique (défense, aéronautique, énergie), le modèle on-prem souverain reste dominant, parfois complété par un cloud privé (OpenStack, VMware Tanzu) ou une infrastructure air-gapped (isolée d’internet).
Footnotes
-
On appelle livrable un objet produit à destination du client, il peut s’agir d’une étude, d’un logiciel, etc. De plus, le code déployé est celui qui est considéré comme utilisé par le client. ↩
-
https://www.sonarsource.com/resources/library/integrating-quality-gates-ci-cd-pipeline/ ↩