Résumé exécutif

Ce résumé condense les conclusions du rapport. Chaque point renvoie au chapitre qui le justifie.

Les règles elles-mêmes

1. Les règles de Western Electric (1956) et de Nelson (1984) achètent de la vitesse de détection avec des fausses alarmes. La règle 1 seule (un point au-delà de 3σ) déclenche une fausse alarme tous les 370 points en moyenne ; les quatre règles de Western Electric, tous les 92 ; les huit de Nelson, environ tous les 74. En échange, un décalage durable de 1σ est détecté en 9 points au lieu de 44 (Règles WE et Nelson).
2. CUSUM et EWMA font mieux que l'empilement de règles : même vitesse de détection que Western Electric, avec quatre à cinq fois moins de fausses alarmes (Autres familles).
3. Les règles supposent des données gaussiennes et indépendantes. Sur des durées asymétriques, les quatre règles signalent 9 % des points sans aucun changement ; sur une série autocorrélée, 41 %. Le logarithme répare le premier cas, pas le second (Pièges).

Le développement humain

1. Le SPC « à la CMMI » a reflué parce que le développement produit des pièces uniques, en faibles volumes, avec des données asymétriques et autocorrélées (Trente ans de SPC).
2. Il a survécu sous d'autres noms là où les mesures sont nombreuses et comparables : détection de régressions de performance (MongoDB, Mozilla, Chromium), règle « trois échecs de suite » pour les tests instables chez Google, alertes SLO à fenêtres multiples (Intégration continue, Production).
3. La « carte de contrôle » de Jira n'en est pas une (Temps de cycle).

Ce que dit la recherche sur la qualité du développement humain

1. Aucun contrôle ne suffit seul. Les inspections trouvent au mieux deux tiers des défauts avant test ; trois analyseurs statiques combinés, environ 4,5 % des bugs réels ; les techniques trouvent des défauts différents (Inspection et revue).
2. La revue moderne trouve peu de bugs : 14 à 25 % des remarques portent sur des défauts fonctionnels, et la détection baisse avec la taille, la vitesse et la méconnaissance du code — mais les commits non relus introduisent deux fois plus de bugs (même chapitre).
3. Un contrôle automatique se juge à ses faux positifs et à son moment : moins de 10 % chez Google ; le même analyseur passe de presque 0 % à plus de 70 % de corrections chez Facebook en signalant au diff plutôt qu'en lot (Analyse statique).
4. La couverture est une mauvaise cible, et le « coût ×100 » d'un défaut tardif n'est pas confirmé par les données (Tests, Défauts).
5. Le biais d'automatisation touche aussi les experts et ne se corrige pas par la formation (Facteurs humains).

Ce que dit la recherche sur le développement par IA

1. L'effet sur la vitesse rétrécit avec le réalisme : +56 % en laboratoire, +26 % en entreprise, g = 0,33 en méta-analyse, transitoire sur projets réels — où avertissements (+30 %) et complexité (+42 %) augmentent durablement (Productivité).
2. Tous les bancs d'essai audités surestiment la réussite des agents, et les tests générés à partir du code figent ses bugs (Bancs d'essai, Tests générés).
3. Un agent ne se corrige pas seul ; il se corrige avec un signal externe (tests, linter, analyseur), et gagne alors 10 à 40 points (Agents autonomes).
4. Après fusion, le code d'agents demande 1,5 fois plus de correctifs, et l'absence de revue est le facteur qui aggrave le plus la dette ; l'horizon de fiabilité à 80 % est 4 à 6 fois plus court qu'à 50 % (PR d'agents).
5. Ce qui manque : la précision des relecteurs IA, l'efficacité de la revue humaine sur du code d'agent, et toute évaluation publiée d'un dispositif de surveillance en production (Synthèse).

Le contrôle du développement par IA

1. Un agent de code est un producteur stochastique : non déterministe même à température 0, et sujet à des dérives invisibles — le postmortem d'Anthropic de septembre 2025 décrit trois défauts d'infrastructure que les évaluations n'avaient pas détectés (Un producteur stochastique).
2. Les données convergent sur un point : l'IA augmente le volume plus sûrement que la qualité ; les signaux de dégradation portent sur la stabilité, la duplication et la reprise (Ce que disent les données).
3. Un agent peut tromper le contrôle (reward hacking) : le contrôle doit être hors de sa portée — tests en lecture seule ou cachés, juge d'un autre modèle (Causes spéciales).
4. Détecter une chute de 80 % à 70 % de réussite demande 210 à 360 essais. Une batterie de 20 tâches ne voit que des effondrements (Mesurer un agent).

Les orchestrateurs entièrement automatisés

1. Un orchestrateur est le meilleur terrain que le SPC ait eu dans le logiciel : beaucoup de runs, un producteur unique et versionné, une télémétrie gratuite (L'usine sans ouvrier).
2. Le taux de fusion n'est pas une mesure de qualité : près des deux tiers des rejets de PR d'agents ne sont pas des échecs de l'agent (même chapitre).
3. Le plan de contrôle proposé tient en quatre couches : qualification, contrôles unitaires (poka-yoke, signaux de triche), quelques cartes stratifiées, requalification à chaque changement connu (Plan de contrôle type).

Les skills

1. Un skill est un standard de travail à deux caractéristiques de qualité — déclenchement et exécution — mesuré contre une ligne de base (Un skill est un standard).
2. Les méthodes de test publiées sont saines, leurs paramètres par défaut sont faibles : avec 3 runs par requête, une requête qui déclenche 70 % du temps est mal classée 22 % du temps (Tester un skill).
3. Réécrire un skill après chaque échec le dégrade : c'est l'entonnoir de Deming, qui double la variance (Surveiller un skill).