i

Description

Un grand magasin Sears

Source

Nyttend · page d’origine

Licence

PD Domaine public

Photo d’origine, non retouchée. L’arrière-plan en est une version stylisée par le site.

L'optimisation locale (« bout de chaîne »)

Quand chaque maillon améliore son propre indicateur, la chaîne dans son ensemble peut aller moins bien.

En bref

• Quoi : on améliore sa partie (son équipe, son lot, son indicateur) sans mesurer l'effet sur le résultat global.
• Pourquoi : chacun voit et est jugé sur son périmètre ; l'ensemble n'appartient à personne.
• Détecter : des équipes aux indicateurs verts pour un produit en retard ; des files d'attente entre les équipes.
• Éviter : mesurer le flux de bout en bout, chercher la contrainte, fixer des objectifs communs, faire travailler les maillons ensemble.

Sur cette page

1. Définition
2. Le mécanisme
3. Où on le rencontre
   1. En conduite de projet
   2. En management
4. Cas célèbres
   1. Sears : des unités qui se font concurrence 2005-2018
   2. Développement contre exploitation : l'exemple de Flickr 2009
5. Signaux de détection
6. Réflexes d'évitement
7. Avec l'IA : détecter, remédier, atténuer
   1. Détecter
   2. Remédier
   3. Atténuer
   4. Prompts à intégrer à vos usages
   5. Comment les intégrer
   6. Précautions
8. Limites
9. Sources et vérification
10. Voir aussi
    1. Se combine avec, ou renforce
    2. Biais voisins
    3. Contrepoids et réflexes associés

Définition#

Illustration fictive

L'optimisation locale (ou sous-optimisation) consiste à améliorer une partie d'un système sans se demander si cela améliore le tout. Dans une organisation, chaque équipe, chaque lot, chaque service cherche à faire mieux selon ses propres indicateurs, et la somme de ces améliorations n'est pas l'amélioration de l'ensemble : elle peut même le dégrader. La littérature sur la décision parle de « sous-optimisation » depuis Charles Hitch (années 1950) ; l'idée a été popularisée en gestion par Eliyahu Goldratt, dans le roman Le But (The Goal, 1984) et la théorie des contraintes.

Le principe de Goldratt est simple : dans une chaîne, le débit est celui du maillon le plus lent, la contrainte. Accélérer un autre maillon ne fait qu'accumuler du travail en attente devant la contrainte. Une heure gagnée ailleurs ne vaut rien ; une heure perdue sur la contrainte est perdue pour tout le système.

Le biais est cognitif et organisationnel à la fois : on juge ce que l'on voit (son périmètre) et on est récompensé pour ce que l'on mesure (ses indicateurs locaux). Il rejoint la loi de Goodhart : quand un indicateur devient un objectif, on l'optimise pour lui-même.

Le mécanisme#

• Un horizon limité. Chacun connaît bien son lot et ses contraintes, mal ceux des autres. On optimise ce que l'on comprend (voir la malédiction du savoir pour le malentendu qui en résulte à la frontière).
• Des indicateurs par service. Taux d'occupation, nombre de tickets clos, taux de couverture, coût par ligne : chacun mesure une équipe. Personne n'est jugé sur le délai de bout en bout.
• Des objectifs qui s'opposent. Les uns sont jugés sur le changement (livrer vite), les autres sur la stabilité (ne rien casser) ; chacun protège son indicateur au détriment du flux commun.
• L'identité de groupe. Les équipes se perçoivent comme des camps : on défend son périmètre contre « eux » (voir le biais d'appartenance au groupe).
• Le « bout de chaîne ». Chaque maillon livre au suivant ce qui respecte sa propre définition de « terminé », sans se soucier de ce que le suivant en fera.

Où on le rencontre#

En conduite de projet#

• Découpage en lots : chaque lot est optimisé (coût, délai, périmètre du fournisseur), mais l'intégration, qui n'appartient à aucun lot, est découverte tard et coûte cher.
• Développement et exploitation : l'équipe de développement est jugée sur le nombre de changements livrés, celle d'exploitation sur la stabilité. Le « mur de la confusion » entre les deux ralentit tout, pour un résultat que ni l'une ni l'autre ne souhaite (voir le cas Flickr ci-dessous).
• Équipes spécialisées par couche : une équipe base de données, une équipe interface, une équipe test ; une fonctionnalité traverse les trois files et attend à chaque passage.
• Taux d'occupation : remplir à 100 % le temps de chacun semble efficace, mais produit des files d'attente et allonge le délai de livraison.
• Livrer « sa partie » : une équipe déclare son lot terminé selon sa propre définition, sans test d'ensemble ; l'équipe suivante découvre les écarts.
• Sous-traitance au moins disant : le prix de chaque lot est minimisé, alors que le coût total, intégration et reprise comprises, augmente.

En management#

• Objectifs par service : les ventes obtiennent des commandes que la production ne peut pas tenir ; la production réduit ses coûts en refusant les petites séries que le client attend.
• Budgets cloisonnés : un service ne finance pas une amélioration qui profite à un autre, même si elle réduit le coût global.
• Évaluation individuelle : chacun est jugé sur sa propre performance ; l'aide à un collègue ne compte pas.
• Réorganisation en unités autonomes : chaque unité maximise son résultat, parfois contre les autres (voir le cas Sears).

Cas célèbres#

Signaux de détection#

