Les autorisations sur Asana : Le guide complet (2026)

Asana est un outil incroyablement puissant, mais ses droits et autorisations peuvent devenir très granulaires. Comprendre l’impact exact de chaque paramètre peut s’avérer complexe.

Heureusement, notre brillante collègue Thaïssa a passé beaucoup de temps à étudier ces configurations complexes pour que vous n’ayez pas à le faire !

Prenez un café, et plongeons dans le vif du sujet. 🙂

Pourquoi les droits et autorisations sur Asana sont cruciaux

Lorsque vous gérez une entreprise, la sécurité des données et la clarté des flux de travail sont primordiales. Vous voulez que votre équipe dispose exactement de l’accès nécessaire pour accomplir son travail, ni plus, ni moins.

Si les autorisations sont trop souples, des tâches importantes pourraient être supprimées par accident. Si elles sont trop strictes, votre équipe se heurte à des obstacles et la productivité chute.

Asana étant très détaillé, comprendre la limite exacte entre un « Lecteur » et un « Éditeur » peut être délicat. Thaïssa a cartographié visuellement chaque scénario pour mettre fin aux incertitudes.

Les 3 domaines principaux étudiés

Pour rendre ce guide facile à consulter, Thaïssa a divisé son enquête en trois domaines spécifiques :

1. Autorisations des collaborateurs sur les tâches
2. Autorisations des membres du projet sur les tâches
3. Autorisations sur les projets dans leur ensemble

1️⃣ Autorisations des collaborateurs sur les tâches

Tout d’abord, nous avons examiné les « Collaborateurs ». Il s’agit de personnes invitées à consulter ou à travailler sur une tâche spécifique, mais qui ne sont pas membres à part entière du projet.

0. Le paramètre

1. Collaborateurs non attribués

S’ils ne sont pas désignés comme responsables de la tâche, les Lecteurs et Commentateurs sont fortement restreints (représentés par un mur de croix rouges dans notre matrice visuelle). Ils ne peuvent pas modifier les dates d’échéance, modifier les descriptions ou modifier les champs personnalisés.

Exemple concret : Le Commentateur non attribué

Disons que vous invitez un collègue d’un autre département pour réviser une tâche. Vous avez besoin de son avis, mais vous ne voulez surtout pas qu’il change accidentellement vos dates d’échéance ou qu’il modifie vos champs personnalisés.

En lui donnant le rôle de Commentateur (en tant que collaborateur non attribué), sa vue correspond exactement à la capture d’écran ci-dessous. Les détails principaux de la tâche sont verrouillés et non cliquables. Cependant, la zone de commentaire en bas reste grande ouverte. Il peut laisser ses réflexions en toute sécurité sans altérer la structure de votre travail !

2. Collaborateurs attribués

Une fois qu’ils sont désignés comme Responsables (attribués), leurs droits changent légèrement. Comme le montre la matrice, ils obtiennent des coches vertes pour des actions comme modifier le responsable et les dates d’échéance, ce qui leur donne juste assez d’accès pour accomplir leur tâche spécifique sans compromettre toute la structure de la tâche.

Attention toutefois à la « ligne violette » : cela signifie que les collaborateurs attribués sont techniquement capables de supprimer la valeur d’un champ personnalisé, ce qui peut représenter un risque. Mais l’événement (la suppression de la valeur) sera enregistré dans l’historique et visible dans les commentaires (vue « Toute l’activité »).

Exemple concret : L’Éditeur attribué

Imaginons que vous attribuiez une tâche spécifique à un freelance de confiance. Vous voulez qu’il ait la liberté de gérer son travail, vous lui donnez donc le rôle d’Éditeur en tant que collaborateur attribué.

Comme vous pouvez le voir ci-dessous, cela lui donne beaucoup de flexibilité. L’encadré vert souligne qu’il peut ajouter des sous-tâches, réécrire la description ou même effectuer un multi-hébergement de la tâche dans un autre projet.

Mais notez l’encadré rouge ! Même avec un accès Éditeur, un collaborateur de tâche ne peut pas modifier les valeurs des champs personnalisés (comme le suivi du « temps réel passé »). C’est une fonction de sécurité brillante, qui garantit que vos données de rapport et vos indicateurs de projet restent intacts, même lorsque vous confiez le gros du travail à quelqu’un d’autre. Si vous voulez que cet utilisateur modifie les champs, invitez-le directement dans le projet.

2️⃣ Autorisations des membres du projet sur les tâches

Ensuite, nous avons exploré les droits des « Membres du projet ». Ce sont les utilisateurs invités à l’ensemble de l’espace projet. Leurs droits de base diffèrent de ceux d’un simple collaborateur de tâche et varient selon qu’ils sont responsables de la tâche ou non.

0. The setting

1. Membres du projet non attribués

