Étude de cas

Boîte unifiée WhatsApp - Centralisation de 24 à 28 numéros

Docker Compose Chatwoot Evolution API Baileys PostgreSQL Redis Python Caddy

Toutes les lignes dans une seule liste : chaque conversation indique sa ligne, avec une étiquette de couleur

Vue d'une seule ligne : la réponse partira du numéro de cette ligne

Contexte

Un client basé en Suisse échange avec ses clientes sur 24 à 28 numéros WhatsApp, comptes classiques et Business, chacun installé sur son propre téléphone Android. Sans outil commun, chaque conversation ne se lit que sur le téléphone de sa ligne : pas de vue d'ensemble, pas de notification centralisée, aucune recherche d'une ligne à l'autre.

La mission : livrer une boîte de réception unique, sur ordinateur, navigateur et iPhone, où chaque message arrive avec sa ligne et son contact, et d'où la réponse repart par le bon numéro. Le tout installé sur un serveur au nom du client, sans retirer les numéros de leurs téléphones et en gardant messages et historique chez lui.

Problème & objectifs

Problème

24 à 28 numéros répartis sur autant de téléphones : impossible de suivre les conversations sans passer d'un appareil à l'autre
L'API officielle WhatsApp Business était exclue : elle retire le numéro du téléphone et refuse les comptes personnels, alors que chaque téléphone devait rester pleinement utilisable
Les outils qui pilotent un navigateur par compte auraient demandé plus de 10 Go de mémoire pour 28 comptes
WhatsApp délie un appareil lié quand le téléphone reste hors ligne environ 14 jours : une ligne peut décrocher sans que personne ne s'en aperçoive
Des données sensibles : messages, contacts et historique ne devaient dépendre d'aucun service tiers, et tout devait rester au nom du client

Objectifs

Réunir toutes les lignes dans une boîte unique : ligne et contact identifiés, ouverture directe de la conversation, réponse envoyée par le bon numéro, recherche dans toutes les lignes
Garder chaque numéro sur son téléphone d'origine, qui reste l'appareil principal
Notifier chaque message entrant sur iPhone, écran verrouillé et ordinateur éteint, en nommant la ligne et le contact
Superviser les lignes : reconnexion automatique, alerte quand une ligne décroche, suivi des téléphones restés trop longtemps hors ligne
Garantir confidentialité et réversibilité : données sur le serveur du client, journaux sans contenu de message, accès nominatifs et révocables
Dimensionner la plateforme pour l'ensemble des lignes, avec un raccordement par lots que le client peut mener seul
Valider la solution en conditions réelles sur les deux types de comptes, classique et Business, selon six critères mesurables définis avec le client

Approche

Les choix techniques ont été arrêtés sur des contraintes chiffrées, puis éprouvés sur des lignes réelles plutôt que sur le papier :

comparaison des options : API officielle écartée (elle retire le numéro du téléphone), automatisation de navigateur écartée (un Chrome par compte), retenu : Evolution API avec le moteur Baileys, qui parle directement le protocole WhatsApp Web multi-appareils, sans navigateur ;
chaque numéro devient un appareil lié, comme WhatsApp Web : il occupe une des 4 places du compte, et le téléphone garde toutes ses fonctions ;
Chatwoot comme interface unique (web et application iOS), une boîte par ligne, sur un serveur Hetzner au nom du client, en Docker Compose derrière Caddy pour le HTTPS ;
versions figées et documentées, aucune étiquette latest : toute montée de version se teste sur une seule ligne avant d'être généralisée ;
diagnostic d'une panne d'appairage apparue côté WhatsApp fin juillet 2026, qu'aucune version publiée de Baileys ne corrigeait : image Evolution API reconstruite avec le correctif amont, vérifiée à la construction ;
protocole de validation en six critères (réception dans la boîte, téléphones intacts, notification, réponse depuis la notification, 72 heures sans décrochage non rattrapé, retour seul en moins de 10 minutes après une coupure réseau provoquée), mesurés par un relevé automatique minute par minute ;
scripts et documentation écrits pour que le client ajoute ou retire une ligne seul.

