Un assistant IA dans WhatsApp : reconstruisez cette connexion étape par étape

Ce que vous allez construire

Le système complet se compose de deux programmes qui tournent côte à côte sur un même serveur, plus un modèle d'IA :

• Le pont — un petit programme (le nôtre est écrit en Go) qui se rattache à votre WhatsApp comme appareil connecté, exactement comme WhatsApp Web. Il reçoit chaque message et peut en envoyer.
• L'intermédiaire — un serveur web (Python chez nous) qui prend chaque message entrant, le transforme en instruction pour le modèle d'IA et renvoie la réponse.
• La mémoire — une base de données qui conserve tous les messages par conversation, pour que l'assistant sache ce qui a été dit auparavant.

Le trajet d'un message : votre téléphone → WhatsApp → le pont → l'intermédiaire → le modèle d'IA → l'intermédiaire → le pont → retour dans votre discussion. Le pont et l'intermédiaire communiquent via deux ports locaux sur le même serveur — rien dans cette chaîne n'a besoin d'être exposé sur internet.

Prérequis

• Un serveur Linux ou VPS (1 CPU et 1 à 2 Go de mémoire suffisent pour commencer)
• Go 1.21 ou plus récent, pour le pont
• Python 3.11 ou plus récent, pour l'intermédiaire
• Une bibliothèque WhatsApp open source ; nous utilisons whatsmeow, qui parle le protocole des appareils connectés de WhatsApp
• Un accès à un modèle d'IA : une clé API d'un fournisseur, ou un outil d'IA utilisable en ligne de commande
• SQLite (présent presque partout) pour la session et l'historique des messages
• Optionnel : ffmpeg et un modèle de transcription comme Whisper, pour les messages vocaux

Vous n'avez pas besoin d'un numéro de téléphone séparé : le pont s'appaire comme appareil supplémentaire sur un compte WhatsApp existant. Pour un usage professionnel, un second numéro est toutefois plus propre.

Phase 1 — le pont : se connecter à WhatsApp

Le pont ne fait que deux choses : rester connecté et transmettre les messages. Voici comment le mettre en place :

1. Créez un nouveau projet Go et ajoutez la bibliothèque WhatsApp comme dépendance.
2. Faites stocker la session par la bibliothèque dans un fichier SQLite local — l'appairage survit ainsi à un redémarrage.
3. Lancez le programme : au premier démarrage, un QR code apparaît dans le terminal.
4. Scannez ce QR code avec votre téléphone via WhatsApp → Appareils connectés, exactement comme pour WhatsApp Web.
5. Enregistrez un gestionnaire d'événements déclenché à chaque message entrant.
6. Dans ce gestionnaire, stockez chaque message dans une seconde base SQLite avec deux tables : une pour les conversations (ID de discussion, nom, dernier message) et une pour les messages (ID, ID de discussion, expéditeur, texte, horodatage, envoyé-par-moi-ou-non).

Testez d'abord cette partie seule : envoyez-vous un message et vérifiez qu'il apparaît dans la base. Ne continuez que lorsque cela fonctionne.

Phase 2 — le pont comme relais : webhook et API d'envoi

Le pont doit transmettre les messages et en envoyer. Il reçoit donc deux visages :

1. Donnez au pont un petit serveur HTTP sur un port local (nous utilisons le 8080), accessible uniquement depuis le serveur lui-même.
2. Ajoutez un endpoint d'envoi : un POST avec destinataire, texte et éventuellement un chemin de fichier, que le pont transforme en message WhatsApp.
3. Ajoutez un endpoint de téléchargement qui récupère et déchiffre les médias d'un message antérieur (les médias WhatsApp sont chiffrés ; la clé accompagne le message et la bibliothèque gère le déchiffrement).
4. Faites en sorte que le gestionnaire de la phase 1 transmette aussi chaque message entrant : un POST avec ID de discussion, expéditeur, texte, horodatage et type de média vers une adresse webhook fixe sur le serveur — le port 8769 chez nous.

Cette adresse webhook, c'est l'intermédiaire de la phase 3. S'il n'existe pas encore, le POST se perd simplement — le pont continue de tourner.

Phase 3 — l'intermédiaire : du message à la réponse

