Le cycle de vie de développement logiciel regroupe les étapes qu'un logiciel traverse, de l'analyse des besoins à la maintenance. Les 6 étapes, les modèles de cycle de vie et la place de la sécurité.
Le cycle de vie de développement logiciel (SDLC, pour Software Development Life Cycle) est l’ensemble des étapes qu’un logiciel traverse de l’idée à son retrait : analyse des besoins, conception, développement, tests, déploiement, puis maintenance. Ces étapes existent dans tous les projets ; ce qui change d’une méthode à l’autre (cycle en cascade, cycle en V, agile, DevOps), c’est leur ordre, leur durée et la fréquence à laquelle on les répète.
On détaille ci-dessous chaque étape, ce qu’elle produit concrètement, les principaux modèles de cycle de vie et comment choisir, ainsi que ce que le SDLC implique aujourd’hui en matière de sécurité.
- Qu’est-ce que le cycle de vie de développement logiciel ?
- Pourquoi suivre un cycle de vie structuré ?
- Quelles sont les 6 étapes du cycle de vie d’un logiciel ?
- Quels sont les principaux modèles de cycle de vie ?
- Comment choisir le bon modèle pour votre projet ?
- Quelle place pour la sécurité dans le SDLC ?
- Quelles erreurs éviter ?
- Questions fréquentes
- Sources
Qu’est-ce que le cycle de vie de développement logiciel ?
Le cycle de vie de développement logiciel décrit le chemin suivi par une équipe pour concevoir, construire, livrer et faire vivre une application, qu’il s’agisse d’un logiciel métier, d’une application web SaaS ou d’une application mobile. Ce n’est pas une méthode en soi, mais un cadre commun : chaque méthode de gestion de projet (cascade, agile, etc.) propose sa façon d’enchaîner les mêmes grandes activités.
Il existe une norme internationale sur le sujet, l’ISO/IEC/IEEE 12207 « Ingénierie des systèmes et du logiciel : processus du cycle de vie du logiciel », dont la dernière édition date de 2026. Elle décrit les processus du cycle de vie (acquisition, développement, exploitation, maintenance, retrait) sans imposer de méthode particulière.
Pourquoi suivre un cycle de vie structuré ?
Un projet logiciel qui dérape le fait rarement pour des raisons techniques. Il dérape parce qu’une étape a été sautée : besoin mal compris, tests bâclés, mise en production sans plan de retour arrière. Un cycle de vie explicite sert à :
- savoir ce qu’on construit avant d’écrire du code, et le mettre par écrit ;
- tenir un budget et un délai, en découpant le travail en livrables vérifiables ;
- faire travailler ensemble les métiers, le design, le développement et l’exploitation, avec des moments de validation clairs ;
- détecter les défauts tôt, là où ils coûtent le moins cher à corriger ;
- garder de la visibilité sur l’avancement, pour le client comme pour l’équipe ;
- prévoir l’après : un logiciel vit des années après sa mise en ligne.
Quelles sont les 6 étapes du cycle de vie d’un logiciel ?
Le découpage varie selon les auteurs (on trouve des versions en 5, 6 ou 7 phases), mais on retrouve toujours les mêmes activités :
1. Analyse des besoins et planification
C’est l’étape qui conditionne toutes les autres. On y réunit les parties prenantes (direction, utilisateurs finaux, équipes métier, développeurs, responsables informatiques) pour répondre à trois questions : quel problème résout-on, pour qui, et comment saura-t-on que c’est réussi ?
On en tire les objectifs, le périmètre, les contraintes (budget, délai, réglementation, intégrations avec les outils existants) et une première estimation. Les besoins sont formalisés dans un document de spécifications ou un cahier des charges. Quand une idée est incertaine, on peut la valider à ce stade par une preuve de concept ou un prototype, avant d’engager le développement complet.
2. Conception
On décide comment le logiciel va répondre au besoin. Deux niveaux :
- La conception générale (ou architecture) : découpage en modules, choix techniques (langages, frameworks, base de données, hébergement), interfaces entre les briques, intégrations externes (API, paiement, CRM).
- La conception détaillée : modèle de données, logique de chaque module, règles de gestion. Côté interface, ce sont les parcours utilisateurs, les wireframes et les maquettes.
Les décisions prises ici sont les plus coûteuses à changer ensuite : un mauvais modèle de données se paie pendant toute la vie du logiciel.
3. Développement
Les développeurs transforment la conception en code. C’est généralement la phase la plus longue. Les bonnes pratiques qui font la différence :
- un gestionnaire de versions (Git) et des revues de code systématiques ;
- un découpage en petites livraisons plutôt qu’un « grand soir » ;
- des tests écrits en même temps que le code ;
- des environnements séparés : développement, préproduction, production.
4. Tests
Objectif : vérifier que le logiciel fait ce qui était prévu, et rien de gênant en plus. On distingue classiquement quatre niveaux :
| Niveau | Ce qu’on vérifie | Qui |
|---|---|---|
| Tests unitaires | Chaque fonction ou composant isolément | Développeurs, automatisés |
| Tests d’intégration | Les échanges entre modules, avec la base de données, avec les API externes | Développeurs, automatisés |
| Tests système | Le logiciel complet dans un environnement proche de la production (fonctionnel, performance, sécurité) | Équipe qualité |
| Recette (tests d’acceptation) | La conformité au besoin exprimé, sur des scénarios réels | Client et utilisateurs |
Les tests de régression, relancés à chaque modification, garantissent qu’une correction n’en casse pas une autre. Leur automatisation est ce qui permet de livrer souvent sans risque : on en parle dans notre article sur les tests automatisés en développement web.
5. Déploiement
Le logiciel passe en production et devient accessible aux utilisateurs. Selon les projets, le déploiement est progressif (un groupe pilote, puis tout le monde) ou global. Une mise en production propre prévoit : la migration des données existantes, la formation ou la documentation utilisateur, la surveillance des premiers jours, et un plan de retour arrière si quelque chose tourne mal.
6. Maintenance et évolution
C’est souvent la phase la plus longue en durée de vie réelle. Elle regroupe :
- la maintenance corrective : corriger les bugs remontés ;
- la maintenance de sécurité : appliquer les mises à jour des dépendances, des frameworks, du serveur ;
- la maintenance évolutive : ajouter des fonctionnalités à partir des retours des utilisateurs ;
- la surveillance : disponibilité, performances, erreurs, grâce à des outils de monitoring.
Le cycle se termine par le retrait du logiciel : export des données, migration vers un nouvel outil, archivage. Une étape souvent oubliée dans les budgets.
Quels sont les principaux modèles de cycle de vie ?
| Modèle | Principe | Points forts | Points faibles |
|---|---|---|---|
| Cascade (waterfall) | Les étapes s’enchaînent une seule fois, chacune validée avant la suivante | Simple à piloter, budget et périmètre fixés au départ | Peu de place au changement, le client voit le résultat tard |
| Cycle en V | Cascade où chaque phase de conception a sa phase de test correspondante (besoin et recette, architecture et tests d’intégration, etc.) | Traçabilité forte, adapté aux contextes réglementés | Même rigidité que la cascade |
| Itératif et incrémental | Le logiciel est construit par versions successives, chacune ajoutant des fonctionnalités | Retours utilisateurs tôt, risques réduits | Demande un pilotage régulier du périmètre |
| Agile (Scrum, Kanban) | Cycles courts (sprints de quelques semaines) qui répètent toutes les étapes à petite échelle | Souplesse, livraisons fréquentes, client impliqué | Exige la disponibilité du client, budget moins figé |
| DevOps | Prolonge l’agile jusqu’à l’exploitation : intégration et déploiement continus, automatisation, surveillance | Mises en production fréquentes et fiables | Demande de l’outillage et une culture d’équipe |
Le Manifeste agile, publié en 2001, résume l’esprit de l’approche en quatre valeurs : les individus et leurs interactions plus que les processus et les outils ; des logiciels opérationnels plus qu’une documentation exhaustive ; la collaboration avec les clients plus que la négociation contractuelle ; l’adaptation au changement plus que le suivi d’un plan. Pour le prolongement côté exploitation, voir notre article sur le DevOps.
Comment choisir le bon modèle pour votre projet ?
- Besoin stable, bien connu, périmètre contractuel fixe (par exemple une migration à l’identique) : une approche en cascade ou en V reste pertinente.
- Besoin encore flou ou marché à tester : itératif ou agile, en commençant par un produit minimum viable qu’on enrichit.
- Logiciel en production qui évolue en continu (SaaS, plateforme e-commerce) : agile avec des pratiques DevOps.
Dans la pratique, beaucoup de projets sont hybrides : un cadrage et une conception générale faits en amont, puis un développement par itérations. C’est une approche adaptée à la plupart des applications web sur mesure : un périmètre de départ clair pour chiffrer, puis des livraisons régulières que le client peut tester.
Quelle place pour la sécurité dans le SDLC ?
Longtemps, la sécurité était vérifiée à la fin, juste avant la mise en ligne. L’approche actuelle consiste à l’intégrer à chaque étape : exigences de sécurité dès l’analyse, modélisation des menaces à la conception, revue de code et analyse des dépendances au développement, tests de sécurité avant le déploiement, veille sur les vulnérabilités en maintenance.
Deux références utiles :
- le Secure Software Development Framework (SSDF) du NIST américain (publication SP 800-218, version 1.1 de février 2022), qui liste les pratiques de développement sécurisé à intégrer dans n’importe quel cycle de vie ;
- le Cyber Resilience Act européen (règlement (UE) 2024/2847), entré en vigueur le 10 décembre 2024 : il impose aux fabricants de produits comportant des éléments numériques, logiciels compris, de les concevoir, mettre à jour et maintenir de façon sécurisée. Les obligations de signalement s’appliquent à partir du 11 septembre 2026, les obligations principales à partir du 11 décembre 2027.
Quelles erreurs éviter ?
- Raccourcir l’analyse des besoins pour « gagner du temps » : c’est la cause la plus fréquente de fonctionnalités refaites.
- Tester seulement à la fin : les défauts découverts tard sont les plus coûteux.
- Confondre agile et absence de cadrage : l’agilité change l’ordre des étapes, elle ne les supprime pas.
- Oublier la maintenance dans le budget : un logiciel non mis à jour devient une faille de sécurité.
- Ne rien documenter : sans documentation minimale, le prochain développeur repart de zéro.
Questions fréquentes
Que signifie SDLC ?
Software Development Life Cycle, soit cycle de vie de développement logiciel : l’ensemble des étapes qu’un logiciel traverse, de l’expression du besoin à son retrait.
Combien y a-t-il d’étapes dans le cycle de vie d’un logiciel ?
Le plus souvent six : analyse, conception, développement, tests, déploiement, maintenance. Certains découpages en ajoutent (faisabilité, retrait) ou en fusionnent, mais les activités restent les mêmes.
Quelle différence entre cycle en V et cycle en cascade ?
Les deux sont séquentiels. Le cycle en V associe explicitement chaque phase de conception à une phase de test : la recette vérifie le besoin, les tests d’intégration vérifient l’architecture, les tests unitaires vérifient la conception détaillée.
L’agile supprime-t-il le cycle de vie ?
Non. Chaque sprint reprend toutes les étapes (besoin, conception, développement, test, livraison) à petite échelle. L’agile raccourcit et répète le cycle au lieu de le dérouler une seule fois.
Quelle est l’étape la plus longue ?
Pendant le projet, le développement. Sur toute la vie du logiciel, la maintenance, qui dure aussi longtemps que le logiciel est utilisé.
