TL;DR — les six étapes en un coup d’œil
Tout projet logiciel sur mesure réussi passe par les mêmes six phases, qu’il soit mené en agile ou en mode hybride. Sauter ou bâcler une étape génère des coûts en aval qui dépassent systématiquement le temps économisé. Voici la version courte :
- Discovery : Définir ce qu’on construit et pourquoi — exigences, périmètre, modèle de données, décisions d’architecture. 4–6 semaines.
- Design & architecture : Wireframes UX, maquettes UI, plan système. 3–5 semaines.
- Sprints de développement : Build agile itératif, logiciel fonctionnel toutes les 2 semaines. 12–24 semaines pour les projets moyens.
- Tests & QA : Tests automatisés, QA manuelle, revue de sécurité, profilage de performance. 3–5 semaines (en parallèle des sprints).
- Déploiement & lancement : Vérification en staging, mise en production, surveillance go-live. 1–2 semaines.
- Support & itération : Corrections de bugs, patchs de sécurité, nouvelles fonctionnalités. 15–20 % du coût de build par an.
Vue d’ensemble : le SDLC complet en un tableau
Le tableau ci-dessous résume ce que chaque phase produit, la durée typique et sa place dans le coût total d’une plateforme de complexité moyenne (build de 90 000 €–230 000 €).
| Étape | Livrables principaux | Durée typique | % du coût de build |
|---|---|---|---|
| 1. Discovery | Document d’exigences, modèle de données, ADR (Architecture Decision Record), charte de projet | 4–6 semaines | 10–15 % |
| 2. Design & architecture | Wireframes, système UI, contrats API, diagramme d’infrastructure | 3–5 semaines | 8–12 % |
| 3. Sprints de développement | Incréments logiciels fonctionnels, démos de sprint, builds prêts pour la release | 12–24 semaines | 55–65 % |
| 4. Tests & QA | Suite de tests automatisés, rapport QA, constats sécurité, baseline de performance | 3–5 semaines | 8–12 % |
| 5. Déploiement & lancement | Environnement de production, pipeline CI/CD, runbook, checklist go-live | 1–2 semaines | 3–5 % |
| 6. Support & itération | Releases de patchs, incréments fonctionnels, tableaux de bord de supervision | En continu | 15–20 % /an |
Étape 1 : Discovery
La discovery est la phase la plus déterminante du cycle de vie logiciel. Elle transforme un problème métier en une spécification technique constructible. Sans elle, les équipes de développement construisent la mauvaise chose à pleine vitesse.
Une phase de discovery bien menée produit quatre artefacts principaux :
- Document d’exigences : user stories, critères d’acceptation, décisions hors périmètre et gestion des cas limites.
- Modèle de données : les entités, relations et contraintes que le système doit représenter. C’est le fondement de toutes les décisions architecturales qui suivront.
- Architecture Decision Record (ADR) : stack technologique, points d’intégration, stratégie d’hébergement, exigences de conformité et compromis documentés avec leur justification.
- Charte de projet : périmètre, jalons, composition de l’équipe, cadence de communication et voies d’escalade.
La discovery dure typiquement 4–6 semaines pour un projet de complexité moyenne et coûte 14 000 €–22 000 € avec une équipe nearshore senior. Elle est presque toujours tarifée séparément du build principal — et c’est justifié. Le livrable de la discovery est ce qui permet à un devis au forfait ou à un cap en régie d’être meaningfully signé. Sans elle, tout prix fixe n’est qu’une estimation.
Les équipes qui sautent la discovery rapportent systématiquement les mêmes symptômes : exigences changeant après que l’architecture est fixée, intégrations découvertes en milieu de sprint, exigences de conformité RGPD/CNIL retrofitées post-lancement. Chacune de ces situations coûte plus cher à corriger que ce qu’aurait coûté une phase de discovery complète. Voir notre guide sur le développement MVP pour une perspective complémentaire sur le cadrage des projets en phase initiale.
Étape 2 : Design & architecture
Le design et l’architecture traduisent les artefacts de discovery en plan visuel et structurel sur lequel l’équipe de développement s’appuiera. Cette étape se déroule en deux flux de travail parallèles.
UX et UI design produit les parcours utilisateurs, wireframes et maquettes haute fidélité. Pour un logiciel orienté produit, réussir l’UX avant le début du développement n’est pas une question esthétique — cela prévient le type de reprise le plus coûteux : reconstruire une interface que les vrais utilisateurs rejettent. Une bibliothèque de composants bien conçue accélère également le développement, car les ingénieurs construisent selon un système cohérent plutôt que d’inventer l’UI écran par écran.
Architecture système produit le diagramme d’infrastructure, les contrats API, le plan de migration des données (le cas échéant) et le runbook technique. Les décisions clés prises ici incluent : monolithe vs microservices, communication synchrone vs orientée événements, stratégie d’authentification et d’autorisation, exigences de résidence et de chiffrement des données, et conception du pipeline CI/CD.
Les décisions d’architecture prises dans cette phase sont coûteuses à remettre en question. Choisir une stratégie de partitionnement de données inadaptée, par exemple, peut nécessiter une migration complète six mois plus tard. Les architectes seniors justifient leur coût dans cette phase en effectuant des arbitrages éclairés plutôt qu’en se rabattant sur le familier ou le l’à-la-mode.
Étape 3 : Sprints de développement
Le développement est là où la plus grande part du budget est consommée — typiquement 55–65 % du coût total. Pour les projets de complexité moyenne, il dure 12–24 semaines sur plusieurs sprints agiles.
Chaque sprint suit le même rythme : planning (définir les objectifs du sprint depuis le backlog), build (les ingénieurs implémentent les stories convenues), revue (logiciel fonctionnel démontré aux parties prenantes), rétrospective (actions d’amélioration de l’équipe). La cadence de sprint de deux semaines remplit une fonction critique : elle fait remonter les désalignements tôt, quand ils sont peu coûteux à corriger, plutôt qu’à la livraison, quand ce n’est plus le cas.
Pratiques d’ingénierie clés qui distinguent une livraison professionnelle d’une livraison amateur :
- Code review : chaque pull request relue par au moins un ingénieur senior avant la fusion. Prévient l’accumulation de dette technique.
- Tests automatisés : tests unitaires, d’intégration et end-to-end écrits en parallèle des fonctionnalités, pas en rattrapage. Couverture minimale de 70 % sur les chemins critiques.
- Feature flags : nouvelles fonctionnalités déployées derrière des flags, permettant un déploiement progressif et un rollback sûr sans surcharge de déploiement.
- Sécurité by construction : validation des entrées, gestion des secrets, mesures contre le Top 10 OWASP et analyse des vulnérabilités des dépendances intégrées au workflow de développement, pas retrofitées en QA.
Pour les équipes soumises à des exigences de conformité (résidence des données RGPD, piste d’audit SOC 2, traitement des données CNIL), les contrôles de conformité doivent être intégrés aux stories de sprint dès le début, pas boltés après la livraison. Voir notre page de développement logiciel sur mesure pour les détails sur notre approche de la livraison agile conforme.
Étape 4 : Tests & QA
L’assurance qualité s’exécute en parallèle des sprints de développement plutôt que comme une phase distincte post-build. Mais un cycle QA dédié à la fin du développement reste indispensable avant toute mise en production.
La pyramide de tests pour un logiciel de niveau production couvre quatre couches :
- Tests unitaires : tests rapides et isolés de fonctions et composants individuels. Exécutés à chaque commit. Doivent couvrir 70 % ou plus de la logique métier.
- Tests d’intégration : vérifient que les composants et services interagissent correctement. Couvrent les contrats API critiques et les opérations en base de données.
- Tests end-to-end : simulent des parcours utilisateurs réels dans un environnement déployé. Couvrent tous les flux principaux et cas limites documentés en discovery.
- Tests non fonctionnels : profilage de performance sous charge réaliste, test de pénétration sécurité (pour les environnements réglementés), audit d’accessibilité (WCAG 2.1 AA minimum pour les logiciels publics EU/US).
Un test de pénétration sécurité est non négociable pour tout logiciel traitant des données personnelles (conformité RGPD), des transactions financières (PCI-DSS) ou des dossiers médicaux (HIPAA). Pour les logiciels à destination des marchés européens, l’évaluation d’impact sur la protection des données (AIPD/DPIA RGPD) est une obligation légale pour les traitements à haut risque au sens de la CNIL et doit être finalisée avant le lancement, pas après une demande d’un régulateur.
Étape 5 : Déploiement & lancement
Le déploiement est la phase la plus courte mais celle dont la visibilité publique est la plus grande. Un lancement raté crée un problème de confiance qui demande des semaines de communication opérationnelle pour être rétabli, indépendamment de la qualité technique du logiciel.
Le déploiement de niveau production pour un projet de complexité moyenne couvre :
- Provisionnement de l’infrastructure : environnement cloud configuré pour la charge de production, groupes de sécurité, politiques de sauvegarde et alerting en place.
- Pipeline CI/CD : pipeline automatisé de build, test et déploiement pour que les futures releases prennent des minutes, pas des jours.
- Rollout progressif : le trafic de production est migré de l’ancien vers le nouveau systéme par incréments (5 % → 25 % → 100 %) avec des déclencheurs de rollback automatique si les taux d’erreur s’envolent.
- Surveillance go-live : tableaux de bord temps réel pour le taux d’erreur, la latence, le débit et les métriques d’infrastructure durant les 72 premières heures post-lancement. Une couverture ingénierie on-call pendant cette fenêtre est attendue.
- Runbook opérationnel : procédures documentées pour les tâches opérationnelles courantes, la réponse aux incidents et les voies d’escalade. Indispensable pour les équipes client qui reprennent la main post-transfert.
Étape 6 : Support & itération
Un logiciel qui n’est pas activement maintenu se dégrade. Pas de façon spectaculaire ni immédiate — mais progressivement. Les dépendances deviennent obsolètes. Les vulnérabilités de sécurité s’accumulent. La performance se dégrade à mesure que les volumes de données augmentent. Des fonctionnalités qui fonctionnaient à 100 utilisateurs tombent à 10 000.
Les références sectorielles situent systématiquement le support et la maintenance continus à 15–20 % du coût initial de build par an. Ce budget couvre pour une plateforme moyenne :
- Patchs de sécurité et mises à jour des dépendances : CVE critiques et élevées patchées sous SLA convenus (typiquement 24–72 heures pour les critiques). Non négociable.
- Corrections de bugs issues des retours utilisateurs réels : les 90 premiers jours post-lancement font remonter la majorité des bugs cas limites passés à travers les tests.
- Scalabilité de l’infrastructure : ajustements de capacité à mesure que la base utilisateurs croît, optimisation des coûts à mesure que les patterns d’usage se stabilisent.
- Itérations fonctionnelles : ajouts de fonctionnalités pilotés par les données utilisateur, améliorations UX et intégrations guidées par la roadmap produit.
- Supervision et on-call : alerting 24/7 avec SLA de réponse définis. Pour les logiciels crôle revenue-critical, les incidents P1 doivent être pris en charge sous 15 minutes.
Pour un build à 140 000 €, prévoyez 21 000 €–28 000 € par an pour le support. Pour un build à 280 000 €, 42 000 €–56 000 € par an. Les équipes qui réduisent le budget support à zéro font face en général à une refonte complète forcée dans 3–5 ans à 150–200 % du coût initial. Voir notre guide sur le coût du développement logiciel sur mesure en 2026 pour le modèle complet des coûts de maintenance.
L’itération dans cette phase n’est pas de la maintenance — c’est du développement produit. Les analyses d’usage, les tickets de support et les retours commerciaux alimentent un backlog priorisé. Les nouvelles fonctionnalités sont plus rapides et moins chères à livrer qu’au cours du build initial, car l’architecture est établie, l’équipe connaît la base de code et le pipeline CI/CD est opérationnel. Choisir le bon partenaire de développement compte ici. Lire notre guide sur comment choisir une société de développement logiciel pour évaluer les partenaires sur ces deux dimensions.
FAQ
Quelles sont les étapes du développement logiciel ?
Les six étapes principales sont : discovery (exigences et architecture), design et architecture (plans UX et système), sprints de développement (build agile itératif), tests et QA (vérification automatisée et manuelle), déploiement et lancement (mise en production), et support et itération (maintenance et évolution fonctionnelle). Chaque étape produit des artefacts spécifiques et conditionne la phase suivante. Sauter des étapes génère des coûts en aval qui dépassent systématiquement le temps économisé.
Pourquoi la phase de discovery est-elle importante ?
La discovery convertit un problème métier en une spécification technique concrète et constructible avant que le moindre budget de développement ne soit engagé. Elle identifie la complexité des intégrations, les exigences de conformité RGPD/CNIL et les contraintes architecturales qui feraient autrement surface comme de coûteuses surprises en cours de build. Les projets qui investissent dans une discovery sérieuse de 4–6 semaines économisent généralement 30–50 % de reprises en cours de build.
Combien de temps prend chaque phase ?
Pour un projet de complexité moyenne : discovery 4–6 semaines ; design et architecture 3–5 semaines ; sprints de développement 12–24 semaines ; tests et QA 3–5 semaines (en parallèle des sprints) ; déploiement et lancement 1–2 semaines. Le délai total est typiquement de 5–9 mois du démarrage jusqu’au lancement en production. Les projets entreprise complexes durent 12–24 mois.
Utilisez-vous une méthode agile ou en cascade ?
Nous utilisons un modèle hybride : des phases structurées de discovery et d’architecture (portes en cascade légères) suivies de sprints agiles de deux semaines pour la livraison. Ce modèle combine la rigueur architecturale et la flexibilité de livraison. La cascade pure est inadaptée à la plupart des logiciels sur mesure car les exigences évoluent. L’agile pur sans architecture en amont génère une dette technique qui s’accumule. Le modèle hybride est le standard actuel pour les logiciels PME/ETI et entreprise.
Que se passe-t-il après le lancement ?
Le logiciel entre dans la phase de support et d’itération : patchs de sécurité, corrections de bugs, scalabilité de l’infrastructure et nouvelles fonctionnalités. Prévoyez 15–20 % du coût de build par an pour cette phase. L’itération post-lancement est plus rapide et moins chère que le build initial car l’architecture et le pipeline CI/CD sont déjà en place. Ne sacrifiez pas ce budget — la maintenance différée crée une dette technique compoundante qui impose une refonte complète dans 3–5 ans.
Publié le 21 mai 2026. Les délais de processus et pourcentages de coûts reflètent une livraison nearshore senior pour des projets logiciels sur mesure de complexité moyenne. Les délais individuels varient selon le périmètre, la complexité des intégrations et les exigences de conformité.
