Modèles de développement

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