Gouvernance Google Ads : valider les modifications de manière contrôlée

Les cinq étapes de la réponse courte sont des limites que l’automatisation ne doit pas franchir sans que cela se voie, indépendamment de la manière dont le système qui exécute est commercialisé. Un cas typique est banal : quelqu’un baisse manuellement une cible d’enchères et, trois mois plus tard, plus personne ne sait pourquoi. maitiq y répond de manière structurelle – avec une décision enregistrée et une mise en œuvre journalisée pour chaque modification qu’il propose.

Pourquoi l’historique des modifications Google ne suffit-il pas ?

L’historique des modifications répertorie les modifications apportées au compte, aux campagnes et aux groupes d’annonces au cours des deux dernières années. Il indique l’horodatage, le type de modification et l’identité à l’origine : personne, API Google Ads, Google Ads Editor, règle automatisée ou l’un des systèmes internes de Google. Il peut être filtré par campagne, groupe d’annonces, type de modification, utilisateur, outil et élément modifié, puis croisé avec les données de performance. Pour des raisons de sécurité, il n’enregistre pas les changements de mot de passe. Google précise en outre que les modifications apportées aux paramètres au niveau du compte ou par des représentants Google lors de consultations ne sont pas toujours toutes répertoriées.

Il répond donc avant tout à une question : qu’est-ce qui a été modifié dans le compte ? Il ne répond pas aux questions suivantes :

• quel objectif commercial était visé ;
• quelles preuves étayaient la proposition ;
• qui a validé sur le plan métier et avec quelle autorisation ;
• quels risques ont été acceptés en connaissance de cause ;
• quel retour en arrière était préparé ;
• si la modification a produit par la suite l’état attendu.

S’y ajoute une limite de lecture que beaucoup d’équipes ne découvrent qu’en construisant leurs propres archives : la vue sur deux ans de l’interface n’est pas un historique récupérable automatiquement. Via l’API Google Ads, la ressource change_event fournit les nouvelles valeurs de champs pour les créations et, pour les mises à jour, les anciennes et les nouvelles valeurs, ainsi que le type de client et, lorsque l’utilisateur est visible dans l’historique des modifications du client web, l’utilisateur à l’origine de la modification, mais exige une fenêtre de dates dans les 30 derniers jours et au maximum 10 000 lignes par requête ; Google précise que toutes les lignes de l’historique n’y figurent pas nécessairement. La ressource change_status remonte à 90 jours, mais ne renvoie pour chaque ressource que la modification la plus récente, sans valeurs de champs. Ces limites de 30 et 90 jours valent pour ces deux ressources, et non pour l’ensemble des données accessibles via l’API. Qui a besoin d’une trace fiable sur plusieurs trimestres doit l’enregistrer lui-même en continu. Une trace interne ne remplace pas l’historique de la plateforme : elle documente les décisions et les actions de maitiq, et non la justification de chaque modification manuelle dans l’ensemble du compte Google.

De quelles cinq étapes une modification a-t-elle besoin ?

1. Éléments à l’appui. La source est décrite telle quelle : période, compte, campagne, entité concernée, indicateurs, disponibilité des données et limites. Les données manquantes restent manquantes.

2. Proposition. La proposition nomme l’action exacte : ancienne et nouvelle valeur lorsqu’une telle comparaison a du sens – une création n’a pas de valeur numérique antérieure –, ainsi que l’objectif, la justification, l’observation contrôlable attendue et les effets secondaires possibles. Une analyse n’est pas encore une action.

3. Décision. Une personne habilitée accepte, refuse ou laisse en suspens ; lorsque le pilote automatique limité est explicitement activé, il peut accepter dans les limites que vous avez fixées. L’identité et l’horodatage sont enregistrés, ainsi qu’un motif lorsqu’il est consigné. Une acceptation n’est pas la mise en œuvre technique.

4. Mise en œuvre autorisée séparément. Seule une identité autorisée à cette fin exécute exactement la modification validée. Une autorisation propre ne signifie pas nécessairement un second clic de validation : lors de l’exclusion d’un mot clé de concurrent, la décision explicite constitue elle-même l’autorisation pour cette opération précise, et l’exécution est malgré tout contrôlée par rapport à la décision, à la portée et à l’objectif. La requête et le retour de Google sont journalisés, ainsi qu’une preuve avant/après lorsque l’opération permet une relecture indépendante.