C'est le cerveau de la chaîne. Un serveur web (nous utilisons FastAPI) avec une seule mission : message en entrée, réponse en sortie.

1. Créez un serveur web avec un endpoint webhook qui accepte le POST du pont.
2. Commencez par une liste d'autorisation : seuls les numéros de téléphone que vous autorisez explicitement sont traités, le reste est ignoré. Ne sautez jamais cette étape — sinon quiconque possède votre numéro peut mettre votre assistant au travail.
3. Pour chaque message, récupérez les derniers messages de cette conversation dans la base de la phase 1 — c'est votre mémoire conversationnelle.
4. Transformez mémoire et nouveau message en une seule instruction pour le modèle d'IA, surmontée d'une courte instruction système : qui est l'assistant, ce qu'il peut et ne peut pas faire.
5. Appelez le modèle d'IA — via l'API d'un fournisseur, ou en lançant un outil d'IA en ligne de commande comme processus séparé (c'est notre méthode ; le processus reçoit l'instruction et imprime la réponse).
6. Envoyez la réponse en POST vers l'endpoint d'envoi du pont de la phase 2.

La boucle est bouclée : quiconque figure sur la liste d'autorisation envoie un message et reçoit une réponse de l'IA — avec mémoire.

Phase 4 — photos, documents et voix

Les messages sont rarement du texte seul. Trois extensions qui font la différence :

1. Si l'intermédiaire voit un type de média dans la charge du webhook, faites-lui récupérer le fichier via l'endpoint de téléchargement du pont et transmettez le chemin local au modèle d'IA — les modèles modernes peuvent examiner les images directement.
2. S'il s'agit d'un message vocal, récupérez le fichier audio et passez-le dans un modèle de transcription ; le texte suit ensuite le même chemin qu'un message normal.
3. Prévoyez une courte attente (2 secondes chez nous) : si quelqu'un envoie trois photos d'affilée, mieux vaut les traiter comme une seule instruction plutôt que d'appeler le modèle trois fois.

Si vous renvoyez de l'audio : attention au format. Les iPhone ne lisent pas tous les fichiers audio — l'AAC/M4A fonctionne, le WAV brut ou l'OGG souvent pas.

Phase 5 — le maintenir en marche (le vrai travail)

Tout ce qui précède se construit en un week-end. C'est ici que partent les mois :

1. Faites tourner le pont et l'intermédiaire comme services systemd avec redémarrage automatique, pour qu'un crash ou un reboot du serveur se répare tout seul.
2. Gérez les deux façons dont la connexion WhatsApp se casse — chacune demande une réponse différente. Un : la session est déconnectée (environ chaque semaine chez nous) ; il faut alors rescanner un QR code. Deux : la bibliothèque est obsolète et WhatsApp refuse la connexion ; il faut alors mettre à jour la bibliothèque et recompiler le pont — sans nouveau QR.
3. Construisez un chien de garde qui vérifie la chaîne toutes les quelques minutes et vous alerte par un canal autre que WhatsApp — si WhatsApp est en panne, une alerte WhatsApp n'arrivera jamais. Nous utilisons l'e-mail.
4. Journalisez chaque message et chaque réponse avec horodatage, pour pouvoir retracer ce qui s'est passé en cas de problème.
5. Pensez aux tâches longues : un utilisateur attend une réponse en quelques secondes, mais les vrais travaux prennent des minutes. Envoyez immédiatement une courte confirmation et laissez le travail continuer en arrière-plan.

Cette maintenance ne s'arrête jamais. Le protocole change, les sessions expirent, les serveurs redémarrent. C'est la partie que nous avons le plus réécrite — et exactement celle qu'une entreprise occupée abandonne en premier.

Comment Mia s'y prend

Tout ce qui précède — le pont, la mémoire, les médias, la voix, les chiens de garde — tourne chez Mia comme service géré sous le nom de Mia DM : le même assistant qui construit vos applications, joignable comme une discussion ordinaire sur votre téléphone et votre ordinateur. Le maintenir en marche, c'est notre travail, pas le vôtre.

Discuter avec Mia est inclus dans chaque abonnement, dans votre propre Mia OS dans le navigateur. Mia DM est incluse gratuitement — pour qui la veut aussi dans sa poche, en dehors de l'OS.