Chapitre 312 minDébutant
Approche prédictive : cycle en V et modèle en cascade
Par Josselyn C., prof de BTS SIO. Mis à jour le .
À la fin de ce chapitre, tu sauras
- décrire les phases du modèle en cascade et du cycle en V ;
- associer chaque niveau de test à la phase de conception qu'il vérifie ;
- citer les livrables et les jalons d'un projet prédictif ;
- dire quand l'approche prédictive convient et quand elle échoue.
4 exercices corrigés1 schéma
L'approche prédictive planifie tout le projet au départ, puis enchaîne des phases dans un ordre fixé : on spécifie entièrement, on conçoit, on réalise, on teste, on livre une fois. Le modèle en cascade et le cycle en V en sont les deux formes classiques ; le référentiel du BTS SIO parle d'approche « prédictive et séquentielle ». Ce chapitre décrit ces deux modèles, leurs livrables et leurs jalons, et dit quand ils conviennent.
Le modèle en cascade
Dans le modèle en cascade, le projet descend une série de phases comme l'eau d'une cascade : chacune produit un livrable, ce livrable est validé, et la phase suivante ne commence qu'après cette validation. On ne remonte pas, ou alors à grand prix.
- Expression des besoins : le cahier des charges.
- Spécifications : ce que fera exactement le système, écran par écran, règle par règle.
- Conception : l'architecture, le modèle de données, le découpage en modules.
- Réalisation : le code, les configurations.
- Tests : on vérifie que tout fonctionne et correspond aux spécifications.
- Déploiement et maintenance : la mise en production, puis les corrections et évolutions.
Le modèle a deux qualités : il est simple à comprendre et il donne au client un engagement clair (un périmètre, un prix, une date). Son défaut est l'effet tunnel : entre la validation des spécifications et les tests, le client ne voit rien pendant des semaines ou des mois. S'il avait mal exprimé son besoin, ou si son besoin a changé entre-temps, il le découvre à la fin, quand tout est construit.
Le cycle en V
Le cycle en V reprend la cascade en la pliant : la branche descendante détaille le système de plus en plus finement, la branche montante le vérifie à chaque niveau, en remontant. Chaque phase de conception, à gauche, prépare les tests qui la vérifieront, à droite.
| Phase de conception (à gauche) | Ce qu'elle produit | Niveau de test qui la vérifie (à droite) | Ce que vérifie le test |
|---|---|---|---|
| Expression des besoins | Cahier des charges | Recette (tests d'acceptation) | Le produit répond au besoin du client, dans ses conditions réelles |
| Spécifications fonctionnelles | Description complète du comportement attendu | Tests de validation (tests système) | Le système complet fait ce que disent les spécifications |
| Conception générale | Architecture : modules, interfaces, base de données | Tests d'intégration | Les modules fonctionnent ensemble, les échanges entre eux sont corrects |
| Conception détaillée | Algorithme et rôle de chaque composant | Tests unitaires | Chaque fonction ou classe fait ce qu'elle doit, isolément |
| Codage (pointe du V) | Le code | — | — |
L'idée forte du V est de préparer les tests au moment où l'on conçoit. Quand la MOA valide le cahier des charges, elle valide aussi les critères de recette ; quand l'équipe écrit les spécifications, elle écrit les cas de tests de validation. Les différents niveaux de tests sont détaillés dans le cours tests.
Livrables et jalons d'un projet prédictif
Un jalon est un point de contrôle daté, de durée nulle, qui marque la fin d'une phase ou un événement important : « cahier des charges validé », « postes livrés », « mise en production ». Au jalon, on vérifie que le livrable attendu existe et qu'il est validé ; c'est là que se prennent les décisions de passer à la suite, de corriger ou d'arrêter. Sur un diagramme de Gantt, un jalon se dessine par un losange (chapitre 4).
| Phase | Livrable | Jalon (décision) |
|---|---|---|
| Cadrage | Note de cadrage, cahier des charges | J1 : cahier des charges validé par la MOA |
| Conception | Spécifications, maquettes, dossier d'architecture, plan de tests | J2 : conception validée, lancement de la réalisation |
| Réalisation | Code, configurations, tests unitaires | J3 : fin de réalisation, version livrée en recette |
| Recette | Cahier de recette exécuté, liste des anomalies, procès-verbal | J4 : recette prononcée |
| Déploiement | Version en production, documentation, formation | J5 : mise en production |
| Clôture | Bilan de projet | J6 : clôture |
Pourquoi une erreur coûte plus cher quand on la découvre tard
Une erreur dans le cahier des charges (un besoin oublié, une règle mal comprise) se corrige en quelques minutes si on la voit à la relecture. Découverte à la recette, elle oblige à reprendre les spécifications, la conception, le code et les tests déjà faits : tout ce qui a été construit dessus. C'est la faiblesse structurelle de l'approche prédictive, et c'est ce qui explique les deux réflexes à avoir quand tu travailles en cycle en V :
- faire valider chaque livrable par écrit avant de passer à la phase suivante (un courriel de la MOA, un procès-verbal de réunion) ;
- montrer quelque chose tôt malgré tout : des maquettes pendant les spécifications, une version intermédiaire au milieu de la réalisation.
Avantages et limites
| Avantages | Limites |
|---|---|
| Vision complète dès le départ : périmètre, budget, date | Le besoin doit être connu et stable dès le début |
| Engagement contractuel clair, facile à chiffrer et à suivre | Effet tunnel : le client ne voit le produit qu'à la fin |
| Documentation complète, utile pour la maintenance et les audits | Un changement coûte cher : il faut reprendre les phases déjà validées |
| Adapté aux équipes nombreuses et aux sous-traitants multiples | Les problèmes d'intégration apparaissent tard |
| Très présent dans les domaines réglementés (santé, aéronautique, ferroviaire), où la traçabilité entre exigences et tests est exigée | Risque de livrer, dans les temps, un produit qui ne sert plus |
L'approche prédictive reste la bonne quand le besoin est stable et bien connu, que les tâches dépendent fortement les unes des autres et qu'on ne peut pas livrer « un morceau » utile : un déménagement de salle serveur, le renouvellement d'un parc, une migration de messagerie, un logiciel embarqué soumis à certification. Elle convient mal quand le besoin est flou ou doit se découvrir en voyant le produit, ce qui est le cas de la plupart des applications (choisir une méthode).
Les variantes : itératif, incrémental, hybride
Entre la cascade pure et l'agile, il existe des intermédiaires.
- Le développement incrémental découpe le produit en lots livrés les uns après les autres, chacun avec son petit cycle en V. Le client utilise le lot 1 pendant que le lot 2 se construit.
- Le développement itératif reprend plusieurs fois le même produit pour l'améliorer : une première version simple, puis des versions enrichies selon les retours.
- L'approche hybride mélange les deux mondes dans un même projet : un cadrage et un budget prédictifs, avec une réalisation agile ; ou une partie réglementaire en cycle en V et une interface en sprints.
Les méthodes agiles (chapitre 6) poussent l'itératif et l'incrémental jusqu'au bout : des itérations de quelques semaines, chacune livrant un produit utilisable.
Le renouvellement du parc en approche prédictive
Le projet de Sorbier Logistique n'est pas un développement logiciel, mais il suit la même logique séquentielle. Antoine Mercier y voit cinq phases et quatre jalons :
| Phase | Contenu | Jalon de fin |
|---|---|---|
| Cadrage | Inventaire de l'existant, recueil des besoins, cahier des charges | J1 : cahier des charges validé par la directrice |
| Achats | Consultation de trois fournisseurs, commande, livraison | J2 : postes livrés |
| Préparation | Création du master, tests sur deux postes pilotes | J3 : pilote validé par les utilisateurs clés |
| Déploiement | Installation des 16 postes et transfert des données | J4 : fin du déploiement |
| Accompagnement et clôture | Guide utilisateur, recyclage des anciens postes, bilan | Clôture |
Le prédictif s'impose ici : le besoin est clair (remplacer 16 postes), les tâches s'enchaînent (pas d'installation sans livraison, pas de déploiement sans master testé) et un poste à moitié installé n'a aucune valeur. Il reste à planifier ces tâches dans le temps : c'est l'objet du chapitre suivant.
Exercices
Exercice 1 sur 4 Placer les tests dans le V Réussi À revoir
Pour chaque test d'une application de gestion des congés, indique le niveau de test et la phase du cycle en V qu'il vérifie.
- La fonction
nbJoursOuvres(debut, fin)renvoie 5 pour une semaine du lundi au vendredi. - La responsable RH valide, avec ses propres demandes réelles, que l'application répond à son besoin.
- Le module de saisie enregistre bien la demande dans la base, et le module de validation la retrouve.
- Le parcours complet « saisir une demande, la faire valider, recevoir la confirmation » fonctionne comme décrit dans les spécifications.
Voir la réponseMasquer la réponse de l'exercice 1
- Test unitaire ; il vérifie la conception détaillée (le rôle de la fonction).
- Recette (test d'acceptation) ; elle vérifie l'expression des besoins.
- Test d'intégration ; il vérifie la conception générale (les échanges entre modules).
- Test de validation (test système) ; il vérifie les spécifications fonctionnelles.
Tu avais trouvé ?
Exercice 2 sur 4 L'effet tunnel Réussi À revoir
Une ESN développe en cascade le logiciel de gestion des adhérents d'une fédération sportive. Les spécifications ont été validées en janvier ; la recette a lieu en septembre. Pendant la recette, la fédération découvre que l'application ne gère pas les licences familiales, créées en mars par une nouvelle règle de la fédération.
- Comment s'appelle le phénomène qui a empêché de le voir plus tôt ?
- Quelles phases faudra-t-il reprendre ?
- Propose deux mesures qui l'auraient évité, sans abandonner l'approche prédictive.
Voir la réponseMasquer la réponse de l'exercice 2
- L'effet tunnel : entre la validation des spécifications et la recette, la MOA n'a rien vu du produit.
- Les spécifications (ajouter la règle), la conception (modèle de données des licences), le code et les tests correspondants, puis une nouvelle recette. Le changement a aussi un coût et un délai qu'il faudra faire valider (une demande de changement, chapitre 10).
- Par exemple : prévoir des jalons de démonstration pendant la réalisation (une version intermédiaire montrée en mai) ; organiser une revue des exigences à chaque changement réglementaire de la fédération ; découper le projet en lots incrémentaux pour livrer la gestion des adhérents avant celle des licences.
Tu avais trouvé ?
Exercice 3 sur 4 Prédictif ou pas ? Réussi À revoir
Pour chaque projet, dis si l'approche prédictive te paraît adaptée et justifie en une phrase.
- Le déménagement de la salle serveur d'un hôpital, un week-end précis.
- Une application mobile pour une start-up qui cherche encore son marché.
- La migration de 200 boîtes aux lettres vers un service de messagerie en ligne.
- Le logiciel de pilotage d'un dispositif médical, soumis à certification.
Voir la réponseMasquer la réponse de l'exercice 3
- Oui : les tâches sont connues, très dépendantes, et la date est imposée ; tout doit être planifié et répété à l'avance.
- Non : le besoin va changer avec les retours des premiers utilisateurs ; une approche agile livrera plus vite quelque chose à tester.
- Oui, en général : le besoin est clair et les étapes sont connues ; on peut migrer par vagues, ce qui ajoute un peu d'incrémental.
- Oui : la certification exige des spécifications complètes, une traçabilité entre exigences et tests et une documentation que le cycle en V produit naturellement.
Tu avais trouvé ?
Exercice 4 sur 4 Les jalons d'un projet de site web Réussi À revoir
Une association fait refaire son site par un prestataire, en cycle en V : cahier des charges, maquettes, développement, recette, mise en ligne. Propose quatre jalons, avec pour chacun le livrable vérifié et la personne qui valide.
Voir la réponseMasquer la réponse de l'exercice 4
Une proposition :
| Jalon | Livrable vérifié | Qui valide |
|---|---|---|
| Cahier des charges validé | Cahier des charges | Le bureau de l'association (MOA) |
| Maquettes validées | Maquettes de toutes les pages types | La présidente, avec deux bénévoles utilisateurs |
| Site livré en recette | Site complet sur un serveur de test, plan de tests | Le chef de projet du prestataire (MOE), avant de le remettre |
| Recette prononcée, mise en ligne | Cahier de recette exécuté, procès-verbal signé | La présidente (MOA) |
Tu avais trouvé ?