Le format XER est un export texte tabulé structuré en tables (PROJECT, PROJWBS, TASK, TASKPRED, CALENDAR, RSRC, ACTVCODE, TASKACTV, entre autres), chacune préfixée par %T et ses colonnes par %F. Sa simplicité apparente cache une contrainte stricte : chaque ligne fait référence à des identifiants internes (task_id, wbs_id, clndr_id) qui doivent exister ailleurs dans le même fichier. Une seule référence orpheline suffit à faire échouer l'import, parfois avec un message d'erreur peu explicite.

Diagnostiquer avant de corriger

Avant toute correction, on ouvre le XER dans un éditeur de texte capable de gérer de gros fichiers tabulés (jamais Excel en premier passage : il reformate les guillemets et les séparateurs, ce qui aggrave la corruption). On repère la table en cause à partir du message d'erreur P6, puis on isole les lignes concernées grâce à leur identifiant unique.

Les trois causes les plus fréquentes, par ordre de probabilité :

  • WBS orpheline — une ligne TASK référence un wbs_id absent de la table PROJWBS, généralement après une suppression manuelle de nœud WBS dans un export partiel.
  • Calendrier manquant — un clndr_id référencé par une activité n'existe pas dans la table CALENDAR du fichier, fréquent lors de la fusion de plannings venant d'environnements P6 différents où les identifiants de calendrier ne coïncident pas.
  • Codes d'activité non mappés — la table ACTVCODE définit des valeurs qui n'existent pas dans l'environnement cible, ou dont l'actv_code_type_id a changé de sens d'un projet à l'autre.

Restructurer une WBS sans casser les relations

La tentation, face à une WBS désorganisée, est de la reconstruire directement dans P6 par glisser-déposer. Sur un planning de plusieurs centaines d'activités, cette approche est risquée : P6 recalcule les identifiants de hiérarchie à la volée et peut silencieusement rompre des liens de prédécesseur/successeur transverses entre lots.

La méthode plus sûre consiste à retravailler la hiérarchie directement dans la table PROJWBS du XER — en réassignant les parent_wbs_id de façon cohérente — puis à réimporter, plutôt que de manipuler l'arborescence dans l'interface graphique sur un fichier déjà fragile.

Calendriers : la source silencieuse d'erreurs de dates

Un calendrier mal assigné ne provoque pas toujours une erreur d'import — c'est le pire des cas, car le planning s'ouvre normalement mais les dates calculées sont fausses. Un jour férié manquant, un calendrier 5 jours appliqué à une activité qui devrait suivre un calendrier 7 jours (montage d'équipement continu, par exemple), et le chemin critique entier devient trompeur sans qu'aucune alerte ne se déclenche.

La vérification systématique consiste à comparer, activité par activité sur les lots critiques, le clndr_id assigné avec le calendrier réellement attendu selon la nature du travail — un contrôle simple, mais trop souvent ignoré lors des reprises de planning sous pression de délai.

Codes d'activités : la dette technique invisible

Les codes d'activité (Activity Codes) sont souvent le premier élément sacrifié lors d'une migration ou d'une fusion de fichiers XER, car leur absence ne bloque pas l'import. Le résultat : un planning techniquement fonctionnel mais dont les filtres, regroupements et rapports historiques ne fonctionnent plus, obligeant à recréer manuellement une structure de reporting qui existait déjà.

Un fichier XER propre n'est pas un fichier qui s'importe sans erreur — c'est un fichier dont chaque référence interne reste cohérente après plusieurs cycles d'export/import. C'est précisément ce niveau de rigueur qu'apporte un consultant Primavera P6 expérimenté sur une reprise de planning.