Automatisation Notion : le choc des Custom Agents à 340 $/mois — plafonner ou reconstruire ?

Le 3 mai, mon automatisation Notion via Custom Agents me coûtait 0 $. Le 4 mai, ces mêmes agents ont commencé à puiser dans les crédits, au tarif de 10 $ pour 1 000 crédits. Sans rien changer, la première projection plaçait mon OS client autour de 340 $/mois.

Le jour où l’automatisation Notion est passée au compteur

Pendant la seconde moitié de la bêta gratuite, j’utilisais les Notion Custom Agents dans un véritable espace de travail dédié aux opérations client : l’OS client de DVNC. Un agent de tri lisait les briefs entrants, un agent produisait chaque jour une synthèse de l’état des missions en cours et un agent de synchronisation maintenait plusieurs bases de connaissances partagées alignées sur les pages de référence. Trois agents tournaient en permanence, auxquels s’ajoutaient quelques autres activés par déclencheur. Coût affiché : zéro.

Le 4 mai 2026, Notion a activé le compteur. Après une bêta gratuite, Custom Agents est passé en disponibilité générale avec une facturation de 10 $ pour 1 000 crédits Notion, en plus de l’abonnement par utilisateur, et uniquement sur les offres Business et Enterprise. Impossible de descendre en gamme tout en conservant la fonctionnalité : les offres Plus et Free n’ont jamais inclus Custom Agents. Il faut donc soit accepter la facturation à l’usage sur Business ou une offre supérieure, soit renoncer entièrement à la fonctionnalité.

Pendant les 48 premières heures, j’ai volontairement laissé les agents fonctionner sans aucune modification. Je voulais mesurer leur consommation réelle, pas travailler à partir d’une estimation. Un opérateur que je suis a publié un chiffre d’environ 337 $ dépensés en un seul mois avec une configuration comparable. Ce montant était très proche de ma propre projection sur 30 jours : ma consommation ne venait donc pas d’une erreur de configuration. C’était le nouveau plancher.

C’est précisément ce que la plupart des récapitulatifs tarifaires ne voient pas. Le 4 mai n’a pas marqué une hausse de prix. Une hausse, c’est une ligne qui passe de 40 $ à 55 $ et un budget que l’on ajuste en conséquence. Ici, une offre gratuite est devenue facturée à l’usage. La différence est fondamentale : toutes les hypothèses de coût qui avaient dicté la configuration, la fréquence et le périmètre des agents étaient désormais fausses, puisque chaque décision reposait sur un « coût du crédit égal à zéro ». La priorité n’était pas de réduire la dépense, mais de repenser le workflow à partir d’un postulat qui venait de disparaître. Notion avait déjà opéré un changement structurellement proche côté développeurs plus tôt dans l’année — voir le mur de crédits des agents externes. Le schéma était donc lisible, mais le reconnaître ne paie pas la facture.

Où partaient réellement les crédits Notion

Ma première décision utile a été de mesurer la consommation agent par agent. L’interface de Notion affiche bien les crédits dépensés à l’échelle de l’espace de travail, mais ne fournit pas par défaut une ventilation claire pour repérer quel agent fait tourner le compteur. Les crédits sont mutualisés dans l’espace et remis à zéro chaque mois. Cela paraît neutre, jusqu’à ce qu’un agent trop bavard ponctionne silencieusement tous les autres workflows d’IA du même espace.

Trois agents représentaient environ 70 % de la consommation. Pas cinq, pas huit. Trois.

L’agent de tri et d’admission — celui qui surveillait une page partagée et classait les nouveaux briefs — était de loin le plus gourmand. Il vérifiait la page toutes les 15 minutes, 24/7. La plupart du temps, rien n’avait changé, mais chaque exécution consommait tout de même des crédits. Le piège, c’est le polling à vide sur des données inchangées. L’agent suivait exactement mes instructions ; simplement, ces instructions étaient devenues coûteuses dès l’activation du compteur.

L’agent chargé de la synthèse client quotidienne arrivait en deuxième position. Il exécutait une tâche par mission active et par jour, répétée sur toute la liste des clients en cours. Le coût unitaire restait raisonnable ; c’est le volume qui posait problème. Un coût par exécution acceptable, multiplié par le nombre de missions puis par 30 jours, produisait à lui seul une facture mensuelle supérieure à l’ensemble des licences Notion du mois précédent.

L’agent de synchronisation documentaire occupait la troisième place, et son cas était le plus intéressant. C’était le moins cher des trois à chaque exécution, mais il se déclenchait à chaque modification. Une seule session de travail sur une page partagée pouvait donc le lancer une douzaine de fois. En pratique, sa fréquence était indexée sur la vitesse de frappe humaine — un choix de configuration que personne ne ferait délibérément à 10 $ les 1 000 crédits.

