Étapes d'un projet

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) + "×");
}

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