Une même liste sert à suivre des bogues, des comptes clients et des campagnes. Résultat : chaque tâche ressemble à un formulaire interminable, les champs pertinents se perdent au milieu des autres et l’équipe finit par laisser des cases vides. Et si le problème n’était pas le manque de discipline, mais le fait de demander les mêmes informations à des travaux qui n’ont rien à voir ? Avec les champs personnalisés par type de tâche, ClickUp donne un contexte aux données.

Dans un espace qui grandit, les champs personnalisés s’empilent ; ils sont bourrés de bonnes intentions, et on n’ose plus les retoucher… On devient sentimental. On ajoute une notion de gravité pour les bogues, le budget pour les campagnes, la date de renouvellement pour les comptes, puis un champ « autres » pour ne rien oublier. Quelques temps plus tard, une personne de l’entreprise ouvre une tâche et doit parcourir une longue colonne de champs dont la moitié ne concerne pas son travail.

Le signal d’alerte est facile à reconnaître : les champs sont présents, mais les valeurs sont incomplètes ; les mêmes informations sont saisies dans plusieurs endroits ; les rapports donnent une impression de précision sans permettre de répondre rapidement à une question simple.

La question n’est donc pas seulement « combien de champs avons-nous ? ». C’est plutôt : « quelles informations sont indispensables pour ce type de travail, au moment où quelqu’un ouvre la tâche ? »

Ce que ClickUp change avec les champs par type de tâche

Le type de tâche devient un contexte de travail

Les notes de version 4.07 de ClickUp annoncent la possibilité d’affecter les champs personnalisés à des types de tâches et de faire remonter en premier les champs qui correspondent au travail en cours. Un bogue, un compte et une campagne peuvent ainsi présenter chacun les données qui aident à décider, plutôt qu’une liste indifférenciée héritée de toute l’organisation.

Ce n’est pas qu’un changement cosmétique. Un champ placé au bon endroit explique implicitement ce que l’équipe doit renseigner. Le système devient un guide discret : il rappelle la question métier sans obliger l’utilisateur à relire une procédure.

Ne confondez pas personnalisation et fragmentation

Le risque serait de déplacer tous les champs vers un type de tâche. Certains champs doivent rester communs à toute la liste : responsable, priorité, prochaine action, date cible ou statut de traitement, selon votre fonctionnement. Ils servent à comparer les travaux entre eux.

Les champs propres au type décrivent, eux, la nature de l’objet :

  • Bogue : environnement, version touchée, gravité, étapes de reproduction ;
  • Compte : valeur, segment, date de renouvellement, niveau de risque ;
  • Campagne : canal, budget, audience, date de lancement, objectif.

La règle est simple : si une information permet de comparer toutes les tâches, elle est probablement partagée. Si elle n’a de sens que pour une catégorie de travail, elle mérite d’être rattachée au type concerné.

L’exemple de structuration proposé dans cet article officiel sur les champs par type de tâche va dans le même sens : garder les champs communs au niveau de la liste et réserver les champs spécifiques à l’objet qui les utilise réellement.

Cas concret : un pipeline qui mélange ventes, campagnes et demandes internes

Imaginons une équipe marketing qui suit dans une même liste les demandes commerciales, les campagnes de contenu et les incidents par les formulaires. Jusqu’ici, tout le monde voyait les mêmes champs : budget, URL de campagne, navigateur, valeur du contrat, audience cible et date de renouvellement. La liste était complète sur le papier, mais pénible dans la pratique.

L’objectif n’est pas de recréer trois systèmes séparés. C’est de conserver un flux commun tout en donnant à chaque tâche une fiche lisible.

Étape 1 : auditer les champs avant de les déplacer !

Exportez ou recensez les champs utilisés dans la liste et classez-les dans quatre colonnes :

  1. Commun : utile à presque toutes les tâches ;
  2. Spécifique : pertinent pour un seul type ;
  3. Redondant : déjà présent dans un autre champ, une description ou un outil ;
  4. Inutilisé : créé par anticipation, mais jamais exploité.

Ne supprimez pas immédiatement les champs douteux. Mesurez plutôt leur taux de remplissage et demandez à quelques utilisateurs pourquoi ils les ignorent. Une case vide peut signaler une mauvaise consigne, mais aussi une donnée qui n’aide personne.

Étape 2 : définir un minimum viable par type

Pour chaque type de tâche, limitez-vous d’abord à cinq ou six informations réellement décisionnelles. Pour une campagne, il peut s’agir du canal, de l’objectif, du budget, de la date de lancement et du propriétaire. Pour un bug, de la gravité, de l’environnement, de la version et d’une reproduction fiable.

