Gantt et Jira : garder le plan et l’exécution alignés

Dans beaucoup d’entreprises, le projet existe deux fois. Le plan, avec ses phases, ses dépendances et ses dates de livraison, se trouve dans un diagramme de Gantt préparé par le chef de projet. Le travail, avec ses tickets, ses sprints et ses affectations, se trouve dans Jira. Tant que les deux restent séparés, quelqu’un doit reporter l’avancement à la main de l’un à l’autre, et les dates du plan vieillissent vite.

Cet article explique pourquoi Jira seul ne suffit pas pour le planning, comment fonctionne la synchronisation bidirectionnelle entre Planitude et Jira Cloud et quelles limites connaître avant de l’activer.

Deux outils, deux questions différentes#

Jira répond à la question sur quoi l’équipe travaille-t-elle en ce moment ? Les backlogs, les tableaux et les sprints sont faits pour cela. Un planning répond à une autre question : quand aurons-nous fini, et quelles tâches ne peuvent pas se permettre de retard ?

Pour répondre à la seconde, il faut des durées, des dépendances avec avances et retards, des calendriers avec jours fériés, des contraintes et un calcul qui répercute chaque changement sur les tâches suivantes. Si l’installation du nouveau serveur prend trois jours de retard, les tests, la formation et la mise en service doivent se décaler d’eux-mêmes, et le chef de projet doit savoir tout de suite si la date de livraison tient encore.

Ce qui manque à Jira pour le planning#

Jira ne manque pas d’outils de planification. La chronologie affiche les dépendances entre éléments liés avec le type de lien « Blocks » et, lorsque les dates de deux éléments liés se chevauchent, la ligne de dépendance devient rouge pour signaler un retard possible^[1]. D’après la page des tarifs d’Atlassian, les dépendances se gèrent au sein d’un même projet avec les offres Free et Standard, et entre projets avec Premium^[2].

Un avertissement n’est cependant pas un recalcul : les dates restent celles qui ont été saisies, et le chemin critique ne figure pas parmi les fonctions décrites. Résultat : le plan vit ailleurs, dans un fichier ou un autre outil, et se désynchronise. Pour une comparaison complète des deux outils, consultez l’article Planitude vs Jira.

Comment fonctionne la synchronisation bidirectionnelle#

L’intégration relie un projet Planitude à un projet Jira Cloud. La connexion utilise OAuth 2.0 d’Atlassian : Planitude ne connaît pas votre mot de passe, conserve les jetons chiffrés et les renouvelle avec les jetons d’actualisation tournants d’Atlassian, qui expirent après 90 jours d’inactivité^[3].

À la première connexion, vous choisissez l’alignement initial :

1. Envoyer le plan vers Jira : un ticket est créé pour chaque tâche et un lien « Blocks » pour chaque dépendance ;
2. Importer depuis Jira : chaque ticket existant devient une tâche en bas du plan, avec date de début, durée, avancement et responsable ;
3. Les deux : d’abord l’import, puis l’envoi des tâches qui ne sont pas encore dans Jira.

Ensuite, les changements circulent dans les deux sens. De Planitude vers Jira, chaque modification du plan est détectée et envoyée en quelques secondes, quelle que soit son origine : grille, Gantt, import ou assistant IA. De Jira vers Planitude, les changements arrivent par les webhooks enregistrés par l’intégration, que Planitude renouvelle avant l’expiration de 30 jours prévue par Atlassian^[4], et une vérification toutes les cinq minutes rattrape les événements manqués.

Les tâches récapitulatives peuvent rester uniquement dans Planitude ou devenir des Epics, avec les tâches qu’elles contiennent comme tickets enfants.

Qui décide de quoi : la règle des champs#

Une synchronisation fiable a besoin d’une règle simple pour chaque champ. Dans Planitude, la voici :

La logique suit le travail réel : le plan décide quand, l’équipe décide où en est une tâche et qui s’en charge. Le statut est traduit en pourcentage par une table modifiable : par catégorie, à faire vaut 0 %, en cours 50 %, terminé 100 %. Si une tâche est déjà à 30 % et que son ticket passe « En cours », l’avancement n’est pas écrasé par un 50 % fixe.

Les personnes sont associées automatiquement par e-mail quand l’utilisateur Jira le rend visible ; sinon, l’association se choisit à la main sur la page de l’intégration.

Dépendances, conflits et suppressions#

Dépendances. Les liens fin-début deviennent des liens « Blocks » : le prédécesseur bloque le successeur. Les liens début-début, fin-fin et début-fin n’ont pas d’équivalent dans Jira et restent uniquement dans Planitude. Les liens « Blocks » ajoutés à la main dans Jira ne sont ni importés ni supprimés.

Dates modifiées dans Jira. Comme les dates sont calculées par le plan, une date modifiée dans Jira est ramenée à la valeur du plan et la modification refusée apparaît dans le journal de l’intégration. Pour déplacer une tâche, on la déplace dans le plan : le moteur recalcule aussi toutes celles qui en dépendent.

Conflits. Pour chaque champ, Planitude compare trois valeurs : la dernière valeur convenue, la valeur actuelle dans le plan et la valeur actuelle dans Jira. Si un seul côté a changé, la modification passe à l’autre. Si les deux ont changé avec des valeurs différentes, c’est le côté qui décide du champ qui l’emporte, et le conflit est consigné avec les deux valeurs. La règle ne dépend que des données, pas des horloges des deux serveurs.

Suppressions. Aucun des deux côtés ne supprime quoi que ce soit chez l’autre. Une tâche supprimée dans Planitude laisse le ticket dans Jira avec l’étiquette planitude-unlinked ; un ticket supprimé dans Jira laisse la tâche dans le plan, et la page propose deux actions : le recréer dans Jira ou ne plus le synchroniser.

Connecter Jira pas à pas#

1. Ouvrez le projet dans Planitude et choisissez ⋯ › Intégrations › Jira.
2. Cliquez sur Connecter Jira et accordez l’accès sur l’écran de consentement d’Atlassian.
3. Si votre compte voit plusieurs sites, choisissez le bon, puis le projet Jira.
4. Vérifiez les options : type de ticket par défaut, tâches récapitulatives en Epics ou non, champ de date de début, étiquette des tickets créés par Planitude.
5. Choisissez l’alignement initial : envoi, import ou les deux.
6. Vérifiez la section Personnes et complétez les associations qui n’ont pas été trouvées par e-mail.

Planitude écrit dans Jira sous l’identité de la personne qui a connecté le projet ; celle-ci a besoin dans Jira des autorisations pour parcourir le projet, créer, modifier, attribuer et lier des tickets, et exécuter des transitions. Le propriétaire et les éditeurs du projet Planitude peuvent configurer l’intégration ; les personnes en lecture seule n’en voient que l’état. Les autres intégrations disponibles sont décrites sur la page Intégrations.

Limites connues#

• Jira Cloud uniquement : Jira Data Center et Server ne sont pas pris en charge.
• Dépendances fin-début uniquement ; un seul responsable par ticket (la personne qui a le plus d’unités sur la tâche).
• Dates au jour près : les heures restent dans Planitude.
• Atlassian autorise 5 webhooks par utilisateur et par site pour une application OAuth^[4] : au-delà du cinquième projet connecté par la même personne sur le même site, les changements venant de Jira arrivent par la vérification toutes les cinq minutes.
• Avec l’option « tâches feuilles uniquement », une tâche qui devient récapitulative est traitée comme retirée et son ticket reçoit l’étiquette planitude-unlinked.

Questions fréquentes#