SDLC & DevOps – Introduction

À la fin de cette page, vous saurez expliquer le SDLC, décrire ses six phases, comparer Waterfall, Agile et DevOps, et relier ces modèles à un pipeline CI/CD moderne (qualité, sécurité, déploiement) — socle avant Azure DevOps Boards / Repos / Pipelines.

Niveau : Débutant · Temps estimé : 25–35 min · Versions testées : concepts SDLC 2026, Ubuntu 24.04 LTS, Kubernetes 1.31+, Terraform 1.9+, Docker Compose v2 · Dernière vérification : 2026-09-12

Slug : sdlc-devops-introduction · Série : Azure DevOps (mega-menu) · Mot-clé SEO : SDLC DevOps

← Contexte : Méthodologies SDLC · → Suivant : Terminologie Agile · Outils : Azure DevOps Tools · Org : Organisation Azure DevOps

Le SDLC (Software Development Life Cycle) est le processus suivi par l’industrie IT pour concevoir, développer, tester et déployer une application logicielle de qualité. Plusieurs équipes (développement, test, opérations, sécurité, métier) transforment ensemble le besoin client en produit livré et maintenu. Comprendre le SDLC réduit le risque, clarifie les livrables et accélère les cycles de release — surtout lorsqu’on l’associe aux pratiques DevOps et à l’automatisation CI/CD.

Prérequis

• Curiosité produit / delivery (pas besoin d’être déjà admin Azure)
• Notions légères de Git (commit, branche, pull request)
• Accès navigateur pour lire les pages du parcours Azure DevOps
• Optionnel : compte Azure DevOps Services Free tier pour les labs suivants

Coût estimé : 0 € pour cette introduction conceptuelle. Les labs pipelines suivants consomment des minutes d’agents Microsoft-hosted du Free tier ADO.

Ce que nous allons couvrir

Besoin client
  → Requirement → Design → Development → Testing → Implementation → Maintenance
        │              Waterfall (séquentiel)
        │              Agile (itérations 1–3 semaines)
        └────────────── DevOps (Dev + Ops + automation CI/CD)

(Schéma — alt : « Six phases du SDLC et trois méthodologies : Waterfall, Agile, DevOps ».)

Cette page densifie l’introduction menu Azure : phases, avantages / inconvénients des modèles, culture DevOps, pipeline d’exemple, erreurs fréquentes, quiz et FAQ. Rien du socle original n’est retiré — tout est enrichi.

Phases du SDLC

Le cycle de vie suit six phases qui transforment les exigences en produit en production. Chaque phase produit des livrables qui alimentent la suivante. Dans un monde DevOps, ces phases se chevauchent et s’automatisent, mais les responsabilités restent les mêmes.

1. Phase Requirement (exigences)

Cette phase vient après la planification initiale. On recueille le maximum d’information auprès du client et des parties prenantes : besoins fonctionnels et non fonctionnels, contraintes, priorités. Workshops, user stories, critères d’acceptation et glossaire métier documentent chaque spécification. Une exigence floue aujourd’hui coûte cher en rework demain.

2. Phase Design (conception)

Architectes et développeurs produisent des designs haut niveau et bas niveau : stack technique, modèles de données, API, wireframes, diagrammes UML. On vérifie que la solution proposée satisfait toutes les exigences collectées. Le design sert de contrat entre métier, Dev et Ops (observabilité, déploiement, sécurité dès la conception).

3. Phase Development (développement)

Les développeurs choisissent l’approche technique et le langage, puis écrivent le code selon le design approuvé. Standards de code, revue par pull request, branches de fonctionnalité et intégration incrémentale limitent la dette. Le versionning (Git / Azure Repos) est non négociable.

4. Phase Testing (tests)

Une fois le logiciel construit, il est déployé en environnement de test. L’équipe QA valide la fonctionnalité du système : tests unitaires, d’intégration, système et d’acceptation. Les suites automatisées dans les pipelines CI détectent les défauts tôt ; tout problème revient au développement avant release.

5. Phase Implementation (mise en production)

Après validation, le produit est libéré aux utilisateurs. Les pipelines de déploiement contrôlés (blue-green, canary, slots Azure App Service) réduisent le downtime. Formation, runbooks et documentation accompagnent le rollout.

6. Phase Maintenance (maintenance)

Les vrais problèmes apparaissent quand les clients utilisent le système au quotidien. Monitoring, correctifs de sécurité, incidents et feedback produit relancent de nouvelles exigences — le cycle recommence. En DevOps, maintenance et delivery forment une boucle continue, pas une phase « après ».

Méthodologies SDLC

Trois familles structurent encore la delivery moderne : Waterfall, Agile et DevOps. Elles ne s’excluent pas toujours : beaucoup d’organisations mixtent gouvernance Waterfall sur le portefeuille et exécution Agile/DevOps sur les équipes.

Waterfall (cascade)

Premier modèle de processus SDLC largement formalisé. C’est un cycle de vie linéaire et séquentiel : le processus est découpé en phases séparées ; le résultat d’une phase sert d’entrée à la suivante ; tant que l’étape N n’est pas terminée, l’étape N+1 ne démarre pas.