5. Vérification. Le contrôle technique établit l’état dans la mesure où il peut être étayé : il rapporte les éléments disponibles – par exemple la réponse de l’API et l’audit – et, lorsque l’opération permet une relecture indépendante, la preuve avant/après. Une vérification manquante reste ouverte au lieu d’être considérée comme confirmée ; aucune confirmation indépendante immédiate n’est promise pour chaque écriture. L’observation ultérieure de l’effet intervient après une fenêtre d’observation définie et évalue l’évolution de l’état concerné. Une corrélation n’est pas présentée comme un effet.

Chaque étape doit prévoir une issue en cas d’erreur. Si des éléments à l’appui pertinents manquent, la décision peut rester bloquée ; les valeurs de statut recommandées sont «éléments insuffisants pour décider», «nouvelle validation nécessaire» pour une décision expirée, «non exécuté» pour un contrôle préalable bloqué, «non élucidé» pour un résultat distant inconnu et «non résolue» pour une vérification ouverte. Une non-applicabilité justifiée ne devient pas automatiquement «éléments insuffisants pour décider». Ces valeurs de statut sont une recommandation pour votre registre, et non cinq valeurs de statut intégrées au produit : chaque opération n’a pas nécessairement d’état avant/après relu indépendamment, de statut d’expiration ou de motif en texte libre enregistré. Une tentative échouée ne doit apparaître ni comme une modification réussie, ni comme «aucune modification nécessaire».

Qui décide quoi ? La base RACI

Distinguez les rôles, pas seulement les personnes : responsabilité métier (objectif, budget, risque), responsabilité SEA (examen métier), responsabilité de la mesure (limites des conversions et de l’attribution), mise en œuvre (exécution), contrôle (vérification indépendante), protection des données et sécurité (accès, consentement, ID de clic) ainsi que finances (budget média et limites d’autorisation).

Pour chaque ligne, un seul rôle est Accountable, jamais un logiciel. Dans les équipes plus petites, une personne porte plusieurs rôles ; les événements restent séparés : d’abord la décision, ensuite l’exécution dans les limites de l’autorisation en vigueur. Complétez chaque ligne par une suppléance et une voie d’escalade, sinon une absence bloque le processus. Ce tableau est un modèle à copier pour votre registre des rôles, pas un champ modifiable de cette page. Voici la position de maitiq : le workflow n’est Accountable dans aucune ligne ; il fournit des éléments à l’appui et une proposition. Une personne nommée de votre équipe décide, ou le pilote automatique limité explicitement activé décide dans les limites que vous avez fixées ; la responsabilité de l’octroi de cette politique reste à la personne nommée. Dans le service géré, un Client Success Manager, votre interlocuteur attitré, accompagne le travail, et la mise en œuvre a lieu dans les limites de l’autorisation délivrée à cet effet, sous forme d’étape journalisée.

Comment maitiq intègre la gouvernance

L’exécution du workflow rassemble des éléments à l’appui et génère des propositions avec la mesure, la justification et les données à l’appui – ancienne et nouvelle valeur lorsqu’une telle comparaison de valeurs existe. La génération de propositions ne modifie rien dans le compte. Une personne habilitée accepte, refuse ou laisse en suspens ; lorsque le pilote automatique limité est explicitement activé, il peut accepter lui-même des propositions dans les limites que vous avez fixées et déclencher, dans la même exécution du workflow, une exécution séparée et contrôlée séparément. La décision est enregistrée avec l’identité et l’horodatage ; la mise en œuvre reste liée aux droits d’exécution contrôlés séparément et est journalisée. Ce qui dépasse ces limites n’est pas accepté automatiquement.

Quelles modifications sont significatives ?

Le niveau d’importance dépend du compte. Il n’existe ni catégories Google universelles, ni seuils en CHF ou en pourcentage valables partout. La matrice est un modèle à copier pour votre registre, pas un champ modifiable de cette page. Calibrez la matrice avec vos propres valeurs :

