Comment déléguer les tâches communautaires sans recruter plus de modérateurs

Pour qui : le fondateur ou le responsable de communauté dont la file de révision grandit plus vite que l'équipe, face à quelques milliers de soumissions en attente, et qui se demande si la réponse est un deuxième modérateur, un troisième, ou une lettre de démission.

Réponse courte : Probablement pas une personne de plus — mais pas pour la raison flatteuse. La majeure partie de la file ne devrait pas exister. Dans Zealy, cinq types de tâches sont conçus pour exiger qu'un humain lise la réponse — et la tâche de date les rejoint avec son réglage par défaut — tandis que tout le reste se règle tout seul dès qu'un membre la réclame. Déléguer à une règle vaut mieux que déléguer à une personne, qui vaut mieux que déléguer à une machine, dans cet ordre, car seule la première supprime le travail au lieu de le déplacer.

Divulgation : Zealy publie ceci et Zealy vend la plateforme qui y est décrite. Chaque affirmation sur ce que fait Zealy a été lue dans le code source de Zealy lui-même le 16 août 2026, et non dans les pages marketing ou la documentation de Zealy. Cela inclut les endroits où il manque à Zealy quelque chose d'évident, et deux pages de la documentation de Zealy qui sont erronées, que nous corrigeons dans la même modification que cet article.

Dernière vérification : 16 août 2026.

Faut-il recruter plus de modérateurs ?

Probablement pas encore. Dans Zealy, cinq types de tâches sont conçus pour atteindre un réviseur humain : texte, URL, nombre, envoi de fichier et sondage — et la tâche de date les rejoint avec son réglage par défaut. Tout le reste se vérifie automatiquement et n'entre jamais dans une file. Avant d'ajouter des personnes, auditez lesquelles de vos quêtes ont réellement besoin qu'un humain lise la réponse.

Presque toutes les conversations « nous sommes submergés de soumissions » commencent par la capacité — combien de réviseurs, combien d'heures, à quelle vitesse chacun traite un élément — alors que la taille de la file a été décidée des semaines plus tôt dans l'éditeur de quêtes, par celui qui a choisi le type de tâche. Une quête qui demande une capture d'écran crée une file. Une quête qui demande de rejoindre un serveur Discord n'en crée pas, car la réponse est vérifiée auprès de Discord sur-le-champ. Même campagne, même récompense, coût opérationnel radicalement différent.

La séquence honnête est donc : supprimer le travail, déléguer ce qui reste, automatiser ce qui subsiste. Les équipes le font systématiquement dans l'ordre inverse, ce qui vous amène à payer une montée de forfait pour accélérer un travail que vous auriez pu supprimer.

Les trois façons de déléguer une file de révision

Vous pouvez déléguer une file de révision de trois façons : à une règle, en rendant la tâche auto-vérifiante ; à une personne, via le rôle de réviseur de Zealy ; ou à une machine, via la révision par IA ou un agent MCP. Les règles suppriment le travail, les personnes appliquent leur jugement, les machines appliquent un prompt écrit à grande échelle.

Voie un : concevoir la disparition du travail de révision

Commencez ici : c'est la seule voie qui supprime le travail au lieu de le déplacer. Cinq types de tâches Zealy sont conçus pour exiger un humain — texte, URL, nombre, envoi de fichier et sondage — et la date se comporte de la même façon par défaut. Tout le reste se résout quand un membre la réclame. Réécrire une tâche de texte en vérification de lien vide la file.

Nous l'avons vérifié en lisant la fonction qui décide si une quête est auto-validée, puis en recoupant chaque validateur d'exécution du service de quêtes. Ces cinq — text, url, number, file, poll — renvoient chacun un statut de révision en attente, sauf si la tâche est explicitement réglée pour s'auto-valider. Les autres renvoient un succès ou une erreur de façon synchrone, donc il n'y a rien à attendre et aucune file où attendre.

Deux exceptions honnêtes, car le code se contredit et nous préférons le dire plutôt que de le lisser :

