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èreContraintes fortesContraintes souples
Logique CPMIgnoréeRespectée
FlexibilitéFaibleÉlevée
RisqueÉlevé (negative float)Faible
UsageObligations contractuelles strictesPilotage & planification
ExemplesMandatory Start/Finish, Start OnSOOA, 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 ?

 
 

Vous avez plus de questions?

Nos derniers articles