Un petit montant peut être critique s’il touche le flux de données de conversion principal ou des droits à l’échelle du compte ; une modification budgétaire importante et immédiatement réversible peut avoir un niveau d’importance moyen. Définissez, pour chaque niveau, la validation requise, la fenêtre de mise en œuvre, le monitoring et le retour en arrière. Les modifications critiques ne démarrent pas pendant les périodes où personne n’est disponible.

Que doit contenir une proposition de modification ?

Le texte libre seul complique la déduplication, l’examen et le reporting. Utilisez des références d’entité stables et des statuts structurés ; la liste de champs ci-dessous est un modèle pour votre format de proposition, pas une saisie de produit :

À quoi ressemble une validation permanente complète ?

Une validation permanente remplace la décision individuelle pour les modifications récurrentes à faible risque. «Optimiser selon les bonnes pratiques» n’est pas une autorisation contrôlable. Comme modèle organisationnel, elle n’est complète qu’avec neuf indications – un modèle à copier pour votre registre des autorisations, pas neuf paramètres du produit :

Tout écart revient à une décision individuelle. À l’échéance, vérifiez activement si la validation est prolongée ; une reconduction tacite n’est pas une décision. L’autopilote limité de maitiq suit un ensemble de limites qui lui est propre, différent et configurable : par modification, un montant et un pourcentage, ainsi qu’un plafond pour la somme des valeurs budgétaires après la modification au niveau de regroupement choisi. Ce sont des limites moins nombreuses ou différentes de celles d’une politique organisationnelle complète – pas une protection plus stricte. Les limites de fréquence, la date d’échéance et la personne responsable nommée sont des champs de votre registre, pas des paramètres du produit ; sans politique activée, la fonction reste désactivée.

Comment valider les recommandations à application automatique ?

L’application automatique (auto-apply) repose sur une activation explicite. Le risque n’est pas une absence de consentement, mais une autorisation non documentée ou oubliée, qui peut survivre à la mémoire du personnel. Google permet d’appliquer automatiquement certains types de recommandations, exclusivement au niveau du compte. Les paramètres d’application automatique tiennent leur propre historique ; il indique, par type, quand il a été activé pour la première fois, combien de fois il a été appliqué au cours de la semaine écoulée et à quand remonte la dernière application. L’ID utilisateur à l’origine de l’activation peut être vérifié dans l’historique des modifications. Ce sont précisément ces champs qui appartiennent à votre propre registre des autorisations, complétés par la finalité commerciale, les actions de conversion protégées, le rythme d’examen, la date d’échéance et la règle d’arrêt.

Documentez chaque type, pas les noms de lots : la portée et le risque varient fortement. Les types disponibles évoluent : Google adapte en continu le catalogue des recommandations applicables automatiquement ; vérifiez la liste à nouveau lors de chaque examen. Chaque examen se termine par un statut explicite par type ; les valeurs recommandées sont «maintenir», «désactiver», «test limité dans le temps», «éléments insuffisants pour décider» ou «escalade». Le score d’optimisation n’est pas un KPI d’entreprise : une recommandation peut correspondre à la logique de la plateforme et contredire malgré tout le cadre commercial.

La distinction est importante : désactiver arrête les applications automatiques futures. Cela ne rétablit pas les modifications déjà appliquées. Pour cela, il existe la voie séparée de l’historique des modifications – pour autant que l’opération concernée permette cette annulation. Si elle ne le permet pas, une modification inverse manuelle autorisée séparément peut être nécessaire, ou l’annulation peut être impossible. La manière de tenir un registre de l’application automatique, du Smart Bidding et des outils externes, de les examiner et de les arrêter est décrite dans le guide Contrôler l’automatisation avec des garde-fous.

À quoi ressemble un protocole de retour en arrière ?

