Que mettre sous carte, et avec quelles règles¶
Ce chapitre condense la partie en un mode d'emploi. Il ne remplace pas les chapitres précédents, qui justifient chaque ligne.
La question préalable : est-ce un flux répétitif ?¶
Avant de tracer une carte, se demander si les points sont comparables. Une carte de contrôle compare chaque point à la variation habituelle des autres ; si chaque point est une pièce unique, il n'y a pas de variation habituelle à laquelle se comparer.
| Plutôt comparable | Plutôt unique |
|---|---|
| Durée d'un même job de CI | Durée d'un chantier d'architecture |
| Latence d'un même benchmark | Nombre de bugs d'une version majeure |
| Taux d'échec d'une suite de tests | Vélocité d'un sprint après réorganisation |
| Temps de cycle des anomalies mineures | Temps de cycle de « tous les tickets » |
Tableau de choix¶
| Mesure | Nature | Carte recommandée | Règles |
|---|---|---|---|
| Temps de cycle par type | Durée asymétrique | XmR sur le logarithme, ou percentiles | Règle 1 ; règles 2 et 3 seulement après passage au log |
| Débit hebdomadaire | Comptage | XmR (ou carte c si la loi de Poisson est plausible) | Règles 1 à 4 |
| Taux d'échec des changements | Proportion | Carte p avec limites variables selon le nombre de déploiements | Règle 1, éventuellement règle 4 |
| Latence d'un benchmark | Continue, bruitée, autocorrélée | Détection de rupture (E-Divisive, test de Student avant/après) | Revue humaine des ruptures |
| Durée de build | Continue, autocorrélée | Détection de rupture ou carte sur résidus | Pas de règles de séquences brutes |
| Échec d'un test | Binaire | Règle « k échecs de suite » | k = 2 ou 3 selon le coût du délai |
| Erreurs en production | Taux par rapport à un SLO | Alertes à fenêtres multiples | Seuils de consommation du budget |
Les quatre règles d'hygiène¶
- Limites calculées, jamais choisies. Les limites d'une carte sont la voix du processus. Une cible (« moins de 3 jours ») est la voix du client. Les mélanger sur un même graphique est l'erreur la plus courante (Wheeler, repris par Vacanti, Vol. II, chapitre « VoP, VoC »).
- Une carte par population homogène. Stratifier par type de travail, par dépôt, par runner de CI.
- Pas plus de règles que d'enquêteurs. Chaque alarme doit déclencher une recherche de cause. Avec 30 cartes sous les quatre règles de Western Electric, on a une fausse alarme tous les 3,6 jours (script §6). Si personne n'enquête, la carte est du décor.
- Ne pas ajuster sur une alarme sans cause. Si l'enquête ne trouve rien, on ne touche à rien. Corriger chaque écart double la variance (script §7, expérience de l'entonnoir de Deming).
À retenir
Dans le développement humain, les cartes de contrôle marchent sur les machines (CI, benchmarks, production) et sur les flux homogènes (tickets d'un même type). Elles marchent mal sur les personnes et sur les projets. La partie suivante montre que l'arrivée des agents d'IA déplace cette frontière : un agent qui code est beaucoup plus proche d'une machine que d'un développeur — y compris dans sa façon de dériver.