« Primavera P6 » recouvre en réalité deux produits distincts : P6 Professional, client lourd installé localement et connecté à une base Oracle ou SQL Server, et P6 EPPM (Enterprise Project Portfolio Management), l'interface web déployée on-premise ou en cloud (Oracle Primavera Cloud pour la version SaaS). Les deux partagent le même moteur de calcul de planning, mais pas exactement le même modèle de données — une nuance qui devient critique dès qu'un planning circule entre deux environnements.

Le format XER n'est pas figé dans le temps

Le format d'export XER porte un numéro de version (visible en première ligne du fichier, ex. ERMHDR 19.12) correspondant à la version de P6 qui l'a généré. Un fichier exporté depuis une version récente peut échouer à l'import sur une installation plus ancienne si celle-ci ne reconnaît pas certains champs ou tables ajoutés depuis. La règle pratique : toujours vérifier, avant un échange inter-organisations, la version P6 du destinataire et exporter au format de compatibilité le plus bas commun (P6 propose un sélecteur de version XER à l'export).

Ce qui ne survit pas toujours à l'aller-retour

Certains éléments sont particulièrement fragiles lors d'un cycle export/import, surtout entre P6 EPPM cloud et P6 Professional :

  • Courbes de ressources (resource curves) — les profils de distribution non linéaire d'une ressource sur une activité peuvent se réinitialiser en distribution linéaire par défaut si l'environnement cible ne reconnaît pas la courbe personnalisée.
  • Champs personnalisés (UDF) de type "indicateur" ou liste déroulante — leur définition doit exister à l'identique dans les deux environnements ; sinon la valeur est perdue silencieusement, sans message d'erreur.
  • Périodes financières (financial periods) — utilisées pour le stockage de l'avancement historique, elles ne sont pas systématiquement incluses dans un export XER standard et nécessitent une vérification spécifique.
  • Baselines multiples — un projet avec plusieurs baselines associées peut n'en conserver qu'une seule après import selon la configuration cible.

Cloud (Oracle Primavera Cloud) : une divergence plus profonde

Au-delà de P6 EPPM on-premise, Oracle Primavera Cloud (OPC) introduit son propre modèle de données, plus proche d'une gestion de portefeuille que d'un simple planning P6. L'import d'un XER classique y fonctionne, mais certains concepts P6 (calendriers globaux partagés, par exemple) sont réinterprétés selon la logique OPC. Un planning migré vers OPC doit systématiquement être revérifié activité par activité sur son chemin critique avant d'être considéré comme fiable.

La checklist avant toute migration

Avant de migrer un planning entre environnements P6, quatre vérifications systématiques : la version XER cible, l'identité des définitions de champs personnalisés entre les deux bases, la présence des baselines attendues après import, et un contrôle du chemin critique avant/après pour détecter tout recalcul silencieux de date.

Cette vigilance est particulièrement importante pour les organisations opérant entre plusieurs pays où la version et l'hébergement de P6 diffèrent d'un partenaire à l'autre — un cas fréquent sur nos missions entre Europe et Golfe.