Un retour en arrière n’est pas une contre-modification spontanée, mais une opération préparée et journalisée. Google offre pour cela une fenêtre temporelle : la plupart des types de modifications des 30 derniers jours peuvent être annulés directement dans la ligne de l’historique des modifications, y compris une recommandation appliquée par erreur – pour autant que l’opération permette cette annulation. Si elle ne le permet pas, une modification inverse manuelle autorisée séparément peut être nécessaire, ou l’annulation peut être impossible. Si un élément associé a été supprimé entre-temps ou si une autre personne a déjà rétabli la valeur, l’interface signale que la modification ne peut pas être annulée. Une recommandation appliquée seulement en partie ne peut pas être annulée avec la fonction d’annulation de cette recommandation ; cela ne prouve pas que chaque modification sous-jacente qui en résulte soit impossible à inverser manuellement. Ne vous fiez donc jamais à cette fonction seule : notez l’ancienne valeur avant la modification.

Consignez pour chaque modification significative : le signal d’arrêt, la référence à la proposition et le justificatif de mise en œuvre, l’ancienne valeur cible avec justificatif, la personne habilitée, l’autorisation valide pour la modification inverse, la voie choisie (annulation dans l’historique, modification inverse manuelle autorisée séparément ou impossible), l’horodatage, la preuve technique établie ensuite, l’effet résiduel sur les coûts et les données ainsi que les points encore ouverts. Une mise en pause réduit l’exposition, mais ne garantit pas qu’aucun coût déjà généré ou signalé tardivement ne suive encore. En cas d’erreur de suivi, le retour en arrière implique en outre d’arrêter un import défectueux et de rapprocher les données.

Comment décrire un système selon son autorisation plutôt que selon son étiquette ?

Une étiquette comme «AI-powered» ne dit rien sur l’architecture de contrôle. Une seule question est déterminante : le système peut-il déclencher une modification aux conséquences importantes sans décision enregistrée et autorisée ? Vérifiez pour chaque niveau – le système d’enchères de Google, les paramètres de compte Google comme l’application automatique et les outils externes – les entités autorisées, la modification maximale, le mode proposition ou direct, la validation humaine, l’identité du fournisseur, la piste d’audit et la voie d’arrêt.

Pour maitiq, la réponse est la suivante : la génération de propositions ne modifie pas Google Ads à elle seule. Une modification ne résulte que d’une décision enregistrée et d’une exécution autorisée séparément et journalisée ; lorsque le pilote automatique limité est explicitement activé, le moteur peut approuver des propositions dans le cadre de la politique et déclencher, dans la même exécution globale du workflow, cette exécution séparée. Les calculs sont déterministes ; l’IA intervient uniquement à titre consultatif, son format de sortie est vérifié, et elle ne peut ni fusionner des propositions, ni les valider, ni les refuser, ni en réécrire les valeurs numériques. Un audit n’applique jamais de modification.

Comment séparer la vérification de l’effet ?

La vérification technique établit l’état dans la mesure où il peut être étayé : elle rapporte les éléments disponibles et laisse ouverte la vérification manquante. L’observation de l’effet demande plus tard comment les indicateurs définis ont évolué. Les deux ne doivent pas se confondre : une modification techniquement correcte peut être inadaptée sur le plan économique, et une évolution favorable après coup ne prouve aucune causalité. Enregistrez séparément le statut de mise en œuvre, la preuve technique disponible, la fenêtre d’observation, la maturité des données, les modifications parallèles et l’incertitude restante. Les définitions des indicateurs et de l’attribution précisent sur quel indicateur, quelle fenêtre et quel modèle d’attribution l’observation ultérieure peut s’appuyer.

Comment éviter la bureaucratie ?

La gouvernance doit accélérer les décisions : limites validées à l’avance pour les modifications réversibles à faible risque, champs de proposition standardisés, rôles selon le niveau d’importance, fenêtres d’examen regroupées, collecte automatique des preuves et exception d’urgence avec obligation de documentation dans un délai que vous fixez vous-même et consignez par écrit. Chaque organisation fixe ce délai elle-même ; les obligations légales, contractuelles et liées aux incidents n’en sont pas affectées.

Questions fréquentes

Sources et mise en perspective

Les sources sont la documentation Google : les pages d’aide décrivent l’historique des modifications, les paramètres d’application automatique et les recommandations ; la référence de l’API décrit ce qui peut être récupéré par voie programmatique. Vous trouverez des informations sur la manière de travailler de maitiq sur maitiq.com.

Faites examiner votre cas concret par maitiq.