Le savoir opérationnel d’une équipe vit dans ses tâches
Dans une entreprise qui pilote son travail dans Asana, une bonne part du savoir opérationnel vit dans des tâches plutôt que dans des documents. Une équipe y écrit comment se déroule une recette, pourquoi une échéance a bougé, ce que le client a répondu au téléphone. Personne ne recopie ensuite ces éléments dans une procédure propre.
Une IA qui n’a pas accès à ces tâches répondra donc à côté sur les questions de terrain. Elle s’appuiera sur ce que l’entreprise a pris le temps d’écrire proprement, c’est-à-dire sur une petite partie de ce qu’elle sait. Le problème est qu’une tâche Asana ne porte aucun droit de lecture qui lui soit propre. Elle emprunte son public à ses projets, et c’est là que tout se décide.
Le public d’une tâche est l’union des membres de tous ses projets
Asana permet à une même tâche de vivre dans plusieurs projets à la fois. C’est une force du produit et une difficulté sérieuse pour un connecteur, parce que la tâche n’a pas de liste de lecteurs et que chacun de ses projets en a une. Là où une carte Trello n’appartient qu’à un seul tableau, une tâche Asana peut relever de trois listes de membres différentes.
Votre Kastel réunit donc les membres de tous les projets où la tâche apparaît, puis vérifie qu’ils appartiennent tous au même service. Quand c’est le cas, la tâche se range dans ce service, et une IA branchée pour quelqu’un d’un autre service ne la voit pas. Quand l’union couvre deux services, la tâche n’est rangée nulle part et attend la décision d’un administrateur.
Le raccourci consisterait à retenir un seul de ces projets, le plus étroit ou le premier venu. Il ouvrirait une fuite lente. Ranger une tâche dans le service commercial la rend lisible par tout le service commercial, y compris par des personnes qui ne sont membres d’aucun des projets concernés. Cette généralisation ne tient que lorsque les membres des projets désignent un seul service, et le connecteur refuse de la faire dans tous les autres cas. C’est la différence entre reprendre un partage et gouverner un contexte.
Ce que votre Kastel lit d’une tâche, et ce qu’il laisse dans Asana
Asana ne renvoie que l’identifiant d’une tâche tant qu’on ne lui demande rien d’autre. Chaque lecture déclare donc les champs qu’elle consomme, et le reste de la tâche n’est jamais transmis.
Les évènements automatiques sont écartés pour une raison de fond. Asana range dans un même flux le commentaire écrit par une personne et le changement de statut posé par le système. Le premier porte une décision, le second dit l’état du travail à un instant donné et se périme tout seul.
Un projet visible par toute l’équipe fait attendre ses tâches
Un projet Asana peut être réservé à ses membres, visible par une équipe entière, ou visible par tout l’espace de travail. Dans les deux derniers cas, la liste des membres explicites du projet ne dit plus qui peut le lire, puisque des personnes y accèdent sans y figurer.
Votre Kastel refuse alors de conclure. Une tâche qui vit dans un tel projet attend un administrateur, même quand la liste des membres explicites désignait proprement un service. Se fier à cette liste reviendrait à sous-estimer l’audience réelle du projet, donc à accorder un accès que personne n’a décidé.
La même prudence s’applique quand une liste de membres revient tronquée, quand un membre n’est pas identifiable dans votre organisation, ou quand la tâche ne vit dans aucun projet. Il n’existe alors aucun public à reprendre, donc aucun service dans lequel ranger la tâche.
Un changement de membres ne modifie aucune tâche, donc nous recalculons
Asana horodate une tâche quand son contenu change. Ajouter ou retirer une personne sur un projet ne touche ni le texte de ses tâches ni leur date de modification, et aucun évènement n’est émis au niveau de la tâche.
Un connecteur qui se contenterait du flux des tâches récemment modifiées ne verrait donc jamais un repartage. Une tâche resterait rangée dans le service où elle est entrée, alors que son projet a changé de main depuis. Votre Kastel recalcule donc à cadence régulière le public de chaque tâche qu’il suit, à partir des membres actuels de ses projets. Quand le résultat diffère de ce qui était enregistré, la tâche est reversée dans le bon service et la version rangée dans l’ancien est retirée.
Chaque outil de suivi impose son compromis sur ce point précis, et le connecteur Jira relit tous les tickets accessibles à chaque passage pour la même raison. Une modification du texte d’une tâche, elle, est prise dès le passage suivant.
Ce que ce connecteur ne fait pas
Il ne travaille pas dans Asana. Aucune tâche n’est créée, commentée, terminée ni déplacée, parce que le client utilisé n’expose que des lectures. Reste un point à dire franchement. Asana ne permet pas de demander un jeton limité à la lecture, donc cette garantie tient à la construction du connecteur et pas à un réglage que vous pourriez vérifier dans votre espace de travail.
Il ne lit qu’un texte. Une tâche dont l’information tient dans son échéance, son responsable et un champ personnalisé entre réduite à son titre, et une tâche sans titre ni texte n’entre pas du tout. Sur un Asana très structuré, une partie de ce que vous voyez à l’écran ne franchit pas la porte.
Beaucoup de tâches resteront en attente, et ce n’est pas un défaut de réglage. Les projets transverses, ceux qui réunissent la production et le commerce autour d’un même client, produisent exactement l’union qui couvre deux services. Un administrateur doit alors décider où ranger ces tâches, une par une ou par règle, et ce travail ne disparaît pas.
Le recalcul des publics passe à sa cadence, pas à chaque minute, donc une personne retirée d’un projet peut encore atteindre ses tâches pendant un temps à travers une IA branchée sur son service. Et une tâche supprimée dans Asana, ou terminée puis purgée, n’est pas effacée de votre Kastel. Elle y est signalée comme disparue à la source et conservée, lisible par les mêmes personnes qu’avant, jusqu’à ce qu’un administrateur l’efface, comme dans tous les connecteurs de Kastel.
Regardez d’abord ce que Kastel refuse de ranger seul.
La page produit décrit ce que le cœur gratuit installe chez vous, connecteurs compris, et ce qu’un administrateur décide ensuite. Sur Asana, la liste des tâches mises en attente est le premier signal utile, parce qu’elle montre où vos projets mélangent plusieurs services.
Voir le produit
