Un projet logiciel ne va pas directement de l'idée au code. Entre les deux, une suite d'étapes, chacune préparant la suivante. Ce chapitre les nomme, explique pourquoi chacune existe, et établit le fait qui gouverne tout le cycle de vie : plus une erreur est détectée tard, plus elle coûte cher à corriger. C'est ce fait qui donne un sens à l'ordre des étapes, et qui expliquera, au chapitre suivant, pourquoi les modèles de développement diffèrent.

Les étapes d'un projet

Un projet logiciel traverse, sous une forme ou une autre, six grandes étapes :

Chaque étape consomme le produit de la précédente : la conception s'appuie sur les besoins, le code sur la conception, les tests sur le code. C'est la même logique de cascade que les phases d'un compilateur — chaque maillon a besoin du précédent.

Pourquoi chaque étape existe

L'erreur du débutant est de vouloir « sauter » directement au code. Chaque étape omise se paie plus tard, et plus cher.

Coder sans avoir analysé les besoins, c'est construire vite quelque chose que le client ne voulait pas : le logiciel « marche » et ne sert à rien. Coder sans conception, c'est empiler des morceaux qui finissent par ne plus tenir ensemble. Déployer sans tests, c'est laisser l'utilisateur découvrir les bugs à votre place — au pire moment. Ignorer la maintenance dès la conception, c'est livrer un logiciel qu'on ne pourra pas faire évoluer.

Aucune de ces étapes n'est une formalité administrative : chacune répond à une question que le projet devra de toute façon affronter. Les nommer, c'est décider quand on y répond — tôt et à froid, ou tard et dans l'urgence.

Ce que coûte une erreur détectée tard

Voici le principe central du chapitre, et l'un des plus robustes du génie logiciel : le coût de correction d'un défaut croît très vite avec le retard de sa détection.

Un malentendu sur le besoin qui aurait coûté 1 à clarifier au départ coûte bien plus cher une fois qu'on a construit dessus. Les ordres de grandeur observés sur de nombreux projets :

1trouvé à l'étape « besoins »        →   1×2trouvé à la conception              →   5×3trouvé à l'implémentation           →  10×4trouvé aux tests                    →  20×5trouvé après déploiement            →  50×6trouvé en maintenance               → 100×

Pourquoi cette explosion ? Parce qu'un défaut découvert tard oblige à défaire tout ce qui a été bâti par-dessus : re-spécifier, re-concevoir, re-coder, re-tester, redéployer — et parfois réparer les dégâts déjà causés chez l'utilisateur. C'est exactement le scénario d'Ariane 5 (chapitre 1) : une hypothèse fausse, détectée à l'allumage plutôt qu'à la spécification.

La leçon pratique en découle directement : on déplace l'effort vers l'amont. Une heure passée à bien comprendre le besoin ou à concevoir en économise dix plus tard. C'est le principe « détecter au plus tôt », et la raison d'être des revues et des tests — qui rapprochent la détection du moment où l'erreur a été commise. L'exercice vous fait chiffrer cette explosion.

À vous

L'exercice ancre les deux idées du chapitre. Vous ordonnez les étapes d'un projet — pour vérifier que chacune prépare la suivante — puis vous chiffrez le coût d'une erreur de besoins selon la phase où on la détecte.

Le facteur passe de 1 à 100 entre la spécification et la maintenance. C'est ce chiffre, plus que tout discours, qui justifie de prendre le temps de spécifier, de concevoir et de tester — au lieu de courir au code.

// Les étapes d'un projet, dans le DÉSORDRE. Chacune produit de quoi nourrir
// la suivante ; les sauter, c'est bâtir sur du vide.
const ETAPES = {
  implementation: "écrire le code",
  besoins:        "comprendre ce que le client veut vraiment",
  maintenance:    "corriger et faire évoluer après la livraison",
  conception:     "décider de l'architecture, découper en modules",
  tests:          "vérifier que le logiciel fait ce qui est demandé",
  deploiement:    "mettre en service chez l'utilisateur",
};

// ── À VOUS (1) : ordonner les étapes ────────────────────────────────────────
const ordre = []; // à compléter : la suite des clés, du début à la fin

