Le carré des contraintes
Au-delà du triangle d'or : le modèle à quatre sommets de Jurgen Appelo pour piloter un projet.
-
5ttr
6ttr
6gms
4ttr
Au-delà du triangle d'or : le modèle à quatre sommets de Jurgen Appelo pour piloter un projet.
Dans n'importe quel projet en équipe, tu vas vivre la même tension : trop à faire, pas assez de temps, une équipe imparfaite, et un client (ou un prof, ou un public) qui veut quand même un résultat de qualité.
Ce cours te donne un outil mental pour rendre ces tensions visibles, en parler, et faire des choix lucides. Cet outil s'appelle le carré des contraintes, proposé par Jurgen Appelo dans Management 3.0 (2010) en évolution du classique triangle d'or.
Si un sommet varie dans un sens, soit les 2 sommets adjacents varient dans le même sens, soit le sommet opposé varie dans le sens inverse.
C'est la règle unique qui régit toute la mécanique du modèle. Le reste du cours en dérive.
À la fin de cette séquence, tu seras capable de :
| # | Notion | Idée centrale |
|---|---|---|
| 1 | Triangle d'or | Le modèle classique : Scope, Time, Cost. Critiqué par Appelo car la qualité y est implicite. |
| 2 | Carré des contraintes | Quatre sommets explicites : Scope, Time, Quality, Resources. |
| 3 | Adjacents vs opposé | Si je modifie un sommet, soit les deux adjacents bougent dans le même sens, soit l'opposé bouge en sens inverse. |
| 4 | Ressources = outils × humains | Une équipe sans outils ne produit pas, des outils sans équipe non plus. La capacité humaine, elle, suit la formule N × C × M × T — multiplicative. |
| 5 | Pas d'arbitrage gratuit | Aucun projet ne maximise les quatre sommets en même temps. Le rôle du chef de projet est de rendre les arbitrages explicites et négociés. |
Depuis les années 1960, la gestion de projet se résume souvent à trois contraintes :
« Vite, pas cher, beaucoup de fonctionnalités — choisis-en deux. »
C'est élégant, mais Appelo trouve que la qualité y est traitée comme un sous-produit silencieux. Elle se dégrade quand on serre les trois autres, mais personne n'en parle ouvertement.
Appelo propose d'ajouter explicitement la Qualité comme quatrième sommet :
Voisinages :
| Sommet | Adjacents (côté du carré) | Opposé (diagonale) |
|---|---|---|
| Scope | Time, Resources | Quality |
| Time | Scope, Quality | Resources |
| Quality | Time, Resources | Scope |
| Resources | Scope, Quality | Time |
Cette topologie est essentielle : c'est elle qui détermine qui doit bouger quand tu modifies un sommet.
Définition. L'ensemble des fonctionnalités, livrables et exigences qui définissent ce que le projet doit produire. C'est la frontière du projet : ce qui est inclus, ce qui est exclu.
Vocabulaire.
Exemple. Un site de réservation avec catalogue, calendrier, paiement en ligne, comptes utilisateurs, scan QR et back-office → scope large. Le même site avec uniquement le catalogue et le calendrier → scope réduit.
Piège classique. Le scope creep : le périmètre grossit en douce au fil du projet (« on pourrait juste ajouter… »). Sans arbitrage, c'est le délai, la qualité ou les ressources qui paient l'addition.
Définition. La durée totale disponible pour livrer le projet. Inclut la date de fin (deadline), les jalons intermédiaires, et le rythme de travail.
Vocabulaire.
Exemple. Une soirée d'entreprise est prévue le 14 février. Cette date ne bouge pas. Si le client demande une nouvelle catégorie de questions trois semaines avant, c'est le scope ou la qualité qui devra s'ajuster — jamais le délai.
Particularité. Le temps est souvent la contrainte la plus rigide : un salon, une rentrée scolaire, une obligation légale, un lancement marketing — ces dates sont externes au projet et ne se négocient pas.
Définition. Le niveau d'exigence du livrable : robustesse du code, ergonomie, accessibilité, performance, sécurité, design, absence de bugs, conformité aux normes.
Vocabulaire.
Exemple. Une app médicale doit être validée sans bug critique — la qualité est imposée par la loi. Un prototype présenté en interne peut tolérer des bugs mineurs : on ajuste après.
Le piège de la qualité sacrifiée. Quand on dit « on livrera vite, on corrigera après », on crée de la dette technique : du code mal écrit qu'il faudra payer (avec intérêts) plus tard. Appelo insiste : rendre la qualité explicite, c'est la rendre négociable en conscience, pas par défaut.
Définition. Tout ce qui est mobilisé pour réaliser le projet : équipe humaine, outils, matériel, budget, locaux.
Vocabulaire.
C'est le sommet le plus mal compris — et c'est sur lui qu'on va passer un peu plus de temps.
⚠️ Note importante. Ce qui suit est un enrichissement personnel du modèle d'Appelo, pas la version d'origine. Dans Management 3.0, Appelo traite les ressources de manière assez globale — équipe et budget réunis. La décomposition ci-dessous est une grille de lecture plus fine pour mieux piloter ce qu'il y a derrière la simple étiquette « ressources ».
Pour un projet, les ressources se regroupent en deux grandes familles :
O) — tout ce qui n'est pas humain mais qui permet de produire : matériel (ordinateurs, serveurs, hardware spécialisé), logiciels (IDE, suites de design, outils de build), infrastructure (cloud, CI/CD, bases de données), locaux, licences, accès aux specs et à la documentation, budget.H) — ce que l'équipe peut réellement produire, qui dépend de quatre facteurs détaillés ci-dessous.Les deux dimensions se combinent de manière multiplicative :
R = O × H
Pourquoi multiplicatif ? Parce qu'une équipe top sans serveur, sans IDE, sans accès aux specs → bloquée. Et des outils flambant neufs sans personne pour les utiliser → rien ne sort. Si l'une des deux dimensions tend vers zéro, l'ensemble tend vers zéro.
H = N × C × M × T
Où :
Dans les exemples qui suivent, on utilise des pourcentages (« compétence à 95 % », « motivation à 0 % »…). Ces chiffres ne sont pas des mesures absolues. Personne ne calcule scientifiquement « 78 % de motivation » ou « 42 % de compétence » — c'est impossible.
Les pourcentages sont là uniquement pour faciliter la compréhension : ils permettent de visualiser intuitivement les ordres de grandeur et l'effet multiplicatif. En pratique, trois niveaux suffisent souvent — élevé / moyen / faible — voire juste la question « est-ce qu'il manque quelque chose ? ».
L'important n'est pas la précision du chiffre. C'est de reconnaître que tous les facteurs jouent en même temps, et que tout facteur très bas fait chuter l'ensemble.
C'est la clé du modèle. Une multiplication a une propriété particulière : si un seul facteur est à zéro, le résultat est zéro, peu importe les autres.
Regardons quatre cas pour s'en convaincre :
1 personne · compétence très élevée · motivation nulle · temps total disponible →
H ≈ 1 × 0,95 × 0 × 1 = 0
Le projet n'avance pas. Aucune productivité. La compétence sans motivation = zéro. C'est la grande leçon d'Appelo : la motivation n'est pas un « bonus » qu'on ajoute, c'est un facteur multiplicatif. Sans elle, tout le reste est neutralisé.
5 personnes · compétence très faible · motivation maximale · temps total disponible →
H ≈ 5 × 0,05 × 1 × 1 = 0,25
L'enthousiasme ne remplace pas le savoir-faire. Une équipe ultra-motivée mais qui découvre une techno la veille du sprint ne livrera pas une plateforme robuste.
1 personne · compétence maximale · motivation maximale · temps disponible très faible (autres projets prioritaires) →
H ≈ 1 × 1 × 1 × 0,05 = 0,05
Un excellent profil à quelques % de son temps fournit la même chose qu'un débutant à quelques % : presque rien. Le temps disponible est crucial — et souvent surestimé.
5 personnes · compétence assez bonne · motivation bonne · temps partiel →
H ≈ 5 × 0,7 × 0,8 × 0,6 ≈ 1,7
Soit environ 17 % d'un maximum théorique de 10 personnes à plein régime sur tous les facteurs. C'est une équipe correcte et réaliste : on ne travaille jamais à fond sur tous les axes en même temps.
Avant chaque sprint, pose-toi (en équipe) les quatre questions :
Et n'oublie pas la première moitié de la formule : a-t-on les outils nécessaires ? Sans accès au serveur de test, sans la bonne licence logiciel, sans la doc à jour, même la meilleure équipe sera bloquée.
Si l'un des facteurs (outils inclus) est très bas → c'est lui qu'il faut adresser en priorité avant d'ajouter du scope.
C'est le cœur du modèle. Pour chaque situation, on applique le principe fondamental : soit les deux adjacents bougent dans le même sens (🟢 vert), soit l'opposé bouge en sens inverse (🔴 rouge).
Un client ajoute une fonctionnalité en cours de projet.
🟢 Soit les deux adjacents augmentent :
🔴 Soit l'opposé diminue :
La direction avance la deadline de trois semaines.
🟢 Soit les deux adjacents diminuent :
🔴 Soit l'opposé augmente :
Un développeur quitte l'équipe à mi-projet.
🟢 Soit les deux adjacents diminuent :
🔴 Soit l'opposé augmente :
Audit qualité imposé, ou cible plus exigeante.
🟢 Soit les deux adjacents augmentent :
🔴 Soit l'opposé diminue :
À chaque demande de changement, trois questions à se poser à voix haute :
L'erreur classique : « on garde tout pareil et on encaisse ». Ça n'existe pas. Le carré rend l'arbitrage explicite au lieu de le subir en silence.
Un sommet souvent oublié mais qui devrait être discuté : toute fonctionnalité ajoutée a un coût environnemental.
Quand tu négocies le scope en équipe, pose la question : cette fonctionnalité justifie-t-elle son empreinte ? Le carré devient alors aussi un outil d'arbitrage éthique. C'est la posture Lean & Green de la gestion de projet moderne.
Pour chaque scénario, indique les deux scénarios de compensation possibles selon le principe fondamental :
Réponse attendue par scénario :
Évalue la capacité réelle de ton équipe agile pour la semaine prochaine. Pour chaque facteur, contente-toi d'un niveau élevé / moyen / faible (pas besoin de pourcentages précis) :
→ Identifie le maillon faible (le facteur le plus bas) et propose une action concrète pour le faire remonter.
Le client demande une fonctionnalité supplémentaire à 10 jours de la livraison. Rédige un message Slack ou e-mail expliquant les deux options possibles (adjacents même sens / opposé sens inverse) et ta recommandation argumentée.
Choisis un projet réel que tu connais (un projet open source, le développement d'un jeu vidéo connu, un grand chantier public…). Analyse-le à travers le carré :
« Le triangle vous dit ce que vous pouvez optimiser. Le carré vous rappelle ce que vous sacrifiez. »