Quand Toshify nous a contactés, leur question était : « Faut-il qu’on construise un site web pour les candidats chauffeurs ? » La réponse a été non. Pas parce que les sites web sont mauvais, mais parce que les chauffeurs argentins n’en consultent pas — ils ouvrent WhatsApp 30 fois par jour. Nous avons donc construit un assistant d’onboarding sur WhatsApp. Voici, dans le détail, ce que nous avons appris en le livrant.

Pourquoi WhatsApp et pas autre chose

Toshify accompagne les chauffeurs souhaitant rejoindre Cabify : ouverture de compte, vérification documentaire, prise en main de l’app, activation. Le brief initial évoquait un site web. Notre audit a montré trois choses.

Premièrement, 95% des candidats sont des chauffeurs déjà actifs (taxi, VTC, plateformes concurrentes) qui veulent une démarche rapide entre deux courses. Ils n’ouvrent pas un navigateur sur leur smartphone — ils ouvrent WhatsApp.

Deuxièmement, l’opérateur historique de l’onboarding (3 ETP au téléphone) capait à 60% de candidats rappelés sous 24h. Pas par incompétence, par contrainte horaire. Un canal asynchrone résout ce problème.

Troisièmement, l’API WhatsApp Business est mature, conforme RGPD, et utilisable en production sans bricolage.

La stack

Nous avons choisi des briques éprouvées : WhatsApp Business API officielle (via Twilio), backend Node.js, orchestration n8n, LLM Gemini avec une base de connaissance documentaire (RAG strict), et push vers Intercom, Supabase et notre outil interne pour la transmission au service commercial.

Pas d’agent autonome multi-étapes, pas de mémoire vectorielle complexe, pas de modèle local. La stack est volontairement simple — c’est ce qui la rend maintenable. Détails dans notre service Chatbots IA.

Trois garde-fous critiques contre les hallucinations

Quand votre agent parle au nom d’une marque (Toshify) qui parle elle-même au nom d’une plateforme tierce (Cabify), une seule réponse fausse peut générer un litige. Trois garde-fous sont systématiques.

Garde-fou 1 — RAG strict. L’agent ne répond qu’à partir de la base documentaire fournie par Toshify (politique chauffeur, conditions Cabify, démarches administratives). Si la question sort de cette base, il transfère.

Garde-fou 2 — Seuil de confiance. Le LLM produit une probabilité de pertinence de la réponse. Si elle est sous 0.85, transfert humain automatique. Mieux vaut transférer un cas facile que halluciner.

Garde-fou 3 — Prompt système anti-spéculation. Le prompt contient explicitement : « Si tu n’es pas sûr, dis “je transfère votre question à un superviseur”. Ne devine jamais. » C’est de l’ingénierie de prompt basique mais critique.

Résultat : zéro hallucination signalée par Toshify en 8 mois de production. Pas parce que le modèle est parfait, mais parce que les garde-fous l’empêchent de bavarder hors-piste.

Les transferts intelligents : quand passer la main

Le piège classique d’un chatbot : tout traiter ou tout transférer. Le bon design est entre les deux.

Nous avons identifié quatre triggers de transfert : (1) la question sort du périmètre couvert par la base documentaire, (2) le candidat exprime une frustration (détectée par classification LLM), (3) le profil correspond à un cas premium ou litigieux (champs CRM), (4) le candidat demande explicitement à parler à un humain.

À l’échelle, 95% des candidats sont traités en autonomie complète, et 5% transférés au superviseur. L’équipe Toshify fait tourner un seul superviseur en supervision active, contre trois ETP avant. Voir le détail dans le cas Toshify.

RGPD et conformité (à ne pas zapper)

WhatsApp Business API est, sur le papier, conforme RGPD. Mais cela ne dispense pas de poser quelques bases.

Opt-in explicite : le candidat doit avoir donné son consentement avant que vous lui écriviez. L’ouverture par le candidat lui-même (via un QR code ou un lien) suffit techniquement.

Conservation des données : nous avons fixé une rétention de 12 mois pour les conversations, 24 mois pour les données de qualification dans le CRM. Au-delà, suppression automatique.

Hébergement : transcripts et données structurées stockés en Europe (France). Cela compte au-delà du RGPD : cela rassure les audits sécurité côté Cabify.

Argentine : la loi 25.326 est largement alignée avec le RGPD. Nous avons fait valider la solution par un avocat local avant la mise en production.

Ce que nous referions différemment

Premier regret : nous avons sous-estimé la diversité de l’espagnol. L’espagnol argentin (Río de la Plata) a un voseo et un lexique distincts de l’espagnol ibérique ou colombien. Nos premiers prompts sonnaient ibériques. Nous avons retravaillé le prompt système pour intégrer le ton local, mais cela aurait été plus simple en amont.

Deuxième regret : nous aurions pris plus de temps à scoper les transferts. Au début, nous avions sous-estimé certains cas atypiques (chauffeur ayant déjà eu un incident sur une autre plateforme, par exemple). Nous avons ajouté ces règles en cours de route, mais une demi-journée d’audit supplémentaire au scoping aurait évité 2-3 itérations.

Troisième regret : aucun. Le canal WhatsApp était le bon choix, la stack était la bonne, les garde-fous ont tenu. C’est rare.

À retenir

Si votre cible utilise WhatsApp, ne lui imposez pas un site web. Mais ne traitez pas WhatsApp comme un canal trivial : la conformité RGPD, les garde-fous contre les hallucinations et la conception fine des transferts demandent autant de rigueur qu’un produit web classique. C’est cette rigueur qui transforme un chatbot gadget en assistant qui tient en production.

Voir le cas Toshify en détail