Ce minimum n’est pas une loi éternelle. Il sert à éviter le réflexe « ajoutons un champ au cas où ». Une équipe renseigne mieux un petit modèle qu’elle comprend qu’un modèle exhaustif qu’elle contourne.

Étape 3 : rattacher les champs au bon type

Dans le gestionnaire de champs, la barre latérale des champs ou la vue de la tâche, utilisez les réglages de type disponibles dans votre espace pour associer un champ à la catégorie qui en a besoin. L’article officiel décrit notamment le réglage Field belongs to dans les paramètres avancés.

Commencez par deux ou trois champs à fort bruit : ceux qui apparaissent partout et ne sont presque jamais remplis hors de leur contexte. Vérifiez ensuite une tâche de chaque type. Le test est réussi si une personne comprend ce qu’elle doit renseigner sans demander « ce champ sert à quoi ? ».

Étape 4 : faire des vues qui expliquent le travail

Créez une vue ou un filtre par type lorsque le besoin est réel : une vue « Bugs à qualifier », une vue « Campagnes en préparation », une vue « Comptes à relancer ». Affichez les colonnes qui servent à la décision de cette vue, pas l’intégralité du modèle de données.

Le but n’est pas de multiplier les vues jusqu’à reproduire le problème ailleurs. Une vue doit répondre à une question de travail précise : que dois-je traiter, comparer ou décider maintenant ?

Étape 5 : mesurer l’effet après deux semaines

Comparez avant et après sur quelques indicateurs simples :

  • taux de remplissage des champs importants ;
  • temps nécessaire pour créer ou qualifier une tâche ;
  • nombre de questions récurrentes sur la signification des champs ;
  • nombre de corrections dans les rapports ;
  • taux d’utilisation des vues par type.

Si la complétude augmente mais que le temps de saisie explose, le modèle est encore trop lourd. Si les données sont propres mais que personne ne les utilise pour décider, le problème est peut-être les consignes de l’équipe, pas le champ lui-même.

Limites et points de vigilance

Les champs par type de tâche améliorent la lisibilité, mais ils ne constituent pas à eux seuls un modèle de données complet. Les équipes qui utilisent plusieurs niveaux de sous-tâches peuvent encore avoir besoin de faire remonter des valeurs numériques, monétaires ou calculées vers la tâche parent.

Sur le portail Canny de ClickUp, la demande de rollup des champs personnalisés des sous-tâches vers la tâche parent apparaît dans les sujets en cours de construction. Cela rappelle une limite importante : masquer le bruit d’un champ ne résout pas automatiquement la question de l’agrégation, du périmètre ni de la source de vérité.

Autre point de vigilance : un type de tâche doit représenter une différence de travail ou de données, pas chaque variante possible et imaginable. Si votre liste possède quinze types et que personne ne sait lequel choisir, vous avez déplacé le champ de la complexité au lieu de la réduire.

Enfin, vérifiez l’impact sur les formulaires, les modèles, les automatisations et les rapports existants avant une migration large. Un champ plus propre à l’écran peut encore être utilisé par une automatisation invisible ou une formule que l’on ne veut pas casser.

Élargir : la qualité des données commence par la qualité de la question

Un champ personnalisé n’est pas seulement une colonne. C’est une question posée à l’équipe : « cette information mérite-t-elle d’être connue et maintenue ? »

Quand la question est identique pour tout le monde, le champ peut rester commun. Quand elle dépend du travail, le type de tâche fournit le contexte. Et quand la réponse ne déclenche aucune décision, il faut peut-être retirer la question.

C’est une manière plus saine de concevoir ClickUp. On ne cherche pas à capturer toute la réalité dans chaque tâche. On choisit les quelques signaux qui rendent le travail visible, comparable et actionnable. La plateforme devient alors moins un formulaire administratif qu’un compagnon de décision.

Conclusion

Le problème de départ n’était pas une équipe incapable de remplir des champs. C’était un modèle qui présentait à chaque personne toutes les questions posées à toute l’organisation.

Les champs par type de tâche permettent de remettre le contexte au premier plan : les bugs montrent ce qui aide à diagnostiquer, les comptes ce qui aide à suivre la relation, les campagnes ce qui aide à arbitrer. La réussite dépend toutefois d’une discipline éditoriale : conserver les champs communs quand ils sont vraiment communs, limiter le nombre de types et vérifier que les données servent à quelque chose.

La meilleure configuration n’est pas celle qui stocke le plus d’informations. C’est celle qui rend la bonne information presque évidente au bon moment.

Travaux pratiques

Choisissez une liste qui mélange au moins deux types de travail. Pendant 30 minutes, classez ses champs en « commun », « spécifique », « redondant » et « inutilisé », puis déplacez seulement deux champs utilisés vers le type qui en a réellement besoin. Mesurez la complétude et le temps de qualification avant d’aller plus loin.