Arbitrer le portefeuille
Fermer un projet libère-t-il vraiment ses réservations futures ?
Pour qui : Le projet est clos dans le tableau mais ses allocations et automatisations continuent de consommer la capacité.
Recherche documentaire le 8 novembre 2026 ; aucune application testée.
Notre avis
Vérifier la clôture sur tâches, réservations, règles et droits résiduels avant de déclarer la capacité libérée.
Dans l’ordre
- Clore le projet et libérer ses effets sont deux contrôles
- Deux réservations, une récurrence et un invité
- Clore un projet témoin puis vérifier les réservations, la prochaine occurrence récurrente et le droit de l’invité.
Pourquoi
- Le statut clos peut laisser des allocations et des règles actives ; vérifier leurs effets évite une capacité faussement libérée.
Ce qui change le choix
Une réserve après livraison peut être légitime pour la recette ; la conserver sous une raison et une échéance propres.
Clore le projet et libérer ses effets sont deux contrôles
Nous ne déclarerions pas la capacité disponible sur le seul changement d’un statut projet. Les réservations peuvent exister dans un autre module, une règle peut continuer à créer des tâches et un invité peut conserver un accès. La clôture doit préciser le sort de chaque élément encore actif.
Commencez par distinguer ce qui doit réellement survivre : réserve de recette, historique, pièce de référence ou obligation de consultation. Supprimer tout serait aussi faux que tout laisser tourner. Chaque exception doit avoir une raison et un responsable, avec une fin lorsque c’est pertinent.
Deux réservations, une récurrence et un invité
Clore un projet fictif contenant ces quatre éléments donne un test court. Faites afficher la capacité future avant et après, puis contrôler la prochaine génération de tâche et l’accès externe. Listez explicitement les objets conservés et ceux qui doivent être retirés par une autre personne.
Nous choisirions le fonctionnement dont l’équipe peut répéter la clôture sans inventaire interminable. Si la recette demande encore du travail, gardez sa réserve sous une étape nommée. Le projet n’est pas obligé de rester artificiellement actif pour porter un reliquat clairement identifié.
Asana documente la suppression et le déplacement d’allocations, y compris par actions de masse.
Asana décrit la création de l’occurrence suivante à l’achèvement d’une tâche récurrente ; les commentaires ne sont pas copiés.
Limites
Analyse documentaire et méthode éditoriale. Les protocoles sont proposés, pas exécutés sur les logiciels. Les exemples chiffrés sont fictifs ; les fonctions dépendent du produit, du forfait, des droits et de la configuration.
Prochaine action
Clore un projet témoin puis vérifier les réservations, la prochaine occurrence récurrente et le droit de l’invité.
Preuves et sources
Ce qui relève d’un fait lu, d’une déclaration, de notre calcul, de notre méthode ou de notre avis. Notre méthode
Déclaration de l’éditeur. Asana documente la suppression et le déplacement d’allocations, y compris par actions de masse.
Relevé du 8 novembre 2026. Édition ou périmètre : Documentation publique du 8 novembre 2026 ; produit et périmètre nommés dans le constat.
- Asana : https://help.asana.com/s/article/capacity-planning Lu le 8 novembre 2026. Documentation officielle lue ; déclaration du fournisseur, aucun essai..
Déclaration de l’éditeur. Asana décrit la création de l’occurrence suivante à l’achèvement d’une tâche récurrente ; les commentaires ne sont pas copiés.
Relevé du 8 novembre 2026. Édition ou périmètre : Documentation publique du 8 novembre 2026 ; produit et périmètre nommés dans le constat.
- Asana : https://help.asana.com/s/article/scheduling-tasks-using-start-dates-due-dates-and-times Lu le 8 novembre 2026. Documentation officielle lue ; déclaration du fournisseur, aucun essai..
Notre méthode. Clore un projet avec deux réservations futures, une tâche récurrente et un invité ; contrôler ce qui reste actif et qui le supprime.
Daté du 8 novembre 2026. Édition ou périmètre : Protocole éditorial proposé ; aucune observation de compte client.