// ── À VOUS (2) : le coût d'une erreur selon QUAND on la trouve ──────────────
// Un défaut introduit à l'étape « besoins » coûte de plus en plus cher à
// corriger à mesure qu'il est découvert tard (facteur multiplicatif observé
// sur de nombreux projets). Compléter coutCorrection().
const FACTEUR = { besoins: 1, conception: 5, implementation: 10, tests: 20, deploiement: 50, maintenance: 100 };

function coutCorrection(phaseDecouverte) {
  // à compléter : renvoyer le facteur associé à la phase de découverte
  return 0;
}

// ── Vérification ────────────────────────────────────────────────────────────
const CORRECT = ["besoins", "conception", "implementation", "tests", "deploiement", "maintenance"];
console.log("Votre ordre :", ordre.join(" → "));
console.log("ordre correct ?", JSON.stringify(ordre) === JSON.stringify(CORRECT));
console.log("");
console.log("Une erreur de BESOINS coûte, selon quand on la trouve :");
for (const p of CORRECT) {
  console.log("   trouvée en " + p.padEnd(15) + " → " + coutCorrection(p) + "×");
}

const ordre = ["besoins", "conception", "implementation", "tests", "deploiement", "maintenance"];

function coutCorrection(phaseDecouverte) {
  return FACTEUR[phaseDecouverte];
}

// ── Ce que l'exercice enseigne ──────────────────────────────────────────────
//
// 1. Chaque étape PRODUIT ce dont la suivante a besoin : les besoins guident
//    la conception, qui guide le code, qu'on teste, qu'on déploie, qu'on
//    maintient. Sauter une étape — coder sans avoir compris le besoin,
//    déployer sans tester — revient à bâtir sur du vide. C'est pourquoi
//    l'ordre n'est pas décoratif.
//
// 2. Le coût d'une erreur EXPLOSE avec le retard de détection. Un malentendu
//    sur le besoin qui aurait coûté 1 à clarifier au départ coûte 10 à
//    corriger une fois codé, 50 après déploiement, 100 en maintenance : il
//    faut re-spécifier, re-concevoir, re-coder, re-tester, redéployer, et
//    parfois réparer les dégâts déjà causés chez l'utilisateur.
//
// 3. La leçon pratique : on DÉPLACE l'effort vers l'AMONT. Une heure passée à
//    bien comprendre le besoin (bloc III) ou à concevoir (bloc IV) en
//    économise dix plus tard. C'est le principe « détecter au plus tôt » —
//    et la raison d'être des revues et des tests (bloc V), qui rapprochent la
//    détection du moment où l'erreur a été commise.
//
// 4. Ce chiffrage explique aussi POURQUOI les modèles de développement
//    diffèrent (chapitre 3) : la cascade parie sur un amont parfait,
//    l'itératif accepte de se tromper mais raccourcit la boucle pour détecter
//    vite. Tous cherchent à réduire le coût des erreurs tardives.

Ce que la suite en fait

Vous connaissez les étapes et savez pourquoi les respecter. Reste une question : dans quel ordre et à quel rythme les enchaîner ? Faut-il tout spécifier avant de coder une seule ligne, ou avancer par petits pas ?

C'est l'objet du chapitre 3 : les modèles de développement — cascade, V, itératif, agile —, qui sont autant de façons d'organiser ces mêmes étapes. Chacun fait un pari différent sur le coût des erreurs tardives que vous venez de mesurer : la cascade parie sur un amont parfait, l'itératif accepte de se tromper mais raccourcit la boucle pour détecter vite.

À retenir

Le chapitre 2 a établi les étapes d'un projet. Reste à décider dans quel ordre et à quel rythme les enchaîner. Faut-il tout spécifier avant d'écrire une ligne de code, ou avancer par petits pas en ajustant en chemin ? C'est la question des modèles de développement — et il n'existe pas de réponse unique. Chaque modèle fait un pari différent sur le coût des erreurs tardives mesuré au chapitre précédent.

Ce chapitre présente les principaux modèles, non pour en couronner un, mais pour savoir lequel choisir selon le contexte — la seule compétence qui compte vraiment ici.

La cascade, et ses limites

Le modèle en cascade est le plus intuitif : on enchaîne les étapes une fois, dans l'ordre, chacune entièrement terminée avant la suivante.