Avantages

• Définition produit stable
• Exigences, processus et résultats bien documentés, fixes et clairs
• Peu d’ambiguïté sur le périmètre
• Échéances spécifiques et planifiables

Inconvénients

• Peu adapté aux projets complexes ou très évolutifs
• Inadapté aux projets longs / continus
• Fragile si les exigences changent (risque modéré à élevé)
• Progressions difficiles à mesurer à l’intérieur d’une phase

Agile

Modèle itératif et incrémental. Le projet est découpé en builds de petite taille ; chaque itération dure environ une à trois semaines ; des équipes cross-fonctionnelles livrent un incrément ; en fin d’itération, le produit est revu avec le client ou les stakeholders. L’accent est mis sur l’adaptabilité du processus et la satisfaction client.

Avantages

• Collaboration entre équipes (travail d’équipe, cross-training)
• Convient aux exigences fixes et changeantes
• Fonctionnalités développées rapidement et démontrables
• Flexibilité pour les développeurs

Inconvénients

• Exige un plan d’ensemble, un leadership Agile et des pratiques de PM — sinon ça dérive
• Fortement dépendant de l’interaction client : si le client n’est pas clair, l’équipe peut partir dans la mauvaise direction
• Documentation souvent légère → transfert vers un nouveau membre difficile
• Sans discipline (Definition of Done, qualité), la dette s’accumule sprint après sprint

Pour le vocabulaire (sprint, backlog, story points, vélocité), enchaînez sur Terminologie Agile et Méthodologies SDLC.

DevOps

DevOps est un ensemble de pratiques qui combine le développement logiciel (Dev) et les opérations IT (Ops). L’objectif : raccourcir le cycle de vie et fournir une livraison continue avec une haute qualité logicielle. DevOps prolonge Agile par l’automatisation, la responsabilité partagée et le feedback de production (logs, métriques, incidents).

Culture utile à retenir (CALMS) : Culture, Automation, Lean, Measurement, Sharing. Côté mesure, les métriques DORA (fréquence de déploiement, délai de changement, taux d’échec, temps de restauration) quantifient si vos pratiques DevOps tiennent leurs promesses.

Critère	Waterfall	Agile	DevOps
Rythme	Phases longues séquentielles	Sprints 1–3 semaines	Flux continu + automatisation
Feedback	Tardif (fin de phase / projet)	Fin de sprint	Continu (prod + pipeline)
Docs	Très riche	Souvent légère	As code + runbooks vivants
Ops	Souvent séparées	Variable	Intégrées (Dev + Ops)
Changement d’exigences	Coûteux	Bien supporté	Attendu et industrialisé

Du SDLC au pipeline CI/CD

Un pipeline illustre comment les équipes modernes appliquent chaque phase SDLC automatiquement : build, tests, scan de sécurité, staging, puis production. Voici un exemple minimal (GitHub Actions) ; le même esprit se retrouve dans Azure Pipelines YAML et les agents Microsoft-hosted.

# .github/workflows/sdlc-pipeline.yml
name: SDLC DevOps Pipeline
on:
  push:
    branches: [ main ]
jobs:
  build-test-deploy:
    runs-on: ubuntu-24.04
    steps:
      - uses: actions/checkout@v4
      - name: Build
        run: docker build -t app:${{ github.sha }} .
      - name: Unit Tests
        run: npm test
      - name: Security Scan
        run: trivy image app:${{ github.sha }}
      - name: Deploy to Staging
        run: kubectl apply -f k8s/staging/
      - name: Integration Tests
        run: ./run-integration-tests.sh
      - name: Deploy to Production
        if: github.ref == 'refs/heads/main'
        run: kubectl apply -f k8s/prod/

Ce pipeline automatise build → tests → scan → staging → prod et impose des quality gates à chaque étape. Sur Azure DevOps, vous retrouverez trigger, pool ubuntu-latest, jobs et environnements avec approvals — voir Azure DevOps Tools et Release Pipeline.

Pont vers Azure DevOps Services

Dans ce parcours mega-menu Azure, le SDLC se matérialise ainsi :

• Boards : exigences, backlog, sprints (phases Requirement + planification Agile)
• Repos : code, branches, PR (Development)
• Pipelines : CI/CD, tests, déploiements (Testing + Implementation)
• Artifacts / Test Plans : packages et preuve de qualité
• Monitoring (Azure Monitor / App Insights) : Maintenance et feedback

Créez d’abord une organisation saine : Organisation et configuration, puis projets et permissions.

Livrables typiques par phase

Pour ancrer le SDLC dans le quotidien d’une équipe Azure DevOps, associez chaque phase à des artefacts visibles dans Boards, Repos et Pipelines. Cela évite le piège « on fait du Agile » sans preuve de progression.

Phase	Livrables utiles	Où ça vit (ADO)
Requirement	User stories, critères d’acceptation, NFR (perf, sécurité, RGPD)	Azure Boards / backlog
Design	ADR courts, diagrammes, contrats API, menace model léger	Wiki / Repos (docs as code)
Development	Code revu, builds verts, couverture de tests de base	Azure Repos + PR policies
Testing	Rapports de tests, scans, UAT sign-off	Pipelines + Test Plans
Implementation	Release notes, runbook, approvals d’environnement	Environments / Release
Maintenance	Dashboards, alertes, post-mortems actionnables	Azure Monitor / work items

