Jour 1 – Fondamentaux DevOps & SRE
Formation accélérée DevOps
Formateur: Patrick Bashizi
© 2026 Tous Droits Reservés
Formateur: Patrick Bashizi
© 2026 Tous Droits Reservés
Objectifs pédagogiques de la journée
1
Comprendre les fondements
Acquérir une vision claire des principes DevOps et SRE.
2
Identifier les défis Client
Relier les concepts aux problématiques spécifiques du client.
3
Poser les premières pierres
Établir les bases d'une transformation culturelle et organisationnelle.
Contexte actuel typique
Un aperçu des défis techniques et opérationnels quotidiens.
Applications Monolithiques
Systèmes complexes et interdépendants, difficiles à mettre à jour et à faire évoluer.
Infrastructure 100% On-Premise
Dépendance forte aux ressources internes, goulots d'étranglement potentiels et coûts de maintenance élevés.
Manque de Monitoring
Visibilité limitée sur la performance des systèmes et difficulté à détecter et diagnostiquer les incidents rapidement.
Conséquences Opérationnelles
Lenteur des mises en production, incidents fréquents impactant les services, et absence de métriques pour l'amélioration continue.
DevOps en bref: Un pont entre développement et opérations
"DevOps n'est pas seulement une question d'outils, c'est une culture de collaboration et d'automatisation."
- Collaboration renforcée : Synergie entre les équipes de développement et d'exploitation.
- Automatisation complète : Intégration continue (CI) et livraison continue (CD) pour des déploiements rapides et fiables.
- Mesure et Feedback : Collecte de données pour améliorer continuellement les processus.
Exemple concret : automatiser un déploiement, réduisant des heures de travail manuel à quelques minutes.
L'Histoire et l'Origine du DevOps
L'origine du DevOps n'est pas le fruit d'une invention unique, mais plutôt d'une convergence de mouvements visant à résoudre le "mur de la confusion" entre les développeurs (Dev) et les administrateurs systèmes (Ops).
Étapes clés de l'émergence
1
Le Wall of Confusion
Les équipes Dev voulaient pousser des changements rapidement, tandis que les Ops privilégiaient la stabilité. Cette opposition créait des goulots d'étranglement majeurs.
2
Les Racines Agiles (2007–2008)
Patrick Debois, consultant belge, frustré par le fossé Dev/Ops, réfléchit à une approche "Agile System Administration". À la conférence Agile 2008 à Toronto, Andrew Shafer propose une session "Agile Infrastructure" — seul Debois s'y présente. Ensemble, ils créent le groupe "Agile System Administration".
3
10+ Deploys per Day (2009)
Lors de la conférence Velocity 2009, John Allspaw et Paul Hammond de Flickr présentent comment automatiser les processus et instaurer une culture de confiance mutuelle permet de déployer plusieurs fois par jour sans casser la production.
4
Naissance du terme DevOps (2009)
Inspiré par cette présentation, Patrick Debois organise les DevOpsDays à Gand, Belgique. Pour le hashtag Twitter, il raccourcit en #DevOps. L'événement connaît un succès viral.
Les Piliers Fondamentaux : Modèle CAMS
Culture
Briser les silos et partager la responsabilité.
Automation
Automatiser l'intégration et le déploiement (CI/CD).
Measurement
Collecter des données pour améliorer la performance.
Sharing
Partager les outils, les succès et les échecs.
Aujourd'hui, le DevOps a évolué pour inclure la sécurité (DevSecOps) et la fiabilité des systèmes avec le Site Reliability Engineering (SRE).
SRE en bref: Ingénierie de la fiabilité des sites
Issu de Google, le SRE (Site Reliability Engineering) applique l'ingénierie logicielle à l'infrastructure.
Origine Google
Né de la nécessité de gérer des systèmes complexes à l'échelle de Google, le SRE se concentre sur la stabilité et la performance des services.
SLAs, SLOs, SLIs
SLA (Service Level Agreement): Engagement contractuel sur la qualité de service.
SLO (Service Level Objective): Cible de performance mesurable.
SLI (Service Level Indicator): Mesure quantitative d'un aspect du service.
SLO (Service Level Objective): Cible de performance mesurable.
SLI (Service Level Indicator): Mesure quantitative d'un aspect du service.
Fiabilité Mesurable
La fiabilité n'est pas subjective ; elle est quantifiée et gérée comme une fonctionnalité produit. Par exemple, une disponibilité de 99.9% signifie seulement 43 minutes de panne par mois.
Exemple DevOps à la CNSS
Contexte :
La CNSS propose sur son site officiel des applications de télé-déclaration (ex. déclaration des salaires par les employeurs).
La CNSS propose sur son site officiel des applications de télé-déclaration (ex. déclaration des salaires par les employeurs).
Avant DevOps (situation actuelle typique)
- Les équipes doivent copier manuellement des fichiers WAR ou PHP sur un serveur chaque fois qu’une mise à jour est disponible.
- Si un bug est trouvé, le rollback est compliqué (il faut restaurer une sauvegarde à la main).
- Chaque mise en production prend plusieurs heures et bloque l’équipe.
Avec DevOps (pipeline CI/CD)
- Chaque commit déclenche automatiquement un pipeline (tests unitaires, build, conteneurisation).
- Le site de télé-déclaration est déployé automatiquement sur un environnement de test.
- Si tout est validé, le déploiement en production se fait en quelques minutes.
- En cas de bug, on revient en arrière immédiatement avec l’image Docker précédente.
👉 Impact concret : moins d’interruptions pour les employeurs, service plus fiable et plus rapide à mettre à jour.
Exemple SRE à la CNSS
Contexte :
Les employeurs se connectent massivement au portail de télé-déclaration en fin de mois pour déclarer les salaires.
Sans SRE (situation actuelle)
- Pas de monitoring clair → l’équipe découvre une panne uniquement après de nombreux appels des employeurs.
- Temps de résolution long (parfois plusieurs heures).
- Pas de mesure claire de la disponibilité : est-ce 95%, 99% ?
Avec SRE (SLA/SLO/SLI)
- Définir un SLO : disponibilité 99,5% du service de télé-déclaration.
- Mesurer un SLI : temps de réponse < 2s pour 95% des requêtes.
- Mettre en place des alertes Prometheus/Grafana → l’équipe sait immédiatement si le service dépasse le budget d’erreur.
- Mise en place de runbooks pour restaurer le service en moins de 30 minutes.
👉 Impact concret CNSS :
- Les employeurs peuvent déclarer sans interruption, même aux périodes de forte charge.
- L’IT de la CNSS prouve la fiabilité de son service par des métriques claires.
Cas pratique CNSS : Où commencer ?
Application des concepts DevOps et SRE aux réalités de notre institution.
Cartographie des Systèmes Actuels
Identifier les interdépendances et les flux de travail. Visualiser l'architecture existante de nos applications et infrastructures.
Identification des Goulets d'Étranglement
Détecter les points de friction et les retards dans nos processus de développement et de déploiement.
Discussion CI/CD
Où l'intégration et le déploiement continus pourraient avoir l'impact le plus significatif sur nos opérations quotidiennes ? Prioriser les initiatives.
Conclusion du Jour 1 & Devoir Maison
"DevOps est une transformation culturelle autant que technique ; SRE est l'art de rendre les systèmes intrinsèquement fiables."
Points clés de la journée :
- DevOps : Culture et automatisation au service de l'efficacité logicielle.
- SRE : Fiabilité mesurable comme objectif fondamental et ingénierie de la performance.
Devoir Maison : Votre regard critique
Préparez-vous à partager ces observations lors de la prochaine session.
Apports Concrets pour le client
Premiers pas vers l'excellence opérationnelle
Meilleure Compréhension
Des enjeux complexes de notre environnement IT et des solutions modernes.
Standardisation via Docker
Un premier pas concret vers l'uniformisation de nos déploiements et environnements.
Vision Claire des Priorités
Identification des actions les plus impactantes pour notre parcours de transformation.
Atelier Pratique sur Git
Plongez dans les fondamentaux de Git et découvrez comment maîtriser le contrôle de version pour une collaboration efficace et une gestion de code robuste.