Lorsque les membres du projet ne sont pas responsables d’une tâche spécifique, leur accès est très clair. Comme vous pouvez le voir dans notre étude, les Lecteurs et Commentateurs sont strictement limités, tandis que ceux ayant un accès Éditeur ou Administrateur bénéficient d’un océan de coches vertes. Ils peuvent multi-héberger des tâches, ajouter des sous-tâches et modifier les descriptions librement.

Exemple concret : L’Administrateur de projet non attribué

Imaginons que vous soyez un manager supervisant une campagne importante. Vous n’êtes pas responsable de chaque tâche individuelle, mais vous devez occasionnellement intervenir pour mettre à jour une tâche, corriger un champ personnalisé ou ajuster un calendrier.

Ici, vous pouvez voir un membre avec des autorisations d’Administrateur de projet consultant une tâche dont il n’est pas responsable. Comme il détient ce rôle de haut niveau, toute la tâche lui est accessible. Il peut facilement modifier les champs personnalisés (comme le menu déroulant coloré affiché) et faire des mises à jour à la volée sans avoir à s’attribuer la tâche au préalable.

2. Membres du projet attribués

Dès qu’un membre du projet est désigné comme responsable d’une tâche, les possibilités s’ouvrent. Même un Lecteur gagne des capacités comme modifier les dates d’échéance et terminer les tâches. Cependant, dans notre matrice, vous remarquerez une coche violette sous la capacité du Lecteur à ajouter un commentaire.

Que signifie la coche violette ? Cela signifie « Oui, il peut le faire, mais nous estimons que cela ne devrait pas être autorisé ». C’est une particularité du système dont il faut se méfier si vous essayez d’imposer un accès strict en lecture seule !

Exemple concret : Le Lecteur attribué

Disons que vous invitez une partie prenante à votre projet en tant que Lecteur. Vous voulez simplement qu’elle puisse observer la progression. Mais ensuite, vous lui attribuez une tâche spécifique pour qu’elle reçoive une notification.

Regardez ce qui se passe : parce qu’elle est maintenant responsable, ses autorisations s’étendent temporairement. Elle peut soudainement modifier les valeurs des champs personnalisés et laisser des commentaires. Si vous voulez vraiment un accès strict en lecture seule, faites très attention à qui vous placez en tant que Responsable !

3️⃣ Autorisations au niveau du Projet

Enfin, nous avons zoomé au niveau macro : le Projet lui-même. C’est ici que l’on détermine qui peut modifier la structure même de votre espace de travail.

0. Le Paramètre

1. La Matrice

Vues et flux de travail (champs, formulaires, règles…) : Seuls les Éditeurs et les Administrateurs peuvent enregistrer de nouvelles vues de projet, partager des projets ou personnaliser les champs, les règles et les formulaires. Dans notre matrice de projet, vous verrez des coches jaunes pour les Éditeurs ici.

Que signifie la coche jaune ? Cela signifie « Oui, mais seulement si les éditeurs sont inclus dans les autorisations du projet ».

Vous devez autoriser les éditeurs à gérer ces paramètres ; sinon, ils pourraient être bloqués ! Notez que par défaut pour un nouveau projet, les autorisations sont généralement définies sur « Administrateurs et éditeurs ».

Exemple concret : L’Éditeur de projet (et les points d’exclamation !)

Imaginez que vous vouliez permettre à votre chef d’équipe de créer des flux de travail personnalisés, vous lui donnez donc le rôle d’Éditeur pour tout le projet. Vous pourriez supposer qu’il peut immédiatement créer des champs personnalisés ou enregistrer des vues d’onglet pour l’équipe.

Pas tout à fait ! Regardez de près l’encadré vert : il peut déplacer des tâches, définir des statuts et modifier des champs existants. Mais remarquez tous ces points d’exclamation rouges (❗️) ? Ils représentent les « coches jaunes » de notre matrice !

Ce symbole signifie qu’il peut personnaliser les champs, les règles et les vues uniquement si un Administrateur est allé dans les paramètres du projet pour donner ce droit aux Éditeurs. Si ce bouton n’est pas activé, ces fonctionnalités restent verrouillées. Et comme le montre l’encadré rouge en bas, quoi qu’il arrive, un Éditeur ne pourra jamais modifier les paramètres d’accès ni ajouter un nouvel Administrateur de projet.

🚀 Prêt à maîtriser votre espace de travail ?

Naviguer dans les paramètres granulaires d’Asana ne doit pas être un cauchemar. Grâce au travail acharné de Thaïssa, vous disposez désormais d’une feuille de route claire sur ce que chaque rôle peut et ne peut pas faire.

Mais vous n’avez pas à mettre tout cela en place seul. Si vous voulez vous assurer que votre espace de travail est sécurisé, optimisé et prêt pour la croissance, nous sommes là pour vous aider.

Souhaitez-vous que nous vous aidions à auditer votre configuration Asana actuelle ? Contactez i.DO dès aujourd’hui et laissez notre équipe d’experts concevoir le flux de travail parfait et fluide pour votre entreprise !