Le 4 juin 1996, la fusée Ariane 5 explose trente-sept secondes après son décollage, emportant 500 millions de dollars de satellites. La cause n'est pas un défaut matériel : c'est une ligne de code réutilisée d'Ariane 4, qui convertit un nombre trop grand pour le format d'arrivée. Le code « fonctionnait » — sur la fusée précédente. Personne n'avait vérifié qu'il fonctionnait encore sur la nouvelle.

Cette histoire résume ce cours. Un bout de code correct dans son contexte devient catastrophique dans un autre, quand il grossit, dure et passe entre plusieurs mains. Savoir programmer ne suffit plus : il faut savoir construire du logiciel. Ce premier chapitre pose ce qui sépare les deux — et pourquoi cela mérite une discipline entière.

Du programme au logiciel

Vous savez écrire un programme : un code qui résout un problème, que vous écrivez, exécutez, et souvent jetez. Un logiciel est autre chose. Trois différences le définissent, et chacune change tout :

• il grossit : des milliers de lignes au lieu de dizaines, qu'aucune tête ne tient plus en entier ;
• il dure : il vivra des années, bien après que vous en ayez oublié les détails ;
• il passe entre plusieurs mains : d'autres le liront, le modifieront, le corrigeront — ou vous le relirez dans six mois, redevenu un étranger pour vous-même.

Un programme jetable peut se permettre d'être sale : personne d'autre ne le lira, il ne durera pas. Un logiciel, non. C'est cette bascule — de l'écrit-une-fois au vécu-longtemps-à-plusieurs — qui fait naître le besoin de méthode. Le génie logiciel est la discipline de cette bascule.

Les qualités attendues

Qu'attend-on d'un logiciel, au-delà de « ça marche » ? Un ensemble de qualités, qu'il faut nommer pour pouvoir les viser :

Deux remarques. D'abord, la correction ne suffit pas : un logiciel correct mais impossible à modifier est condamné dès la première évolution. Ensuite, ces qualités s'arbitrent : on ne les maximise pas toutes à la fois, on choisit lesquelles priment selon le contexte — un jeu vidéo et un logiciel bancaire ne font pas les mêmes compromis. Nommer ces qualités, c'est se donner les mots pour discuter ces arbitrages.

Le coût de la maintenance

Voici le fait le plus contre-intuitif du chapitre, et celui qui justifie tout le reste. Écrire la première version d'un logiciel ne représente qu'une fraction de son coût total. L'essentiel arrive après la première livraison — c'est la maintenance :

• corrective : réparer les bugs découverts en usage ;
• adaptative : suivre les changements d'environnement (nouveau matériel, nouvelle loi, nouvelle version d'un système) ;
• évolutive : ajouter des fonctionnalités demandées.

Sur un logiciel qui dure, la maintenance dépasse couramment les deux tiers du coût total. Et le plus coûteux, dans la maintenance, n'est pas d'écrire du code : c'est de comprendre le code existant avant d'oser y toucher — environ la moitié du temps.

La conséquence est directe et gouverne tout le cours : optimiser le seul développement initial — « coder vite, tant pis pour la propreté » — revient à économiser sur la petite part pour alourdir la grande. Lisibilité (chapitre 6), conception (chapitre 7), tests (chapitre 8) ne sont pas des luxes de puristes : ce sont des investissements qui réduisent le coût dominant. L'exercice vous fera calculer ce basculement.

Quelques échecs célèbres

Les grands ratés du logiciel enseignent plus que les réussites, parce que leurs causes sont presque toujours méthodologiques, pas techniques :

• Ariane 5 (1996) : du code réutilisé sans revérifier ses hypothèses dans le nouveau contexte. Un défaut de spécification et de test, pas de programmation.
• Therac-25 (1985-87) : un appareil de radiothérapie qui a irradié mortellement des patients, à cause de conditions de course et d'une confiance excessive dans un logiciel non testé. Un défaut de conception et de vérification.
• Mars Climate Orbiter (1999) : une sonde perdue parce que deux équipes ont mélangé unités métriques et impériales. Un défaut de communication et d'interface entre équipes.

Le point commun n'est pas l'incompétence des programmeurs — souvent excellents. C'est l'absence, ou la faiblesse, du processus : spécifier, communiquer, vérifier. C'est précisément ce que ce cours installe.

Les rôles dans une équipe

Puisqu'un logiciel passe entre plusieurs mains, il se construit à plusieurs, et chacun tient un rôle — parfois plusieurs, dans une petite équipe :

• le client (ou son représentant) exprime le besoin et valide le résultat ;
• l'analyste traduit le besoin en spécifications (bloc III) ;
• le concepteur décide de l'architecture (bloc IV) ;
• le développeur écrit le code ;
• le testeur vérifie (bloc V) ;
• le chef de projet coordonne, planifie, arbitre (bloc VI).

