Choisir une plateforme de diffusion pour vos agents IA : 12 critères
Douze critères pour choisir une plateforme de diffusion sociale pilotable par un agent IA : MCP et API, clés à scopes, audit, variation par compte et tarifs.
Pour choisir une plateforme de diffusion destinée à des agents IA, vérifiez si un agent peut y accomplir tout le travail : se connecter sans qu'un humain clique d'écran en écran, trouver les bons comptes, construire des publications variées pour chaque compte, attendre la validation, programmer en toute sécurité et lire les résultats compte par compte. Examinez ensuite les garde-fous autour de tout cela : scopes des clés, journal d'audit, API officielles des réseaux et tarifs qui ne pénalisent pas l'automatisation. Une plateforme conçue pour des humains, à laquelle on a ajouté une API après coup, échoue généralement sur deux ou trois de ces points, et c'est précisément là que les projets d'agents s'enlisent.
Les douze critères ci-dessous sont ceux que nous utiliserions pour évaluer n'importe quelle plateforme, y compris la nôtre. Ils sont regroupés en quatre familles (accès, contrôle, qualité de diffusion et adéquation au modèle économique) et se terminent par un court test pratique que vous pouvez mener en un après-midi.
Pourquoi « avoir une API » ne suffit-il plus ?
La plupart des outils social media proposent une API depuis des années. Ces API ont généralement été conçues pour des développeurs qui écrivent des intégrations : on lit la documentation, on écrit du code, on gère l'authentification, on fait correspondre les champs. Un agent fonctionne autrement. Il découvre les opérations à l'exécution, lit les descriptions pour décider quoi appeler, et a besoin d'erreurs structurées sur lesquelles il peut agir. Une plateforme pensée pour les agents expose ses opérations sous forme d'outils via un standard comme le Model Context Protocol, les décrit clairement et limite ce que chaque clé peut faire. Si vous découvrez MCP, commencez par notre explication à l'intention des marketeurs.
Accès : l'agent peut-il joindre la plateforme proprement ?
1. Un serveur MCP distant
L'agent doit pouvoir se connecter via une URL, sans installation locale. Vérifiez le transport. La spécification MCP définit Streamable HTTP pour les serveurs distants. Vérifiez aussi le fonctionnement de l'authentification, et les clients qu'elle permet ou exclut.
2. Une API REST documentée, avec une description OpenAPI
Tous les flux de travail ne tournent pas dans un assistant. Les tâches programmées et les outils internes appellent directement les API. Une description OpenAPI, par exemple le fichier OpenAPI 3.1 de Shager, permet aux développeurs et aux générateurs de code d'utiliser les mêmes opérations que les outils MCP. Vérifiez que les formats de réponse et d'erreur sont cohérents : un agent se remet bien mieux d'un { "error": { "code", "message" } } que d'une page d'erreur HTML.
3. L'auto-inscription de l'agent, avec revendication par un humain
Un agent peut-il créer seul un espace d'essai et transmettre à un humain un lien pour en prendre possession ? Cela supprime l'étape la plus lente de l'évaluation. Le garde-fou : le bac à sable doit rester limité tant qu'un humain ne l'a pas revendiqué. La marche à suivre d'inscription pour les agents de Shager fonctionne ainsi : un bac à sable non revendiqué peut créer des brouillons, mais ne peut ni programmer, ni publier, ni envoyer de demandes de validation, ni créer de liens de connexion.
Contrôle : pouvez-vous limiter et observer ce que fait l'agent ?
4. Des clés à scopes
Des autorisations séparées pour la lecture, l'écriture et la publication constituent le garde-fou le plus important de la diffusion pilotée par des agents. Sans elles, la seule chose qui sépare un prompt d'une publication publique, c'est l'interprétation qu'en fait le modèle.
5. Un journal d'audit des appels d'agents
Vous devez pouvoir consulter chaque appel passé par un agent, avec quelle clé et à quel moment. Demandez si le journal est accessible à l'équipe dans le produit, ou seulement via le support.
6. Des états brouillon et validation gérés comme des objets à part entière
L'agent doit pouvoir créer un brouillon, demander une validation, vérifier son statut et ne programmer qu'ensuite, le tout via des outils. Si la validation oblige le client à créer un compte, attendez-vous à ce que les validations traînent. Notre article sur la validation humaine des publications d'agents explique pourquoi ce point de contrôle se place entre le brouillon et la programmation.
Qualité de diffusion : le résultat sera-t-il sûr et efficace à grande échelle ?
7. Une variation par compte en un seul appel
Cherchez un moyen de définir une légende, un premier commentaire et un format différents pour chaque compte au sein d'une seule requête de publication. Sans cela, les agents envoient soit la même légende partout, soit un appel par compte, ce qui est plus lent et plus difficile à gérer.
8. Un envoi échelonné et une vérification avant envoi
Envoyer sur de nombreux comptes à la même seconde est un schéma que surveillent les plateformes. Vérifiez si la plateforme espace les envois entre les comptes et vous laisse régler l'intervalle, et si elle vérifie chaque publication au regard des règles du réseau cible avant l'envoi.
9. Uniquement les API officielles des réseaux
Demandez sans détour comment la plateforme publie. L'automatisation de navigateur et les identifiants partagés mettent les comptes des clients en danger au regard des conditions d'utilisation des réseaux. La question appelle un oui ou un non, et la réponse doit être donnée par écrit.
10. Une attribution par compte
Une plateforme destinée aux agences doit générer un lien suivi par compte et restituer les clics par compte et par publication via l'API, pour que l'agent puisse produire le bilan hebdomadaire.
Modèle économique : la plateforme convient-elle à l'économie d'une agence ?
11. L'intégration des clients sans mot de passe
La plateforme doit permettre aux clients de connecter leurs propres comptes via un lien, sans créer de compte et sans partager d'identifiants, et un agent doit pouvoir créer ces liens via l'API une fois qu'un humain l'y a autorisé.
12. Des tarifs qui ne taxent pas l'automatisation
Vérifiez si l'accès API et MCP est inclus ou réservé aux formules les plus chères, si chaque relecteur humain coûte une licence, et comment le prix évolue avec le nombre de comptes. Les agences grandissent en nombre de comptes : une tarification au compte avec utilisateurs illimités leur convient donc généralement mieux qu'une tarification à la licence. Les formules de Shager, avec API, MCP et utilisateurs illimités à tous les niveaux, sont présentées sur la page des tarifs.
Comment noter votre présélection ?
Utilisez une grille simple. Notez chaque critère 0, 1 ou 2, et signalez ceux qui sont pour vous éliminatoires.
| Critère | Éliminatoire ? | Plateforme A | Plateforme B | Plateforme C |
|---|---|---|---|---|
| 1. Serveur MCP distant | Oui | |||
| 2. API REST avec OpenAPI | ||||
| 3. Auto-inscription avec revendication | ||||
| 4. Clés à scopes | Oui | |||
| 5. Journal d'audit | Oui | |||
| 6. États brouillon et validation | ||||
| 7. Variation par compte | ||||
| 8. Échelonnement et vérification | ||||
| 9. API officielles uniquement | Oui | |||
| 10. Attribution par compte | ||||
| 11. Liens de connexion client | ||||
| 12. Adéquation des tarifs |
Les critères éliminatoires dépendent de votre activité. Les quatre signalés ici sont ceux sur lesquels nous ne transigerions pas pour un travail client.
Quel test pratique mener ?
La documentation vous dit ce qu'une plateforme a l'intention de faire. Un test vous dit ce qu'un agent peut réellement y faire. Confiez la même tâche à chaque candidate, avec le même assistant.
- Se connecter. Ajoutez le serveur MCP à votre assistant. Chronométrez.
- Découvrir. Demandez : « Que peux-tu faire sur cette plateforme ? » Les descriptions d'outils d'un bon serveur permettent à l'assistant de répondre avec précision.
- Construire. Demandez à l'agent de créer un brouillon pour trois comptes, avec une légende différente pour chacun, un premier commentaire contenant un lien et une vidéo au format vertical.
- Provoquer une erreur. Donnez-lui une vidéo aux mauvaises dimensions pour un Reel. Observez si l'erreur est assez claire pour que l'agent l'explique et la corrige.
- Tester le verrou. Avec une clé dépourvue du droit de publier, demandez à l'agent de programmer. Il doit essuyer un refus net.
- Faire valider. Envoyez une demande de validation à un collègue qui joue le rôle du client. Notez s'il a eu besoin d'un compte.
- Lire les résultats. Demandez les clics par compte sur une période passée.
- Auditer. Retrouvez la trace de tout ce que l'agent vient de faire.
Pour Shager, les étapes 1 à 8 correspondent à whoami, list_workspaces, list_channels, upload_media_from_url, create_post avec per_channel, request_approval, schedule_post et get_analytics, le journal d'audit se trouvant dans le tableau de bord des agents.
FAQ
Faut-il plutôt construire notre propre couche de diffusion sur les API des réseaux ?
C'est possible, et certaines grandes équipes le font. Mettez en balance le coût de l'examen de l'application par chaque réseau, la gestion des jetons, la vérification des formats, les limites de requêtes et les évolutions permanentes des API avec une plateforme qui gère déjà tout cela. Pour la plupart des agences, le coût du développement est difficile à justifier.
Combien de temps doit durer une évaluation ?
Le test pratique ci-dessus prend un après-midi par plateforme. Faites-le suivre de deux semaines de vrais brouillons pour un client avant de vous engager.
Une plateforme doit-elle prendre en charge tous les réseaux dès le premier jour ?
Elle doit prendre en charge les réseaux qu'utilisent vos clients aujourd'hui, avec un plan crédible pour les autres. Shager publie aujourd'hui sur les pages Facebook, les comptes professionnels Instagram, les chaînes YouTube, les comptes X et les profils personnels LinkedIn. TikTok fonctionne aussi, mais tant que TikTok n'a pas validé l'application, les publications ne peuvent viser que des comptes privés et sont publiées en privé.
Si Shager figure dans votre présélection, un agent peut lancer le test lui-même en créant un bac à sable, et le point d'entrée des agents détaille la configuration pour chaque client.
