Un agent qui publie sur les réseaux sociaux a des exigences différentes de celles d’une personne qui le fait, et la plupart découlent du même fait : personne ne surveille au moment où il agit.
Ce dont un agent a besoin, contrairement à une personne
Un état de brouillon réellement utile. Pas une file cachée, mais des publications qu’un humain peut voir, réviser et publier. C’est la fonctionnalité la plus importante pour la publication par un agent, et c’est celle le plus souvent traitée comme un à-côté.
La validation avant la publication, pas au moment de la publication. Une personne remarque qu’une légende est trop longue. Un agent non, et si la vérification a lieu au moment de la publication, l’échec survient des heures plus tard, une fois l’agent parti. Les erreurs doivent revenir sur l’appel de création, là où l’agent peut réagir.
Des identifiants restreints et révocables. Séparés de vos autres clés. Quand quelque chose tourne mal, vous voulez révoquer exactement l’agent, pas faire tourner l’identifiant que partage votre pipeline de production.
Des quotas qui arrêtent une boucle. Une boucle de nouvelles tentatives peut produire beaucoup de publications rapidement. Un plafond strict est ici une fonctionnalité de sécurité, pas seulement un palier de facturation.
Des erreurs structurées. Un agent peut agir sur « la légende dépasse 280 caractères sur x ». Il ne peut rien faire d’un 400 générique.
Les modes de défaillance contre lesquels concevoir
L’invention avec assurance. Un modèle produira une statistique, un prix ou une affirmation de fonctionnalité plausible plutôt que de dire qu’il ne sait pas. Rien de factuel ne devrait être généré. Les faits viennent d’une source que votre code contrôle.
Les tempêtes de nouvelles tentatives. Un agent qui traite un délai dépassé comme un échec et réessaie peut dupliquer des publications, car une création qui a expiré peut avoir réussi. Les nouvelles tentatives doivent être sûres ou vérifiées, jamais aveugles.
Publier au mauvais moment. Un agent n’a aucune idée qu’aujourd’hui est un mauvais jour pour publier quelque chose de joyeux. Tout ce qui touche à l’actualité ou à la controverse a besoin d’un humain.
La dérive de ton. Livrés à eux-mêmes, les posts générés convergent vers le même registre, et une audience le remarque avant vous.
MCP contre une clé API
Deux façons de connecter un agent, et elles conviennent à des situations différentes.
MCP, quand l’agent est un assistant comme Claude ou un éditeur doté d’IA. Le serveur expose des outils nommés, l’assistant choisit lesquels appeler. Le moins de travail, et le bon choix pour une personne qui travaille de façon conversationnelle.
Une clé API, quand vous avez écrit l’agent vous-même et qu’il tourne sans supervision. Des appels directs, votre propre flux de contrôle, votre propre gestion des erreurs.
OAuth, si votre agent agit pour le compte des comptes d’autres personnes plutôt que du vôtre. Chaque utilisateur autorise plutôt que de coller un identifiant.
Ce que fournit BulkPublish
- Serveur MCP :
@bulkpublish/mcp-server - API : 59 points de terminaison documentés couvrant les publications, la planification, les médias, les canaux, les labels, l’analytique, les flux RSS et les quotas
- Authentification : clé API (
Bearer bp_...), ou OAuth 2.1 avec des scopes granulaires - Plateformes : 15
- Validation : limites de caractères et règles de médias par plateforme vérifiées à la création de la publication, pas à la publication
| Free | Pro | Business | |
|---|---|---|---|
| Requêtes API/jour | 30 | 5 000 | 50 000 |
| Clés API | 1 | 5 | 10 |
| Publications | 3/jour | 30/jour | Illimité |
Les publications peuvent être créées comme brouillons, ce qui est le réglage sur lequel commencer et, pour la plupart des usages, sur lequel rester.
Les scopes OAuth sont granulaires (posts:read, posts:write, media:read, media:write, analytics:read, channels:read, full), de sorte qu’un agent qui n’a besoin que de créer des brouillons n’obtient pas la capacité de supprimer.
En résumé
Un agent a besoin d’un véritable état de brouillon, d’une validation à la création plutôt qu’à la publication, d’identifiants restreints qu’il peut perdre sans rien emporter d’autre, et de quotas qui arrêtent une boucle. Donnez-lui le scope le plus étroit qui suffit à la tâche, ne le laissez jamais générer un fait, et gardez un humain entre la génération et la publication tant que vous n’avez pas une bonne raison de faire autrement.