• Tâches de date. Une liste les traite comme toujours automatiques, tandis que le validateur qui s'exécute réellement respecte le réglage d'auto-validation de la tâche, que l'éditeur laisse désactivé par défaut. Nous ne vous dirons pas que les tâches de date sont automatiques quand le code se contredit. Testez-en une avant de vous y fier.
• Proof of Humanity. Elle se résout automatiquement à l'exécution mais n'apparaît dans aucune des deux listes — tout comme le type de quête de partenariat — donc une quête contenant uniquement cette tâche est signalée comme non auto-validée. Elle se comporte mieux qu'elle ne l'annonce. (Ce qu'elle détecte est couvert dans comment organiser un airdrop qui ne se fait pas farmer — c'est un filtre à bots, pas un filtre anti-sybil.)

La réécriture qui réduit réellement la file d'attente

Regardez d'abord vos tâches textuelles. La plupart posent une question à réponse unique, formulée comme une dissertation. « Dites-nous ce que vous avez appris dans la documentation » est une file d'attente. « Collez le hash de la transaction » est une tâche texte ou URL avec une bonne réponse, et elle se valide d'elle-même. « Faites une capture d'écran de votre position » est une file d'attente, et une tâche fichier ne fait aucune vérification de contenu, donc un relecteur ouvre chaque image. « Laquelle de ces trois est notre modèle de frais » est un quiz, et les quiz n'atteignent jamais un humain.

La règle empirique que nous défendrions : si vous pouvez écrire la réponse à l'avance, la tâche ne devrait pas être dans la file d'attente. Si vous ne pouvez pas, affectez du personnel plutôt que de prétendre qu'une consigne suffira.

Le piège : une bonne réponse vide approuve tout

C'est le paragraphe de cet article qui a le plus de chances de vous épargner une mauvaise semaine. La validation automatique sur les tâches texte, URL, nombre et date compare la soumission d'un membre à une bonne réponse que vous configurez, et ces quatre comparaisons court-circuitent lorsque cette bonne réponse est vide. Elle n'échoue pas en mode fermé et ne vous avertit pas. Elle approuve tout.

Deux comportements connexes à connaître avant d'activer des interrupteurs en masse. Un sondage avec validation automatique activée approuve tout par conception — ce n'est pas un bug, puisqu'un sondage n'a pas de mauvaise réponse, mais activer la validation automatique sur tout un module pour résorber un arriéré distribue les récompenses du sondage à tout le monde. Et valider automatiquement un envoi de fichier approuve l'envoi, pas le contenu ; n'importe quel fichier passe.

Si vous retenez une seule habitude opérationnelle de cet article, que ce soit celle-ci : après avoir activé la validation automatique, réclamez vous-même la tâche avec une réponse volontairement fausse et confirmez qu'elle échoue.

Un contrôle des doublons supprime du travail ; l'autre ne fait que l'annoter

