Trente ans de SPC dans le logiciel¶
L'idée d'appliquer les cartes de Shewhart au développement logiciel n'est pas neuve. Elle a eu son heure de gloire institutionnelle à la fin des années 1990, puis a reflué. Ce chapitre raconte cette histoire, parce que les objections de l'époque sont exactement celles qui reviennent aujourd'hui avec les agents d'IA.
Le Software Engineering Institute et la navette spatiale¶
Le livre de référence¶
En 1999, William Florac et Anita Carleton, du Software Engineering Institute (SEI) de l'université Carnegie Mellon, publient Measuring the Software Process: Statistical Process Control for Software Process Improvement (Addison-Wesley, collection SEI). Le livre adopte le vocabulaire de Donald Wheeler — on y parle de process behavior charts plutôt que de control charts. Ses chapitres suivent un ordre d'atelier : planifier la mesure, collecter, analyser le comportement du processus, construire les cartes, puis améliorer.
Le terrain : le logiciel de vol de la navette¶
Le terrain d'expérimentation était exceptionnel. Le SEI a travaillé avec l'équipe du logiciel embarqué de la navette spatiale (United Space Alliance, héritière d'IBM) sur un processus d'inspection de code déjà très mature. Le rapport NASA de 1999 décrit « une collaboration où le SEI et le projet du logiciel embarqué de la navette pouvaient expérimenter l'application du SPC aux activités d'inspection » (NTRS 20000097967). L'article de synthèse paraît dans IEEE Software en 2000 (Florac, Carleton, Barnard, vol. 17 n° 4, DOI 10.1109/52.854075).
Pourquoi ce terrain compte
La navette est le cas le plus favorable imaginable : un logiciel unique, maintenu pendant des décennies, par une équipe stable, avec un processus d'inspection codifié et répété des milliers de fois. Si les cartes de contrôle devaient marcher quelque part dans le logiciel, c'était là. Le choix de l'inspection plutôt que du développement lui-même est révélateur : c'est l'activité la plus proche d'une opération répétitive.
CMMI : le SPC devient une exigence de certification¶
Le modèle de maturité CMMI a ensuite inscrit la démarche dans ses niveaux supérieurs :
| Niveau | Nom | Domaines de processus liés au SPC |
|---|---|---|
| 4 | Quantitatively Managed | OPP (performance des processus de l'organisation), QPM (gestion quantitative de projet) |
| 5 | Optimizing | CAR (analyse causale), OPM (gestion de la performance) |
OPP demande d'établir des lignes de base de performance des processus (process performance baselines) ; QPM demande que les projets choisissent des sous-processus à « gérer statistiquement » à partir de ces lignes de base (Wikipédia, CMMI ; résumé secondaire). Le texte officiel de la version 1.3 n'a pas pu être consulté pour ce rapport ; ces descriptions sont des résumés.
Erreur fréquente : PSP n'est pas du SPC
Le Personal Software Process de Watts Humphrey (1995) est souvent rangé dans la même famille. Ses outils statistiques sont pourtant la régression (méthode d'estimation PROBE), les intervalles de prédiction et des mesures de rendement — pas les cartes de Shewhart ni les règles de séquences. Le confondre avec le SPC revient à confondre « mesurer » et « détecter une cause spéciale ».
Le reflux : les données logicielles violent les hypothèses¶
Le débat de 2008¶
En mai 2008, IEEE Software publie un Point/Counterpoint (vol. 25 n° 3, p. 48-51, DOI 10.1109/MS.2008.68) :
- Pour — Ed Weller et David Card, Applying SPC to Software Development: Where and Why ;
- Contre — Bob Raczynski (Lockheed Martin) et Bill Curtis, Software Data Violate SPC's Underlying Assumptions.
Ce sont deux courtes tribunes, pas des études empiriques. Le texte intégral n'a pas pu être consulté pour ce rapport ; on ne peut donc pas attribuer aux auteurs une liste précise d'hypothèses violées. Le titre suffit cependant à situer la thèse, et la littérature qui suit la reprend sous plusieurs formes.
Ce que dit la revue systématique¶
L'équipe de Bari (Baldassarre, Caivano, Visaggio), rejointe par Barbara Kitchenham, l'une des fondatrices des revues systématiques en génie logiciel, publie en 2007 un protocole de revue (EASE 2007, PDF ouvert). Le résumé pose le problème en une phrase :
La production logicielle diffère de la fabrication parce qu'elle repose sur les humains plutôt que sur les machines, et qu'elle produit des objets uniques.
L'objectif affiché de la revue est de savoir si le SPC est « utilisé efficacement et correctement » par les praticiens. D'autres travaux suivent la même ligne :
- la revue de Garcés et Pino (2014, Sistemas y Telemática) ;
- le mapping de Brito, Barcellos et Santos (2018, JSERD), qui recense 84 mesures et note que « le choix des mesures pour le SPC peut être une tâche difficile ».
Les quatre objections récurrentes¶
Reconstituées à partir de cette littérature, les objections se ramènent à quatre. Chacune sera mesurée dans les chapitres suivants :
| Objection | Ce qu'elle casse | Où on la mesure |
|---|---|---|
| Pièces uniques : chaque ticket est différent | La notion même de « processus stable » | Temps de cycle |
| Distributions asymétriques | Les limites à 3σ et surtout les règles de séquences | Pièges, script §3 |
| Faibles volumes : quelques dizaines de points par trimestre | La puissance de détection | Script §4 |
| Autocorrélation : chaque point dépend du précédent | Toutes les règles à la fois | Script §3 |
Ce qui a survécu¶
Le SPC « à la CMMI », en tant que démarche de certification, a reflué. Mais trois de ses idées ont survécu, souvent sans que leurs utilisateurs le sachent :
- La séparation entre bruit et signal — reprise par la détection de régressions de performance, qui a remplacé les seuils fixes par des tests statistiques (chapitre 3) ;
- Les règles de séquences — réinventées sous la forme « trois échecs de suite » pour les tests instables, ou des fenêtres multiples dans les alertes SRE (chapitre 4) ;
- Les cartes XmR de Wheeler — revenues par la porte du Kanban, chez Daniel Vacanti (chapitre 2), et par celle du pilotage d'entreprise, chez Cedric Chin (Commoncog).
À retenir
Le SPC logiciel a échoué là où il voulait certifier un processus de création. Il a réussi là où il surveille un flux répétitif de mesures comparables : temps de build, latences, taux d'échec, durées de cycle sur une échelle adaptée. La frontière entre ces deux usages est la question centrale de ce rapport — y compris pour les agents d'IA.