Opérations d'écriture sécurisées

Les appels à run_write_operation peuvent dépenser de l'argent, mettre en pause des campagnes, modifier les budgets, modifier des créatifs en direct, envoyer des emails ou facturer des clients. Traitez chacun comme une modification en production.

Quand ce protocole s'applique

Le déclencheur est le flag requires_approval: true sur l'opération dans la réponse find_operations. Si requires_approval: true, vous devez utiliser run_write_operation et devez suivre le protocole en quatre étapes ci-dessous. Si requires_approval: false, utilisez run_operation et ignorez ce protocole — aucune confirmation nécessaire.

Le protocole d'écriture en quatre étapes

Toujours suivre cette séquence exacte avant d'appeler run_write_operation :

1. Énoncez le changement en langage clair. Incluez la plateforme, le compte, le nom/l'ID de l'objet, et ce qui va changer. Exemple :

   « Je suis sur le point de mettre en pause la campagne Google Ads 'Brand — US Search' (ID 1234567890) dans le compte Acme US (MCC 999-888-7777). Cela arrêtera les dépenses immédiatement. »

2. Énoncez le rayon d'impact. Quelles dépenses, trafic, revenus ou audience sont affectés ? Récupérez rapidement un chiffre avec run_operation si vous ne le savez pas.
3. Demandez une confirmation explicite. Attendez un oui. « C'est bon », « allez-y » ou « faites-le » comptent tous. Tout ce qui est ambigu = demandez à nouveau.
4. Exécutez, puis vérifiez. Après le retour de l'appel, récupérez l'état actuel de l'objet avec run_operation et confirmez que le changement a été appliqué.

Règles strictes

• Ne regroupez jamais plus de 5 opérations d'écriture sans reconfirmer. Si un workflow nécessite 20 mises en pause, faites les 5 premières, résumez, puis demandez « continuer avec le lot suivant ? ».
• Ne supprimez jamais sauf si l'utilisateur a dit « supprimer » (pas « retirer », pas « mettre en pause »). Préférez toujours la mise en pause/désactivation à la suppression.
• Ne modifiez jamais les budgets de plus de 50 % en un seul appel sans une étape de confirmation supplémentaire. Les gros changements de budget sont faciles à mal doser.
• Ne lancez jamais une opération d'écriture immédiatement après une découverte déclenchée par le modèle. L'utilisateur doit d'abord avoir demandé le changement en ses propres termes.
• Ne supposez jamais une connexion. Si l'utilisateur a plusieurs comptes Google Ads et n'a pas spécifié, demandez.

Toujours vérifier avant d'exécuter

• « Cela réinitialize-t-il l'apprentissage ? » Sur Meta, les décalages budgétaires > 20 %, les changements d'audience > 10 %, les changements de placement, les changements d'événement d'optimisation et les échanges créatifs majeurs réinitialisent la phase d'apprentissage de l'ensemble d'annonces (~7 jours de performance dégradée). Sur Google Ads, le changement de stratégies d'enchères réinitialise l'apprentissage (~1–2 semaines). Avertissez explicitement l'utilisateur quand un changement prévu déclenchera une réinitialisation.
• « Ce changement nécessite-t-il une recherche d'ID actualisée ? » Les changements structurels (créer une nouvelle RSA, remplacer un créatif Meta, créer un nouvel ensemble d'annonces) retournent de nouveaux IDs. Ne réutilisez pas les IDs obsolètes d'avant dans la conversation après un changement structurel — récupérez-les à nouveau.
• « Existe-t-il une opération dédiée pour ceci ? » Sur Google Ads, gads_mutate est le générique de dernier recours. Si une opération dédiée existe (par ex. gads_update_campaign_budget), utilisez-la — intention plus claire, meilleure validation, moins de pièges.

Quand run_write_operation renvoie une erreur

• Erreur d'authentification → l'utilisateur doit se reconnecter à https://www.markifact.com/app/connections. Arrêtez, ne réessayez pas.
• Erreur de validation → récupérez à nouveau le schéma d'opération avec get_operation_inputs, corrigez le payload, demandez à l'utilisateur de confirmer l'appel corrigé avant de réessayer.
• Limite de débit / quota → reculez, ne réessayez pas en boucle.