Le document ClickUp est l’endroit où la méthode finit par vivre
Les équipes qui vivent dans ClickUp finissent par y écrire autre chose que des tâches, le mode opératoire d’un lancement, la note d’un rendez-vous client, la liste des décisions prises sur un projet. Ces documents sont souvent la seule version écrite de la façon dont l’entreprise travaille vraiment.
Une IA qui ne les lit pas répond depuis le vide, ou depuis ce qu’elle sait du monde en général, ce qui est pire. Elle a donc besoin de ces documents, et de rien de plus que ce que son interlocuteur a le droit d’y voir.
Kastel traite les documents et les tâches de ClickUp avec deux connecteurs séparés, parce que ClickUp les expose par deux interfaces différentes et avec deux modèles de partage sans rapport l’un avec l’autre. Celui-ci lit les documents. Pour les listes, les statuts et les commentaires de tâches, voyez le connecteur ClickUp. Chacun porte sa propre clé, et brancher l’un ne branche jamais l’autre.
ClickUp Docs ne dit pas qui a le droit de lire un document
La limite est plus large ici que sur la plupart des sources, et elle mérite d’être nommée avant tout le reste. L’interface que ClickUp ouvre sur ses documents ne renvoie aucune liste de personnes autorisées. Elle expose un seul signal de partage, un indicateur qui dit si le document est publié sur le web. Les droits du dossier ou de l’espace qui le contient ne sont pas lisibles davantage.
Nous n’inventons donc rien à partir de l’emplacement du document. Un document rangé dans un espace réservé à la direction ressemble, vu de l’interface, à un document rangé n’importe où ailleurs. Déduire une audience de cet emplacement supposerait que vos dossiers ClickUp reflètent exactement vos services, ce qui est rarement vrai et ne se vérifie jamais depuis l’interface.
La conséquence est directe. Un administrateur désigne le service auquel reviennent les documents lus par ce connecteur, et ce service est le seul à les lire. Le nom qu’il donne est vérifié contre l’organisation réelle de votre Kastel, donc un service écrit dans un fichier de configuration mais absent de votre organisation ne débloque rien, et les documents restent en réserve. C’est le même sens de la prudence que celui décrit sur la page sécurité.
Un document publié sur le web sort de ce mécanisme. Le partage le plus large possible ne se traduit pas par le service le plus large possible, donc le document est mis en réserve et attend une décision. L’indicateur lui-même est lu avec méfiance. Une valeur inattendue à cet endroit est traitée comme un document public, donc comme un document qui attend.
Un document devient un texte, page après page
Un document ClickUp est un empilement de pages. Le connecteur reprend le titre de chaque page et son texte, dans l’ordre, et en fait un seul document dans votre Kastel. Le texte est demandé au format markdown, donc les titres et les listes gardent leur structure au lieu de s’aplatir.
Seul ce texte est retenu. Un champ qui reviendrait sous une forme inattendue, un objet là où le connecteur attend une phrase, produit du vide plutôt que son contenu déplié. Cette précaution coûte parfois un passage moins complet, et elle évite qu’une structure entière atterrisse dans votre Kastel sans que personne l’ait nommée.
Un cas mérite d’être signalé, parce qu’il touche à ce qui reste lisible chez vous. Quand un document est vidé de son contenu dans ClickUp, la version que votre Kastel en avait retenue est retirée. Vider un document a donc un effet immédiat sur ce que l’IA peut atteindre, là où le supprimer produit un résultat différent, décrit plus bas.
Ce que votre Kastel retient d’un document ClickUp
Le périmètre se décrit en pages et en texte, puisque c’est tout ce que cette interface rend disponible.
L’indicateur de publication sur le web est lu comme une règle de droit et jamais comme du contenu. Il sert à décider qu’un document attend une décision, et il n’apparaît pas dans ce qu’une IA reçoit.
Les questions qu’on nous pose sur ce connecteur
Pourquoi deux pages pour ClickUp, l’une pour les tâches et l’autre pour les documents ?
Parce que ClickUp expose deux interfaces différentes et deux modèles de partage qui n’ont rien en commun. Une tâche appartient à une liste dont les membres sont lisibles, donc son public se déduit de son conteneur. Un document n’expose aucune liste de personnes, donc son public est désigné par un administrateur. Deux règles aussi éloignées ne tiennent pas dans un seul connecteur, et les mélanger reviendrait à appliquer la plus permissive des deux.
Est-ce que tous mes documents finissent dans le même service ?
Oui, pour les documents que ce connecteur lit. C’est une contrainte de ce que ClickUp expose et non un choix de conception. Là où un espace Notion porte au moins une propriété de type Personne sur laquelle s’appuyer, ClickUp Docs ne porte rien. La seule autre issue consiste à ne désigner aucun service, auquel cas tous les documents restent en réserve et chaque décision d’accès est prise à la main.
Que se passe-t-il quand un document est supprimé ou archivé dans ClickUp ?
Il disparaît de la liste vivante que le connecteur relit à chaque passage, et votre Kastel le marque comme disparu à la source. Son contenu déjà retenu y reste consultable par les mêmes personnes qu’avant, jusqu’à l’effacement qu’un administrateur décide. C’est le comportement de tous les connecteurs, et il vaut aussi pour un document simplement archivé.
Une IA peut-elle modifier un de mes documents ?
Non. Le client utilisé n’expose que des lectures, et aucune méthode de création, de modification ou d’archivage n’y existe. Le connecteur ne peut pas écrire dans ClickUp, quelle que soit l’IA branchée de l’autre côté.
Ce que ce connecteur ne fait pas
Il ne devine pas l’audience d’un document. ClickUp Docs ne l’expose pas, donc la décision est prise une fois, par un administrateur, pour l’ensemble des documents lus. Nous n’avons pas voulu d’un connecteur qui répartirait vos documents en lisant leur emplacement, parce qu’il aurait l’air de fonctionner jusqu’au jour où un document se retrouve dans le mauvais service.
Le grain est grossier, et il faut le savoir avant de brancher. Un fichier partagé porte ses propres destinataires et un ticket porte son niveau de sécurité, alors qu’un document ClickUp ne porte ni l’un ni l’autre. La finesse que vous obtenez sur d’autres sources n’existe pas ici. Pour des documents réellement sensibles, l’option prudente consiste à ne pas les mettre dans le périmètre du tout.
Cette interface n’expose aucun filtre de date, donc chaque passage énumère l’espace de travail entier avant de comparer les dates. Une pagination qui boucle ou qui s’interrompt fait échouer le passage plutôt que de rendre une liste incomplète, puisqu’une liste incomplète ferait passer des documents bien vivants pour disparus. Le rafraîchissement est donc plus lourd que sur une source capable de signaler ses changements.
Il ne fait rien des tâches. Les listes, les statuts et les commentaires de tâches relèvent d’un connecteur distinct, avec sa propre clé et ses propres règles de partage, et brancher les documents n’ouvre aucun accès aux tâches.
Regardez comment un document devient du contexte gouverné.
La page produit détaille le chemin complet, de la lecture d’une source à la réponse qu’une IA branchée peut donner, avec la décision d’accès à chaque étape. C’est le meilleur endroit pour juger si le grain de ClickUp Docs vous suffit.
Voir le produit