Les pièges rencontrés sur les lignes réelles (appairage, envoi depuis Chatwoot, anomalies connues d'Evolution API) sont corrigés ou documentés dans le dépôt livré.

Points techniques

Architecture : Docker Compose : Evolution API 2.3.7 (une instance par numéro), Chatwoot 4.18 (interface web et application iOS), PostgreSQL 16 avec une base par service, Redis 7, Caddy 2 pour le HTTPS automatique. Seul Caddy est exposé sur Internet ; Evolution API n'écoute qu'en local et son gestionnaire s'ouvre par tunnel SSH.

Correctif d'appairage : Depuis fin juillet 2026, WhatsApp envoie pendant l'appairage une notification que Baileys acquittait sans la traiter : le QR code se renouvelait sans jamais aboutir. Image construite sur l'image officielle figée par empreinte, Baileys passé en 7.0.0-rc14 avec le correctif amont non encore publié, plus un correctif d'une ligne écrit pour ce déploiement : le code d'appairage à 8 caractères reste le même pendant toute la série au lieu de changer toutes les 20 secondes. La construction échoue si un correctif manque.

Notifications iPhone : Un initialiseur Ruby monté dans Chatwoot, sans modifier son image, redéfinit trois méthodes : chaque message entrant notifie les membres de la boîte de sa ligne (Chatwoot ne notifiait que la personne assignée), le titre nomme la ligne, et un réglage retire l'aperçu côté serveur pour qu'aucun contenu ne parte vers le relais de notification et Apple.

Supervision : Relevé de l'état de chaque session chaque minute, sans contenu ni numéro. Une ligne déconnectée plus de 10 minutes déclenche une alerte dans une boîte Chatwoot « Supervision », donc sur l'iPhone, puis un message à son retour. Chaque lundi, un résumé : disponibilité par ligne, téléphones sans activité depuis 10 jours, sauvegardes, disque, nouvelles versions et correctifs amont fusionnés.

Exploitation : Scripts Python sans dépendance externe pour raccorder, réappairer ou retirer une ligne : boîte, étiquette de couleur, règle d'automatisation et notifications réglées en une commande, relançable sans effet de bord. Sauvegardes nocturnes des bases avec test de restauration, coupure réseau provoquée et chronométrée pour la validation.

Sécurité & réversibilité : Serveur durci (SSH par clé uniquement, accès root coupé, pare-feu, mises à jour de sécurité automatiques), secrets générés hors dépôt, double authentification des comptes, journaux sans contenu de message avec rotation, accès nominatifs et procédure de révocation, archive chiffrée pour remonter l'ensemble sur un autre serveur.

Résultats

La mission a livré une plateforme conçue pour l'ensemble des lignes :

le socle complet sur le serveur du client, dimensionné pour 28 lignes avec de la marge (jusqu'à environ 32) : HTTPS, sauvegardes quotidiennes, secrets externalisés, double authentification ;
une solution validée en conditions réelles sur les deux types de comptes, classique et Business, selon un protocole mesuré minute par minute, le téléphone restant l'appareil principal ;
une boîte unifiée : ligne et contact identifiés sur chaque conversation, étiquette de couleur par ligne jusque sur l'iPhone, réponse envoyée par le bon numéro, recherche dans toutes les lignes à la fois ;
des notifications iPhone qui nomment la ligne et le contact, avec ou sans aperçu au choix du client ;
une supervision qui alerte dans la boîte elle-même, complétée d'un résumé chaque semaine ;
un raccordement outillé : chaque ligne se branche en une commande, par lots de 4 à 5, avec contrôle de la mémoire et de la stabilité entre deux lots ;
neuf documents d'exploitation, du guide d'utilisation à la réversibilité, et une étude chiffrée des sorties réseau pour répartir les lignes en 6 lots.

Ajouter une ligne tient en une commande et quelques minutes, téléphone en main, et la procédure est écrite pour que le client la fasse seul.

Ce que j'ai appris

choisir une architecture sur des contraintes chiffrées (mémoire, appareils liés, conservation des numéros) plutôt que sur la popularité d'un outil ;
diagnostiquer une régression dans une bibliothèque tierce, suivre le correctif amont et l'intégrer dans une image figée et vérifiable ;
étendre une application existante sans la forker, par un initialiseur ciblé et documenté, à revérifier à chaque montée de version ;
définir avec le client des critères de validation mesurables, et outiller leur preuve plutôt que de l'affirmer ;
concevoir une supervision utile : peu d'alertes, au bon endroit, avec la marche à suivre ;
penser confidentialité et réversibilité dès le départ : données chez le client, journaux sans contenu, accès révocables.

Cette mission m'a appris qu'une intégration fiable tient autant à la rigueur qui l'entoure qu'au code : versions figées, mesures, documentation et procédures que le client peut suivre seul.