Programmer avec un agent : fuseaux horaires, échelonnement, et surtout pas quarante Pages à 9 h pile

Une bonne stratégie de programmation pour un agent tient en trois règles : toujours envoyer les heures au format ISO 8601 avec un décalage explicite calculé à partir du fuseau horaire du client, laisser la plateforme échelonner les envois compte par compte au lieu de tout déclencher d'un coup, et répartir les longues listes de comptes sur des publications et des horaires distincts plutôt que de lancer une diffusion géante. D'abord le brouillon, puis la programmation comme étape à part, et une annulation qui ne coûte rien.

Tout ce qui suit vise à rendre ces règles concrètes, avec les champs exacts qu'attend Shager.

Pourquoi les agents se trompent-ils d'heure ?

Les modèles de langage sont fâchés avec les horloges. Ils ne savent pas quelle heure il est si on ne le leur dit pas, ils écrivent sans sourciller 2026-11-02T09:00:00 sans décalage et ils convertissent les fuseaux de tête. Autant de raisons pour qu'une publication parte à 7 h au lieu de 9 h.

Shager ferme une première porte en refusant toute ambiguïté : schedule_at doit être au format ISO 8601 avec un décalage, par exemple 2026-10-20T09:00:00+03:00. Un horodatage sans Z ni décalage est rejeté à la validation. Ce format correspond au profil défini dans la RFC 3339, et il vaut la peine de le nommer explicitement dans les instructions de votre agent.

La seconde porte, c'est le décalage lui-même. +03:00 est juste pour Israël en octobre et faux en décembre. Les décalages changent avec l'heure d'été, et les dates de changement diffèrent entre Israël, l'Union européenne et les États-Unis. L'agent ne doit jamais coder un décalage en dur. Il doit résoudre le nom du fuseau du client grâce à la base de données des fuseaux horaires de l'IANA, fournie avec tous les langages courants, et calculer le décalage pour la date concernée.

from datetime import datetime
from zoneinfo import ZoneInfo

local = datetime(2026, 11, 2, 9, 0, tzinfo=ZoneInfo("Europe/Berlin"))
print(local.isoformat())   # 2026-11-02T09:00:00+01:00

Chaque espace de travail Shager possède aussi un timezone, un nom de fuseau IANA défini à la création de l'espace (par défaut Asia/Jerusalem). Demandez à l'agent de le lire et de s'en servir. Quand vous faites tourner un seul agent pour de nombreux clients, tous les clients ne partagent pas le même fuseau, et l'espace de travail est le seul endroit qui enregistre celui de chaque client.

Faites défiler sur le côté pour voir tout le schéma

Le brouillon d'abord, la programmation ensuite

create_post peut programmer immédiatement si vous lui passez schedule_at. Je laisse rarement les agents le faire pour des clients. Le schéma le plus sûr se fait en deux appels :

1. create_post sans schedule_at, qui enregistre un brouillon.
2. schedule_post avec l'ID de la publication et l'heure, une fois qu'une personne ou une règle a donné son feu vert.

{
  "tool": "schedule_post",
  "arguments": {
    "workspace_id": "ws_example",
    "post_id": "pst_example",
    "schedule_at": "2026-10-20T09:00:00+03:00"
  }
}

Il y a aussi une raison liée aux autorisations. Dans Shager, programmer exige la portée publish sur la clé API, alors que rédiger un brouillon ne demande que write. Une personne accorde publish explicitement lorsqu'elle revendique l'environnement de test d'un agent, et peut créer des clés sans cette portée. Cette séparation vous permet de laisser une grande liberté à un agent rédacteur tout en gardant l'étape finale entre les mains d'une personne. Les détails se trouvent dans clés API, portées et audit.

schedule_post a aussi un comportement utile en cas d'échec : si un compte risque de rejeter la publication, ou si la validation du client est requise et manquante, l'appel échoue avec une raison claire au lieu de programmer une diffusion qui échouera à moitié.

Combien de temps dure vraiment une diffusion échelonnée ?

Shager publie compte par compte, avec une pause aléatoire entre les comptes d'un même réseau. Le champ stagger_seconds fixe cette plage, [30, 90] par défaut. Les réseaux tournent en parallèle : la durée d'une diffusion dépend donc du réseau qui compte le plus de comptes.

Le calcul est assez simple pour qu'un agent le fasse avant de choisir un horaire :

Comptes sur le plus gros réseau	Échelonnement	Écart moyen	Durée approximative
10	[30, 90]	60 s	environ 9 minutes
40	[30, 90]	60 s	environ 39 minutes
40	[60, 180]	120 s	environ 78 minutes
120	[30, 90]	60 s	environ 2 heures

