Théorie des contraintes

Objectif

La théorie des contraintes dirige l'effort d'amélioration vers le facteur qui limite le débit d'un système. Le PMBOK Guide range ses cinq étapes de focalisation parmi les méthodes d'amélioration continue comme le PDCA, le Lean et Six Sigma.

Elle répond à un problème fréquent: chaque équipe s'améliore et le système ne livre pas davantage. Une chaîne livre au rythme de son étape la plus lente. La théorie dit où porter l'effort et quelles étapes il est inutile d'accélérer.

Le livrable tient sur une page. Il nomme la contrainte et son type, les décisions qui l'exploitent et les règles qui y subordonnent le reste du système. Si le débit doit encore croître, le livrable chiffre une proposition d'élévation. Le débit, les stocks et les dépenses d'exploitation mesurent l'effet de chaque décision.

Usage

Quand l'utiliser

• Débit insuffisant alors que chacun est occupé: chercher l'étape qui limite le système avant d'ajouter des ressources.
• File d'attente qui grossit devant une étape: des dossiers ou des tickets qui s'accumulent signalent une contrainte physique.
• Investissement de capacité à décider: vérifier que le recrutement, la licence ou l'équipement porte sur la contrainte.
• Ressource partagée par un flux continu de demandes: un environnement de test ou un spécialiste; fixer ses priorités et le rythme d'entrée.
• Indicateurs d'occupation par poste: les remplacer par le débit, les stocks et les dépenses du système.
• Règle qui freine tout le flux: une fenêtre de mise en production mensuelle ou une double signature; la traiter comme une contrainte politique.
• Organisation qui pratique déjà la TOC ou le Lean: le PMBOK Guide demande au chef de projet d'y adapter la gestion des ressources du projet.

Quand ne pas l'utiliser

• Aucun flux mesuré: la contrainte désignée reste une opinion; mesurer d'abord files et temps d'attente par un value stream mapping.
• Planning d'un projet aux ressources disputées: appliquer la méthode de la chaîne critique, qui transpose la théorie aux projets.

Description

La contrainte au sens de la théorie

Une contrainte est «tout élément ou facteur qui empêche un système d'atteindre un niveau de performance plus élevé par rapport à son but». Watson, Blackstone et Gardiner reprennent cette définition du dictionnaire de l'APICS. Le PMBOK Guide parle du facteur limitant le plus important sur le chemin d'un objectif.

Dans la théorie, le mot n'a pas le sens de la triple contrainte. Le périmètre, le délai et le coût bornent un projet et s'échangent l'un contre l'autre. La contrainte de la théorie est le point du système qui fixe son débit.

La théorie tient qu'un système compte peu de contraintes et qu'elles déterminent sa performance. Watson et ses coauteurs classent les contraintes par type. Le type décide du traitement.

Mesurer le système plutôt que les postes

Goldratt juge une décision à son effet sur trois mesures du système. L'ACCA les définit ainsi:

• débit (throughput): le rythme auquel le système génère de l'argent par ses ventes;
• stocks (inventory): l'argent investi dans ce que le système destine à la vente;
• dépenses d'exploitation (operating expense): l'argent dépensé pour transformer les stocks en débit.

Une équipe qui ne vend pas ce qu'elle livre mesure par substitution: le débit en éléments livrés et acceptés par semaine, les stocks en travail commencé et pas encore livré, les dépenses d'exploitation en coût hebdomadaire de l'équipe.

Ces mesures contredisent l'efficacité par poste. Goldratt et Fox ont posé cette opposition en règles (1986). Watson et ses coauteurs en citent deux: «une heure perdue sur le goulot d'étranglement est une heure perdue pour tout le système»; «une heure gagnée sur un poste qui n'est pas le goulot n'est qu'un mirage». Un poste non contraint qui travaille à 100 % n'augmente pas le débit. Il produit du stock devant la contrainte. L'ACCA admet donc du temps mort sur les postes non contraints.

Les cinq étapes de focalisation

Goldratt et Jeff Cox ont exposé les étapes dans The Goal. Elles ont ensuite évolué en processus d'amélioration continue (POOGI, process of ongoing improvement). Le POOGI y ajoute des préalables: l'équipe définit le système et son but, puis choisit les mesures qui l'alignent sur ce but. Pour Goldratt, une entreprise a pour but de gagner de l'argent maintenant et à l'avenir. Un service public ou une équipe projet nomme le sien avant de chercher ce qui le limite.