Ces livrables ne remplacent pas le jugement d’équipe : ils rendent le SDLC auditable. Sur un produit régulé, la documentation Waterfall reste précieuse ; sur un SaaS qui itère chaque semaine, privilégiez des ADR courts et des pipelines qui prouvent la qualité.

Quand vous passez à Azure Pipelines, gardez la même cartographie mentale : un job de build couvre Development/Testing, un deployment job couvre Implementation, et les alertes Monitor ferment la boucle Maintenance. Le vocabulaire change, pas l’intention du SDLC.

Comment choisir Waterfall, Agile ou DevOps ?

Choisissez Waterfall (ou un hybride stage-gate) lorsque le périmètre est contractuellement figé, les validations métier sont rares, et le coût d’un changement tardif est extrême (certaines intégrations industrielles ou projets à jalons légaux). Conservez alors des phases nettes et des documents d’exigences signés — sans abandonner pour autant l’automatisation des builds.

Préférez Agile lorsque le feedback utilisateur est fréquent, le backlog évolue, et l’équipe peut livrer un incrément démontrable toutes les 1 à 3 semaines. Ajoutez DevOps dès que vous voulez que cet incrément atteigne la production de façon sûre : tests automatisés, infrastructure as code, observabilité et responsabilité partagée Dev/Ops.

En pratique, le parcours de ce site pousse DevOps + Azure DevOps Services : organisation propre, Boards pour le flux de valeur, Repos Git, Pipelines YAML, puis Bicep pour l’IaC. Cette introduction SDLC est la carte ; les chapitres suivants sont le terrain.

Erreurs fréquentes

• Sauter la phase Requirement → scope creep et attentes manquées
• Lancer des pipelines sans tests automatisés ni scan de sécurité
• Stocker des secrets directement dans les YAML (utiliser Variable groups / Key Vault / secret managers)
• Traiter la Maintenance comme « après-projet » au lieu d’une boucle DevOps
• Copier Waterfall sur un produit qui change chaque semaine (ou inversement : zéro doc sur un système régulé)
• Utiliser d’anciens registres conteneur obsolètes (ex. k8s.gcr.io au lieu de registry.k8s.io) dans les exemples K8s
• Confondre « on a un outil CI » avec « on a une culture DevOps » (sans ownership Ops ni métriques)

Quiz (5 questions)

1. 1. Quelles sont les six phases classiques du SDLC dans l’ordre ?
2. 2. Pourquoi Waterfall peine-t-il quand les exigences changent souvent ?
3. 3. Citez deux avantages et deux inconvénients d’Agile.
4. 4. En une phrase, qu’ajoute DevOps par rapport à Agile ?
5. 5. Quel intérêt d’inclure un pipeline CI/CD dans une intro SDLC ?

FAQ

Quel est l’objectif principal du SDLC ?

Fournir un processus répétable qui transforme les exigences en logiciel en production tout en contrôlant coût, qualité et risque.

En quoi DevOps diffère-t-il d’Agile ?

Agile se concentre sur le développement itératif et le feedback client ; DevOps ajoute l’automatisation opérationnelle et la responsabilité partagée sur tout le cycle de vie, y compris la production.

Pourquoi montrer un pipeline CI/CD dès l’introduction SDLC ?

Parce qu’il démontre concrètement comment chaque phase est appliquée automatiquement, ce qui réduit les erreurs manuelles et accélère les releases.

Quelle méthodologie pour des exigences qui changent souvent ?

Agile et DevOps gèrent mieux l’évolution que Waterfall, grâce aux cycles courts et au feedback continu.

Quelles versions d’outils recommander en 2026 pour les labs liés ?

Ubuntu 24.04 LTS, Kubernetes 1.31 ou plus récent, Terraform 1.9+, Docker Compose v2 ; côté Azure DevOps, YAML Pipelines et agents Microsoft-hosted à jour.

Pour aller plus loin

• Méthodologies SDLC (approfondissement)
• Terminologie Agile
• Azure DevOps Tools
• Jenkins (CI historique encore très présent)
• Explorer GitOps (Argo CD), IaC (Terraform 1.9+ / Bicep) et les métriques DORA
• Platform engineering : portails self-service pour les développeurs

Conclusion

Retenez trois idées : (1) le SDLC structure le passage du besoin au run ; (2) Waterfall, Agile et DevOps offrent des rythmes et des compromis différents, tous encore utiles ; (3) un pipeline CI/CD n’est pas un gadget — c’est la façon moderne d’exécuter les phases Testing et Implementation avec des quality gates.

Maîtriser les phases du SDLC et choisir la bonne méthodologie permet de livrer un logiciel fiable plus vite. Les pratiques DevOps, soutenues par des pipelines automatisés, relient développement et opérations pour une livraison continue de valeur — c’est le socle du parcours Azure DevOps de ce site.

Retour parcours Azure DevOps — hub de la série et leçons sœurs.