03. Les contraintes gouvernent le système

Quand la livraison ou la stabilité glissent, ce n'est pas l'effort: c'est une contrainte révélée.

03. Les contraintes gouvernent le système
Représentation symbolique abstraite d'un flux contraint, révélée par la vue globale

Travailler plus fort ne suffit plus

Quand les organisations arrivent chez JPSoftWorks, les équipes sont déjà engagées à fond.

Des backlogs pleins.
Des incidents fréquents.
Les contextes changent trop fréquemment
Des objectifs manqués.

À ce stade, l'effort n'est plus la variable. Le système l'est.

Et chaque système a une, ou même des contraintes.


Une vérité systémique incontournable

Un système ne peut jamais dépasser sa contrainte principale.

Peu importe la performance ailleurs.

Le problème n'est pas d'avoir des contraintes.
Le problème, c'est de les ignorer.


L'usine, encore et toujours

Dans une chaîne de production, on n'accélère pas partout. On agit au goulot:

  • Plus de capacité
  • Plus d'automatisation
  • Moins d'entrée
  • Meilleur design

Le logiciel fonctionne exactement pareil.


Les contraintes se révèlent par les signaux

Souvent, elles apparaissent via:

  • Des SLOs (Service Level Objectives) manqués
  • Des SLAs (Service Level Agreements) fragiles
  • Une MTTR (Mean Time to Recovery) qui grimpe
  • Une fatigue opérationnelle accrue

Ces signaux ne sont pas des échecs. Ce sont des alertes systémiques.


SLOs et SLAs: des détecteurs de contraintes

Chez JPSoftWorks, un SLO manqué n'est pas un blâme. C'est une information.

La fréquence des écarts révèle:

  • Un manque de capacité
  • Une dépendance humaine
  • Une automatisation absente
  • Un flux déséquilibré

La vélocité fonctionnelle sans santé des SLOs est un mirage.


Gouvernance et réalisme

Les objectifs rendent la gouvernance concrète.

Quand les SLOs se dégradent, la question n'est pas qui a fauté, mais quelle contrainte vient d'apparaître.


Sécurité mesurée, pas supposée

Quand les SLAs de sécurité sont visibles:

  • Les problèmes deviennent discutables
  • Les améliorations deviennent ciblées
  • La sécurité s'intègre naturellement au flux

Automatiser là où ça fait mal

Automatiser hors contrainte ne change rien.
Automatiser au goulot change tout.


WIP et contraintes

Une contrainte ignorée entraîne:

  • Accumulation de travail
  • Multitâche (et latences de changement de contexte fréquents)
  • Dégradation des SLOs

Limiter le WIP protège le système, comme nous l'avons vu récemment.


Mise en pratique

  • Définir des SLOs clairs
  • Observer leur dérive
  • Lier SLOs et flux
  • Améliorer au bon endroit (concept du "low hanging fruit")

Mot de la fin

Les contraintes parlent. Les SLOs traduisent.

Si vos équipes sont épuisées et vos objectifs instables, le système vous envoie un message.

Chez JPSoftWorks, c'est là que commence le vrai travail DevOps. Si vous voulez que ça change, on peut vous aider.


Références

SujetLien
Theory of Constraintshttps://en.wikipedia.org/wiki/Theory_of_constraints
The Phoenix Projecthttps://itrevolution.com/the-phoenix-project/
SRE & SLOshttps://sre.google/sre-book/service-level-objectives/
Kanbanhttps://kanban.university/
Team Topologieshttps://www.teamtopologies.com/