# Agents IA et publication sur des centaines de comptes : les règles de sécurité _2026-09-09 · Les règles d'un agent IA qui publie sur de nombreux comptes : API officielles, clés limitées, légendes variées, envois échelonnés, limites, plan d'arrêt._ Un agent IA qui publie sur des centaines de comptes reste dans les clous s'il applique quelques règles simples : publier uniquement via les API officielles des réseaux, n'avoir que la clé la plus restreinte possible, ne jamais envoyer la même légende à plusieurs comptes, espacer les envois d'un compte à l'autre, respecter les limites et les politiques de chaque réseau, et disposer d'un moyen d'arrêter rapidement une diffusion. La plupart de ces règles devraient être imposées par la plateforme et par les portées des clés, les instructions de l'agent ne servant que de deuxième ligne de défense, pas de seule protection. Voici le règlement que nous recommandons, rédigé pour que vous puissiez en coller l'essentiel directement dans la skill d'un agent. Chaque règle est accompagnée de sa justification : un agent qui comprend le pourquoi gère mieux les cas limites qu'un agent qui suit une consigne nue. ## Pourquoi les agents ont-ils besoin de leurs propres règles de sécurité ? Une personne qui programme des publications commet ses erreurs une par une. Un agent les commet par lots. Si les instructions contiennent une erreur, celle-ci se retrouve sur tous les comptes de la diffusion. Le volume démultiplie le bon travail comme le mauvais. Les réseaux disent aussi clairement que le volume et la répétition font partie des signaux qu'ils surveillent. La [politique de Meta sur le spam](https://transparency.meta.com/policies/community-standards/spam/) vise la publication à très haute fréquence, manuelle ou automatisée, ainsi que les contenus répétitifs. Les [règles de YouTube sur le spam, les pratiques trompeuses et les escroqueries](https://support.google.com/youtube/answer/2801973) visent les contenus répétitifs et non ciblés. Ces politiques portent sur un comportement, pas sur la question de savoir si c'est une personne ou un logiciel qui a appuyé sur le bouton. ## Le règlement ### Règle 1 : uniquement les API officielles L'agent publie via une plateforme qui utilise l'API officielle de chaque réseau. Pas d'automatisation de navigateur, pas d'identifiants partagés, pas de points d'accès non officiels. Shager publie exclusivement via les API officielles des réseaux : cette règle est donc respectée par le choix de la plateforme, et non par la discipline de l'agent. Pourquoi : les méthodes non officielles enfreignent les conditions d'utilisation, mettent le compte lui-même en danger et tombent en panne de façon imprévisible. ### Règle 2 : des clés au moindre privilège Démarrez chaque agent avec `read` et `write`. N'ajoutez `publish` que lorsqu'une personne a décidé que cet agent peut programmer. Utilisez des clés distinctes par client ou par agent, pour qu'en révoquer une n'arrête pas tout. Pourquoi : une clé qui ne peut pas publier transforme une mauvaise instruction en mauvais brouillon, ce qui est sans conséquence. Notre article sur [les clés API, les portées et l'audit](/fr/blog/api-keys-scopes-and-audit) explique la configuration. ### Règle 3 : d'abord le brouillon, ensuite la programmation Chaque diffusion crée des brouillons. La programmation est une étape distincte, qui vient après la relecture ou la validation du client. Pourquoi : cela crée un point de contrôle naturel sans ralentir le travail de production de l'agent. Le raisonnement complet se trouve dans [la validation humaine des publications d'agents](/fr/blog/human-approval-for-agent-posts). ### Règle 4 : une légende différente pour chaque compte Quand une publication part sur plusieurs comptes, utilisez `per_channel` pour donner à chaque compte sa propre légende et, le cas échéant, son propre premier commentaire. Les affirmations et les offres restent identiques ; l'accroche, les détails locaux, la formulation et l'appel à l'action changent. Pourquoi : un texte identique sur de nombreux comptes au même moment, c'est exactement ce à quoi ressemble un contenu répétitif vu de l'extérieur. Notre guide sur [les variantes de légende par compte](/fr/blog/caption-variation-per-account-with-ai) montre comment procéder sans s'éloigner de la marque. ### Règle 5 : échelonner les envois N'envoyez pas à tous les comptes dans la même seconde. Le paramètre `stagger_seconds` de Shager définit une plage de délai aléatoire entre les comptes, par défaut `[30, 90]` secondes. Pour les grands groupes ou les clients sensibles, élargissez-la. Pourquoi : étaler les envois dans le temps, c'est ainsi qu'une vraie équipe publierait sur de nombreuses Pages, et cela limite les rafales qui trahissent l'automatisation. ### Règle 6 : connaître les limites strictes de chaque réseau Certaines limites sont publiques. Instagram, par exemple, indique que les comptes sont [limités à 100 publications via l'API sur une période glissante de 24 heures](https://developers.facebook.com/docs/instagram-platform/content-publishing). En fonctionnement normal, votre agent ne devrait jamais s'approcher de ce genre de limite ; si c'est le cas, c'est le plan qui est mauvais. Les médias ont aussi des contraintes de format. Pour importer une vidéo destinée aux Reels, aux Shorts ou aux stories, transmettez `width`, `height` et `duration_ms` à `upload_media_from_url`, afin qu'elle soit validée avant la création de toute publication. Pourquoi : une publication rejetée au moment de l'envoi gaspille un créneau, et des échecs répétés sont un bruit dont vous ne voulez pas sur le compte d'un client. ### Règle 7 : laisser la plateforme vérifier avant l'envoi Shager vérifie chaque publication par rapport aux règles du réseau cible avant l'envoi. L'agent doit traiter une erreur de validation comme une information : lire le code et le message d'erreur, corriger la publication et réessayer une fois. Si elle échoue deux fois, il s'arrête et fait un rapport. Pourquoi : un agent qui réessaie à l'aveugle peut transformer un problème en dizaines d'appels en échec. ### Règle 8 : respecter la limite de débit de l'API L'API Shager autorise 120 requêtes par minute et par clé. Une diffusion bien conçue utilise le ciblage par groupe et `per_channel` dans un seul `create_post`, plutôt qu'un appel par compte : elle s'approche donc rarement de cette limite. Pourquoi : regrouper les appels va plus vite et maintient la diffusion dans les limites sans boucles d'attente dans la logique de l'agent. ### Règle 9 : prévoir un plan d'arrêt Avant une grosse diffusion, sachez comment l'interrompre. `list_posts` montre ce qui est programmé, et le `label` de la diffusion indique quelles publications en font partie ; `cancel_post` retire chacune d'elles avant son heure d'envoi. Une personne peut aussi révoquer la clé depuis le tableau de bord des agents, ce qui bloque tout nouvel appel de cet agent. Pourquoi : c'est avant d'en avoir besoin qu'il faut concevoir le bouton d'arrêt. ### Règle 10 : tenir un journal d'audit, et le lire Chaque appel d'agent est enregistré dans le journal d'audit du tableau de bord des agents. Quelqu'un devrait le consulter chaque semaine, pas seulement après un incident. Pourquoi : une dérive du comportement de l'agent apparaît dans le journal avant d'apparaître en public. ## Le règlement en texte de skill Voici une version condensée à placer dans une skill ou un prompt système : ```text SAFETY RULES (always apply) 1. Create drafts only unless the instructions explicitly say to schedule an approved post. 2. When targeting more than one account, always use per_channel with a distinct caption for each account. Never send identical captions. 3. Use stagger_seconds of at least [30, 90]; use [60, 180] for groups larger than 20 accounts. 4. For video, always pass width, height and duration_ms on upload. 5. Never state a price, discount, date or claim that is not in the brief. 6. On a validation error, fix and retry once. On a second error, stop and report the error code and message. 7. Label every post in a run with the same label so the run can be listed and cancelled as a group. 8. Never call schedule_post on a post that has not been approved. ``` Les seuils de la règle 3 sont une suggestion de notre part, pas une règle des réseaux. Choisissez des valeurs adaptées à vos clients et tenez-vous-y. ## À quoi ressemble une grosse diffusion bien sécurisée ? 1. `whoami` pour confirmer que les portées de la clé correspondent à la tâche. 2. `list_groups` et `list_channels` pour déterminer précisément quels comptes sont concernés, et annoncer leur nombre avant toute autre action. 3. `upload_media_from_url` avec les dimensions et la durée complètes. 4. `create_post` avec `group_ids`, `per_channel`, `first_comment`, `stagger_seconds` et un `label` de diffusion, en brouillon. 5. `request_approval`, ou passage de relais à un relecteur humain. 6. Après validation, `schedule_post` pour chaque publication validée. 7. Après l'heure d'envoi, `get_post` sur un échantillon pour confirmer la diffusion, et signalement des éventuels échecs. L'étape 2 est celle que les équipes sautent, et qu'elles regrettent. Un agent qui annonce « cette diffusion cible 212 comptes répartis dans 3 groupes » laisse à une personne l'occasion de répondre « ce n'est pas le bon groupe » avant même qu'un seul brouillon existe. ## FAQ ### Publier via un agent est-il plus risqué que de publier à la main ? Le risque est différent, pas forcément plus élevé. Un agent répète ses erreurs à grande échelle, alors qu'une personne commet des erreurs dispersées. Avec des clés limitées, des diffusions qui commencent par des brouillons et des légendes variées, une diffusion par agent peut être plus régulière qu'un travail manuel sur de nombreux comptes. ### Quelle est la valeur la plus sûre par défaut pour stagger_seconds ? Par défaut, Shager espace les comptes de 30 à 90 secondes. Aucun réseau ne publie de valeur d'espacement idéale : élargissez la plage pour les grands groupes et jugez sur les résultats plutôt que sur une règle empirique. ### Peut-on arrêter une diffusion programmée une fois lancée ? Oui. Les publications pas encore envoyées peuvent être retirées avec `cancel_post`, et le libellé commun de la diffusion permet de les repérer facilement dans `list_posts`. Révoquer la clé bloque tout nouvel appel. Pour comprendre comment les plateformes traitent la publication en volume, lisez [comment éviter les blocages pour spam en publiant à grande échelle](/fr/blog/avoid-spam-blocks-when-posting-at-scale), puis copiez le règlement ci-dessus dans la skill de votre agent avant sa prochaine diffusion. --- Source: https://shager.ai/fr/blog/safety-rules-for-agents-posting-at-scale