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

_2026-09-18 · Comment un agent IA doit programmer sur de nombreux comptes : décalages ISO 8601, fuseaux et heure d'été, calcul des délais, groupes répartis, annulations._

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](https://www.rfc-editor.org/rfc/rfc3339), 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](https://www.iana.org/time-zones), fournie avec tous les langages courants, et calculer le décalage pour la date concernée.

```python
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](/fr/blog/one-agent-many-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.

## 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.

```json
{
  "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](/fr/blog/api-keys-scopes-and-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](/fr/blog/avoid-spam-blocks-when-posting-at-scale) 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.

```json
{
  "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.

## 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](https://developers.facebook.com/docs/instagram-platform/content-publishing) pour vérifier l'utilisation en cours. YouTube attribue un quota d'API par projet, [10 000 unités par jour par défaut](https://developers.google.com/youtube/v3/getting-started), 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](/fr/blog/prompts-for-a-content-agent) contient un bloc de programmation à coller tel quel.

---
Source: https://shager.ai/fr/blog/scheduling-strategy-for-agents