C'est la dernière ligne qui surprend. Si un client exige que « tout soit en ligne avant 10 h » et que vous avez 120 Pages Facebook, une programmation à 9 h ne suffit pas. Il faut soit commencer plus tôt, soit scinder la diffusion.

Ne répondez pas à une échéance en réduisant l'échelonnement à [0, 5]. La pause existe pour qu'une diffusion massive ne ressemble pas à une rafale venue d'une seule source. Notre article sur comment éviter les blocages pour spam en publiant à grande échelle explique pourquoi le rythme compte davantage que n'importe quelle légende.

Répartir par groupe, pas par heure

Pour les gros clients, le meilleur schéma consiste à faire une publication par groupe de comptes, chacune avec son propre horaire. Une enseigne avec 90 pages de magasins peut être découpée par région. L'agent crée trois publications, une par groupe régional, programmées sur des matinées différentes ou étalées sur la journée.

{
  "tool": "create_post",
  "arguments": {
    "workspace_id": "ws_example",
    "group_ids": ["grp_north"],
    "caption": "Winter hours start Sunday at every northern branch.",
    "per_channel": [
      { "channel_id": "ch_fb_haifa", "caption": "Haifa branch: winter hours start Sunday. We open at 8:30." }
    ],
    "campaign": "winter-hours",
    "stagger_seconds": [60, 150]
  }
}

Les groupes se créent avec create_group, qui prend un nom et une liste de channel_ids. Tous les canaux actifs d'un groupe sont ajoutés quand vous ciblez ce groupe.

Faites défiler sur le côté pour voir tout le schéma

Les limites des réseaux que l'agent doit respecter

Les réseaux plafonnent eux-mêmes ce qu'un compte peut publier via leurs API. Meta documente une limite par compte pour les publications Instagram faites via l'API sur une fenêtre glissante de 24 heures, et propose un point d'accès content_publishing_limit pour vérifier l'utilisation en cours. YouTube attribue un quota d'API par projet, 10 000 unités par jour par défaut, et les mises en ligne figurent parmi les opérations les plus coûteuses.

Shager s'occupe de l'envoi, mais la planification revient à l'agent. Un compte qui reçoit six publications dans la journée pose un problème de stratégie avant de poser un problème d'API. Je donne aux agents une règle maison simple : pas plus d'une publication dans le fil par compte et par jour, sauf avis contraire d'une personne.

Calendriers, jours fériés et jours calmes

Le calendrier de Shager intègre les fêtes israéliennes, ce qui compte pour les clients israéliens : une publication programmée la veille d'une grande fête tombe sur un public déconnecté. Pour les clients ailleurs, donnez à l'agent, dans ses instructions, le calendrier propre au client, avec ses fermetures et ses événements. Les modèles savent à peu près quand tombent les jours fériés ; ils ne savent pas que l'entrepôt de ce client ferme pour inventaire le dernier vendredi du trimestre.

Annuler et déplacer

cancel_post déprogramme une publication dont la diffusion n'a pas commencé. Il ne la supprime pas : elle redevient un brouillon validé, et l'agent peut rappeler schedule_post avec un nouvel horaire. L'annulation concerne les publications encore en attente ; une fois la diffusion commencée, cancel_post ne s'applique plus.

Avant de déplacer quoi que ce soit, l'agent doit appeler list_posts avec status réglé sur SCHEDULED pour voir ce qui figure déjà dans la file de cet espace. Deux diffusions programmées qui tombent sur les mêmes comptes dans la même heure : c'est l'erreur auto-infligée que je vois le plus souvent.

FAQ

Quel fuseau horaire Shager utilise-t-il si l'agent envoie de l'UTC ?

Un horodatage avec Z est sans ambiguïté : Shager le programme à cet instant précis. Le fuseau de l'espace de travail compte pour la façon dont les gens voient la programmation dans le calendrier et pour le raisonnement de l'agent. Envoyer l'heure locale avec le bon décalage garde les journaux de l'agent lisibles pour les personnes qui les vérifient.

L'agent peut-il programmer différents comptes à différentes heures dans une même publication ?

Une publication a un seul schedule_at, puis les comptes partent dans l'ordre échelonné. Pour des horaires vraiment différents, créez des publications distinctes, généralement une par groupe. Les rapports n'en sont que plus clairs, puisque chaque publication peut porter son propre label.

Quel échelonnement par défaut est raisonnable ?

La valeur par défaut [30, 90] convient à la plupart des diffusions. Pour la vidéo et pour les diffusions de plus d'une cinquantaine de comptes sur un même réseau, je l'élargis à quelque chose comme [60, 150] et je commence plus tôt. Le prix à payer, c'est du temps, pas de la portée.

Pour aller plus loin

Intégrez ces règles aux instructions permanentes de votre agent plutôt que de les répéter à chaque tâche. L'article sur les prompts pour un agent de contenu contient un bloc de programmation à coller tel quel.