1besoins → conception → implémentation → tests → déploiement → maintenance

Ses forces : il est simple à planifier et à suivre, chaque étape produit un document validé avant de passer à la suite. Il convient quand les besoins sont stables et bien connus d'avance.

Son défaut est mortel dès que ce n'est pas le cas : on ne vérifie l'adéquation au besoin qu'à la toute fin. Si l'on s'est trompé de cap à la spécification, on ne le découvre qu'au déploiement — au moment où la correction coûte 50 ou 100 fois plus cher (chapitre 2). La cascade parie sur un amont parfait : tout comprendre, tout prévoir avant de coder. Dans un monde où le client découvre souvent ce qu'il veut en le voyant, ce pari est perdu d'avance.

Le modèle en V

Le modèle en V est une cascade repliée qui corrige un de ses défauts : il associe à chaque étape de spécification/conception (la branche descendante) un étage de test correspondant (la branche remontante).

1   besoins  ───────────────────────  tests de recette2     conception  ───────────────  tests d'intégration3        conception détaillée ──  tests unitaires4                   code

L'idée est de préparer les tests en même temps que l'on spécifie : en écrivant le besoin, on écrit déjà comment on le vérifiera (le test de recette) ; en concevant l'architecture, on prévoit les tests d'intégration. Cela ancre la vérification tôt et relie chaque niveau de test au niveau de description qui lui correspond. Mais le V reste, sur le fond, une cascade : il fait le même pari d'un amont figé, avec les mêmes limites si les besoins bougent.

Développement itératif et incrémental

Plutôt que de tout faire une fois, le développement itératif et incrémental livre le logiciel par petits morceaux fonctionnels (incréments), en répétant le cycle à chaque tour (itérations). On construit une première version modeste mais utilisable, on la montre, on l'ajuste, on ajoute le morceau suivant.

Le renversement de pari est complet : au lieu de miser sur un amont parfait, on accepte de se tromper — mais on raccourcit la boucle de retour pour le découvrir vite, sur un petit incrément, quand la correction est encore bon marché. C'est la réponse directe au coût des erreurs tardives : plutôt que d'essayer de les éviter toutes d'avance (impossible si les besoins bougent), on les détecte tôt en confrontant souvent le logiciel à la réalité.

C'est le bon choix quand les besoins sont flous, mouvants, ou que le client les découvre en voyant le produit — c'est-à-dire, en pratique, la plupart des projets.

Les méthodes agiles et Scrum

Les méthodes agiles poussent l'itératif à l'extrême : cycles très courts, client associé en continu, et priorité donnée au logiciel qui marche plutôt qu'à la documentation exhaustive. Scrum en est la déclinaison la plus répandue. Son vocabulaire, à connaître :

• le sprint : une itération courte et de durée fixe (une à quatre semaines), au bout de laquelle on livre un incrément fonctionnel ;
• le backlog : la liste priorisée de tout ce qu'il reste à faire, d'où l'on tire le travail de chaque sprint ;
• la mêlée (daily scrum) : un point quotidien très court où chacun dit ce qu'il a fait, ce qu'il va faire, et ce qui le bloque.

L'esprit : remplacer un cahier des charges figé au départ par une conversation permanente avec le client, et une liste de priorités qu'on réajuste à chaque sprint. C'est adapté au monde où « le client découvre ce qu'il veut en le voyant » — mais cela exige de la discipline et une vraie disponibilité du client, ce qui n'est pas toujours réuni.

Comment choisir

Aucun modèle n'est « le bon » dans l'absolu : le bon dépend du contexte, et le facteur décisif est la stabilité des besoins.

C'est la question à se poser — « mes besoins sont-ils figés ou vont-ils changer ? » — bien plus que le choix d'un nom de méthode. L'exercice vous fait appliquer cette règle à des projets concrets. Pour votre projet de semestre, aux besoins modestes mais que vous préciserez en avançant, une approche itérative légère est la plus réaliste : livrez tôt une version minimale, puis enrichissez.

À vous

L'exercice met en pratique la seule vraie compétence du chapitre : choisir. Vous recommandez un modèle pour plusieurs projets — pilotage d'avion, application de startup, migration comptable, site web à définir — selon la stabilité de leurs besoins.