Les alertes de relecture signalent une soumission comme duplicate (un autre membre a envoyé le même contenu pour la même tâche) ou reused (ce membre l'a envoyé auparavant), uniquement sur les tâches texte et fichier, avec une recherche sur 180 jours. Elles sont indicatives — rien dans le chemin de code qui enregistre un verdict ne les lit. Elles informent un humain ; elles ne décident rien. Et sur les tâches fichier, la correspondance est plus faible qu'elle n'en a l'air : les envois sont comparés par leur URL stockée, et chaque envoi obtient une nouvelle clé, donc renvoyer le fichier identique n'est jamais détecté comme doublon.

Le rejet des doublons à la soumission est un réglage distinct, sur opt-in, qui rejette une réponse texte répétée avec une erreur avant qu'elle n'atteigne votre file d'attente. Il est désactivé par défaut sur les tâches texte et URL, normalise en supprimant les espaces superflus, en réduisant les espaces et en passant en minuscules — donc une reformulation passe à travers — et il empêche tout membre de réutiliser ce texte, y compris celui qui l'a écrit en premier. C'est celui-là qui réduit une file d'attente.

Voie deux : déléguer à une personne avec le rôle reviewer

Le rôle reviewer de Zealy est une délégation étroite : il ouvre neuf des 225 surfaces de routes protégées par rôle dans l'API de Zealy, toutes liées à la relecture, et un reviewer ne peut pas approuver ses propres réclamations. Vous l'attribuez avec un lien d'invitation qui porte un rôle, une expiration et un nombre maximal d'utilisations.

Il n'existe aucun rôle appelé moderator dans Zealy. Le rôle est reviewer, et il y a cinq rôles au total : admin, editor, reviewer, guest et banned. (La documentation de gestion des membres de Zealy indique qu'il y en a quatre. Elle omet banned, qui est un rôle réel accepté par l'endpoint de changement de rôle. Cette page est corrigée dans le même changement que cet article.)

Les cinq rôles forment une échelle strictement linéaire — admin au-dessus d'editor, au-dessus de reviewer, au-dessus de guest, au-dessus de banned — et chaque vérification de permission du produit pose une seule question : le rôle de ce membre est-il au moins à ce niveau ? Donc la description honnête du modèle de permissions de Zealy est qu' il n'y en a pas. Pas d'ensembles de permissions, pas de rôles personnalisés, aucun moyen de limiter un rôle à une quête, un module ou une campagne. Nous avons cherché dans les définitions du modèle et de la base de données des concepts de permission, ability et grant ; les seules correspondances étaient des colonnes OAuth sans rapport.

Voici ce que l'échelle répartit sur ces 225 surfaces protégées par rôle :

Comme l'échelle est linéaire, un reviewer obtient aussi tout ce qui est protégé au niveau guest. Mais ces neuf surfaces constituent toute la délégation et relèvent toutes du travail de relecture, ce qui explique pourquoi promouvoir quelqu'un au rôle reviewer est une bien meilleure réponse que de le promouvoir admin pour qu'il puisse aider.

Notez la ligne editor. Editor est une attribution bien plus large que reviewer : il porte tout ce qu'un reviewer peut faire, plus la configuration des quêtes, modules et sprints, la visibilité des quêtes non publiées et la réinitialisation des réclamations. La documentation de Zealy sur les membres le décrit comme la configuration des quêtes, des sprints et des membres et la consultation de toutes les pages, ce qui semble plus étroit que la réalité ; cette page est corrigée dans le même changement que cet article. Promouvez quelqu'un au rôle editor lorsqu'il construit des campagnes, et au rôle reviewer lorsqu'il ne fait que lire des soumissions.

Comment attribuer le rôle, et ce que cela vous coûte

Les changements de rôle sont réservés aux admins, et un admin ne peut pas changer son propre rôle. Le mécanisme à utiliser est le lien d'invitation, qui porte un rôle, une expiration et un nombre maximal d'utilisations. Utilisez les trois : une invitation qui expire en 48 heures avec un maximum d'une utilisation est un objet très différent d'un lien qui traîne dans un groupe Telegram pendant huit mois.

Ensuite, soyez honnête sur le coût. Un réviseur peut attacher jusqu'à 20 000 XP bonus à chaque claim qu'il approuve, aucune vérification de rôle ne le restreint, et une seule action groupée peut porter 1 000 claims — ainsi une seule passe d'approbation peut générer jusqu'à 20 millions d'XP. Déléguer la révision, c'est déléguer le pouvoir d'attribuer des XP. Pour la plupart des communautés, c'est acceptable et même souhaitable, car les XP bonus sont le moyen pour un réviseur de récompenser une excellente soumission — mais si vos XP alimentent un classement qui distribue des tokens, vous avez donné à cette personne un levier sur le versement. Zealy enregistre une piste d'audit complète par verdict, ce qui rend cela détectable après coup plutôt que préventable. Si votre candidat vient d'un programme de contributeurs, comment gérer un programme d'ambassadeurs crypto couvre ce que ce rôle vous coûte.

Les réviseurs ne peuvent pas réviser leurs propres claims — silencieusement

Les propres claims d'un réviseur sont exclus de ce qu'il peut approuver, appliqué dans la couche de service et de nouveau dans quatre garde-fous SQL distincts. Bien. La nuance est la partie intéressante : le filtre est silencieux. Un réviseur qui sélectionne en masse un lot contenant son propre claim ne reçoit aucune erreur. Ce claim est retiré du lot et reste en attente, et personne n'est prévenu. Si un réviseur jure avoir approuvé quelque chose qui se trouve encore dans la file, vérifiez ceci en premier.

Deux réviseurs sur une même file vont entrer en collision

Il n'y a ni réservation, ni verrouillage, ni attribution dans la file de révision de Zealy. Nous avons cherché dans le dépôt des verrous de réviseur, des prises de claim, des attributions de révision et des concepts d'assigné dans l'API, le backend et la webapp ; la recherche d'attribution n'a rien renvoyé du tout. Le seul verrou du système est un court mutex d'écriture qui empêche une double écriture, pas une réservation de file.

La conséquence n'est pas celle que vous imaginez. Deux réviseurs sur la même file voient les mêmes claims et lisent tous deux la même soumission. S'ils sont d'accord, le second reçoit une erreur, car Zealy refuse de passer un claim au statut qu'il possède déjà, et ce temps de lecture est perdu. S'ils ne sont pas d'accord, il n'y a aucune erreur : le second verdict remplace le premier, les récompenses sont nettoyées ou réattribuées en conséquence, et personne n'est prévenu qu'un collègue avait déjà décidé. Le cas silencieux est le désaccord, celui que vous voudriez le plus voir signalé. Il n'existe pas non plus de moyen d'attribuer un réviseur à une quête ou un module spécifique — vous ne pouvez pas exprimer « Ana traite les soumissions design, Ben traite les preuves on-chain » dans le produit.

Coordonner les réviseurs est un problème humain dans Zealy aujourd'hui. Dites-le à voix haute à votre équipe plutôt que de les laisser le découvrir dans une dispute sur Discord. Partitionnez la file dans un message épinglé : par module, par jour, ou une personne du plus ancien au plus récent pendant que l'autre travaille du plus récent au plus ancien — la répartition la plus grossière possible, et elle réduit quand même les collisions.

Révision groupée : un verdict pour jusqu'à 1 000 claims

La révision groupée de Zealy accepte jusqu'à 1 000 claims en un seul appel, et la contrainte réside dans ce que cet appel transporte : un statut, un commentaire, une note et une valeur d'XP bonus pour tout le lot. Il n'y a pas de verdict par élément dans une action groupée. Cela la rend excellente pour un ensemble homogène — chaque soumission sur une quête cassée, chaque claim sur une tâche que vous avez annulée — et dangereuse pour un ensemble mixte, puisque le commentaire que lisent 1 000 membres est la même phrase. Triez impitoyablement avant de sélectionner.

Voie trois : déléguer le verdict à une machine

La révision IA de Zealy exécute Google Gemini 2.5 Flash Lite sur un prompt que vous rédigez, par quête, sur les plans Plus et Enterprise au 16 août 2026. Elle ne recommande pas un verdict que vous confirmez. Elle écrit le verdict, et sa justification devient le commentaire que lit le membre.

Relisez cela deux fois, car la documentation de révision de Zealy décrivait la révision IA comme fournissant des recommandations intelligentes pour vous aider à traiter les révisions. C'est faux, et c'est corrigé dans le même changement que cet article. Il n'y a aucune étape de confirmation humaine dans le chemin de code : le modèle renvoie un résultat, Zealy enregistre une approbation ou un rejet depuis un compte système dédié, et la justification du modèle atterrit dans la boîte de réception du membre.

C'est une décision produit véritablement différente de la révision assistée par IA, et elle mérite un niveau de soin différent de votre part :

• Activez-la par quête, en activant la révision IA sur la quête et en rédigeant un prompt non vide. Ce n'est pas un interrupteur à l'échelle de la communauté, ce qui est la bonne granularité : vous pouvez automatiser une tâche à fort volume sans automatiser vos décisions de jugement.
• Rédigez le prompt comme un standard de rejet, pas comme une ambiance. Le modèle produit un message de rejet destiné au membre, donc tout ce qui est vague dans votre prompt devient un commentaire vague et donc exaspérant sur la soumission de quelqu'un.
• Un cron remet en file les retardataires toutes les 15 minutes, en reprenant les claims en révision IA restés en attente plus d'une heure sans réviseur. Un arriéré ne pourrit pas silencieusement.

Une mise en garde de mesure si vous l'utilisez. Les verdicts IA sont attribués à un compte système portant un rôle admin, donc sur une communauté utilisant la révision IA, il apparaît dans les analyses des meilleurs réviseurs comme n'importe quel autre réviseur. Avant de dire à votre équipe combien de claims vos humains ont traités, excluez-le.

Plans, vérifiés le 16 août 2026

La révision IA est incluse dans les plans Plus et Enterprise, et la page de tarifs de Zealy l'indique comme non incluse dans Free ou Standard. Sur une communauté gratuite que nous avons vérifiée via l'API de capacités de Zealy le 16 août 2026, elle était signalée indisponible avec la raison requires_plus_or_enterprise. Vérifiez la capacité sur votre propre communauté plutôt que de la supposer d'après le nom du plan.

Plus coûte 359 $ par mois facturés annuellement, et Enterprise est sur devis, facturé annuellement. Le plan Free est à 0 $ avec 1 000 validations de quêtes par mois et des membres illimités ; Standard est à 149 $ par mois facturés annuellement. Les prix excluent la TVA et les autres taxes de vente applicables, et tous proviennent de la page tarifaire de Zealy, consultée le 16 août 2026.

La décision qui compte : à 200 validations par semaine, passer à l'automatisation est un mauvais échange face à un après-midi passé à convertir des tâches textuelles en tâches vérifiables. À des milliers de soumissions ouvertes par semaine, avec la norme écrite noir sur blanc, c'est un bon échange.

Déléguer à un agent via MCP

L'autre voie machine est un agent. Zealy expose la revue via son serveur MCP, et la forme de cette délégation est volontairement plus restrictive que la voie humaine.

• Un agent peut soumettre jusqu'à 1 000 validations en un seul appel, le même plafond que la revue en masse, avec la même contrainte d'un seul verdict pour le lot.
• Un agent a besoin du rôle admin admin, alors qu'un réviseur humain n'a besoin que de reviewer. La route publique de revue rejette une décision de revue MCP venant de moins que cela, il n'existe donc pas de version « taille agent » de l'octroi restreint — soit l'inverse du modèle de moindre privilège auquel on s'attendrait.
• Chaque écriture nécessite un nouveau jeton de confirmation humaine. Pas une session, pas une approbation antérieure — une nouvelle confirmation à chaque appel.
• L'argent est hors de portée. Un contrôle sur chaque revue d'admin publique bloque toute validation portant une récompense NFT, token, USDC ou Zaps, empêchant un agent de la faire changer d'état. Un agent peut vider votre file d'XP ; il ne peut pas faire bouger une validation qui verse un paiement. Si vous gérez des distributions, comment distribuer des tokens aux membres actifs d'une communauté explique qui envoie réellement quoi.
• Les agents ne peuvent créer que des invitations invité, jamais des invitations de réviseur. Un agent ne peut pas constituer votre équipe de revue à votre place.

Quand la réponse est véritablement une autre personne

Recrutez ou embauchez quand le jugement est le produit : qualité subjective, normes communautaires, recours, cas limites et tout ce où un rejet erroné vous coûte un contributeur. Ajoutez une personne quand votre file contient de vrais désaccords plutôt que du volume. Le volume est un problème de conception ; le désaccord est un problème d'effectif.

Le test que nous appliquerions avant d'ajouter un réviseur : prenez 20 validations en attente et faites-les examiner indépendamment par deux personnes. Si elles sont d'accord sur 19, votre file est du volume, et le volume se résout par des règles et des prompts. Si elles sont d'accord sur 13, votre file contient un vrai jugement, et aucun réglage d'auto-validation ni prompt de modèle ne fera disparaître ce désaccord — il le rendra seulement invisible.

Trois situations où une personne est la bonne réponse et où nous ne chercherions pas à vous en dissuader :

Les soumissions créatives et de format long où la qualité est le critère de récompense. Si vous payez pour du bon travail plutôt que pour du travail terminé, quelqu'un doit décider ce que signifie « bon », de façon répétée, et le défendre.

Tout ce qui comporte une voie de recours. Un membre rejeté qui se plaint a besoin d'un humain capable d'inverser la décision, et inverser une revue est aussi ce qui retire un rôle Discord déjà accordé par une approbation — un réviseur faisant passer une validation de succès à échec le fait aussi. Rien d'autre ne revérifie ces octrois ; ils sont à usage unique.

Les paiements de grande valeur. Si un verdict décide qui reçoit des tokens, mettez une personne dessus. Les propres règles d'agent de Zealy encodent déjà cette opinion : une machine ne peut pas faire changer d'état une validation portant une récompense financière.

Ce que Zealy mesure, et ce qu'il ne mesure pas

Zealy affiche un nombre de revues en attente, une piste d'audit par verdict, les meilleurs réviseurs par volume et par taux d'approbation, les totaux d'étoiles et de signalements par membre, et un export CSV allant jusqu'à 10 000 lignes. Il ne calcule ni délai de revue, ni latence de file, ni SLA, ni débit. Nous avons cherché ces noms dans le code source et n'en avons trouvé aucun.

Nous sommes précis parce que la version de cet article que nous avions initialement prévue reposait sur des données de chronométrage de la file de revue, et ces données n'existent pas. Nous avons cherché dans les paquets de Zealy les termes time-to-review, review latency, average review time, review duration, review throughput et reviews-per-hour. Zéro résultat, aucun regroupement par ancienneté, aucun tableau de bord de débit. Donc quand un fournisseur vous dit que ses clients ont réduit le temps de revue d'un certain pourcentage, demandez quel système a produit ce chiffre. Nous n'avons pas pu produire le nôtre, et nous n'allons pas en inventer un.

Deux autres points à lire correctement :

« Meilleurs réviseurs par taux d'approbation » est un taux d'approbation, pas un taux d'exactitude. Il indique la part des verdicts d'un réviseur qui étaient des approbations. Il ne dit rien de la justesse de ces verdicts. Un réviseur qui approuve tout obtient 100 %.

Le délai de revue est calculable, simplement pas rapporté. Le CSV de revue contient les horodatages de création et de mise à jour de chaque validation, mais pas les événements de revue ; pour une validation examinée une fois et laissée telle quelle, l'écart entre les deux est votre délai de revue, et une médiane est à un tableur de distance. Les validations réexaminées nécessitent l'historique par validation pour être exactes. C'est une vraie lacune dans Zealy et nous préférons l'écrire plutôt que de la contourner.

L'arithmétique, clairement étiquetée comme arithmétique

Il n'y a aucune donnée Zealy ici, voici donc un cadre à remplir avec vos propres chiffres. Chaque entrée est une hypothèse que vous fournissez, pas une mesure que nous avons faite.

weekly human-review load
  = claims per week
  × share of claims on text / URL / number / file / poll tasks
  × share of those not auto-validated
  × your own seconds per review

Supposez 2 000 validations par semaine, un tiers sur des types de tâches nécessitant un humain, aucune auto-validée, 40 secondes chacune : environ 7,4 heures par semaine, entièrement construites à partir de chiffres que vous avez fournis. Le point n'est pas la réponse. C'est que les deuxième et troisième facteurs deviennent visibles, et ce sont les deux que vous pouvez changer sans embaucher personne.

Où d'autres outils battent Zealy sur ce point

Le bot Discord de Zealy ne fait aucune modération. Il n'expulse, ne bannit et n'exclut temporairement personne, et il ne fournit ni messages de bienvenue, ni rôles par réaction, ni tickets, ni journalisation. Les outils de modération propres à Discord et les bots natifs Discord construits autour d'eux s'en chargent. Les clés API de Zealy sont également bien plus granulaires que ses rôles humains.

Sur le premier point, nous avons cherché dans le code source du bot Discord de Zealy les appels kick, ban, timeout, bulk-delete, guild-ban, AutoMod, moderate-members et audit-log, ainsi que les messages de bienvenue, rôles par réaction, salons vocaux, tickets et journalisation. Les seules correspondances étaient des lignes qui désactivent la mise en cache. Son installation propose même un ensemble de permissions restreint à côté de l'option Administrateur complet — Gérer les rôles, Mentionner tout le monde et Envoyer des messages — soit exactement l'ensemble de permissions de quelque chose qui ne modérera rien. Si votre problème est que des gens se comportent mal sur votre serveur Discord, Zealy n'est pas le bon outil : notre guide des outils d'engagement et de croissance Discord est un meilleur point de départ — il couvre les bots de modération et les paramètres natifs de Discord qui gèrent une grande partie de cela gratuitement — et la documentation de l'intégration Discord décrit ce que fait réellement le bot de Zealy.

Sur le second point, la comparaison est embarrassante et interne. Le modèle de clés API de Zealy compte 40 capacités distinctes, dont des capacités séparées pour lire les revues, exporter les revues et écrire les revues, et ses deux préréglages de création de quêtes n'ont aucune capacité de revue. C'est un véritable modèle de moindre privilège : une machine qui parle à Zealy peut recevoir la permission de lire la file de revues et non de la trancher.

Un humain ne le peut pas. Un humain obtient une position sur une échelle à cinq échelons, donc si vous voulez que quelqu'un trie et signale sans approuver, il n'y a aucun moyen de l'exprimer. L'API sait le faire ; le modèle de rôles, non. Quand on nous demande des rôles personnalisés, c'est cet écart qu'on a rencontré, et pointer vers notre propre modèle de clés API est la façon la plus honnête de l'admettre. Et encore une fois, parce que c'est le point opérationnel : tout outil conçu comme une file de travail résout le débit multi-personnes par l'assignation. Zealy le résout avec un message épinglé dans votre canal d'équipe.

Comment configurer cela dans Zealy, dans l'ordre

Auditez quelles quêtes utilisent les cinq types de tâches humaines. Convertissez ce que vous pouvez. Définissez les bonnes réponses avec soin, car une réponse vide approuve tout. Ensuite, invitez un ou deux réviseurs via un lien plafonné et expirant, convenez à l'oral de qui travaille sur quel module, et seulement alors décidez si la revue par IA justifie une mise à niveau de forfait.

1. Comptez votre file par type de tâche, pas par taille, puis convertissez ce qui se convertit. Ce qui compte, c'est combien de claims en attente portent sur des tâches texte, URL, nombre, fichier et sondage, et parmi celles-ci, combien posent une question dont la réponse est connaissable. Une question à réponse unique devient un quiz ou une tâche texte avec une bonne réponse ; une capture d'écran prouvant que vous l'avez fait devient une tâche on-chain, lien ou intégration partout où l'action laisse une trace que Zealy peut vérifier.

2. Testez chaque auto-validation que vous activez, puis activez le rejet des doublons là où le copier-coller est le mode d'échec. Claimez la tâche vous-même avec une mauvaise réponse et confirmez qu'elle échoue ; cette habitude de deux minutes évite le piège de la bonne réponse vide. Le rejet des doublons est désactivé par défaut sur les tâches texte et URL et ne détectera pas une reformulation.

3. Promouvez des réviseurs, pas des éditeurs, via un lien d'invitation plafonné. Définissez une expiration et un nombre maximal d'utilisations, et dites par écrit à la personne que le rôle peut accorder jusqu'à 20 000 XP bonus par claim, sur jusqu'à 1 000 claims en une seule action, et que vous pouvez voir chaque verdict.

4. Partitionnez la file dans un message épinglé. Par module, par jour, ou du plus ancien au plus récent versus du plus récent au plus ancien. Le produit ne le fera pas pour vous, et deux personnes sur une file non divisée dupliqueront le travail.

5. Seulement maintenant, envisagez la revue par IA. Si le standard peut être écrit, que le volume est élevé et que vous êtes sur Plus ou Enterprise, rédigez le prompt comme le message de rejet que vous seriez à l'aise d'envoyer, car c'est ce qu'il deviendra. Commencez sur une quête et lisez les cinquante premiers commentaires qu'il écrit avant de l'activer ailleurs.

6. Exportez chaque mois et calculez votre propre délai de revue. Zealy ne le calculera pas. Soustrayez l'horodatage de création de chaque claim de son horodatage de mise à jour dans l'export CSV ; c'est exact pour les claims revus une fois, et les claims revus à nouveau nécessitent leur historique de revue. Dix minutes dans un tableur vous disent si tout cela a fonctionné.

Le fil conducteur, c'est que « dois-je recruter » est presque toujours la mauvaise question, posée une décision de conception trop tard. Déléguez d'abord à une règle, car c'est la seule voie où le travail disparaît plutôt que de se déplacer. Déléguez ensuite à une personne, et soyez honnête avec elle sur le pouvoir XP et les collisions. Déléguez enfin à une machine, et seulement quand vous pouvez écrire le standard. Pour le contexte plus large, le module des bases de la gestion de communauté est le complément et la documentation de revue de Zealy couvre la mécanique de la file. Et si vous n'avez pas encore arrêté vos outils, notre enquête sur les logiciels de gestion de communauté chiffre la catégorie au sens large, main-d'œuvre de modération incluse.