Fail-open : pourquoi une vérification anti-bots ne doit jamais faire tomber votre site

Une vérification anti-bots se place sur les pages qui comptent le plus : la connexion, l'inscription, le checkout. C'est ce qui la rend utile, et aussi dangereuse. Si chaque checkout l'attend, le jour où elle est lente, votre checkout est lent ; le jour où elle tombe, vous tombez aussi.

Fail-open, fail-closed

Quand la vérification ne peut pas répondre, il y a deux choix. Fail-closed bloque le visiteur : sûr contre les bots, fatal pour l'activité, car chaque vrai client est bloqué aussi. Fail-open laisse passer le visiteur : pendant la panne, les bots entrent comme avant votre vérification, et personne d'autre ne le remarque.

Pour presque tous les sites, le fail-open est le bon choix. Quelques minutes sans protection anti-bots coûtent peu ; quelques minutes sans checkout coûtent cher, ainsi que la confiance de ceux qui l'ont vu.

Quatre règles pour appeler une vérification anti-bots

1. Un timeout court. Choisissez le maximum que vous ajouterez à la page, 100 à 200 ms, et imposez-le dans votre code. Ne comptez jamais sur la rapidité du fournisseur.
2. Toute erreur laisse passer le visiteur. Un timeout, une erreur de connexion, un 5xx, un 402 pour une offre épuisée, ou un corps illisible : tout cela signifie « pas de réponse », et pas de réponse signifie continuer.
3. N'agir que sur une réponse sûre. Bloquez sur la classe de bot la plus haute ; sur des preuves plus faibles, ajoutez de la friction comme un code par e-mail, jamais un mur.
4. Journaliser les ratés. Comptez les timeouts et les erreurs, pour qu'une panne soit un graphique, pas un mystère.

À quoi cela ressemble dans le code

const d = await fetch(API + "/v1/decide", {
  method: "POST",
  headers: { Authorization: `Bearer ${KEY}` },
  body: JSON.stringify({ ip, user_agent, token, path }),
  signal: AbortSignal.timeout(150),
}).then((r) => r.json()).catch(() => null);

if (d?.class === "bot_high") return res.status(403).end();
// anything else, including no answer: carry on

Le catch est toute la politique : tout ce qui échoue devient null, et null n'est jamais un bot.

Le côté navigateur est aussi fail-open

Le script sur votre page ne doit jamais la bloquer non plus. S'il ne peut pas joindre le service, la page fonctionne exactement comme sans lui ; la décision du serveur a simplement moins de preuves cette fois-là.

Comment Bot Protection est conçu pour cela

Bot Protection est un appel depuis votre serveur, pas un proxy devant votre site, il n'est donc jamais sur le chemin d'une requête que vous n'avez pas choisi de vérifier. Son tag attend un temps borné et abandonne en silence. À votre limite de dépenses, il répond 402, que votre code traite comme n'importe quelle autre erreur : les visiteurs passent, et vous recevez un e-mail avant que cela n'arrive.