Vous verrez qu'il n'y a pas de bon modèle universel : la même question — « les besoins sont-ils figés ou mouvants ? » — sépare nettement les cas cascade/V des cas itératif/agile.

// Le choix d'un modèle de développement dépend surtout de DEUX questions :
//   - les besoins sont-ils STABLES et connus d'avance, ou vont-ils changer ?
//   - peut-on se permettre de découvrir tard qu'on a pris le mauvais cap ?
//
// Repères :
//   CASCADE   : besoins stables, tout spécifié avant de coder. Simple à
//               planifier, mais on ne teste l'adéquation qu'à la toute fin.
//   EN V       : cascade où chaque étape de gauche a son étage de test à droite.
//   ITÉRATIF  : on livre par petits incréments, on ajuste à chaque tour.
//   AGILE     : itératif poussé, cycles très courts, client associé en continu.

const PROJETS = [
  { nom: "Logiciel de pilotage d'un avion (norme figée)", besoinsStables: true,  changementsFrequents: false },
  { nom: "Application mobile pour une startup",           besoinsStables: false, changementsFrequents: true  },
  { nom: "Migration d'un système comptable bien défini",  besoinsStables: true,  changementsFrequents: false },
  { nom: "Site web dont le client découvre ce qu'il veut", besoinsStables: false, changementsFrequents: true },
];

// ── À VOUS : recommander un modèle ──────────────────────────────────────────
// Règle simple : si les besoins sont stables et changent peu -> cascade / V.
//                sinon (besoins mouvants) -> itératif / agile.
function recommander(p) {
  // à compléter : renvoyer "cascade / V" ou "itératif / agile"
  return "?";
}

for (const p of PROJETS) {
  console.log(recommander(p).padEnd(18) + " ← " + p.nom);
}

function recommander(p) {
  if (p.besoinsStables && !p.changementsFrequents) return "cascade / V";
  return "itératif / agile";
}
// Avion, migration comptable -> cascade / V (besoins figés, norme claire).
// Startup, site web à découvrir -> itératif / agile (besoins mouvants).
//
// ── Ce que l'exercice enseigne ──────────────────────────────────────────────
//
// 1. Il n'existe pas de « meilleur » modèle dans l'absolu : le bon dépend du
//    CONTEXTE. Le facteur décisif est la STABILITÉ des besoins.
//
// 2. La CASCADE (besoins -> conception -> code -> tests, dans l'ordre, une
//    fois) convient quand les besoins sont figés et bien connus : un pilotage
//    d'avion soumis à une norme, une migration bien spécifiée. Son défaut
//    mortel ailleurs : on ne vérifie l'adéquation au besoin qu'à la TOUTE FIN
//    — si on s'est trompé de cap, on le découvre trop tard (coût 100×,
//    chapitre 2). Le modèle en V ajoute à la cascade un étage de test en
//    regard de chaque étape, sans changer ce pari.
//
// 3. Le développement ITÉRATIF et INCRÉMENTAL livre par petits morceaux
//    fonctionnels, et AJUSTE à chaque tour. On accepte de se tromper, mais on
//    RACCOURCIT la boucle de retour pour le découvrir vite et pas cher. C'est
//    le bon choix quand les besoins sont flous ou mouvants.
//
// 4. Les méthodes AGILES (dont Scrum) poussent l'itératif à l'extrême :
//    cycles très courts (les SPRINTS), liste de tâches priorisée (le BACKLOG),
//    point quotidien (la MÊLÉE), et surtout le CLIENT associé en continu — au
//    lieu d'un cahier des charges figé au départ. Elles répondent au monde où
//    « le client découvre ce qu'il veut en le voyant ».
//
// En L1, retenez la question, pas le dogme : les besoins sont-ils stables ?

Ce que la suite en fait

Vous savez situer les étapes et choisir un modèle. Le bloc III entre dans la première étape de toutes — celle dont le chapitre 2 a montré qu'elle est la plus coûteuse à rater : l'analyse et la spécification.

Le chapitre 4 apprend à recueillir les besoins et à les écrire sans ambiguïté ; le chapitre 5 à en tirer trois diagrammes UML utiles. C'est là que se joue le cap du projet — et, cette semaine, celui de votre projet de semestre, dont vous rédigerez bientôt le cahier des charges.

À retenir