L'Histoire du Génie Logiciel — De la Cascade à l'Agile

Cette fiche retrace l’évolution du génie logiciel depuis les méthodes prédictives héritées du BTP jusqu’à l’émergence de l’agilité et du cadre Scrum, en passant par les crises majeures qui ont imposé le changement.

---

1. 1970 : Le Modèle en Cascade (Waterfall) & Le Cycle en V — L’Illusion du Génie Civil

L’analogie trompeuse du BTP

Faute de méthode propre, les managers ont calqué l’informatique sur le bâtiment (plans figés à 100% → contrats → coulage du béton). Croire que du logiciel s’apparente à du béton armé a été l’erreur fondamentale de départ.

Les 6 étapes descendantes étanches

Exigences → Analyse → Conception → Codage → Tests → Exploitation

Règle d’étanchéité stricte : interdiction de remonter en arrière. Le code n’arrive qu’en 4ᵉ étape.

Le paradoxe Winston Royce (1970)

Royce a publié le dessin de la cascade pour dénoncer les risques suicidaires de tester à la fin et préconiser des prototypes itératifs. L’industrie n’a retenu que le schéma sans lire ses avertissements.

L’Effet Tunnel

Coupure totale entre l’équipe technique et le client pendant 18 à 24 mois. À la livraison, le produit est obsolète, inadapté ou rejeté.

Le Cycle en V (années 1980)

Amélioration de la préparation des tests (chaque étape de gauche prépare symétriquement son niveau de test à droite), mais maintien de l’effet tunnel car le client attend toujours la toute fin.

À retenir : Le logiciel est une matière vivante et incertaine. Vouloir tout figer deux ans à l’avance dans un contrat sans livraisons intermédiaires mène droit à l’échec.

---

2. 1985-1996 : La Crise du Logiciel & Le Crash d’Ariane 5 (Vol 501) — La Preuve par les Faits

Le rapport CHAOS (Standish Group, 1994)

8 380 projets informatiques audités → 31% annulés, 53% en dépassement critique (189% du budget), seuls 16% de réussite. Preuve statistique de l’échec des méthodes prédictives.

La chronologie du 4 juin 1996 (Ariane 5, Vol 501)

Décollage à Kourou (500 M$ de charge utile). À T=36,7s, le calculateur de guidage primaire plante sur une exception logicielle. Le calculateur de secours identique plante 50 ms plus tard sur le même bug. Tuyères braquées à 90° → destruction à T=37s.

Le bug technique (Integer Overflow en Ada)

Tentative de conversion d’un nombre décimal 64 bits (36 864,42) en entier 16 bits (limité à +32 767). Pas de gestionnaire d’exception prévu pour économiser du temps CPU → arrêt net du processeur.

Les failles humaines organisationnelles

Ce module de calcul était totalement inutile en vol sur Ariane 5 (vestige d’Ariane 4 laissé par habitude), et le code n’avait jamais été testé avec les paramètres de vol réels.

Les 3 leçons modernes :

1. Suppression impérative du code mort
2. Automatisation des tests sur données réelles
3. Sécurisation stricte du typage

---

3. 2001 : Le Manifeste Agile (Snowbird, Utah) — La Rupture Philosophique

En février 2001, 17 praticiens (Kent Beck, Martin Fowler, Ken Schwaber, Jeff Sutherland, Ward Cunningham…) se réunissent à Snowbird (Utah). Constat commun : le logiciel n’est pas une chaîne de montage d’usine, mais une activité de création intellectuelle continue face à un monde incertain.

Les 4 Valeurs Cardinales du Manifeste Agile

Valeur	Formulation
1. Humains & Échanges	Les individus et leurs interactions PLUS QUE les processus et les outils
2. Code Opérationnel	Des logiciels fonctionnels et testés PLUS QU’UNE documentation exhaustive
3. Partenaire Client	La collaboration avec les clients PLUS QUE la négociation contractuelle
4. Adaptation (GPS)	L’adaptation au changement PLUS QUE le suivi aveugle d’un plan figé

L’analogie du GPS : Face à un imprévu, l’équipe agile recalcule son itinéraire en continu pour apporter le maximum de valeur, plutôt que de s’écraser contre un mur par respect d’un vieux plan.

---

4. Le Cadre Scrum en Pratique : Mécanique & Rôles — L’Organisation Opérationnelle

Méthode agile la plus déployée en entreprise (analogie de la mêlée au rugby où tout le groupe est solidaire) :

Les 3 Rôles Complémentaires (sans subordination)

Rôle	Responsabilité
👑 Product Owner (PO)	Définit le QUOI et priorise le Backlog
👥 Squad de Développeurs	Autonome, décide du COMMENT technique
🧭 Scrum Master (SM)	Coach méthodologique et facilitateur

De l’Épopée à la User Story

Les grands chantiers (Épopées/Epics) sont découpés en User Stories (US) rédigées du point de vue d’un Persona :
« En tant que [Persona] — Je veux [Fonctionnalité] — Afin de [Valeur] »

La Boucle de Sprint

Période de durée fixe (1 à 3 semaines) :

1. Sprint Planning : Choix des US et définition du Sprint Goal
2. Daily Standup : Point quotidien debout (5-10 min) devant le Kanban
3. Développement : Conception, Code, Tests (tableau Kanban de suivi)
4. Incrément Livrable : 100% conforme à la Definition of Done (DoD)
5. Sprint Review : Démontrer le produit fini aux utilisateurs
6. Rétrospective : Analyser le fonctionnement interne (Kaizen)

Definition of Done (DoD) : Grille d’exigences qualité non négociable (code testé, documenté, revu par un pair). Pas de tâche « presque finie » : 100% de la DoD ou non terminée.

---

Résumé des Transitions Majeures

Période	Approche	Problème	Solution
1970	Cascade / Waterfall	Effet tunnel, livraison tardive	Cycle en V (tests symétriques)
1985-1996	Crise du logiciel	84% d’échec (CHAOS), Ariane 5	Preuve de l’échec des méthodes rigides
2001	Manifeste Agile	Planification rigide inadaptée	4 valeurs : Humains, Code, Client, Changement
2000+	Scrum	Mise en œuvre opérationnelle	3 rôles, Sprints, DoD, Rétrospectives

---

Message clé pour le BTS SIO : Le génie logiciel a mis 30 ans à comprendre que le logiciel n’est pas du béton. L’agilité n’est pas une mode : c’est la réponse structurelle à la nature vivante, incertaine et créative du développement logiciel.