Primavera P6 distingue trois familles de calendriers, du plus large au plus précis. Comprendre cette hiérarchie évite bien des surprises sur les dates.

• Calendriers globaux (global) : partagés par toute la base de données, donc disponibles pour tous les projets. On y trouve les calendriers standards de l'entreprise (5 jours, 7 jours, postés…). Ils sont gérés par l'administration et servent de socle commun.
• Calendriers projet (project) : propres à un projet donné. On les crée quand un projet a des règles spécifiques (fériés régionaux particuliers, arrêt estival du chantier, semaine de travail aménagée) qui n'ont pas vocation à exister ailleurs.
• Calendriers ressource (resource) : attachés à une ressource précise (une équipe, un engin) qui ne travaille pas selon le rythme général — par exemple une grue louée disponible seulement certains jours, ou une équipe en horaires décalés.

On accède à la gestion des calendriers via le menu Enterprise > Calendars, qui permet de basculer entre globaux, projet et ressource. La règle de bon sens : utiliser un calendrier global standard tant que possible, et ne créer un calendrier projet ou ressource que lorsqu'une vraie spécificité l'exige.

Le calendrier n'est pas un détail de paramétrage : c'est lui qui traduit une durée en dates réelles. Quand vous saisissez « 10 jours » sur une activité, P6 ne sait pas encore quand elle finira tant qu'il ne connaît pas le calendrier : combien de jours par semaine, quels fériés, quelles exceptions.

L'effet est cumulatif. Sur un projet de plusieurs centaines de jours, une différence de rythme hebdomadaire ou quelques jours fériés oubliés se répercutent sur toutes les dates en aval. Une date de fin de projet peut glisser de plusieurs semaines uniquement à cause d'un calendrier mal réglé, sans qu'aucune durée n'ait été modifiée.

Le calendrier détermine aussi le chemin critique (vu au module 2) : deux activités de même durée mais sur des calendriers différents n'occupent pas la même place dans le temps, ce qui change quelles activités deviennent critiques.

Concrètement, paramétrer un calendrier revient à décrire le temps de travail réel. Trois éléments principaux le composent :

• La semaine de travail : quels jours sont travaillés (typiquement lundi à vendredi), et le cas échéant le nombre d'heures par jour si vous travaillez en durées horaires plutôt qu'en jours.
• Les jours fériés et exceptions « chômées » : les jours non travaillés à inscrire explicitement (fériés nationaux, ponts, fermeture annuelle). Un férié non saisi sera traité comme un jour travaillé — et toutes les dates en seront faussées.
• Les exceptions « travaillées » : à l'inverse, un jour normalement chômé que l'on décide de travailler (un samedi de rattrapage, par exemple) doit être déclaré comme exception travaillée.

Ces éléments se gèrent dans l'éditeur de calendrier accessible depuis Enterprise > Calendars, en ouvrant le calendrier concerné. On y peint, jour par jour ou semaine type, le temps travaillé et non travaillé. Un calendrier soigné en amont, c'est des dates fiables pour tout le projet.

Une fois les calendriers définis, encore faut-il qu'ils soient appliqués aux bons éléments. Deux niveaux d'affectation comptent.

Le calendrier par défaut du projet : dans les paramètres du projet (vue Enterprise > Projects, puis l'onglet des réglages par défaut des activités), on désigne le calendrier qui sera attribué automatiquement à toute nouvelle activité. Régler ce défaut correctement dès le départ évite d'avoir à corriger des dizaines d'activités plus tard.

Le calendrier de chaque activité : chaque activité porte un champ « calendrier » (visible et modifiable dans la vue des activités, colonne ou onglet dédié). On peut donc surcharger le défaut pour une activité particulière qui suit un rythme différent — par exemple des essais réalisés en continu sur un projet par ailleurs en 5 jours.

La discipline à tenir : vérifier le calendrier par défaut avant de saisir la moindre activité, puis ne surcharger au cas par cas que les rares activités qui le justifient. Multiplier les exceptions au niveau activité rend le planning difficile à auditer.

Au-delà du calendrier, quelques réglages du projet conditionnent le comportement de tout le planning. Les libellés exacts varient selon la version, mais les notions sont stables. On les trouve dans les paramètres du projet, dans les onglets de réglages par défaut et d'options de planification.

• L'unité de durée par défaut : décider si l'on raisonne en jours ou en heures, et s'y tenir. Mélanger des unités est une source classique d'incohérences.
• Le type de pourcentage d'avancement par défaut : la manière dont P6 mesure l'avancement d'une activité (par exemple selon la durée écoulée, ou selon une saisie manuelle). Le choix par défaut s'applique aux nouvelles activités ; le fixer évite des incohérences au moment du suivi.
• Les options de planification (scheduling) : les règles que P6 applique quand il (re)calcule le planning — notamment le traitement des relations et des contraintes. On les laisse souvent sur les réglages standards au début, mais il faut savoir qu'elles existent.
• La data date initiale : la date d'arrêté de départ du planning, généralement calée sur la date de début prévue du projet. C'est le point zéro à partir duquel on fera avancer le suivi.

Régler ces paramètres avant de saisir les activités, c'est garantir que chaque tâche créée hérite des bons comportements. Les corriger après coup oblige souvent à reprendre activité par activité.

Trois pièges reviennent sans cesse chez les débutants. Les connaître, c'est déjà les éviter :