Comment la limite de débit business use case de Meta mesure les Pages Facebook

Qu'est-ce que la limite de débit business use case de Meta pour les Pages ?

Pour les Pages, la limite de débit business use case de Meta est le budget d'appels sur 24 heures que Meta applique aux requêtes de la Pages API faites avec un jeton d'accès de Page ou un jeton d'accès d'utilisateur système. La référence de Meta sur la limitation de débit de la Graph API donne la formule en une ligne :

Calls within 24 hours = 4800 * Number of Engaged Users

La phrase au-dessus de la formule en fixe les termes : « Requests made by your app to the Pages API using a Page access token or system User access token are counted against the app's call count. An app's call count is the number of calls it can make during a rolling 24 hour window. »

Le budget appartient donc à l'application, la fenêtre est glissante au lieu de se réinitialiser à minuit, et la taille du budget varie avec le nombre de personnes qui ont interagi avec la Page au cours de la dernière journée. Une Page avec 50 utilisateurs engagés finance 240 000 appels en 24 heures. Une Page sans aucun utilisateur engagé en finance zéro, selon la même arithmétique.

Le business use case, que Meta abrège en BUC, est l'un des deux systèmes de limitation de débit de Meta. L'autre est Platform Rate Limits, le système au niveau de l'application et de l'utilisateur sur lequel l'en-tête x-app-usage rend compte. Les Pages sont l'endroit où Meta sépare les deux selon le jeton.

Quels jetons placent les appels aux Pages sous la limite business use case ?

C'est le jeton d'accès qui décide, et rien d'autre. Meta énonce la séparation en haut de la référence sur la limitation de débit : « requests made with application or user access tokens are subject to Platform Rate Limits, while requests made with system user or page access tokens are subject to Business Use Case Rate Limits. »

Le même appel à POST /{page-id}/feed atterrit dans un système différent selon l'identifiant que votre application envoie. La publication repose sur les jetons de Page, car la référence Page Feed exige « A Page access token » pour publier au nom de la Page, et un jeton d'accès de Page dérivé d'un jeton utilisateur longue durée n'a pas de date d'expiration. Ces appels relèvent des limites business use case.

Meta recommande aussi la voie business use case pour lire les Pages publiques. Les références Page Feed et Page Photos disent toutes deux : « When using the Page Public Content Access feature, use a system user access token to avoid rate limiting issues. » Meta ne donne aucune raison, mais l'effet est clair : un jeton d'utilisateur système fait passer ces lectures du budget Platform horaire au budget business use case de 24 heures.

Quand les deux systèmes pourraient s'appliquer, Meta tranche : « If both Platform and Business Use Case rate limits can be applied to a request, BUC rate limits will be applied. »

Qu'est-ce qui compte comme utilisateur engagé pour la limite des Pages ?

Toute la définition de Meta tient en une phrase : « The Number of Engaged Users is the number of Users who engaged with the Page per 24 hours. » Elle ne nomme aucune action qualifiante. Les J'aime, les commentaires, les partages et les clics n'y figurent pas.

La même page réutilise ensuite le terme avec un autre sens. Dans la section Messenger, la formule est Calls within 24 hours = 200 * Number of Engaged Users, et Meta la définit autrement : « The Number of Engaged Users is the number of people the business can message via Messenger. » Deux formules d'un même document emploient le même terme pour deux populations différentes, avec des multiplicateurs de 4800 et de 200.

Il n'y a pas non plus de plancher. La section Threads de la même référence en fixe un explicitement : « The minimum value for impressions is 10 (so if the impressions is less than 10 we default to 10). » La section Pages n'a aucune ligne équivalente. Une Page toute neuve, ou une Page en sommeil, a une formule qui multiplie 4800 par un nombre proche de zéro.

La formule laisse aussi une question ouverte. Elle dimensionne le budget d'après l'engagement d'une seule Page, mais elle impute les appels à ce que Meta appelle « the app's call count ». Meta ne dit pas si deux Pages connectées à la même application puisent dans deux budgets ou dans un seul. L'en-tête, abordé ensuite, indexe la consommation par un ID que le tableau des champs de Meta décrit comme « The ID of the business associated with the token making the API calls ». C'est une entreprise, pas une Page, et le texte ne dit jamais comment le budget d'une Page se rattache à elle.

Comment lire X-Business-Use-Case-Usage pour les appels aux Pages ?

