Comprendre la tarification des workers (bêta)

Les workers exécutent du code en arrière-plan pour automatiser des tâches dans Notion. Ils sont parfaits pour les tâches qui ne nécessitent pas de raisonnement par l’IA, telles que la synchronisation de données, la rédaction de mises à jour et la gestion d’événements. Les workers sont souvent associés à des agents personnalisés : l’agent décide de ce qu’il faut faire et les workers exécutent efficacement des étapes spécifiques.

Pendant la phase bêta, les workers sont gratuits pour les forfaits Business et Enterprise (y compris les essais Business). À partir du 11 août 2026, ils nécessiteront des crédits Notion. Les administrateur·rices d’espace de travail peuvent acheter des crédits Notion en tant que module complémentaire pour les forfaits Business et Enterprise.

La période bêta gratuite s’applique uniquement aux workers. Les actions des agents personnalisés consommeront des crédits en fonction de l’offre et des paramètres de crédits de votre espace de travail.

Les workers utilisent des crédits Notion qui sont comptabilisés sous forme d’exécutions. Chaque exécution représente une unité de travail effectuée en votre nom. Le nombre de crédits par exécution peut varier en fonction de la quantité de travail effectuée par le worker, par exemple la durée de son exécution ou la quantité de traitement nécessaire. En général, plus la tâche est importante, plus le nombre de crédits consommés est élevé.

Les workers peuvent s’exécuter de plusieurs manières (nous continuerons à étoffer cette liste) :

• Synchronisations (programmées) : Chaque synchronisation compte comme une exécution.

• Appels d’outils (déclenchés par l’agent) : Chaque appel d’outil de worker déclenché par un agent personnalisé compte comme une exécution.

• Webhooks (déclenchés par des événements) : Chaque événement traité par un worker compte comme une exécution.

Les workers coûtent généralement 0,0023 $ par exécution, ce qui correspond à environ 4348 exécutions pour 1000 crédits Notion par mois (10 $). Ils sont moins chers que les agents personnalisés, car leur tarification est basée sur la quantité de travail qu’ils effectuent lorsqu’ils s’exécutent sans nécessiter une de prise de décision par l’IA.

Les tables ci-dessous présentent de manière détaillée les coûts de référence pour chaque type d’action des workers. Utilisez ces informations comme point de départ pour comprendre les coûts. Votre utilisation réelle peut varier et constitue le meilleur moyen de déterminer la quantité de crédits nécessaire.

Les exemples ci-dessous montrent les types d’utilisation de la synchronisation. Votre utilisation réelle dépend de la fréquence d’exécution de vos synchronisations et de la quantité de travail effectuée par un worker lors de chaque exécution.

La synchronisation d’un plus grand nombre de données ou la gestion de plusieurs mises à jour coûtera plus cher. Si vous avez plusieurs synchronisations, plusieurs workers ou des workers qui s’exécutent en réponse à de nombreux événements, l’utilisation totale peut être plus élevée.

Exemple 1 : Une synchronisation nocturne transfère les tickets Jira clôturés dans un journal d’ingénierie Notion pour un examen hebdomadaire.

• Fréquence de synchronisation : Tous les jours (faible)

• Exécutions par jour : 1

• Coût par mois : 0,07 $

Exemple 2 : Une synchronisation Zendesk par heure actualise les tickets ouverts et le risque lié au SLA dans un tableau de bord des opérations d’assistance dans Notion, afin que les chef·fes d’équipe puissent rééquilibrer la couverture au fil de la journée.

• Fréquence de synchronisation : Toutes les heures (moyen)

• Exécutions par jour : 24

• Coût par mois : 1,66 $

Exemple 3 : Une synchronisation du pipeline maintient à jour un outil de suivi des ventes dans Notion avec les étapes des opportunités Salesforce tout au long de la journée de travail.

• Fréquence de synchronisation : Toutes les 15 minutes (élevé)

• Exécutions par jour : 96

• Coût par mois : 6,62 $

Les workers peuvent également alimenter des outils personnalisés utilisés par les agents personnalisés. Par exemple, un agent personnalisé peut appeler un worker pour récupérer des données d’un autre système, effectuer un calcul ou mettre à jour des enregistrements.

L’utilisation des appels d’outils dépend de la fréquence à laquelle un agent appelle un worker. Chaque appel d’outil compte comme une exécution de worker distincte (ainsi, une exécution d’agent peut générer plusieurs exécutions de worker).

Exemple 1 : Chaque jour, un agent de suivi des bugs examine les tickets Jira ouverts. À chaque exécution, le worker récupère l’état du ticket, cherche les obstacles et rédige un résumé sur une page de projet Notion.

• Volume d’appels d’outils : Planifié (faible)

• Exécutions de worker : Trois par exécution de l’agent personnalisé

• Exécutions de l’agent personnalisé : 30 par mois

• Coût par mois : 0,21 $

Exemple 2 : Un agent RevOps s’exécute lorsqu’une transaction passe à une étape suivante dans Salesforce. Chaque exécution déclenche le processus de validation des champs obligatoires, l’appel à Clearbit pour l’enrichissement et l’écriture de l’enregistrement dans un outil de suivi de pipeline Notion.

• Volume d’appels d’outils : Déclenché par une activité (moyen)

• Exécutions de worker : Quatre par exécution de l’agent personnalisé