• Tous les indicateurs d'équipe sont verts, et pourtant le produit est en retard ou le client mécontent.
• Des files d'attente entre les équipes : tickets en attente, travaux « prêts mais pas intégrés ».
• Des « ce n'est pas mon périmètre » à la frontière entre deux équipes ou deux lots.
• Une amélioration annoncée par un service dont personne d'autre ne perçoit l'effet.
• Les équipes plaident pour leurs indicateurs plutôt que pour le résultat du produit.
• L'intégration, la recette ou la mise en production sont toujours le point de surprise du planning.
• On gagne du temps sur une étape, et le délai total ne change pas.

Réflexes d'évitement#

1. Mesurer le flux de bout en bout. Le délai entre l'idée (ou la demande) et son usage en production, plus que le taux d'activité de chaque équipe. Une carte de la chaîne de valeur montre où le travail attend.
2. Trouver la contrainte. Appliquez les cinq étapes de Goldratt : identifier la contrainte, l'exploiter à plein, y subordonner le reste, l'élargir, puis recommencer. N'améliorez pas ce qui n'est pas la contrainte.
3. Des objectifs communs. Au moins un indicateur partagé par les équipes d'une même chaîne (délai, qualité à la livraison, satisfaction du client final).
4. Désigner un responsable de l'ensemble. Pour chaque produit ou chaque flux, quelqu'un répond du résultat global, avec l'autorité nécessaire.
5. Équipes de bout en bout. Quand c'est possible, réunir dans une équipe les compétences nécessaires à une livraison (développement, test, exploitation) plutôt que d'enchaîner des files.
6. Limiter le travail en cours. Un nombre maximal d'éléments par étape (tableau Kanban) fait apparaître la contrainte au lieu de la masquer.
7. Définir « terminé » côté consommateur. Un lot est livré quand l'équipe suivante peut l'utiliser, pas quand le producteur a fini.
8. Intégrer tôt et souvent. Les interfaces entre lots sont testées dès le début, avant que chaque lot ne soit « fini ».

Avec l'IA : détecter, remédier, atténuer#

Prompts à intégrer à vos usages#

1. Chercher la contrainte d'une chaîne. Avec un export de tickets ou une description de processus, anonymisés.

Voici la description d'une chaîne de livraison avec ses étapes, ses équipes et, si possible, des durées ou des files d'attente : [texte ou export].
1. Dresse la liste des étapes dans l'ordre et indique, pour chacune, ce qui la fait attendre ou ce qu'elle attend.
2. Dis où, d'après ces données, le travail s'accumule le plus, et quelles données manqueraient pour l'affirmer.
3. Indique, pour trois améliorations locales possibles, si elles réduiraient le délai global ou non, et pourquoi.
N'invente aucune donnée : signale chaque hypothèse comme telle.

2. Objectifs locaux contre objectif commun. Pour préparer un atelier entre deux équipes dont les objectifs s'opposent.

Voici les objectifs et indicateurs de l'équipe A : [liste] et ceux de l'équipe B : [liste]. Les deux équipes travaillent sur le même produit.
1. Décris, pour chaque indicateur, le comportement qu'il encourage et ce que cela provoque pour l'autre équipe.
2. Repère les conflits d'objectifs entre A et B.
3. Propose deux ou trois indicateurs partagés, avec pour chacun un effet pervers possible.
4. Rédige dix questions ouvertes pour un atelier commun, formulées sans reproche.

Comment les intégrer#

• Au démarrage d'un chantier : le prompt 1 aide à dresser la carte du flux avant de décider quoi améliorer.
• En atelier d'équipes : le prompt 2 sert de support de discussion, pas de verdict.
• En suivi : mesurez le délai de bout en bout, avant et après chaque amélioration.

Précautions#

• L'IA ne connaît pas votre organisation : ses réponses restent des hypothèses à confronter aux équipes.
• Ne tirez aucune conclusion individuelle à partir d'exports de tickets : l'objet est le flux, pas les personnes.
• Un indicateur partagé peut lui aussi être détourné : relisez les effets pervers avec les équipes.
• Anonymisez les exports et ne collez pas de données confidentielles dans un outil non autorisé.

Limites#

• Spécialiser, mesurer par équipe et déléguer sont nécessaires : personne ne peut piloter un grand système sans le découper. Le défaut est de ne pas piloter aussi le tout.
• Toute amélioration locale n'est pas inutile : celle qui porte sur la contrainte, ou qui réduit un risque, améliore l'ensemble. Le critère est son effet sur le flux global, pas sa taille.
• La théorie des contraintes simplifie : dans un travail de conception, la contrainte se déplace, et plusieurs maillons peuvent limiter en même temps.
• Le cas Sears est une lecture journalistique à partir de témoignages ; le déclin du groupe a plusieurs causes.
• Vouloir tout optimiser globalement conduit à la paralysie : il faut des responsabilités locales claires et un arbitrage global.

Sources et vérification#

• Goldratt & Cox (1984), The Goal: A Process of Ongoing Improvement, North River Press (traduction française : Le But).
• Hitch & McKean (1960), The Economics of Defense in the Nuclear Age, Harvard University Press — origine du terme « sous-optimisation ».
• Kimes (2013), « At Sears, Eddie Lampert's Warring Divisions Model Adds to the Troubles »,Bloomberg Businessweek, 11 juillet 2013
• Bloomberg, « Sears Goes Bankrupt, Mired in Debt and Deserted by Shoppers » (15 octobre 2018)
• Allspaw & Hammond (2009), « 10+ Deploys Per Day: Dev and Ops Cooperation at Flickr », conférence O'Reilly Velocity.
• Forsgren, Humble & Kim (2018), Accelerate: The Science of Lean Software and DevOps, IT Revolution Press.
• Kim, Behr & Spafford (2013), The Phoenix Project, IT Revolution Press — roman, utile pour la pédagogie plus que comme preuve.

Voir aussi#