OTTO

OTTO · WhatsApp

1. Client :

   Je veux assurer ma voiture immatriculée AA-123-BC.

2. OTTO :

   Très bien, je calcule votre devis responsabilité civile.

3. Client :

   Oui, je confirme la souscription de mon véhicule et je veux payer maintenant.

4. OTTO :

   Parfait, votre souscription est bien enregistrée. Réglez le montant via ce lien de paiement Wave : checkout.wave.com/… Votre attestation vous sera transmise dès réception du paiement.

Contexte

Sanoo InsurTech veut vendre et renouveler l’assurance automobile au Sénégal, puis dans la zone UEMOA, là où se trouvent déjà les clients : sur WhatsApp et chez les cabinets de courtage. Le cahier des charges d’avril 2026 décrit un agent conversationnel capable de mener une souscription complète, et un tableau de bord pour les courtiers qui suivent leurs clients et leurs ventes.

Le problème

Une souscription d’assurance n’est pas une conversation libre. Il faut un devis exact, des pièces justificatives lisibles, un paiement mobile money confirmé, une attestation émise par l’assureur partenaire, et la possibilité d’annuler et de rembourser. Chaque étape dépend d’un système extérieur, et aucune ne tolère une réponse inventée par le modèle.

S’y ajoutent les contraintes d’une plateforme partagée : plusieurs cabinets dont les données ne doivent jamais se croiser, des coûts de modèles de langage à maîtriser, et un service qui doit rester utilisable quand un fournisseur tombe.

Mon approche

Un monolithe modulaire plutôt que des microservices. Le back-end FastAPI est découpé par domaine, avec un service séparé pour l’orchestration des agents. Vingt-deux décisions d’architecture sont consignées dans des ADR, pour que chaque choix reste justifiable.

L’isolation des cabinets par la base de données. Chaque cabinet est un locataire, séparé par la sécurité au niveau des lignes de PostgreSQL : une erreur dans le code applicatif ne suffit pas à exposer les données d’un autre cabinet.

Un moteur de langage qui ne dépend d’aucun fournisseur. Le cahier des charges prévoyait un seul modèle. J’ai construit une interface commune à plusieurs fournisseurs : DeepSeek en tête, Qwen3-32B via OpenRouter en cours de validation, un modèle local en secours. La bascule est automatique, chaque appel est tracé avec son coût, et une alerte se déclenche avant le dépassement du budget mensuel.

Des agents configurés, pas codés. Un agent se décrit par des données : son rôle, ses outils, ses sources. Les réponses sur les garanties s’appuient sur une recherche hybride (mots-clés et embeddings multilingues) dans les documents de l’assureur. Les pièces justificatives passent par l’OCR de Google Vision, puis sont structurées par le modèle.

L’exploitation pensée dès le départ. Le fournisseur WhatsApp est interchangeable (Meta, Twilio, Whapi). La plateforme tourne en Docker Compose sur un VPS, avec métriques et journaux centralisés. Les tests couvrent l’API, le tableau de bord et des parcours complets, y compris une campagne nocturne avec de vrais modèles.

Pour le pilote, la vente passe d’abord par le web et le tableau de bord ; l’agent WhatsApp est en pause.

Ce qui a changé

Le 10 octobre 2026, la boucle complète (devis, paiement, attestation, annulation, remboursement) a été validée en conditions de test, avec le paiement et l’assureur en environnement d’essai. Le pilote avec des cabinets de courtage est décidé.

Ce que j’en retiens

Un agent IA ne vaut que par ce qui l’entoure : dans une souscription, la conversation est la partie visible, mais la confiance se joue sur le devis exact, le paiement confirmé et l’attestation.