2026 — OpenClaw et WhatsApp sur VPS Linux cloud : appairage QR, persistance des sessions, coexistence multi-canaux — étapes reproductibles et FAQ par niveaux (déconnexion / 429)

WhatsApp est le canal que vos clients ont déjà dans la poche, mais c’est aussi l’adaptateur le plus bruyant à faire tourner à côté d’une passerelle : la fenêtre QR se referme vite, les fichiers de session sont précieux, et la limitation côté Meta apparaît souvent comme des déconnexions floues tant qu’on ne sépare pas les coupures de transport des tempêtes de HTTP 429. Ce guide propose une voie reproductible pour OpenClaw sur un VPS Linux cloud en 2026 : scanner une fois, persister l’état sous un utilisateur système dédié, faire coexister Telegram ou Slack sans mélanger les secrets, et dépanner par paliers plutôt que de rebooter au hasard. Pour réduire la surface exposée et clarifier loopback versus HTTPS public sur le même hôte, voir aussi 2026 — OpenClaw Linux, VPS cloud : surface d’attaque minimale — modèles de pare-feu, liaison Gateway en loopback et administration par tunnel SSH ; matrice face au reverse proxy HTTPS public et FAQ par paliers.

Mise en place reproductible : préparation du VPS, appairage QR, premier message

Créez un utilisateur non root (par exemple openclaw) et une racine d’état unique en écriture, par exemple /var/lib/openclaw/whatsapp, appartenant à cet utilisateur. Installez OpenClaw comme sur le reste de la machine — archive ou conteneur — mais montez le répertoire de session comme volume hôte pour que les reconstructions n’effacent jamais l’appairage. Démarrez la passerelle une fois au premier plan, récupérez la chaîne QR ou le QR ASCII dans les journaux, scannez avec le téléphone professionnel dans le délai annoncé, puis vérifiez que le processus journalise « connecté » avant de le passer en arrière-plan.

Pour un second adaptateur sur le même type de VPS avec TLS, callbacks et discipline des jetons, la mécanique de bord est comparable à celle décrite dans 2026 — OpenClaw et Slack sur VPS Linux cloud : jetons de bot, abonnements aux événements, URL de callback vers la passerelle — déploiement reproductible et FAQ 403 / rejeu par niveaux — le transport change, mais l’hygiène des secrets et des chemins reste la même.

# ~/.config/systemd/user/openclaw-whatsapp.service
[Service]
WorkingDirectory=/var/lib/openclaw/whatsapp
ExecStart=/usr/local/bin/openclaw gateway --profile whatsapp
Restart=on-failure
RestartSec=5

Activez le « lingering » pour l’utilisateur du service si l’unité doit survivre à la déconnexion, et orientez la rotation des logs vers le journal de la passerelle uniquement — ne faites jamais tourner des fichiers de session actifs au milieu d’une écriture. Après le premier appairage réussi, redémarrez volontairement une fois : si la session se recharge sans redemander de QR, le chemin de persistance est correct.

Persistance des sessions : ce qui doit survivre aux reboots et aux mises à jour d’image

Traitez le magasin de session WhatsApp comme une base de mots de passe : chiffrement au repos si votre build le permet, droits 0700, sauvegardes chiffrées hors machine, et aucune copie sur les portables des développeurs « pour gagner du temps ». L’appairage lie du matériel cryptographique à l’identité de la passerelle ; cloner le répertoire vers un second VPS sans migration contrôlée impose en général un nouveau QR et double brièvement le trafic d’enregistrement sortant — schéma typique qui déclenche les garde-fous anti-abus.

Ne snapshottez le répertoire que lorsque le processus est arrêté ; copier des fichiers chauds invite des paires corrompues qui ressemblent à des déconnexions aléatoires. Si vous déployez en bleu/vert, montez le même volume sur la nouvelle instance avant de basculer le trafic, puis retirez l’ancienne VM seulement après envoi et réception de messages réussis sur le nouveau nœud.

Inscrivez le chemin racine de session dans le runbook à côté du nom d’unité, gardez-le hors partitions éphémères (ne liez jamais l’état vers /tmp), et épinglez la version du paquet passerelle à côté de l’unité pour que les retours arrière correspondent aux changements de format de fichiers mentionnés dans les notes de version.

Coexistence multi-canaux avec Telegram, Slack ou Discord

Faites tourner des profils ou processus séparés par canal, chacun avec son propre fichier de jeton ou racine de session, et une file de sortie unique pour que les appels d’outils n’entrelacent pas les réponses entre réseaux. WhatsApp ne doit pas lire les variables d’environnement de Telegram et inversement ; une mauvaise ligne collée dans .env suffit pour router le trafic vers le mauvais adaptateur tout en laissant les sondes de santé au vert.

Préférez des fichiers EnvironmentFile distincts par unité systemd, des noms de service explicites (openclaw-whatsapp.service vs openclaw-slack.service) et des journaux séparés : lors d’un incident nocturne, le bon fichier de log évite d’attribuer à Slack une erreur WhatsApp ou l’inverse.

Pour l’autorisation, les listes d’autorisation et la déduplication lorsque deux réseaux alimentent un même cerveau, réutilisez les mêmes principes que pour les autres messageries : transports différents, même histoire d’autorisation.

Dépannage par paliers : déconnexion simple versus limitation 429

Palier 1 — connectivité : validez UDP/TCP sortants vers les points de terminaison WhatsApp depuis le VPS lui-même, pas depuis votre portable via SSH. Une perte sporadique sur de petits hébergeurs corrèle souvent avec des boîtes intermédiaires agressives ; changer de sortie ou stabiliser le résolveur peut peser plus qu’un bump de version OpenClaw.

Palier 2 — intégrité de session : si les journaux évoquent un conflit ou une déconnexion multi-appareils, assurez-vous qu’un seul rédacteur principal touche le répertoire de session. Les ponts qui se connectent au même numéro expulsent la session passerelle sans message d’erreur poli.

Palier 3 — plafonds : lorsque les réponses évoquent une limitation ou que des HTTP 429 se répètent, instrumentez le débit d’envoi par minute, fusionnez les réponses automatiques dupliquées, et ajoutez un backoff avec jitter avant de relancer les flux lourds en outils. Traitez le 429 comme un problème de budget, pas de mot de passe — faire tourner des clés API ne ralentit pas une session WhatsApp qui envoie tout simplement trop vite. Si certains fils reçoivent encore des messages pendant que d’autres échouent, cherchez le fan-out (un événement entrant qui génère trop de réponses sortantes) et regroupez les notifications ; des 429 aux heures ouvrées indiquent souvent que trafic humain et bot partagent un même numéro et méritent des limiteurs séparés.