Reconstituée à partir des dix premiers jours suivant le basculement puis extrapolée sur un mois, l’estimation ressemblait à ceci. Agent de tri : environ 160 $/mois avec la fréquence de polling initiale. Agent de synthèse : environ 95 $/mois avec le nombre actuel de missions. Synchronisation documentaire : environ 45 $/mois au volume de modifications observé. Les quatre agents plus légers se partageaient les quelque 40 $/mois restants. Total : entre 335 $ et 345 $, soit un montant cohérent avec le chiffre public d’un autre opérateur utilisant un espace de travail de forme comparable.

Cette dépense venait s’ajouter à une stack opérationnelle que j’ai déjà détaillée — voir le socle à 387 $/mois. Ajouter une ligne de 340 $ à ce socle aurait fait franchir à l’ensemble un seuil que j’avais explicitement fixé. Ce n’était donc pas « un petit dépassement à absorber », mais un problème structurel.

Plafonner ou reconstruire : trois scénarios chiffrés

Trois options, chacune appuyée par des chiffres réels, mais une seule adaptée à ma charge de travail. Avec les mêmes données, quelqu’un d’autre pourrait arriver à une autre conclusion. C’est justement pour cela qu’il faut faire le calcul au lieu de reprendre une recommandation toute faite.

Option A — rester intégralement facturé à l’usage, sans rien changer. C’est le bon choix lorsque le nombre d’exécutions est faible, que la valeur créée à chaque passage est élevée et que la prévisibilité de la facture compte moins que la maîtrise du coût absolu. Pour un espace lançant chaque jour quelques tâches agentiques à forte valeur — par exemple un agent produisant un livrable précisément cadré qui épargne une heure de travail humain — la tarification à l’usage reste pertinente. Le tarif de 10 $ pour 1 000 crédits n’est pas le scandale ; le vrai problème, ce sont les agents dont le calcul économique ne tient à aucun coût unitaire. Pour cet espace, j’aurais accepté jusqu’à environ 80 $/mois compte tenu de ce qu’il produit. La projection atteignait quatre fois ce plafond. L’option A était écartée.

Option B — plafonner et revoir le périmètre. Supprimer tout polling permanent. Remplacer les déclenchements à intervalles fixes par des événements ou des lancements manuels. Regrouper les synthèses, auparavant exécutées mission par mission, dans un unique traitement quotidien produisant une vue consolidée. Appliquer un debounce à l’agent de synchronisation afin qu’il ne se lance qu’une fois par session de modification, plutôt qu’à chaque édition. Après ce recadrage, la projection tombait à environ 70–85 $/mois : sous le plafond, avec les mêmes livrables essentiels, mais au prix d’une perte sensible d’instantanéité pour le tri. Cet agent s’exécute désormais toutes les deux heures au lieu de toutes les quinze minutes. Ce délai est un vrai coût produit qu’il fallait regarder en face.

Option C — reconstruire sur une infrastructure maîtrisée. Sortir l’agent le plus lourd — celui de tri — de Notion et le recréer sous la forme d’un Cloudflare Worker planifié par cron, appelant directement Claude puis réécrivant le résultat dans la page Notion via l’API. Coût de développement initial : environ 6–8 heures de travail concentré pour une personne déjà familière de ce type d’architecture, ce qui est mon cas. Coût récurrent : le forfait Worker que je paie déjà, plus quelques dollars seulement de tokens Claude par mois à ce volume. Des fondateurs exploitent publiquement des stacks d’agents auto-hébergées comparables, et le calcul devient favorable dès que le volume d’exécution dépasse le seuil de rentabilité.

Seul le seuil de rentabilité compte. Au rythme de mon agent de tri, Notion revenait à environ 160 $/mois. Sur une infrastructure maîtrisée, le coût récurrent tombait à environ 4 $/mois. En amortissant le développement sur 12 mois avec un taux interne généreux de 150 $/heure, le temps consacré représente environ 100 $/mois la première année. Coût total de la reconstruction en année 1 : environ 104 $/mois, contre environ 160 $/mois dans Notion. À partir de l’année 2 : environ 4 $/mois contre environ 160 $/mois. L’investissement est rentabilisé dès la première année, puis l’avantage se cumule.

La même discipline de P&L opérationnel que j’ai appliquée à l’offre Codex vaut ici, mais de l’autre côté de l’équation. Dans ce premier cas, je devais décider s’il fallait changer d’outil pour profiter d’une incitation gratuite ; ici, il s’agit de reconstruire autour d’un outil dont l’économie a changé sous mes pieds. Même méthode, direction opposée.

Ma décision : une architecture hybride. Reconstruire l’agent de tri sur un Worker — l’option C, réservée à la ligne la plus lourde. Plafonner et redimensionner les agents de synthèse et de synchronisation documentaire — l’option B pour les postes intermédiaires. Laisser les quatre agents plus légers entièrement facturés à l’usage — l’option A pour la longue traîne.

