De nombreux développeurs commencent avec des outils basés sur le navigateur comme Selenium ou Puppeteer pour piloter WhatsApp Web. Ces outils lancent une instance complète de Chrome, qui peut consommer des centaines de mégaoctets de RAM et nécessite un environnement VNC persistant ou sans tête. Le coût en mémoire et en CPU devient rapidement un obstacle pour les projets amateurs ou pour faire évoluer des dizaines de bots sur un seul VPS.
Baileys supprime la couche navigateur
Baileys communique directement avec le protocole binaire de WhatsApp Web via WebSockets, éliminant ainsi le besoin d’un navigateur graphique [6]. Comme seul le client WebSocket s’exécute, la consommation de mémoire chute à quelques mégaoctets et la charge CPU reste faible. En pratique, un VPS modeste avec 1 vCPU et 2 Go de RAM peut héberger un bot Baileys sans problème de performance [7]. Cette efficacité réduit également la surface d’attaque : aucun exploit de navigateur à craindre.
Déployer Baileys sur les Cloudflare Workers
Le projet whatsapp‑cloudflare‑workers adapte Baileys au runtime edge de Cloudflare. Il s’agit d’un fork qui regroupe la bibliothèque avec le petit runtime Worker et supprime les API spécifiques à Node qui ne sont pas disponibles en edge [1][2]. Le worker ouvre une connexion WebSocket directe à WhatsApp, la maintient pendant une courte fenêtre (généralement 10–50 secondes), exécute l’action requise (enregistrement d’un numéro ou envoi d’un message), puis ferme le socket pour libérer les ressources [1][2]. Ce modèle correspond à la nature sans état des Workers et évite le coût de maintenir des connexions longues sur le edge.
Exemple de flux de travail
- Déclencheur – Une requête HTTP vers le Worker contient le numéro de téléphone cible et la charge utile du message.
- Connexion – Le Worker démarre une session WebSocket Baileys.
- Envoi – Le message est transmis via le même protocole utilisé par le client web officiel.
- Fermeture – Après réception de la réponse, le socket est terminé, maintenant l’exécution en dessous de la limite CPU de 10 ms d’un Worker typique.
Avantages en termes de coût et de politique par rapport à l’API officielle
L’API officielle WhatsApp Business (WABA) exige la vérification de l’entreprise, l’approbation des modèles de messages et des frais par message (souvent autour de 0,005 $) [7]. Ces exigences ajoutent à la fois une charge administrative et un coût récurrent. En revanche, une solution Baileys auto‑hébergée contourne la modération des modèles et élimine les frais par message, offrant aux développeurs une pleine liberté sur le contenu des messages [7]. Bien que WABA garantisse la délivrance et le support, de nombreux projets de petite à moyenne taille jugent le compromis acceptable lorsque le coût est la préoccupation principale.
Efficacité des ressources et mise à l’échelle sur le edge
Comme Baileys ne lance pas de navigateur, un seul worker edge peut gérer de nombreuses sessions de courte durée. La mise à l’échelle horizontale — déployer des dizaines d’instances identiques — n’est pas nécessaire pour un trafic modeste. À la place, les développeurs peuvent mettre en file d’attente les messages sortants dans un stockage durable (par ex., Cloudflare KV ou une file d’attente tierce) et laisser chaque Worker récupérer un travail, envoyer le message, puis se terminer. Ce modèle basé sur une file d’attente garde le système léger tout en supportant les pics de trafic [1][2].
Compromis
| Aspect | Automatisation par navigateur | Baileys sur Workers |
|---|---|---|
| Mémoire | Des centaines de Mo par bot | < 10 Mo |
| CPU | Élevé (Chrome) | Faible (WebSocket uniquement) |
| Coût | VPS + licence Chrome (le cas échéant) | Invocations Worker à la demande |
| Garanties de livraison | Dépend de la stabilité de Chrome | Identiques au protocole WhatsApp Web |
| Complexité | Gestion des navigateurs sans tête | Gestion des Workers de courte durée |
Conseils pratiques pour démarrer
- Lire la documentation de Baileys pour comprendre les flux d’authentification et la gestion du QR‑code [6].
- Cloner le fork du worker et déployer avec
wrangler publish– le dépôt inclut unwrangler.tomlprêt à l’emploi pour une configuration rapide [1][2]. - Stocker les identifiants en toute sécurité en utilisant Cloudflare Secrets ; le worker les récupérera à l’exécution.
- Mettre en place une file d’attente (par ex., Cloudflare Workers Queues) pour alimenter les messages dans la fonction edge, en veillant à ne jamais dépasser la fenêtre d’exécution de 10 secondes.
- Surveiller l’utilisation via les analyses Cloudflare ; la plateforme rapporte le nombre de requêtes et le temps CPU, vous aidant à rester dans le budget.
En combinant le client WebSocket léger de Baileys avec le réseau edge mondial des Cloudflare Workers, les développeurs peuvent créer des bots WhatsApp à la fois économiques et très réactifs, sans le poids lourd de l’automatisation via navigateur.
Sources
[1] GitHub – whatsapp‑cloudflare‑workers fork of Baileys. [2] README of the Cloudflare Workers project. [6] Baileys documentation. [7] Blog post on self‑hosted Baileys bots vs. WABA.
Sources
- GitHub - pierangelo04/whatsapp-cloudflare-workers: A version of Baileys …
- whatsapp-cloudflare-workers/README.md at master - GitHub
- WhatsApp bot on VPS via Baileys: free instead of WhatsApp
- Baileys - Baileys
- whatsapp-cloudflare-workers - npm Package Security Analysis … - Socket
- whatsapp-cloudflare-workers 6.7.17-worker-1.0.3 on npm - Libraries.io
- Introducing @zervonex/baileys - A Tailored Fork of the Baileys WhatsApp …
- workers.dev · Cloudflare Workers docs
