Guide complet des contraintes dans Primavera P6 : types, exemples et bonnes pratiques
Introduction :
Dans le management de projet, l’ordonnancement est un processus complexe qui nécessite de trouver un équilibre entre une logique réseau (CPM) et des contraintes réelles du projet. Dans Oracle Primavera P6, les contraintes sont utilisées pour imposer des règles spécifiques sur les dates de début et de fin des activités, afin d’aligner le planning avec les exigences contractuelles, réglementaires et opérationnelles.
Ce guide propose une analyse détaillée et à forte valeur ajoutée des contraintes dans Primavera P6, incluant :
- Les différents types de contraintes
- Leur impact sur le calcul du planning
- Les différences clés entre contraintes fortes (hard) et contraintes souples (soft)
- Les bonnes pratiques pour garantir que les contraintes renforcent — et non détériorent — la qualité d’un planning structuré
👉 Objectif : passer d’un planning “forcé” à un planning robuste, défendable et exploitable en Delay & Risk Strategy.
Que sont les contraintes dans Primavera P6 ?
Les contraintes dans Primavera P6 sont des restrictions basées sur des dates, appliquées aux activités pour orienter ou forcer leur planification, en complément (ou parfois au détriment) de la logique réseau.
Au lieu de se reposer uniquement sur les relations entre activités (FS, SS, etc.), les contraintes permettent de contrôler directement les dates de début ou de fin.
Cas d’usage typiques :
- Exigences réglementaires (dates imposées par les autorités)
- Obligations contractuelles (jalons, paiements)
- Disponibilité des ressources
- Dépendances externes (approbations, fournisseurs)
⚠️ Attention : une mauvaise utilisation peut générer :
- du negative float
- un planning irréaliste
- une perte de flexibilité
Types de contraintes dans Primavera P6
Les contraintes sont classées en deux catégories principales :
👉 Contraintes fortes (Hard) vs Contraintes souples (Soft)
1. Contraintes fortes (Hard Constraints)
Les contraintes fortes imposent des dates fixes et ignorent souvent la logique réseau.
⚠️ À utiliser avec précaution.
🔴 a. Start On (Démarrer le)
- Force le démarrage à une date précise
- Ignore les prédécesseurs
Exemple :
Autorisation d’excavation à partir du 15/06/2025
🔴 b. Finish On (Finir le)
- Force la fin à une date donnée
- Peut créer du negative float
Exemple :
Structure terminée au 30/08/2025 (contrat)
🔴 c. Mandatory Start (Début obligatoire)
- Démarrage imposé, sans tenir compte de la logique
Exemple :
Commissioning fixé au 05/01/2026
🔴 d. Mandatory Finish (Fin obligatoire)
- Fin imposée, même si la logique indique autre chose
Exemple :
Livraison imposée au 31/12/2026
2. Contraintes souples (Soft Constraints)
Les contraintes souples guident le planning sans casser la logique CPM.
👉 Recommandées en pratique
🟢 a. Start On or After (SOOA)
- Ne peut pas commencer avant une date
Exemple :
Montage acier après livraison (10/05/2025)
🟢 b. Start On or Before
- Doit démarrer avant une date limite
Exemple :
Coulage béton avant le 01/07/2025
🟢 c. Finish On or After (FOOA)
- Ne peut pas finir avant une date
Exemple :
Tests jusqu’au 15/12/2025
🟢 d. Finish On or Before
- Doit finir avant une date
Exemple :
Clos couvert avant le 01/11/2025
Hard vs Soft Constraints : différences clés
| Critère | Contraintes fortes | Contraintes souples |
|---|---|---|
| Logique CPM | Ignorée | Respectée |
| Flexibilité | Faible | Élevée |
| Risque | Élevé (negative float) | Faible |
| Usage | Obligations contractuelles strictes | Pilotage & planification |
| Exemples | Mandatory Start/Finish, Start On | SOOA, FOOB |
Exemple : Negative Float causé par une contrainte
Scénario :
- Activité : Final Testing
- Contrainte : Mandatory Finish – 30/10/2025
- Calcul logique : fin au 05/11/2025
Résultat :
- Float = -5 jours
👉 Indique un conflit planning / contrainte
Bonnes pratiques (niveau expert – Delay & Risk Strategy)
✅ 1. Utiliser les contraintes avec parcimonie
Trop de contraintes = planning artificiel
✅ 2. Privilégier les contraintes souples
Maintiennent l’intégrité du modèle CPM
✅ 3. Surveiller le negative float
👉 Indicateur critique de dérive
✅ 4. Justifier chaque contrainte
- Contractuelle
- Réglementaire
- Technique
👉 Indispensable en contexte claims
✅ 5. Tester le planning sans contraintes
👉 Vérifier la robustesse de la logique réseau
Conclusion
Les contraintes dans Primavera P6 sont des outils puissants de pilotage :
- Bien utilisées → planning réaliste et maîtrisé
- Mal utilisées → planning biaisé et juridiquement fragile
👉 Règle d’or :
La logique réseau doit primer — les contraintes ne doivent jamais la remplacer
Dans vos projets, utilisez-vous plutôt des contraintes hard ou soft ?
Avez-vous déjà géré un planning avec du negative float important ?