Une fois la reconstruction livrée, le coût mensuel projeté de cette approche hybride se situe autour de 45–55 $, auquel s’ajoute une dépense ponctuelle d’environ 7 heures. Face aux 340 $ prévus sans intervention, cela représente quelque 290 $ économisés par mois pour une seule session de développement concentrée. La trajectoire à 30/60/90 jours est la suivante : le premier mois absorbe les heures de reconstruction et reste partiellement facturé à l’usage — environ 110 $ en coût réel équivalent, temps compris ; le deuxième se rapproche du régime de croisière — environ 55 $ ; le troisième l’atteint — environ 45 $.

Ce que j’aurais dû faire autrement — et j’en suis un peu embarrassé — était de mesurer les crédits consommés par chaque agent dès le premier jour de la bêta, pas après l’activation du compteur. Cette période gratuite constituait la fenêtre idéale pour calculer précisément le coût futur de chaque agent selon la tarification à venir, puisque Notion avait publié ses tarifs de crédit bien en amont. Au lieu de cela, j’ai assimilé « gratuit » à « inutile de mesurer ». Reconstituer la consommation agent par agent après coup m’a demandé davantage de temps qu’un suivi en temps réel. Cette règle, je l’applique désormais partout.

La règle avant toute automatisation Notion toujours active

La leçon n’est pas que « Notion Custom Agents coûte trop cher ». Certains de mes agents y tournent encore et y resteront. Elle est plus précise, donc plus utile : une automatisation gratuite en bêta est un passif dans votre graphe de dépendances, pas une fonctionnalité.

Lorsqu’un éditeur propose gratuitement et sans compteur une fonction d’automatisation en bêta, il offre en réalité la possibilité de construire gratuitement votre workflow autour d’un modèle tarifaire qui n’existe pas encore. Dès que ce modèle apparaît, deux choix restent possibles : accepter les montants facturés à l’usage, quels qu’ils soient, ou reconstruire dans l’urgence. Le moment le moins coûteux pour effectuer ce travail se situe avant l’activation du compteur, pas après.

Voici le test que j’applique désormais avant d’intégrer une automatisation gratuite en bêta à un chemin critique :

1. Chiffrer la version facturée avant même que le compteur existe. Si l’éditeur n’a pas encore publié ses tarifs, modéliser un scénario plausible à partir de produits comparables et vérifier si l’agent reste rentable.
2. Mesurer le coût par exécution dès le premier jour. Considérer la période gratuite comme une fenêtre d’observation, pas comme une gratuité sans conséquence.
3. Identifier le chemin de reconstruction avant d’en avoir besoin. Déterminer quels agents devraient migrer vers une infrastructure maîtrisée si l’équation économique basculait, et estimer le nombre d’heures nécessaire.
4. Limiter la fréquence permanente à l’intervalle acceptable le plus lent. Si un polling toutes les 2 heures convient, ne pas le régler sur 15 minutes simplement parce que c’est possible. La cadence est un levier de coût : gratuit à réduire pendant la bêta, beaucoup plus coûteux à ralentir ensuite, lorsque les habitudes de l’équipe se sont déjà formées autour d’une réponse plus rapide.

La solution hybride retenue pour l’OS client n’est pas élégante. Faire cohabiter trois modèles de coût dans un même espace demande davantage de configuration que je n’en prévoirais en partant de zéro. Mais elle épouse la réalité du travail et ramène la facture mensuelle sous le plafond fixé pour cet espace avant l’activation du compteur. C’est le seul test qui compte.

Une automatisation gratuite en bêta est un passif, pas une fonctionnalité. Chiffrez-la avant de l’intégrer, faute de quoi il faudra la reconstruire sous pression lorsque quelqu’un d’autre l’aura décidé.

Combien coûtent les Notion Custom Agents depuis le 4 mai 2026 ?

10 $ pour 1 000 crédits Notion, facturés en plus de l’abonnement. La fonctionnalité est réservée aux offres Business et Enterprise ; les offres Free et Plus ne l’ont jamais incluse.

Peut-on conserver Custom Agents avec l’offre Plus pour éviter les crédits ?

Non. Custom Agents n’a jamais été disponible sur Free ou Plus : aucune rétrogradation ne permet donc de le conserver. Il faut soit utiliser Business ou une offre supérieure avec facturation à l’usage, soit renoncer à la fonctionnalité.

Que se passe-t-il lorsqu’un espace de travail n’a plus de crédits ?

Les Custom Agents s’arrêtent. Les autres fonctions de Notion AI, comme Meeting Notes et Notion Agent dans sa version standard, continuent de fonctionner dans la limite de l’usage raisonnable prévu par l’offre sous-jacente.

Reconstruire ses agents sur sa propre infrastructure coûte-t-il moins cher ?

Seulement au-delà d’un certain volume d’exécution. En dessous du seuil de rentabilité, le coût des crédits à l’usage reste inférieur aux heures de développement et de maintenance. Au-dessus — surtout pour des agents permanents lancés plusieurs fois par jour — l’infrastructure maîtrisée creuse son avantage à partir de la deuxième année.