Aller au contenu
HA_

← Tous les articles

· 4 min de lecture

Ne jamais agir en silence dans le compte d’un client

Pourquoi ClickFortify ne crée jamais rien en arrière-plan dans le compte publicitaire d’un client, et ce qu’une étape de validation doit montrer avant de le faire.

productarchitectureadtech

Traduction automatique. Lire l’original

ClickFortify travaille à l’intérieur des systèmes des autres. Pour exclure le trafic invalide, il doit se connecter au compte Google Ads ou Meta d’un client et y modifier des éléments. Cet accès est au cœur du produit, et c’est aussi la partie que je traite avec le plus de prudence. Une règle est née de cette prudence, et elle guide désormais chaque cas similaire : nous n’agissons jamais en silence dans le compte d’un client.

D’où vient la règle

Pendant le travail sur la connexion Meta, quelqu’un a proposé de créer automatiquement un Meta Pixel lorsque le client n’en avait pas. En apparence, l’idée semblait utile. Le client a besoin d’un pixel, nous pouvons en créer un, alors pourquoi demander ?

J’ai refusé. Non pas parce qu’un pixel serait dangereux, mais à cause de ce que ce raccourci suppose : que nous savons mieux que le client ce qui doit exister dans son compte, comment cela doit s’appeler et où cela doit se trouver. Ce n’est pas le cas. C’est son compte.

Ce que nous faisons à la place

Tout parcours qui créerait quelque chose dans le compte externe d’un client affiche d’abord une étape de validation. Cette étape comporte quatre éléments :

  • Un nom modifiable. Nous en suggérons un, et le client peut le changer.
  • L’endroit où il sera créé. Le compte ou l’entreprise auquel il sera rattaché, indiqué clairement.
  • Ce que nous en ferons. Une phrase honnête expliquant pourquoi nous en avons besoin.
  • Un bouton « Créer » sur lequel le client appuie. Rien ne se passe en arrière-plan.

Les valeurs par défaut sont acceptables. Une bonne valeur par défaut fait gagner du temps au client, et la plupart l’accepteront. L’exécution silencieuse ne l’est pas. La différence est faible en effort et immense en signification : avec une valeur par défaut, c’est le client qui décide ; sans étape de validation, nous décidons à sa place.

La règle ne concerne pas que les pixels. Elle couvre tout ce que nous pourrions créer dans le compte d’un client, qu’il s’agisse d’une balise, d’une audience ou de toute autre entité de la plateforme.

// Illustrative: a change we propose, but never apply on our own
type ProposedAction = {
  kind: 'create';
  resourceType: string;  // what will be created
  name: string;          // suggested by us, editable by the customer
  parentId: string;      // the account or business it will live under
  purpose: string;       // what we will do with it, in plain words
  confirmedBy?: string;  // empty until the customer presses Create
};

La propriété utile se trouve dans le dernier champ. Tant qu’une personne n’a pas confirmé l’action, ce n’est qu’une proposition.

Pourquoi c’est important

Le client garde la maîtrise du nommage et de l’emplacement. Un compte publicitaire est rarement utilisé par une seule personne ou un seul outil. Une ressource portant un nom que personne n’a choisi, rattachée à une entreprise que personne n’a sélectionnée, est au mieux un encombrement, au pire une source de confusion.

La confiance est le produit. Un client qui connecte son compte publicitaire nous prête ses clés. S’il découvre quelque chose que nous avons créé sans lui demander, la question suivante est de savoir ce que nous avons fait d’autre. Une création silencieuse paraît paternaliste, même quand l’intention est bonne.

Les surprises dans le système de quelqu’un d’autre coûtent cher. Le compte du client ne nous appartient pas, et nous ne voyons pas tout ce qui s’y passe par ailleurs. Une modification qui semble anodine de notre côté peut entrer en conflit avec une convention de nommage ou un reporting.

Cela facilite le support et le retour en arrière. Quand le client a créé quelque chose volontairement, via un écran qui lui expliquait à quoi cela servait, il sait d’où cela vient. S’il veut l’annuler, il sait quoi chercher. Une action en arrière-plan le laisse se débrouiller seul.

Au-delà de la création

Le même raisonnement s’applique à tout ce qu’un produit fait dans un système externe, pas seulement à la création de ressources. Une exclusion écrite dans un compte publicitaire est elle aussi une modification de la configuration de quelqu’un d’autre. À mon sens, de telles modifications devraient être visibles et attribuables : le client devrait pouvoir voir ce qui a été fait, et que cela vient de nous. C’est un principe auquel je tiens, pas une description de chacun de nos écrans.

À retenir

  1. Considérez le compte externe d’un client comme le sien, même si vous y avez un accès en écriture.
  2. Proposez des valeurs par défaut, mais placez chaque création derrière une étape de validation avec un nom modifiable, son emplacement, sa finalité et un bouton de confirmation explicite.
  3. Modélisez la création comme une proposition qui ne devient une action qu’après confirmation par une personne.
  4. Demandez-vous si le client serait surpris de découvrir la modification plus tard. Si oui, ne la faites pas en silence.