Supervision et automatisation des tests

Vous êtes prévenu, au lieu de le découvrir dans les chiffres des semaines plus tard. Les deux défaillances invisibles depuis un écran de résultats sont une répartition qui ne correspond plus à votre configuration, et un test qui a discrètement cessé d’enregistrer quoi que ce soit, en général parce qu’un déploiement a emporté le script ou qu’une règle de ciblage ne s’applique plus. Les deux déclenchent par défaut une alarme par e-mail et par Slack, les deux marquent chaque résultat de ce test comme non fiable, et les deux empêchent la plateforme d’agir dessus. Le travail qui vous attend est une file classée plutôt qu’un fouillis, et il est déduit de ce qui est vrai à l’instant, si bien que rien ne disparaît parce que quelqu’un a effacé une notification.

Rien, jusqu’à ce que vous l’activiez, et ensuite moins que vous ne l’imaginez. L’automatisation et le déploiement automatique d’un gagnant sont deux interrupteurs distincts, tous deux désactivés au départ, parce qu’arrêter automatiquement le mauvais test coûte le trafic déjà dépensé, tandis que déployer automatiquement un perdant change ce que voit chaque visiteur. Avant d’agir, la plateforme doit franchir trois contrôles de fiabilité et une durée minimale. Et automatisation désactivée, elle évalue tout de même tout et consigne ce qu’elle aurait fait, avec le code même qui l’aurait fait, si bien que vous pouvez vérifier pendant un mois qu’elle a raison avant de la laisser agir.

Les membres sont en lecture seule sur toute la plateforme : ils voient chaque test et chaque résultat et n’en modifient aucun. Cette règle est appliquée une seule fois, de façon centrale, plutôt qu’écran par écran, ce qui importe parce qu’un modèle de permissions appliqué écran par écran est un modèle où le prochain écran construit devient discrètement l’exception. Démarrer, arrêter et déployer restent aux administrateurs et aux propriétaires, et chaque modification qui compte est consignée sur le test avec un nom et une date.

C’est la forme même autour de laquelle la supervision est construite. Tout ce qui reste non résolu sur chaque compte auquel vous avez accès est rassemblé dans une vue, groupé par client et par site, classé de sorte que ce qui n’est pas fiable passe avant ce qui attend simplement une décision. Le périmètre vient du compte avec lequel vous êtes connecté plutôt que d’un identifiant dans l’adresse, si bien qu’il n’y a pas d’identifiant de compte à vérifier dans l’URL, ni aucun à trafiquer. Une agence voit son portefeuille ; un client mono-marque voit son propre compte dans le même écran.

Les alertes partent par e-mail, sur Slack, ou nulle part, réglées par type d’événement et par personne plutôt qu’une seule fois pour tout le compte, et les messages Slack renvoient à l’écran exact auquel l’événement se rapporte. Côté mesure, chaque site est réglé sur GA4, Matomo ou la mesure native de Pertento, ce qui signifie que les conversions que nous comptons peuvent être les événements que votre analytique compte déjà, plutôt qu’une seconde définition de l’achat que quelqu’un devra réconcilier.