Publier immédiatement via une API est simple. C’est la planification qui pose les problèmes intéressants, parce qu’une publication planifiée est une promesse sur l’avenir, et l’avenir contient le changement d’heure, des pannes et des publications sur lesquelles on change d’avis.
Fuseaux horaires : passez-en un explicitement
Le bug de planification le plus courant est une publication qui dérive d’une heure deux fois par an.
Une heure planifiée a besoin de deux choses : l’instant, sous forme d’horodatage ISO-8601, et le fuseau dans lequel il a été exprimé, sous forme de nom IANA comme America/New_York.
await bp.posts.create({
content: 'Morning update.',
channels: [{ channelId: 1, platform: 'linkedin' }],
status: 'scheduled',
scheduledAt: '2026-04-10T14:00:00Z',
timezone: 'America/New_York',
});Ne stocker qu’un instant UTC convient pour un cas ponctuel. C’est faux pour tout ce qui est récurrent, car « chaque jour ouvré à 9 h heure locale » correspond à un instant UTC différent avant et après un changement d’heure. C’est le fuseau qui rend cela correct.
Ne stockez jamais un décalage brut comme -05:00 en substitut d’un fuseau. Les décalages changent, pas les fuseaux.
Modélisez plus de deux états
Une publication n’est pas seulement planifiée ou publiée. Construisez au moins pour :
- draft, créée mais non mise en file d’attente
- scheduled, en file d’attente pour une heure
- processing, envoyée à la plateforme, résultat inconnu
- published, confirmée en ligne
- failed, avec une raison
- partial, publiée sur certaines cibles et pas d’autres
Les deux qu’on oublie sont processing et partial.
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 réel arrive plus tard.
partial existe parce qu’une publication cible généralement plusieurs plateformes. Si trois réussissent et une échoue, ni « published » ni « failed » n’est vrai, et forcer l’un ou l’autre produit une interface qui ment à l’utilisateur.
Ce qui se passe quand une plateforme est en panne
Concevez pour ce cas, car il arrive.
Les échecs transitoires devraient réessayer avec un backoff. Une plateforme qui renvoie 503 pendant deux minutes ne devrait pas faire perdre la publication.
Les nouvelles tentatives doivent être sûres. Une création qui a expiré peut avoir réussi. Réessayer à l’aveugle duplique la publication, ce qui est pire que l’échec initial. Vérifiez avant de réessayer.
Les échecs permanents ne devraient pas réessayer du tout. Un jeton expiré ou une légende invalide ne se corrigera pas tout seul, et réessayer ne fait que consommer du quota et retarder la notification.
Quelqu’un doit être averti. Une publication planifiée qui échoue à 3 h du matin passe inaperçue, sauf si vous l’avez rendue visible. Les webhooks sont le bon mécanisme.
Modifier et annuler
Une publication planifiée est une promesse que vous devrez peut-être rompre. Votre intégration devrait permettre de changer l’heure, de modifier le contenu, et d’annuler purement et simplement.
Notez que les plateformes diffèrent sur le fait d’autoriser cela une fois qu’elles détiennent la publication, ce qui est une des raisons pour lesquelles planifier dans votre propre couche et soumettre au dernier moment se comporte mieux que de confier à la plateforme une publication à date future.
Emplacements de file d’attente contre horaires explicites
Deux modèles de planification, et chacun a sa place.
Les horaires explicites sont ce que vous voulez quand une publication doit tomber à un moment précis : un lancement, un événement, une annonce coordonnée.
Les emplacements de file d’attente sont ce que vous voulez pour un flux régulier. Vous définissez une cadence de publication et la prochaine publication prend le prochain emplacement libre, si bien que vous ne choisissez pas d’horodatage pour chaque publication d’un lot.
Pour le travail en masse, le second est beaucoup moins fastidieux, et c’est le modèle qui rend « mettre trente publications en file » une opération sensée plutôt que trente décisions.
Plannings récurrents
Distinct d’une publication planifiée. Un planning récurrent est une règle qui continue de produire des publications selon une fréquence : quotidienne, hebdomadaire, bimensuelle ou mensuelle.
Deux choses à concevoir. Le fuseau compte encore plus ici, pour la raison du changement d’heure évoquée plus haut. Et le média attaché à une publication récurrente doit être conservé plutôt que nettoyé après publication, car le planning en a de nouveau besoin la fois suivante.
Limites de plan
| Free | Pro | Business | |
|---|---|---|---|
| Requêtes API/jour | 30 | 5 000 | 50 000 |
| Publications | 3/jour | 30/jour | Illimité |
| Plannings récurrents | Aucun | 10 | Illimité |
En résumé
Passez un fuseau horaire IANA avec chaque horodatage planifié, surtout pour tout ce qui est récurrent. Modélisez processing et partial comme de véritables états, car la publication asynchrone et les publications multi-plateformes font que les deux se produisent réellement. Réessayez les échecs transitoires avec un backoff, ne réessayez jamais une création à l’aveugle, et utilisez des webhooks pour qu’un échec à 3 h du matin ne passe pas inaperçu.