Bot Butcher

Qu’est-ce que Bot Butcher ?

Bot Butcher est une API anti-spam pour les formulaires de contact sur site, fournie par Hillside Lab Inc., qui aide principalement les développeurs à classifier les messages avant qu’ils n’arrivent dans leurs boîtes aux lettres, leurs systèmes de relation client ou leurs systèmes de tickets.

Il analyse le contenu des messages soumis par les visiteurs et peut, en combinant l’adresse du site web, comprendre le contexte pour retourner un résultat structuré indiquant s’il s’agit ou non de spam.

Fonction principale

• Classification dans le contexte : Envoyer les messages du formulaire à l’interface de classification, en y associant l’adresse du site web, afin que le système puisse distinguer les demandes normales, les contenus promotionnels et les messages indésirables automatisés.
• Décision structurée : l’interface renvoie une valeur booléenne indiquant s’il s’agit de spam, le message_id et un code d’état, permettant au programme d’autoriser, d’isoler, de marquer ou de rejeter le message.
• Recherche dans les archives historiques : en utilisant le message_id, il est possible de consulter l’heure à laquelle un message a été traité, son texte original, le nom de domaine, les métadonnées ainsi que les résultats de classification, ce qui facilite l’analyse des workflows.
• Metadata personnalisé : La demande peut inclure des métadonnées JSON pour enregistrer les formulaires, les locataires, les événements ou les identifiants de registres internes.
• Expérience sans code de vérification : la vérification a lieu du côté serveur, il n’est pas nécessaire que les visiteurs reconnaissent des images ou résolvent des défis interactifs, ce qui permet de réduire les obstacles à la soumission des formulaires.
• Utilisation sur plusieurs sites : les droits de tarification incluent un nombre illimité de formulaires de site ; il est possible de protéger plusieurs projets depuis le même compte, mais le volume d’appels reste calculé au total pour le compte.
• Contrôle de la confidentialité : les utilisateurs peuvent activer l’option de ne pas conserver les messages et d’interdire leur utilisation pour l’entraînement ; ces deux options ne coûtent rien actuellement.

Entrée et sortie

Processus d’accès

1. Validez votre inscription en utilisant votre adresse e-mail, ou connectez-vous avec un compte tiers pris en charge, et acceptez les conditions d’utilisation.
2. Obtenez la clé API dans votre compte, et stockez-la dans une variable d’environnement du serveur ou dans un système de gestion de clés.
3. Collecter le message dans le backend du formulaire de contact, et ajouter le domaine et les métadonnées si nécessaire.
4. Envoyer une requête à l’interface de classification, ajouter la clé dans l’en-tête de la requête, puis analyser les valeurs spam et message_id retournées.
5. Définissez des règles d’autorisation, d’isolement, de révision manuelle ou de refus en fonction des risques liés aux opérations ; ne vous fiez pas uniquement à une décision automatique unique pour supprimer définitivement un message.
6. Utiliser des messages de test pour couvrir les consultations normales, la vente, les différentes langues, le contenu vide et les demandes anormales, afin de valider le traitement des erreurs et les stratégies de délai d’expiration.
7. Après mise en ligne, surveillez le nombre d’appels, les erreurs de détection et les coûts, et déterminez, conformément aux exigences de confidentialité, si les messages doivent être conservés et s’ils doivent être utilisés pour l’entraînement.

Langages de développement et méthodes d’implémentation

Le document fournit des exemples de requêtes en cURL, Python, JavaScript, TypeScript, Java, C# et Rust ; les fonctionnalités principales peuvent également être appelées depuis d’autres langages backend capables d’envoyer des requêtes réseau et de parser du JSON.

Ces extraits de code sont des exemples d’appels d’interface et ne doivent pas être considérés comme un SDK officiel complet et publié.

Adapté aux utilisateurs et aux scénarios

• Développeurs de sites d’entreprise et de sites indépendants qui doivent réduire les spams provenant des formulaires de contact.
• Gérer des sites web pour plusieurs clients, et souhaiter partager un ensemble d’interfaces anti-spam avec l’équipe de création de sites.
• Équipe des techniques de marketing et de vente qui doit filtrer les prospects avant qu’ils n’accèdent au système de relation client.
• Développeurs de plateformes pour générer des sites web, des SaaS verticaux ou des produits de formulaires multi-locataires.
• Les équipes de produits souhaitent éviter que les visiteurs ne remplissent les codes de vérification traditionnels, tout en conservant la capacité du serveur à évaluer les risques.