Dans votre projet de semestre, en équipe de trois ou quatre, vous tiendrez ces rôles à tour de rôle. L'essentiel à comprendre dès maintenant : la plupart des difficultés d'un projet ne sont pas techniques mais humaines et organisationnelles — se comprendre, se répartir le travail, ne pas se marcher dessus. Le reste du cours outille exactement cela.

À vous

L'exercice rend tangible le fait central du chapitre : le développement initial n'est qu'une fraction du coût d'un logiciel. Vous calculez le coût total de possession sur plusieurs années, et la part qu'y prend la maintenance — souvent plus des deux tiers.

C'est ce chiffre qui donne son sens à tout le reste du cours : si la maintenance domine, alors tout ce qui la rend moins chère — lisibilité, conception, tests, versionnage — est un investissement, pas une coquetterie.

// Un logiciel n'est pas payé une fois : il VIT. Après la première livraison,
// on corrige des bugs, on l'adapte (nouveau matériel, nouvelle loi), on
// ajoute des fonctions. Ce coût-là, la MAINTENANCE, dure des années.
//
// Données typiques d'un projet réel (en jours-personnes) :
const developpementInitial = 200;   // écrire la 1re version
const maintenanceParAn = 60;        // corrections + évolutions, chaque année
const dureeDeVieAnnees = 8;         // combien d'années le logiciel sert

// ── À VOUS (1) : coût total de possession ───────────────────────────────────
function coutTotal() {
  // à compléter : développement initial + maintenance sur toute la durée de vie
  return 0;
}
// À VOUS (2) : la part de la maintenance dans le total, en pourcentage.
function partMaintenance() {
  return 0; // à compléter
}

// ── Ce qui rend la maintenance chère : où le temps passe ────────────────────
// La maintenance, ce n'est pas surtout ÉCRIRE du code, c'est le COMPRENDRE.
const repartitionMaintenance = {
  "comprendre le code existant": 50,   // % du temps de maintenance
  "modifier": 25,
  "tester la modification": 25,
};

// ── Résultats ────────────────────────────────────────────────────────────────
console.log("Développement initial :", developpementInitial, "jours");
console.log("Maintenance totale    :", maintenanceParAn * dureeDeVieAnnees, "jours");
console.log("Coût total            :", coutTotal(), "jours");
console.log("Part de la maintenance:", partMaintenance().toFixed(0), "%");
console.log("");
console.log("Dans la maintenance, le temps va surtout à :");
for (const [poste, pct] of Object.entries(repartitionMaintenance)) {
  console.log("   " + poste.padEnd(28) + pct + " %");
}

function coutTotal() {
  return developpementInitial + maintenanceParAn * dureeDeVieAnnees;   // 200 + 480 = 680
}
function partMaintenance() {
  return (maintenanceParAn * dureeDeVieAnnees) / coutTotal() * 100;    // 480 / 680 ≈ 71 %
}

// ── Ce que l'exercice enseigne ──────────────────────────────────────────────
//
// 1. Le développement initial n'est que la PARTIE VISIBLE. Ici, 200 jours pour
//    écrire la 1re version, mais 480 jours de maintenance ensuite : environ
//    70 % du coût total arrive APRÈS la première livraison. Sur beaucoup de
//    projets réels, la maintenance dépasse les deux tiers du coût.
//
// 2. Conséquence directe : optimiser le seul développement initial (« coder
//    vite, tant pis pour la propreté ») revient à économiser sur 30 % pour
//    alourdir les 70 %. C'est le calcul qui justifie TOUT le reste du cours —
//    lisibilité, conception, tests, versionnage : ce sont des investissements
//    qui réduisent le coût dominant, la maintenance.
//
// 3. La maintenance est chère parce qu'elle consiste d'abord à COMPRENDRE du
//    code qu'on n'a pas écrit (ou qu'on a oublié) : la moitié du temps. D'où
//    l'importance d'un code LISIBLE (chapitre 6) et de TESTS qui disent si une
//    modification a cassé quelque chose (chapitre 8) — sans eux, comprendre et
//    modifier sans risque devient hors de prix.
//
// 4. Un « programme » qu'on jette après usage peut se permettre d'être sale.
//    Un « logiciel » qui dure et passe entre plusieurs mains, non : c'est
//    exactement la différence que ce chapitre installe.

Ce que la suite en fait

Vous savez maintenant pourquoi le génie logiciel existe. Le reste du cours répond au comment, en suivant la vie d'un projet — celui, précisément, que vous démarrez cette semaine en équipe.

Le bloc II ouvre par le cycle de vie : quelles étapes traverse un projet, de l'idée à la maintenance, et selon quel modèle les enchaîner (cascade, itératif, agile). C'est la carte du terrain que les blocs suivants exploreront un à un — et que votre projet parcourra pour de vrai.

À retenir