La partie planification d’un planificateur de réseaux sociaux se boucle en un week-end. Une file d’attente, un worker, un cron. Ce n’est vraiment pas difficile, et c’est pour cela que l’estimation est toujours fausse.
Tout ce qui coûte cher se trouve de l’autre côté.
La partie facile
Une table de publications avec une heure planifiée, un worker qui se réveille, trouve les publications dues et les publie. Ajoutez une nouvelle tentative et c’est terminé.
Si vous construisez cela comme projet d’apprentissage ou pour une seule plateforme que vous contrôlez, arrêtez de lire ici. La suite concerne ce qui se passe quand de vrais comptes et plusieurs plateformes entrent en jeu.
Le modèle de données dont vous avez réellement besoin
Plus d’états que ce à quoi on s’attend :
- draft, créé mais pas mis en file d’attente
- scheduled, mis en file d’attente pour une heure donnée
- processing, envoyé à la plateforme, résultat inconnu
- published, confirmé
- failed, avec une raison
- partial, publié sur certaines cibles et pas d’autres
processing existe parce que plusieurs plateformes acceptent une publication et la publient de façon asynchrone. Un 200 n’est pas une publication, et le résultat arrive plus tard, hors bande. Sans cet état, votre interface affiche un succès qui peut parfois être faux.
partial existe parce qu’une publication cible généralement plusieurs plateformes. Trois réussissent, une échoue. Ni “published” ni “failed” n’est vrai, et forcer l’un ou l’autre produit un produit qui ment à ses utilisateurs.
Il vous faut aussi des lignes par cible plutôt qu’un statut unique sur la publication, car l’échec est propre à chaque plateforme.
Fuseaux horaires
Stockez l’instant et le fuseau IANA, pas un décalage.
“Tous les jours de semaine à 9h heure locale” correspond à un instant UTC différent avant et après un changement d’heure d’été. Ne stocker que l’UTC fonctionne jusqu’en mars, puis tout dérive d’une heure et les rapports de bugs deviennent confus, car c’est correct la moitié de l’année.
Le travail par plateforme
C’est ici que l’estimation s’effondre. Par plateforme :
Un flux OAuth séparé. Scopes différents, durées de vie de jetons différentes, écrans de consentement différents.
Un job de rafraîchissement séparé. C’est celui qui fait mal. Les jetons expirent, le rafraîchissement échoue silencieusement, et personne ne le découvre avant qu’une publication planifiée ne parte pas. Il vous faut un rafraîchissement planifié, une surveillance des échecs de rafraîchissement, un état de connexion cassée et un flux de reconnexion. C’est plus de travail que le flux OAuth lui-même.
Un pipeline média séparé. Une plateforme récupère une URL, une autre veut un envoi en morceaux reprenable, une autre veut des dimensions ou codecs spécifiques. Vous devrez héberger et éventuellement transcoder.
Une limite de débit séparée, avec sa propre fenêtre et son propre comportement en cas de dépassement.
La revue d’application. Plusieurs plateformes conditionnent la publication à une revue impliquant votre application, une politique de confidentialité et parfois une vidéo de démonstration. C’est du temps calendaire que vous ne contrôlez pas, et cela peut être refusé.
Le changement perpétuel. Les versions d’API sont dépréciées, les champs renommés, les permissions resserrées, selon le calendrier des plateformes. Chacun est un travail imprévu avec une échéance que vous n’avez pas fixée.
Multipliez par le nombre de plateformes. Puis continuez à le payer, pour toujours.
Les règles de publication
Au-delà de la livraison, ce que les utilisateurs veulent réellement, c’est ne pas publier quelque chose qui sera rejeté. Cela signifie encoder par plateforme :
- Les limites de caractères
- Le nombre, la taille, le format, la durée et le ratio d’aspect des médias
- Quels types de publication nécessitent des médias
- Quels formats existent tout court
Et valider à la création plutôt qu’à la publication, car un échec au moment de la publication est un échec que l’utilisateur découvre après coup, le moment déjà passé.
Construisez-le si
- Vous publiez sur exactement une plateforme, en permanence
- La publication est votre produit et votre différenciateur
- Vous avez besoin d’une profondeur bien au-delà de la publication, comme la gestion publicitaire
Ne le construisez pas si
La publication est une fonctionnalité de quelque chose d’autre que vous construisez et elle touche trois plateformes ou plus. Le coût n’est pas la construction, c’est la maintenance, et la maintenance grandit avec le nombre de plateformes alors que votre équipe, elle, ne grandit pas.
L’alternative
Une seule intégration, où le renouvellement des plateformes devient le problème de quelqu’un d’autre.
- URL de base :
https://app.bulkpublish.com - Authentification : clé API, ou OAuth 2.1 si vous agissez au nom des comptes de vos utilisateurs
- Surface : 59 endpoints documentés
- Plateformes : 15
- Validation : limites vérifiées à la création, pas à la publication
- SDK : Node et Python, plus une collection Postman et un serveur MCP
| Free | Pro | Business | |
|---|---|---|---|
| Requêtes API/jour | 30 | 5 000 | 50 000 |
| Clés API | 1 | 5 | 10 |
En bref
La file d’attente se boucle en un week-end. Les états, les fuseaux horaires, et un flux OAuth plus un job de rafraîchissement plus un pipeline média par plateforme constituent le véritable projet, et le renouvellement des plateformes fait qu’il ne se termine jamais. Construisez-le si la publication est votre produit ou si vous restez sur une seule plateforme pour toujours. Sinon, l’intégration que vous n’entretenez pas vaut plus que celle que vous entretenez.