i

Description

Une cascade qui dévale une paroi rocheuse par paliers

Source

Ivano Giambattista · page d’origine

Licence

CC0 Domaine public

Photo d’origine, non retouchée. L’arrière-plan en est une version stylisée par le site.

Les méthodes prédictives (cascade, cycle en V, spirale, RUP, PMBOK, PRINCE2, Merise, CMMI)

Vous saurez distinguer les méthodes dites prédictives (plan d'abord, exécution ensuite) : cascade, cycle en V, spirale, RUP, approche PMI/PMBOK, PRINCE2, Merise, et le référentiel de maturité…

En bref

• Vous saurez distinguer les méthodes dites prédictives (plan d'abord, exécution ensuite) : cascade, cycle en V, spirale, RUP, approche PMI/PMBOK, PRINCE2, Merise, et le référentiel de maturité CMMI (qui n'est pas une méthode de cycle de vie).
• Vous comprendrez pourquoi elles existent, ce qu'elles garantissent réellement (traçabilité, contrôle, contractualisation) et où elles cassent (incertitude, changement tardif, feedback tardif).
• Vous saurez dire quand elles restent le bon choix : périmètre figé, réglementation, contrat au forfait, migration à iso-fonctionnel.
• Vous verrez leur version data : cadrage de datamart, recette métier sur chiffres, kits d'installation, migrations de version.
• Vous pourrez les comparer ensuite dans le comparatif et les marier aux méthodes agiles dans choisir et hybrider.

Sur cette page

1. 1. Ce que « prédictif » veut dire
2. 2. La cascade (waterfall)
3. 3. Le cycle en V
4. 4. Le modèle en spirale
5. 5. RUP, le processus unifié
6. 6. L'approche PMI / PMBOK
7. 7. PRINCE2
8. 8. Merise et la tradition française
9. 9. CMMI : un référentiel de maturité, pas un cycle
10. 10. Forces et faiblesses : synthèse notée
11. 11. Quand le prédictif reste le bon choix
12. 12. Le prédictif appliqué à la data
13. 13. Expert : le coût du changement, le cône d'incertitude, les contrats
14. 14. Contribution de l'IA
15. 15. Voir aussi

Niveau : 🟢→🔴

1. Ce que « prédictif » veut dire#

🟢 Novice — Une méthode prédictive (on dit aussi « dirigée par le plan », plan-driven) fait le pari qu'on peut connaître l'essentiel avant de construire : on spécifie, on conçoit, on planifie l'ensemble, puis on exécute en mesurant l'écart au plan. Son contraire n'est pas le chaos mais l'approche adaptative, qui planifie par petits morceaux et apprend en livrant (voir méthodes agiles et lean).

Trois idées structurent toutes les méthodes de ce dossier :

Les termes de base (périmètre, jalon, WBS, chemin critique…) sont définis dans les fondamentaux et le glossaire.

2. La cascade (waterfall)#

🟢 Novice — Le modèle en cascade enchaîne des phases : exigences → conception → réalisation → vérification → maintenance. Chaque phase produit un livrable validé qui alimente la suivante. Image : une cascade ne remonte pas.

🟡 Pratique — Origine, souvent mal racontée : l'article de Winston Royce (1970) Managing the Development of Large Software Systems présente le schéma séquentiel pour le critiquer : Royce y juge ce modèle risqué tel quel et propose des boucles de retour, un prototype et une implication du client. Le terme « waterfall » n'est pas de lui. La cascade pure est donc largement un homme de paille devenu norme : celle qu'on pratique réellement est une cascade avec retours (« cascade avec boucles de rétroaction »).

Quand la cascade fonctionne :

• les exigences sont stables et compréhensibles dès le début ;
• la technologie est maîtrisée (pas de découverte technique) ;
• le coût d'une erreur découverte tard est supportable ou compensé par une contractualisation ferme ;
• l'organisation exige des portes de décision formelles (comités, revues de jalon, paiement par étape).

Quand elle échoue : le feedback arrive tard. L'utilisateur voit le produit à la fin ; l'erreur d'exigence, introduite en phase 1, n'est détectée qu'en phase 4, au moment où elle coûte le plus cher à corriger.

🧪 Exemple — Un datamart de ventes spécifié intégralement (modèle en étoile, 40 mesures, règles de calcul) avant tout chargement. À la recette, le chiffre d'affaires « net » diffère de celui du contrôle de gestion de 3 %, à cause d'un traitement des avoirs absent du cahier des charges. En cascade, la correction remonte en conception, impacte tables, chargements, DAX et tests : un rejeu complet. Un prototype chiffré sur un mois de données l'aurait révélé à J+10.

🔴 Expert — Le défaut structurel est le couplage entre la validation et la livraison : tant que rien n'est livré, rien n'est validé en conditions réelles. Les remèdes classiques (prototypage, développement incrémental, revues par pairs) sont des emprunts à d'autres familles, ce qui montre que la cascade est un cas limite plus qu'un point d'équilibre.

3. Le cycle en V#

🟢 Novice — Le cycle en V est une cascade où chaque phase de conception est mise en regard d'une phase de test de même niveau. À gauche on descend (spécifier, concevoir), en bas on code, à droite on remonte (tester, recetter).

🟡 Pratique — Le point essentiel est la correspondance : un test se rédige en même temps que la spécification qu'il vérifie, pas après le code. Cela impose de rendre chaque exigence testable et fournit la traçabilité exigence → test (matrice de couverture).

Il faut distinguer vérification (« fait-on le produit correctement ? », par rapport aux spécifications) et validation (« fait-on le bon produit ? », par rapport au besoin). Le V prévoit les deux, à des niveaux différents.

Éléments d'histoire fiables : le V-Modell allemand (administration fédérale, années 1990, révisé en V-Modell XT) a popularisé la forme ; en France, le cycle en V est devenu le standard de fait des maîtrises d'ouvrage et de nombreux marchés publics informatiques, où l'on distingue MOA (maîtrise d'ouvrage) et MOE (maîtrise d'œuvre). Il reste omniprésent dans les secteurs à forte exigence de preuve (ferroviaire, aéronautique, médical, automobile) : les normes qui y règnent (par exemple les familles DO-178C, ISO 26262, IEC 62304) s'expriment explicitement en vérification/validation à niveaux.

Forces : traçabilité, tests pensés tôt, vocabulaire commun MOA/MOE, adaptation aux contrats par phase. Faiblesses : peu de feedback réel avant la phase droite, rigidité au changement, tendance à la recette-tunnel (la validation a lieu tout à la fin, sur un bloc énorme).

🧪 Exemple (fil rouge data) — Pour un datamart alimenté par une application de force de vente : besoin « suivre le linéaire par enseigne » ↔ recette : pour trois magasins échantillons, le total affiché dans Power BI doit égaler le relevé terrain (écart toléré : 0 sur les quantités, 0,01 sur les montants) ; spécification de modèle ↔ test d'intégration : comptage des lignes par table de faits et contrôle des clés orphelines ; conception détaillée d'une procédure de chargement ↔ test unitaire : rejeu idempotent sur un jeu minimal. Le V se traduit très bien en tests de données (voir le thème de la matrice recette et validation métier).

🔴 Expert — Le V suppose des interfaces entre niveaux stables : si la conception générale bouge, tous les tests descendants sont invalidés. D'où l'intérêt de découper en sous-systèmes avec des contrats d'interface (schémas, contrats de données) figés plus tôt que le reste. Pour la data, le contrat de données entre source et datamart est l'interface la plus critique ; voir sources et contrats de données.

4. Le modèle en spirale#

🟡 Pratique — Proposé par Barry Boehm (1986), le modèle en spirale est un cycle piloté par le risque. Chaque tour traverse quatre quadrants : (1) fixer objectifs et contraintes, (2) analyser les risques et construire un prototype, (3) développer et vérifier, (4) planifier le tour suivant. La taille de l'investissement croît à chaque tour, mais seulement après réduction des risques les plus graves.

Idée maîtresse : le risque détermine le processus. Si le risque principal est l'interface utilisateur, on prototype ; si c'est la performance, on fait un banc d'essai ; si c'est l'intégration, on construit un squelette de bout en bout. Boehm a aussi formulé des jalons d'ancrage (anchor point milestones) qui ont influencé le RUP.

Forces : traite l'incertitude avant de s'engager ; compatible avec de gros projets à risques techniques. Faiblesses : demande des compétences d'analyse de risque rares ; difficile à contractualiser (le nombre de tours est inconnu) ; souvent mal appliquée comme simple cascade en plusieurs passes.

🧪 Exemple data — Avant de s'engager sur une architecture complète, on effectue un tour de pointe : charger un mois de données réelles d'une source instable, mesurer la durée de chargement et la qualité (doublons, clés nulles), décider « poursuivre / changer de stratégie ». C'est une spirale en miniature, et c'est exactement ce que tout bon cadrage data devrait contenir.

5. RUP, le processus unifié#

🟡 Pratique — Le Rational Unified Process (RUP, Rational Software, fin des années 1990, autour de Jacobson, Booch et Rumbaugh, avec UML) est un processus itératif et incrémental dirigé par les cas d'utilisation, centré sur l'architecture et piloté par les risques. Il organise le projet en quatre phases :

Et en parallèle des disciplines (modélisation métier, exigences, analyse/conception, implémentation, test, déploiement, gestion de configuration, gestion de projet, environnement) dont l'effort varie selon la phase.

Forces : architecture traitée tôt, itérations, cohérence conceptuelle, outillage riche. Faiblesses : lourdeur (la personnalisation est obligatoire mais mal faite), jargon, documentation abondante. Son héritage vit dans OpenUP et surtout dans les pratiques d'architecture agile « juste assez » (just enough design up front).

🔴 Expert — La contribution durable du RUP : la phase d'élaboration comme moment où l'on retire les risques d'architecture et où l'on mesure l'avancement par ce qui s'exécute, pas par ce qui est documenté. Cette idée (valider l'architecture par un incrément exécutable) est reprise par le « squelette ambulant » (walking skeleton) et par les architectures évolutives des équipes DevOps (CI/CD).

6. L'approche PMI / PMBOK#

🟢 Novice — Le PMI (Project Management Institute) publie le PMBOK Guide, corpus de connaissances de gestion de projet. Il n'impose pas un cycle de vie : il décrit des processus et des domaines de connaissance applicables à un projet prédictif, itératif, incrémental ou agile. La certification PMP s'appuie dessus (et couvre depuis quelques années aussi l'agile et l'hybride).

🟡 Pratique — Dans les éditions classiques (jusqu'à la 6ᵉ), le guide structure le projet en cinq groupes de processus (initiation, planification, exécution, maîtrise, clôture) et dix domaines de connaissance : intégration, périmètre, échéancier, coûts, qualité, ressources, communications, risques, approvisionnements, parties prenantes.

La 7ᵉ édition (2021) a changé de logique : elle passe d'une liste de processus à 12 principes et 8 domaines de performance, en s'ouvrant explicitement à l'adaptatif ; la 8ᵉ édition, publiée en novembre 2025, conserve cette base de principes et de domaines de performance mais la resserre (6 principes et 7 domaines de performance selon le PMI).

Outils prédictifs typiques, que l'on retrouve dans tout projet réel :

• WBS / OBS (découpage du produit ou du travail en livrables jusqu'à des paquets de travail) ;
• Chemin critique (CPM) et PERT (estimation à trois points : E = (O + 4M + P) / 6) ;
• EVM (Earned Value Management) : valeur planifiée PV, valeur acquise EV, coût réel AC. Indices : CPI = EV / AC (efficience coût), SPI = EV / PV (efficience délai).
• Registre des risques (probabilité × impact), registre des parties prenantes, matrice RACI ;
• Gestion intégrée des changements (demandes de changement, comité de contrôle).

Exemple EVM : datamart de 100 jours-homme budgétés, en semaine 8.

Forces : vocabulaire universel, boîte à outils complète, compatible avec toute organisation (contrats publics, PMO). Faiblesses : le catalogue est un menu, pas une méthode ; sans arbitrage, on empile des artefacts ; l'EVM s'applique mal au travail de recherche ou de découverte (pas de « baseline » stable).

7. PRINCE2#

🟡 Pratique — PRINCE2 (PRojects IN Controlled Environments) est une méthode britannique issue de l'administration, aujourd'hui portée par PeopleCert (ex-AXELOS). Édition courante : PRINCE2 7ᵉ édition (2023) (état 2026-10, à vérifier pour les évolutions de la certification). Elle repose sur :

• 7 principes : justification continue de l'activité, apprentissage par l'expérience, rôles et responsabilités définis, gestion par étapes, gestion par exception, orientation produit, adaptation à l'environnement du projet ;
• 7 thèmes (rebaptisés « pratiques » dans la 7ᵉ édition : business case, organisation, plans, qualité, risques, problèmes, progression, auxquels s'ajoute l'élément transverse « personnes » (leadership, management, culture) — à vérifier pour les libellés français exacts) ;
• 7 processus : élaboration du projet, orientation, initialisation, contrôle d'une étape, gestion de la livraison des produits, gestion des limites d'étape, clôture.

Concepts clés à retenir pour la pratique :

C'est la gestion par étapes qui rend PRINCE2 intéressant pour le hybride : on peut, au sein d'une étape, exécuter en agile — le cadre de gouvernance reste (tolérances, business case, étape), l'exécution est libre. AXELOS/PeopleCert a publié un guide dédié à l'articulation avec l'agile (PRINCE2 Agile).

Forces : gouvernance claire, arrêts anticipés assumés, très adapté aux contrats publics et aux grandes DSI. Faiblesses : formalisme, lourdeur si l'on applique tous les rapports sans adaptation, risque de « PRINCE2 avec un P » (rituel sans pensée).

8. Merise et la tradition française#

🟡 Pratique — Merise (années 1970-1980, France ; Tardieu, Rochfeld, Colletti) est une méthode d'analyse et de conception des systèmes d'information. Elle sépare données et traitements et distingue trois niveaux d'abstraction : conceptuel (le quoi, indépendant de la technique), logique/organisationnel (le comment organisationnel), physique (l'implémentation). Trois cycles : cycle de vie (conception → réalisation → maintenance), cycle de décision (choix et arbitrages), cycle d'abstraction (conceptuel → logique → physique).

Livrables emblématiques : MCD (modèle conceptuel de données, entités-associations avec cardinalités), MLD, MPD, MCT/MOT (modèles conceptuel/organisationnel des traitements). Le MCD→MLD→MPD a formé des générations de développeurs français aux bases relationnelles.

Pourquoi le citer ici ? Parce que Merise est le grand-père français de la modélisation de données et parce que le « cycle en V à la française » (MOA/MOE) en est l'écosystème. Pour la data :

Forces : rigueur de modélisation, langage commun, transmissibilité. Faiblesses : modélisation de l'existant orientée bases transactionnelles ; la modélisation décisionnelle (étoile, flocon) suit d'autres règles (voir Kimball ci-dessous) ; cadence séquentielle.

9. CMMI : un référentiel de maturité, pas un cycle#

🟡 Pratique — CMMI (Capability Maturity Model Integration, issu du SEI de Carnegie Mellon, aujourd'hui géré par l'ISACA) décrit des bonnes pratiques d'organisation et évalue la maturité des processus. Ce n'est pas une méthode de conduite de projet : il ne dit pas « fais d'abord X puis Y », il dit « un processus de gestion des exigences est-il défini, mesuré, amélioré ? ». Le modèle à niveaux de maturité :

La version 2.0 (2018) a modernisé le modèle (vues par domaine de pratique, compatibilité agile affichée). Le principe de matrice « niveaux + pratiques » est aussi celui des matrices de maturité de cette rubrique, avec la différence qu'ici on mesure des résultats observables plutôt qu'une conformité à des processus (voir NOTATION).

10. Forces et faiblesses : synthèse notée#

🟡 Pratique — Notes /5, appréciation d'expert, contexte : projet logiciel ou data de taille moyenne (équipe de 6–15 personnes, 6–18 mois), organisation de taille moyenne. Elles ne valent pas universellement (cf. NOTATION). Le tableau croisé complet, avec les méthodes agiles, est dans le comparatif.

Lecture critique : la prévisibilité n'est élevée que si le plan est juste ; une note 4/5 en prévisibilité cache un risque de fausse précision. L'adéquation data reste moyenne partout parce que la nature des projets data — découverte de la qualité des sources, besoins qui se précisent en voyant les chiffres — est peu compatible avec l'hypothèse « tout connaître d'abord ». La légèreté (overhead) est faible : c'est le prix de la gouvernance.

11. Quand le prédictif reste le bon choix#

🟡 Pratique — Choisir le prédictif n'est pas un archaïsme quand :

1. Le périmètre est figé par l'extérieur : réglementation (reporting prudentiel, états financiers, déclarations), norme sectorielle, cahier des charges publié.
2. Le contrat est au forfait avec obligation de résultat : le prix et le périmètre sont fixés ; un plan détaillé protège les deux parties (voir choisir et hybrider).
3. Le coût d'une erreur en production est extrême (sécurité des personnes, finance, santé) : la vérification/validation doit être prouvable, y compris à un auditeur.
4. La technologie ou la migration est à iso-fonctionnel : migrer un datamart d'une version de SQL Server à une autre, passer d'un schéma à un autre sans changer les règles de calcul : tout est connu, la cible est comparable à la source.
5. Les dépendances physiques sont longues : matériel, appel d'offres, délais d'infrastructure, fenêtres de livraison fixes.
6. L'équipe est dispersée ou en sous-traitance sans interaction fréquente : la documentation remplace la conversation.
7. L'organisation est peu mature en autonomie : un cadre fort rassure et évite l'anarchie.

12. Le prédictif appliqué à la data#

🟡 Pratique — Les projets BI/data ont des traits propres qui modifient la lecture du prédictif.

Ce qui se prête bien à un cadre prédictif

• Migrations (version de SQL Server, de niveau de compatibilité, de schéma, de version du produit) : périmètre connu, critère d'acceptation objectif (« mêmes chiffres avant/après » sur un jeu figé) → cycle en V avec plan de recette de non-régression.
• Livrables réglementaires : états dont la définition est externe.
• Installations et livraisons en kits : un kit d'installation versionné suppose un plan de déploiement, des prérequis vérifiés, une procédure de retour arrière — la discipline du prédictif (plan de mise en production, dossier d'exploitation).
• Gouvernance des modèles de données d'entreprise : le modèle de référence (dictionnaire, conventions de nommage) exige de la stabilité.

Ce qui résiste

• Découverte de la qualité des sources : on ne sait pas, avant d'avoir regardé, que 12 % des clients ont deux identifiants. Le plan est faux par construction → il faut un tour de découverte (profilage) avant d'engager un planning ferme.
• Besoins décisionnels : le décideur découvre ce qu'il veut en voyant des chiffres.
• Historisation et rejeu : décisions d'historisation (SCD type 1/2), politiques de purge, idempotence des chargements — à trancher tôt, coûteuses à changer (voir modélisation et architecture).

Éléments de plan spécifiques à la data (à prévoir dans tout cadre prédictif) :

13. Expert : le coût du changement, le cône d'incertitude, les contrats#

🔴 Expert — Trois idées expliquent la fortune et les limites du prédictif.

1. La courbe du coût du changement. L'argument fondateur des méthodes séquentielles est l'hypothèse (Boehm, années 1970-80, données de grands projets) que le coût de correction d'une erreur croît exponentiellement avec la phase où on la détecte. Cette hypothèse a été contestée : Kent Beck (Extreme Programming Explained) a soutenu que de bonnes pratiques techniques (tests automatisés, refactoring, intégration continue) aplatissent la courbe. La vérité est contextuelle : la courbe reste raide pour le matériel, le contrat, la migration de données en production, le déploiement réglementé ; elle s'aplatit pour le code bien testé et déployable en continu. Pour un datamart : changer le nom d'une mesure DAX avant diffusion coûte une minute ; changer le grain d'une table de faits après six mois de chargements coûte un rechargement et une revalidation métier.

2. Le cône d'incertitude. (Boehm ; McConnell l'a vulgarisé dans Software Estimation.) En début de projet, l'estimation varie d'un facteur de l'ordre de 4 de part et d'autre (de 0,25× à 4×) ; elle se resserre à mesure que l'on décide et que l'on construit. Conséquence : un engagement précis très tôt est une fausse précision. Les ordres de grandeur ne sont pas des données mesurées sur votre contexte — à manier comme tels. L'estimation et ses pièges sont traités dans fondamentaux et dans le thème de matrice planification et estimation.

3. La nature du contrat. Le prédictif est avant tout une technologie contractuelle : forfait, jalons de paiement, pénalités, recette formelle. Le triangle coût-délai-périmètre y est figé (le périmètre est la variable que l'on tente de ne jamais bouger) alors que l'agile fixe le coût et le délai et fait varier le périmètre (le « triangle de fer » est ici inversé). D'où une conséquence pratique : tant que le contrat est au forfait sur périmètre, l'équipe a un intérêt économique à documenter l'écart et à refuser l'évolution ; une relation « de confiance » ne tient que si la gouvernance prévoit une gestion du changement explicite et peu coûteuse en frictions. Voir contractualiser.

Métriques utiles en pilotage prédictif (à lire ensemble, jamais seules) :

Ces indicateurs sont détaillés, avec leurs usages et leurs biais, dans métriques et reporting de projet.

14. Contribution de l'IA#

🤖 IA — Là où le prédictif produit beaucoup de documents structurés, l'IA générative aide mais ne remplace pas le jugement.

Exemple de prompt : « À partir de ces 12 exigences, propose pour chacune un cas de recette vérifiable (donnée d'entrée, résultat attendu chiffré, tolérance) et signale celles qui ne sont pas testables. »

Ce que l'IA ne remplace pas : l'engagement (c'est un humain qui signe le plan), la responsabilité de la recette, la connaissance des données réelles, la détection d'un besoin implicite. Risque spécifique du prédictif : l'IA fabrique du papier plausible à bas coût — la dette documentaire s'accumule plus vite. Détails dans IA et conduite de projet.

15. Voir aussi#

• Suite logique : Méthodes agiles et lean · Comparatif des méthodes · Choisir et hybrider.
• Bases : Fondamentaux · Scrum, le cadre · Scrum et data · Méthodes spécifiques à la data · Pièges et bonnes pratiques.
• Livraison : CI/CD · CI/CD pour la data.
• Outils : outils de planification · Azure DevOps / TFS.
• Maturité : gouvernance et pilotage · gestion des risques · gestion du périmètre et des exigences.
• Glossaire · Notation.

✻ Rédigé par Claude Sonnet 5.5