1. Identifier la contrainte. L'équipe compare la charge et la capacité de chaque étape sur des données: horodatages des tickets, dates d'entrée et de sortie des dossiers. La file d'attente la plus longue se trouve souvent devant la contrainte. L'équipe nomme aussi le type de la contrainte.
2. Décider comment exploiter la contrainte. L'équipe obtient de la contrainte le plus grand débit possible avec les ressources actuelles. Un remplaçant tient la contrainte pendant les pauses et les réunions. Elle ne traite que du travail qui sortira du système. Le contrôle de qualité passe donc avant elle. Un autre poste reprend toute tâche qu'il peut faire à sa place.
3. Subordonner tout le reste à cette décision. Chaque autre étape règle son rythme sur la contrainte. En amont, les étapes n'engagent pas plus de travail que la contrainte n'en absorbe. En aval, elles traitent sans attendre ce qui sort de la contrainte. Les postes non contraints gardent donc de la capacité inutilisée. Cette réserve protège la contrainte des aléas.
4. Élever la contrainte. L'équipe ajoute de la capacité à la contrainte par un recrutement, un achat, une sous-traitance ou un second équipement. Elle ne le fait que si le débit doit encore croître après les étapes 2 et 3. Watson et ses coauteurs posent cet ordre: exploiter avant d'élever.
5. Si une étape précédente a levé la contrainte, revenir à l'étape 1. Goldratt y ajoute une consigne: ne pas laisser l'inertie s'installer. L'équipe revoit alors les règles posées pour l'ancienne contrainte: le rythme d'entrée, les priorités, les horaires du remplaçant. Une règle qui reste en place après le déplacement peut devenir une contrainte politique.

Chaque contrainte levée en fait apparaître une autre ailleurs. Les étapes forment donc une boucle.

Tambour, tampon, corde

La méthode tambour-tampon-corde (drum-buffer-rope, DBR) met en œuvre les étapes 1 à 3 pour une contrainte physique ou de marché. Le tambour est la contrainte que l'étape 1 identifie: son rythme fixe celui du système. Le tampon sert l'exploitation: c'est une marge de temps devant la contrainte. Le travail y arrive un peu avant qu'elle en ait besoin. Un incident en amont ne la laisse donc pas sans travail. La corde sert la subordination: elle relie l'entrée du travail au tambour. Le système n'engage un élément que lorsque la contrainte en a consommé un.

Dans une équipe qui suit son travail sur un tableau kanban, une limite d'en-cours commune à toutes les colonnes jusqu'à la contrainte tient lieu de corde: une carte n'entre que lorsqu'une autre sort de la contrainte. Le PMBOK Guide range la théorie des contraintes et la méthode Kanban parmi les approches qui maximisent le flux.

Pour une contrainte politique, l'équipe change la règle. Goldratt a proposé pour cela les processus de réflexion (thinking processes). Ces arbres logiques relient les effets indésirables à la règle qui les cause.

La théorie des contraintes et les techniques voisines

Pièges

Élever avant d'exploiter. L'achat de capacité est la réponse la plus visible et la plus chère. Une contrainte qui perd du temps en pauses, en reprises ou en tâches qu'un autre poste peut faire garde ce gaspillage après l'achat. L'équipe épuise les étapes 2 et 3 avant de chiffrer l'étape 4.

Occuper tout le monde. La direction qui mesure l'occupation de chaque poste ou les tickets fermés par personne obtient des postes occupés et un stock devant la contrainte. Le débit reste celui de la contrainte.

Désigner la contrainte au jugé. Ni l'équipe qui se plaint le plus ni la personne la plus chargée en heures ne sont forcément la contrainte. Une équipe peut être surchargée de travail qui ne sortira jamais du système. L'équipe identifie la contrainte sur les files et le débit mesurés.

Rester sur l'ancienne contrainte. Après une élévation, l'équipe continue de travailler sur l'étape qu'elle connaît. La contrainte a pu se déplacer. Chaque heure gagnée sur l'ancienne est alors un mirage. L'équipe repasse par l'étape 1 après chaque changement de capacité.

Déclarer une contrainte externe intraitable. La GPM relève qu'une contrainte peut échapper à la maîtrise de l'organisation: un fournisseur unique, une autorisation réglementaire. L'équipe exploite la contrainte et y subordonne le reste du système. L'élévation passe alors par un contrat ou une négociation.

Limites

Watson, Blackstone et Gardiner relèvent les faiblesses de la théorie. Ses solutions sont faisables sans être toujours optimales. Ses procédures sont mal définies et la littérature ne désigne aucune méthode préférée. La littérature définit le débit de plusieurs façons. Goldratt le définit comme les ventes moins les coûts totalement variables. La comptabilité par le débit sert le court terme et ne fournit pas de coût de revient pour fixer un prix. Les auteurs ne trouvent pas de preuve claire d'un écart de performance avec le juste-à-temps.