Meta joint cet en-tête aux réponses traitées selon la logique business use case et le décrit comme « a JSON-formatted string that describes current application rate limit usage. This header can return up to 32 objects in one call. » Les entrées sont indexées par ID d'objet business, et le type de chaque entrée nomme la limite dont elle rend compte. Pour les appels aux Pages, la valeur à rechercher est pages.

L'exemple de Meta montre une entrée Pages comme celle-ci :

"10153848260347724": [
  {
    "type": "pages",
    "call_count": 97,
    "total_cputime": 23,
    "total_time": 23,
    "estimated_time_to_regain_access": 0
  }
]

Deux problèmes se logent dans l'exemple même de Meta. D'abord, la clé 10153848260347724 apparaît deux fois dans l'exemple, une fois avec une entrée ads_insights et une fois avec l'entrée pages. JSON ne l'interdit pas, mais la RFC 8259 le déconseille : « The names within an object SHOULD be unique », et quand ils ne le sont pas, « the behavior of software that receives such an object is unpredictable. Many implementations report the last name/value pair only. » JSON.parse en JavaScript garde la dernière. Si l'en-tête réel répète un jour une clé comme le fait l'exemple, un parseur standard écarte silencieusement l'une des deux entrées, alors parcourez chaque entrée et filtrez sur type au lieu de chercher une clé unique.

Ensuite, call_count est défini sur « a rolling one hour period » alors que la formule des Pages compte les appels sur « a rolling 24 hour window ». La section Instagram du même document présente exactement le même décalage. Meta ne dit pas quelle fenêtre utilise le pourcentage des Pages. Organisez-vous autour de la fenêtre de 24 heures, puisque c'est celle de la formule des Pages.

Les bonnes pratiques sous cet en-tête ont été écrites pour la publicité, jusqu'à « Switch to other ad accounts and come back to this account later. » Aucune ne mentionne les Pages.

Que se passe-t-il quand une Page atteint sa limite business use case ?

Les appels échouent avec l'erreur 80001. La réponse d'exemple de Meta :

{
  "error": {
    "message": "(#80001) There have been too many calls to this Page account. Wait a bit and try again. For more info, please refer to https://developers.facebook.com/docs/graph-api/overview/rate-limiting.",
    "type": "OAuthException",
    "code": 80001,
    "fbtrace_id": "AmFGcW_3hwDB7qFbl_QdebZ"
  }
}

Les références Page Photos et Page Post reprennent le même texte pour 80001 dans leurs propres tableaux d'erreurs, c'est donc bien le code que rencontre réellement une tâche de publication ou de lecture.

Le message dit « Wait a bit and try again. » La section des bonnes pratiques sur la même page dit quelque chose de plus strict : « When the limit has been reached, stop making API calls. Continuing to make calls will continue to increase your call count, which will increase the time before calls will be successful again. » Suivez la seconde. Lisez estimated_time_to_regain_access dans l'entrée pages, mettez la file de cette Page en pause pendant autant de minutes, et ne sondez pas avec des appels de test entre-temps.

Le tableau d'erreurs de Meta pour les limites business use case contient une coquille à signaler. Il liste « error code 32 » face à « Page calls made with a User access token », dans un tableau consacré aux limites business use case, alors que le même document dit que les appels aux Pages avec un jeton utilisateur suivent la logique Platform. Le tableau Platform est le bon : le code 32 « Indicates that the User or app whose token is being used in the Pages API request has reached its rate limit. » Traitez 32 comme une erreur Platform et 80001 comme l'erreur business use case, et orientez-les vers des chemins de reprise différents.

Rien de tout cela ne dit combien de publications une Page peut faire. Les limites de publication quotidiennes de Facebook forment un système distinct, avec ses propres échecs.

En quoi la limite business use case diffère-t-elle de la limite au niveau de l'application ?

Presque toutes les propriétés diffèrent, y compris l'unité de temps. Les multiplicateurs sont plus proches qu'il n'y paraît : 200 appels par heure pendant 24 heures font 4800 appels par jour, donc les deux formules accordent le même débit quotidien par personne comptée. Ce qui change, c'est qui est compté.

Un outil de planification avec peu d'utilisateurs actifs quotidiens mais des Pages clientes très actives obtient bien plus de marge avec des jetons de Page qu'avec des jetons d'application. Une application populaire branchée sur des Pages calmes obtient l'inverse.

