Vous gérez plusieurs équipes qui travaillent sur les mêmes livrables ? Vous avez sûrement rêvé d’afficher une tâche unique dans deux plans Microsoft Planner pour éviter les doublons et garder tout le monde synchronisé. Voici comment comprendre les limites du produit actuel et les stratégies éprouvées pour contourner cette contrainte.
Pourquoi Planner n’affiche pas une tâche dans plusieurs plans ?
Planner stocke chaque tâche dans un conteneur logique appelé plan. Au niveau de l’API Graph, une tâche est liée à un unique planId
; aucune propriété ne permet d’attribuer plusieurs plans à la même carte. Cette conception vise la simplicité, mais elle empêche la mutualisation directe d’une tâche entre deux plans. Du point de vue de l’interface comme de l’API, « une tâche = un plan ».
Copier n’est pas synchroniser
L’interface permet de copier une tâche vers un autre plan. Attention : les deux objets deviennent autonomes ; changer la date d’échéance dans le plan A ne mettra pas à jour la copie du plan B. Vous devrez gérer manuellement les évolutions ou mettre en place une automatisation.
Action | Résultat | Synchronisation future |
---|---|---|
Copie manuelle | Deux tâches indépendantes | Non |
Copie via Power Automate | Deux tâches créées puis suivies | Partielle (selon le flux) |
Externalisation du suivi (To Do, Lists) | Un référentiel unique + liens | Oui (vue unifiée externe) |
Créer une synchronisation avec Power Automate
Power Automate peut répliquer (et mettre à jour) les données d’une tâche d’un plan vers l’autre :
- Déclencheur : « Lorsqu’une tâche est créée ou modifiée » dans le plan A.
- Condition : Vérifier qu’elle porte une étiquette dédiée (ex. :
SYNCHRO_B
). - Action : Utiliser Create a task dans le plan B si la correspondance n’existe pas, sinon Update task.
- Stockage d’état : Enregistrer l’ID de la tâche miroir dans un champ personnalisé (description, commentaire ou propriété étendue via l’API) pour éviter les doublons bouclés.
Réalisez le même flux en sens inverse (plan B → plan A) ou centralisez la logique dans un unique flux maître. Gardez en tête :
- Latence : quelques secondes à plusieurs minutes selon la charge.
- Conflits : deux mises à jour simultanées peuvent lancer des boucles. Gérez un horodatage (dernier auteur-gagnant) et limitez les propriétés synchronisées (titre, échéance, état).
- Quota : chaque action API consomme des appels ; évitez de déclencher sur toutes les modifications superflues (check‑list, commentaires).
Exemple de modèle JSON (simplifié)
{
"trigger": "Planner.TaskUpdated",
"actions": [
{
"name": "GetMirrorTask",
"condition": "Task.Details.Contains('[MirrorID:')",
"success": "UpdateMirror",
"failure": "CreateMirror"
},
{
"name": "UpdateMirror",
"operation": "Planner.UpdateTask",
"fields": ["title","dueDateTime","percentComplete"]
},
{
"name": "CreateMirror",
"operation": "Planner.CreateTask",
"destinationPlanId": "PLAN_B_ID",
"metadata": "[MirrorID:${trigger.TaskId}]"
}
]
}
Optimiser sans dédoubler : étiquettes, seaux et filtres
Avant de coder une usine à gaz, demandez‑vous si vos équipes peuvent travailler dans un même plan :
- Étiquettes pour distinguer les contextes (Marketing, Dev, Support).
- Seaux pour découper les flux de travail (Backlog, En cours, Relecture).
- Filtres pour chaque partenaire : chacun peut enregistrer ses vues favorites.
Avantages : temps réel, pas de scripts ni de maintenance, toutes les mises à jour dans une seule carte.
Utiliser Microsoft To Do ou Lists comme surface de référence
Autre tactique : conserver la source dans Planner, mais créer un renvoi dans un outil plus transversal :
- To Do importe automatiquement vos affectations Planner ; chaque collaborateur voit les mêmes tâches dans Tâches assignées à vous.
- Lists sert de tableau de bord projet : référencez la tâche (URL), ajoutez des métadonnées communes (priorité globale, sponsor) puis affichez la liste à plusieurs équipes ou sites SharePoint.
Passer à Project for the Web pour un besoin multi‑projets avancé
Si vous manipulez des dizaines de plans imbriqués, Project for the Web (ou un PPM tiers) offre :
- Un Project ID unique avec plusieurs boards/timelines.
- La notion de dépendances entre tâches de projets différents.
- Des vues Roadmap consolidées et des rapports Power BI prêts à l’emploi.
C’est payant, mais cela évite de transformer Planner (outil d’équipe agile) en gestion de portefeuille.
Graph API : état des lieux technique
Pour les développeurs, l’appel GET /planner/tasks/{id}
renvoie un objet où :
planId
(string) : identifiant unique du plan parent.bucketId
(string) : colonne du plan.conversationThreadId
,details
…
Aucune collection planIds[]
n’existe. Publier une suggestion sur le Feedback Portal reste la seule voie pour voir évoluer le modèle.
Bonnes pratiques pour limiter la confusion
- Indiquer la source : dans la description, ajoutez « Plan d’origine : Marketing Roadmap » ou un préfixe dans le titre (
[MKT]
). - Lier les copies : collez l’URL de la carte sœur dans le champ Références.
- Standardiser les champs : mêmes étiquettes, même ordre de check‑list, même définition de statuts.
- Former les utilisateurs : expliquez qu’une coche « Terminé » dans le plan A ne propage pas automatiquement l’état dans le plan B.
- Documenter le flux : stockez le schéma Power Automate dans un wiki d’équipe pour qu’il survive aux départs.
Étude de cas : synchronisation “Projet transversal”
Une entreprise de services numériques devait piloter un lot commun à trois équipes (développement, UX, sécurité). Ils ont choisi :
- Un plan maître « Projet Transversal » : backlog central, rôles, échéances.
- Trois plans satellites (« Dev Backlog », « UX », « SecOps ») pour les activités quotidiennes.
- Un flux Power Automate : toute tâche maîtresse porte une étiquette
#Mirror
. À la création, le flux génère une copie adaptée (champs pertinents) et pousse l’URL de la source dans la description. - Des règles de gouvernance : seul le PM modifie la date d’échéance, les équipes satellites mettent leur pourcentage d’avancement ; une revue hebdo synchronise les écarts.
Résultat : visibilité consolidée côté PMO, autonomie côté équipe, moins de doublons.
FAQ
Peut‑on “partager” une tâche via un lien ?
Le lien d’une tâche est un simple hyperlien ; il ouvre la carte dans son plan d’origine. Aucune duplication dynamique n’est créée.
Le champ Assignments permet‑il d’assigner la même tâche à plusieurs plans ?
Non. Il ne gère que les utilisateurs ; il ne change pas la relation plan‑tâche.
Les regroupements “Étiquettes” peuvent‑ils être synchronisés ?
Elles sont locales au plan. Un script ou manuel est nécessaire pour harmoniser la couleur/nom entre plusieurs plans.
Quid des connecteurs tiers ?
Des outils comme Zapier ou Make répliquent la logique de Power Automate ; la contrainte planId demeure.
Conclusion
Microsoft Planner ne propose toujours pas d’association native d’une tâche à plusieurs plans. Les solutions de contournement s’articulent donc autour de trois axes :
- Organisationnelle : regrouper ou baliser les activités dans un seul plan.
- Automatisation contrôlée : copier et maintenir la synchronisation via Power Automate, en acceptant un léger délai et un risque de conflit.
- Montée en gamme : basculer vers Project for the Web ou un PPM tiers si la complexité l’exige.
En attendant une évolution de l’API, documentez vos processus, formez vos équipes et votez sur le Feedback Portal pour influencer la feuille de route.