La GPM ajoute qu'un regard fixé sur la contrainte peut masquer d'autres pistes d'amélioration. Selon Watson et ses coauteurs, les processus de réflexion reposent sur une interprétation subjective. Leur validité et leur fiabilité restent à démontrer. Ces outils sont aussi difficiles à enseigner à la direction des entreprises. Watson et ses coauteurs notaient en 2007 que Goldratt semblait s'en éloigner: il avait lancé pour les consultants une démarche nommée Viable Vision.

Watson et ses coauteurs citent une enquête menée en 2003 par IndustryWeek: moins de 5 % des usines des États-Unis conduisaient alors leur amélioration avec la théorie.

Considérations IA

Sur un export de tickets ou de dossiers, un assistant d'IA qui exécute du code calcule par étape la file, le temps d'attente et le débit hebdomadaire. Il produit le tableau de charge et de capacité de l'étape 1 et signale l'étape devant laquelle le travail s'accumule. Dans les directives internes et les procès-verbaux, il relève les règles qui limitent le flux: fenêtres de mise en production, signatures, seuils d'approbation. L'équipe obtient une première liste de contraintes politiques à vérifier. À partir des effets indésirables que l'équipe a notés, le modèle ébauche les arbres des processus de réflexion.

L'équipe choisit elle-même la contrainte. Un modèle de langage désigne l'étape la plus plausible d'après les mots des documents; seules les données de flux désignent la contrainte. L'élévation engage un budget et des personnes. La direction en décide. Un export qui montre le débit ou la file de collaborateurs nommés contient des données personnelles au sens de la loi sur la protection des données (LPD). L'équipe l'anonymise ou obtient l'accord du conseiller à la protection des données avant de l'envoyer à un service en ligne.

Exemples

La contrainte fixe le débit et se déplace quand on l'élève. L'équipe qui développe le portail en ligne d'une caisse de compensation AVS mesure ses étapes en éléments du backlog par semaine.

Le second environnement ajoute 4 éléments de capacité aux tests et 1 seul élément au débit. Le déploiement plafonne à 9 et devient la contrainte. L'équipe revient à l'étape 1 sur le déploiement.

Visualisations

Après l'exploitation et la subordination, les tests fixent le rythme de la chaîne du portail. Les autres étapes gardent une capacité inutilisée.

Coût

Outils

Un tableau blanc suffit pour dessiner la chaîne, noter la capacité et la file de chaque étape et marquer la contrainte. Un tableur calcule charge, capacité et débit par étape et suit les mesures semaine après semaine.

Jira et Azure DevOps enregistrent chaque passage d'une étape à l'autre. Leur diagramme de flux cumulé montre la bande qui s'élargit devant la contrainte. Un outil de process mining comme Celonis reconstitue les temps d'attente d'un processus à partir des journaux d'un ERP. Une simulation teste l'effet d'une élévation avant l'achat.

Sources

• Project Management Institute (2025), A Guide to the Project Management Body of Knowledge (PMBOK Guide), 8e édition: §2.6.2.5 Monitor and Control Resourcing, qui nomme la théorie des contraintes dans sa liste d'outils (figure 2-45); §2.6.3 Tailoring Considerations (Industry context) pour l'adaptation de la gestion des ressources aux méthodes de l'organisation; §4.2.2 Adaptive Approaches pour la description de la contrainte et la théorie parmi les approches qui maximisent le flux; Section 5, entrée «Theory of constraints (TOC)» pour la définition et le lien avec la CCPM; entrée «Continuous improvement» pour les cinq étapes de focalisation parmi les méthodes d'amélioration continue. Le PMBOK Guide ne décrit pas les étapes.
• Goldratt, Eliyahu M. et Cox, Jeff (1984), The Goal: A Process of Ongoing Improvement, North River Press: le roman d'entreprise où Goldratt expose les cinq étapes de focalisation.
• Watson, K. J., Blackstone, J. H. et Gardiner, S. C. (2007), «The evolution of a management philosophy: The theory of constraints», Journal of Operations Management 25(2), p. 387-402: la définition de la contrainte d'après le dictionnaire de l'APICS et ses types; les règles de Goldratt et Fox (1986); les cinq étapes de focalisation et les préalables du POOGI; la méthode tambour-tampon-corde; le débit, les stocks et les dépenses d'exploitation; les processus de réflexion; les faiblesses de la théorie.
• ACCA, «Throughput accounting»: les définitions du débit, des stocks et des dépenses d'exploitation; l'heure perdue sur le goulot d'étranglement; le temps mort admis sur les postes non contraints.
• GPM Deutsche Gesellschaft für Projektmanagement (2024), «Theory of Constraints (TOC): Definition, Prinzipien & Anwendungsbereiche»: la contrainte hors de la maîtrise de l'organisation; le risque d'un regard fixé sur la seule contrainte.