Le multiplicateur 4800 n'est pas propre aux Pages. Meta utilise le même nombre pour Instagram, où il multiplie les impressions au lieu des utilisateurs engagés, et la version Instagram de cette formule a ses propres bizarreries d'en-tête. Seule la version Pages dépend du jeton que vous envoyez.

Questions fréquentes

Quelle est la formule de la limite de débit business use case de Meta pour les Pages ?

Calls within 24 hours = 4800 * Number of Engaged Users, où Meta définit les utilisateurs engagés comme « the number of Users who engaged with the Page per 24 hours. » Elle s'applique aux appels à la Pages API faits avec un jeton d'accès de Page ou d'utilisateur système.

Quel code d'erreur signifie qu'une Page a atteint sa limite business use case ?

L'erreur 80001, avec le message « There have been too many calls to this Page account. Wait a bit and try again. » L'erreur 32 est le code Platform Rate Limits pour les appels à la Pages API faits avec un jeton utilisateur ou d'application.

Un jeton d'accès utilisateur utilise-t-il la limite business use case sur les Pages ?

Non. Meta oriente les appels à la Pages API faits avec des jetons d'accès d'application ou d'utilisateur vers les Platform Rate Limits. Les appels faits avec un jeton utilisateur comptent dans le quota horaire propre à cet utilisateur, que Meta ne communique pas, et ceux faits avec un jeton d'application comptent dans le budget horaire de l'application, 200 * Number of Users. Seuls les jetons de Page et d'utilisateur système utilisent la limite business use case.

Combien de temps attendre après l'erreur 80001 ?

Lisez estimated_time_to_regain_access dans l'entrée pages de l'en-tête X-Business-Use-Case-Usage. Meta le définit comme le temps, en minutes, jusqu'à ce que les appels ne soient plus limités. N'effectuez aucun appel sur cette Page d'ici là, puisque Meta indique que de nouveaux appels prolongent le blocage.

Que signifie « engaged users » dans la limite de débit des Pages de Meta ?

Meta dit seulement qu'il s'agit du nombre d'utilisateurs qui ont interagi avec la Page sur 24 heures, et ne liste aucune action qualifiante. La même page sur la limitation de débit emploie « Engaged Users » pour Messenger avec une autre définition, le nombre de personnes auxquelles l'entreprise peut envoyer un message.

Pourquoi Meta recommande-t-il un jeton d'utilisateur système pour Page Public Content Access ?

Les références Page Feed et Page Photos demandent aux applications qui utilisent Page Public Content Access d'employer un jeton d'accès d'utilisateur système « to avoid rate limiting issues. » Un jeton d'utilisateur système fait passer ces lectures du budget Platform horaire au budget business use case de 24 heures.

Quelle différence y a-t-il entre l'erreur 80001 et l'erreur 32 sur les appels aux Pages ?

L'erreur 80001 est l'erreur business use case pour les jetons de Page et d'utilisateur système, avec le message "There have been too many calls to this Page account". L'erreur 32 est un code des Platform Rate Limits pour les appels à l'API des Pages faits avec un jeton d'utilisateur ou d'application. Le tableau d'erreurs de Meta pour les limites business use case liste 32 pour les appels avec jeton d'utilisateur, ce qui contredit le reste du document. Traitez 32 comme une erreur Platform et orientez les deux erreurs vers des chemins de reprise différents.

Combien d'appels une Page Facebook avec 50 utilisateurs engagés obtient-elle en 24 heures ?

La Page finance 240 000 appels, soit 4800 multiplié par 50, sur une fenêtre glissante de 24 heures. Une Page sans utilisateur engagé finance zéro selon le même calcul. La section sur les Pages ne fixe aucun minimum, contrairement à celle de Threads, qui ramène les impressions à 10 au minimum.

Deux Pages connectées à la même application partagent-elles un seul budget de limite de débit ?

Meta ne le précise pas. La formule dimensionne le budget d'après l'engagement d'une Page, mais elle impute les appels au compteur d'appels de l'application. L'en-tête X-Business-Use-Case-Usage classe l'usage par l'ID de l'entreprise associée au jeton, pas par Page. Lisez donc chaque entrée au lieu de supposer un budget distinct par Page.

La limite business use case plafonne-t-elle le nombre de publications d'une Page ?

Elle plafonne les appels d'API, pas les publications. Les limites quotidiennes de publication de Facebook forment un système à part, avec ses propres erreurs. Les appels de publication vers POST /{page-id}/feed comptent quand même dans le budget d'appels, car ils passent par des jetons de Page.