Avantages du produit

• Les structures d’entrée et de sortie de l’interface sont simples, ce qui facilite leur intégration dans les backends de formulaires existants ainsi que dans les chaînes de traitement de messages.
• Le contexte du nom de domaine peut aider le modèle à comprendre la signification d’une même phrase sur différents sites web.
• Ne pas conserver les messages et interdire l’entraînement offrent un contrôle des données plus précis pour les activités sensibles.
• Aucun nombre de formulaires limité : plusieurs sites peuvent être gérés en centralisant les appels et les frais.
• Définir des frais fixes gratuits ou faibles pour une faible consommation, idéal pour tester l’efficacité en utilisant d’abord un trafic réel.

Limites des capacités et restrictions d’utilisation

• Toute classification automatique peut entraîner des erreurs ; les leads commerciaux importants doivent être placés dans une zone d’isolement ou soumis à une vérification manuelle, plutôt que d’être supprimés définitivement.
• Le taux de précision annoncé sur le site officiel provient de leur propre référence d’évaluation manuelle, et non de tests effectués par un tiers indépendant ; les résultats réels dépendent du langage, du secteur d’activité et de la répartition des messages.
• Le champ « domain » est optionnel, mais son omission réduit le contexte ; selon la politique de confidentialité officielle, cela entraîne une baisse d’environ 6 % de la précision lors des tests.
• L’interface doit envoyer le contenu du formulaire à un service externe ; une évaluation de conformité doit être effectuée avant de traiter des informations sensibles, médicales, financières ou réglementées.
• Les noms de domaine invalides peuvent encore obtenir des résultats de classification et des indications, mais la qualité du jugement peut être réduite ; l’appelant doit valider les entrées.
• Les temps d’attente réseau, les quotas ou les erreurs d’authentification ne peuvent pas être assimilés à des messages normaux ou des spams ; l’application doit définir une stratégie de gestion des échecs indépendante.
• Pour l’instant, le nom du modèle spécifique, le délai de réponse fixe, l’accord de niveau de service ou le rapport d’audit de sécurité indépendant ne sont pas divulgués.

Prix et facturation

Les échelons sont calculés en fonction du nombre de demandes par mois ; la facture réelle peut également être influencée par les taxes, la région du compte ou les paramètres de règlement, et il convient de se référer à la page de règlement du compte.

Les conditions stipulent que les frais payés ou engagés avant la résiliation de l’abonnement ne sont pas remboursables, et que la résiliation n’exonère pas les frais déjà accumulés.

Confidentialité, sécurité et traitement des données

• Il est possible, dans les paramètres, de choisir de ne pas enregistrer les messages, afin que le contenu soumis ne soit pas conservé dans le stockage des messages historiques.
• Il est possible de choisir les messages à interdire pour l’entraînement du modèle ; cette option n’est pas facturée en supplément pour le moment.
• Le domaine peut être omis pour réduire le contexte du site partagé, mais cela implique un compromis entre la confidentialité et l’efficacité de la classification.
• La notice de confidentialité indique que les données stockées sont conservées selon des méthodes conformes aux exigences HIPAA, mais l’utilisation de ce service ne suffit pas à elle seule à garantir que les activités du client respectent l’ensemble des obligations de conformité médicale.
• La politique de confidentialité indique que des informations relatives au compte, au dispositif et à la navigation peuvent être collectées, et que les informations nécessaires sont transmises au fournisseur de services.
• Les cartes de paiement sont traitées par des processeurs de paiement, et Bot Butcher affirme ne pas collecter directement les informations des cartes.
• Les clés API ne doivent être placées que du côté serveur, et ne peuvent pas être intégrées dans des pages web publiques, des interfaces mobiles ou des dépôts de code publics.
• Avant soumission, il convient de réduire les données personnelles non pertinentes et d’indiquer dans sa politique de confidentialité les finalités du traitement, ainsi que les règles relatives au traitement et à la conservation par des tiers.

API, code et statut open source

Résumé

Bot Butcher convient pour intégrer la détection des spams dans les formulaires de contact dans le flux de travail serveur, en particulier pour les équipes ayant besoin d’une gestion multi-sites, d’une faible friction d’interaction et de modes d’utilisation des données configurables.

Avant la connexion officielle, il convient d’utiliser son propre ensemble de messages réels pour évaluer les erreurs de détection, et d’implémenter en même temps des mécanismes de retour en arrière en cas d’échec, une révision manuelle, une protection des clés, des informations sur la confidentialité et un suivi des coûts.