Le DevOps en 2025 n’est plus une simple approche d’intégration continue.
C’est un cycle complet de développement, d’exploitation et d’amélioration continue, où chaque étape - du code au déploiement - est automatisée, maîtrisée et mesurable.
L’objectif n’est plus seulement d’écrire du code fonctionnel, mais de garantir sa qualité, sa traçabilité et sa mise en production sans friction.
Cet article est issu de la conférence menée par Anaïs ALEX et Léo RICHARD, développeurs full stack (KAIZEN Solutions) lors de la TECH WEEK 2025.
Il vise à montrer comment ce processus s’articule, de manière concrète et intégrée.
Comprendre le DevOps : un cycle, pas un poste
Le DevOps n’est pas un rôle figé car difficile à définir, mais c’est un enchaînement de pratiques : planifier, coder, builder, tester, déployer, monitorer.
Chaque étape contribue à la stabilité et à la qualité du produit livré.
Dans la réalité des projets, tout dépend du niveau d’exigence et du degré d’automatisation souhaité : certaines équipes vont jusqu’à l’intégration continue complète (CI/CD), d’autres n’en appliquent qu’une partie.
Mais le cœur de la démarche reste le même : réduire la distance entre le code et la valeur livrée.
Les outils essentiels : Git, Docker, Kubernetes
Le socle technique du DevOps moderne repose sur trois piliers :
- Git, gestionnaire de versions et plateforme de collaboration (avec GitHub ou GitLab pour les workflows, les revues de code et la gestion de projet).
- Docker, pour exécuter des applications dans des conteneurs isolés et reproductibles, légers et portables.
- Kubernetes, pour déployer et orchestrer ces conteneurs : gérer leur cycle de vie, leur montée en charge, leur supervision et leurs logs.
Ces outils assurent une cohérence et une portabilité totale entre les environnements, du poste local au cloud.
étude de cas
Étape 1 — De l’application locale à l’intégration continue
Le point de départ : un projet web classique, développé en local, combinant un frontend Angular, un backend Python et une base de données PostgreSQL.
Le but est de passer d’un “chez moi ça marche” à un pipeline automatisé et fiable.
Le code est hébergé sur GitHub, puis intégré dans des GitHub Actions, qui exécutent à chaque push :
- du linting pour la qualité syntaxique
- des tests pour vérifier la robustesse
- un build du code pour s’assurer que tout compile correctement.
L’automatisation permet de garantir que la qualité reste constante, quel que soit le contributeur.
La rapidité du pipeline devient un vrai indicateur d’agilité : plus les builds sont courts, plus les feedbacks sont rapides.
Étape 2 — Conteneurisation et optimisation
Une fois la CI en place, l’étape suivante consiste à conteneuriser l’application.
Chaque composant (frontend, backend, base de données) est encapsulé dans une image Docker dédiée.
Les Dockerfiles sont optimisés : installation des dépendances, build multi-stage, limitation de la surface d’attaque, exposition des bons ports.
Les images sont ensuite envoyées vers un registre Docker (ici, GitHub Registry) pour être versionnées et réutilisées.
Là encore, le gain est double : reproductibilité et rapidité. Grâce au cache Docker, les builds récurrents ne durent que quelques secondes, même sur des projets lourds.
Étape 3 — Passage au déploiement Kubernetes
Vient ensuite le déploiement sur un cluster Kubernetes, ici hébergé sur OVHcloud.
Le cluster est constitué de trois nœuds, chacun pouvant héberger un backend, un frontend et une base PostgreSQL.
Les déploiements sont décrits via Helm, qui formalise la configuration des services : ressources allouées, ports exposés, images à utiliser, volumes persistants.
Chaque application devient un ensemble de briques déclaratives et orchestrées.
Cette approche garantit la scalabilité, le monitoring en temps réel et une gestion claire des ressources. Mais pour l’instant, le déploiement nécessite encore une commande manuelle (helm install). C’est la dernière étape avant l’automatisation totale.
Étape 4 — L’automatisation complète avec ArgoCD
C’est ici qu’entre en scène ArgoCD, l’outil open source de Continuous Deployment conçu pour Kubernetes.
Il surveille les dépôts Git et déploie automatiquement les nouvelles versions dès qu’un changement est détecté.
ArgoCD utilise Git en source unique de vérité : le dépôt ne contient plus seulement le code, mais aussi les définitions d’infrastructure et les manifestes de déploiement.
Chaque tag correspond à une version en production, chaque commit déclenche un ajustement du cluster.
Dans cette configuration :
- le projet est déployé automatiquement sur Kubernetes dès qu’une image Docker est prête
- les environnements staging et production sont synchronisés selon leurs branches respectives
- les versions sont visibles dans l’interface ArgoCD, avec état des pods, logs et ressources consommées.
ArgoCD va jusqu’à se surveiller lui-même : sa configuration est stockée dans Git, et l’outil se met à jour automatiquement lorsqu’elle change.
Une approche GitOps complète, où la production s’auto-régule.
Étape 5 — L’infrastructure invisible : DNS, certificats, secrets
Autour de ce pipeline central gravitent plusieurs composants essentiels :
- Cert-Manager, pour la génération automatique de certificats HTTPS via Let’s Encrypt.
- External-DNS, qui crée les enregistrements DNS dans OVH dès qu’un nouvel espace ou service est déployé.
- Sealed Secrets, qui chiffre et versionne les clés d’accès dans le dépôt.
- Renovate, qui analyse les dépendances et crée automatiquement des pull requests de mise à jour.
Ces outils assurent la cohérence entre infrastructure et code.
Créer un nouvel environnement devient aussi simple qu’un git push.
Étape 6 — La livraison continue maîtrisée
Le pipeline peut encore aller plus loin avec des outils comme Release Please, qui gèrent automatiquement les versions et changelogs selon les conventional commits.
Chaque fusion génère un tag, une release et une documentation correspondante.
À ce stade, tout est automatisé :
- build, test et conteneurisation
- déploiement sur Kubernetes
- publication en staging ou production
- génération de certificats, DNS et secrets.
Le déploiement devient instantané et traçable, et la restauration tout aussi rapide grâce au rollback intégré de Kubernetes.
Conclusion - Le DevOps comme système vivant
Ce parcours illustre à quel point le DevOps moderne est devenu un système vivant, auto-maintenu et auto-déployé.
Git n’est plus seulement un gestionnaire de code, mais le point central de l’infrastructure, de la qualité et de la livraison.
Avec des outils comme ArgoCD, Cert-Manager ou Renovate, chaque commit déclenche une chaîne complète : du code au cluster, sans intervention manuelle.
C’est la promesse d’un DevOps 2025 : plus fluide, plus fiable, et surtout plus proche de la valeur.
Envie d’aller plus loin ? Découvrez le replay intégral de la conférence de la Tech Week 2025 :
Retour aux articles