• Exécutions de l’agent personnalisé : 3000 par mois

• Coût par mois : 27,60 $

Exemple 3 : Un agent Support Eng s’exécute pour chaque ticket Zendesk entrant. À chaque exécution, le worker récupère le ticket, extrait le contexte du compte Salesforce, applique les règles de routage de Notion et publie sur le canal Slack approprié.

• Volume d’appels d’outils : En continu (élevé)

• Exécutions du worker : Cinq par exécution de l’agent personnalisé

• Exécutions de l’agent personnalisé : 9000 par mois

• Coût par mois : 103,50 $

Les exemples ci-dessous présentent des volumes de webhooks typiques et leur coût potentiel. Votre utilisation réelle dépend du nombre d’événements envoyés par vos outils et du nombre de déclencheurs de webhooks que vous avez configurés. Chaque événement entrant que vous traitez compte comme une exécution par un worker. Le coût total évolue donc en fonction de votre volume d’événements.

Exemple 1 : Un webhook Stripe se déclenche lors de la création et de la résiliation d’un abonnement. Le worker met à jour un outil de suivi de la facturation Notion en y ajoutant les détails de l’événement.

• Volume d’événements entrants : Faible

• Événements par jour : 20

• Coût par mois : 1,38 $

Exemple 2 : Un webhook GitHub se déclenche à chaque fusion de pull request sur 10 dépôts. Le worker enregistre chaque fusion dans un journal des modifications Notion et notifie le canal Slack concerné.

• Volume d’événements entrants : Moyen

• Événements par jour : 200

• Coût par mois : 13,80 $

Exemple 3 : Un webhook Zendesk se déclenche à chaque création de ticket et à chaque changement d’état. Le worker enrichit chaque événement avec les données du compte Salesforce et met à jour un tableau de bord d’assistance Notion.

• Volume d’événements entrants : Élevé

• Événements par jour : 5000

• Coût par mois : 345,00 $

Dans la version bêta gratuite, vous pouvez suivre l’utilisation des crédits par le worker au cours des 30 derniers jours directement dans la CLI. L’utilisation des Workers apparaîtra également dans le tableau de bord des crédits Notion d’ici fin mai, permettant aux administrateur·rices de suivre l’utilisation des crédits de leurs Workers et Agents personnalisés au même endroit.

Affiche une ventilation détaillée de l’utilisation d’un worker au cours des 30 derniers jours. Cela comprend les crédits d’aperçu estimés, le nombre d’exécutions et les métriques d’exécution/de réseau qui aident à expliquer ce qui génère l’utilisation.

% ntn workers usage
ID 019e1dda-fbf0-7eb0-aa37-8d3c11ee6c2d
Nom ntn-worker-usage-validation
ID de l’espace b07104cd-477e-8123-9b74-0003e5d75c7b
Période 30 derniers jours
Crédits estimés pour l’aperçu 0,39
Exécutions 2
Durée d’activité CPU 4 582 ms
Durée du Wall 5 138 ms
Transfert réseau 0,02 Mo entrant / 0,02 Mo sortant

Affiche un résumé de tous les workers, y compris l’estimation des crédits d’aperçu utilisés et les exécutions au cours des 30 derniers jours.

ntn workers usage --all
ID NOM EST. CRÉDITS
019e1dda-fbf0-7eb0-aa37-8d3c11ee6c2d ntn-worker-usage-validation 0,39

FENÊTRE D’EXÉCUTIONS
2 30 j

Vous pouvez gérer les workers dans votre espace de travail en allant dans Paramètres et en sélectionnant l’onglet Workers.

Depuis cette interface, vous pouvez :

• Activer ou désactiver les workers pour votre espace de travail. Par défaut, les workers sont désactivés.

• Contrôler qui peut utiliser les workers, y compris des personnes ou des groupes d’utilisateur·rices spécifiques.

• Suivre et gérer les workers individuels.

  • Afficher tous les workers de votre espace de travail, y compris leur propriétaire et leur état.

  • Désactivez ou supprimez un worker à tout moment.

  • Suspendre tous les workers.

Les Workers sont gratuits dans la version bêta ; vous pouvez donc profiter de cette période pour exécuter des processus réels et estimer le nombre de crédits dont vous aurez besoin une fois que les crédits seront appliqués.

Essayez d’appliquer les meilleures pratiques ci-dessous pour que l’utilisation des Workers reste prévisible :

• Commencez par une fréquence peu élevée. Pour les synchronisations, commencez par des exécutions horaires ou quotidiennes si des mises à jour en temps réel ne sont pas nécessaires.

• Augmentez la fréquence uniquement si nécessaire. Passez à une fréquence de 15 minutes, 5 minutes ou une minute uniquement si le flux de travail l’exige.

• Effectuez des traitements par lots autant que possible. Au lieu d’exécuter un Worker pour chaque petit changement, regroupez les mises à jour.

• Synchronisez uniquement ce dont vous avez besoin. Synchronisez uniquement les bases de données, les enregistrements ou les champs nécessaires.

• Évitez les nouvelles tentatives inutiles. Si un Worker échoue, assurez-vous qu’il ne fait pas de nouvelles tentatives trop fréquemment sans que le problème sous-jacent soit résolu.

• Examinez régulièrement l’utilisation. Vérifiez l’utilisation de la CLI lors de la configuration et après des modifications majeures du flux de travail.