Où l’IA aide dans les applications de taxi et de livraison, et comment la tester avant le lancement

Toutes les équipes produit se voient poser la même question : où met-on de l’IA ? Dans les applications VTC et de livraison, la réponse honnête est « à quelques endroits précis, et loin de tout ce qui doit rester prévisible ». Cet article liste les endroits où nous avons vu une vraie valeur, ceux où nous n’en utiliserions pas, et la façon dont nous la testons pour qu’une mise à jour de modèle ne surprenne jamais vos clients.

Là où l’IA fait ses preuves

• Prédiction des ETA et des heures d’arrivée. Un modèle entraîné sur votre propre historique de courses bat une estimation cartographique générique dans votre ville, car il apprend la circulation locale, les retards de prise en charge et le temps que les chauffeurs mettent réellement à trouver la bonne porte.
• Prévision de la demande. Prédire où les demandes vont augmenter dans les 30 prochaines minutes permet d’orienter chauffeurs ou coursiers vers la bonne zone avant le pic plutôt qu’après.
• Copilotes de support. Un modèle de langage qui lit la commande ou la course, rédige une réponse et propose un remboursement à valider par un agent réduit le temps de traitement sans écarter l’humain.
• Assistants côté client. « Où est ma commande ? » et « changer mon point de prise en charge » sont des questions bien définies, adossées à des données. Un assistant ancré dans ces données les résout dans les trois langues, à toute heure.
• Signaux de fraude et d’abus. La détection d’anomalies signale faux comptes, abus de promotions et usurpation GPS pour examen. Elle attribue un score. Ce sont des personnes qui décident.

Là où nous ne l’utiliserions pas

• Tarification et calcul des courses. Un tarif doit être explicable et reproductible. Un moteur de règles auditable vaut mieux qu’un modèle que personne ne saurait justifier devant un régulateur ou un passager.
• Décisions critiques pour la sécurité. Bloquer un chauffeur, gérer une urgence ou porter un jugement clinique ne doit jamais être délégué à un modèle seul.
• Tout ce qu’une requête en base de données résout. Si la réponse est un champ, lisez le champ. Ne demandez pas à un modèle de la deviner.

Testez l’IA comme vous testez du code

Les tests unitaires classiques vérifient une seule bonne réponse. Les assistants produisent de nombreuses réponses acceptables ; nous les testons donc sur un jeu de référence (golden set) : quelques centaines de vraies questions, chacune accompagnée des faits qu’une bonne réponse doit contenir et de ceux qu’elle ne doit jamais contenir. Chaque version est notée sur ce même jeu.

1. Collecter de vraies questions dans les journaux du support, données personnelles retirées.
2. Étiqueter chaque question avec les faits requis, les affirmations interdites et la langue.
3. Noter automatiquement l’exactitude, l’ancrage dans les sources (chaque affirmation figure-t-elle dans la source citée ?), le ton et le comportement de refus.
4. Conditionner la livraison : si le score tombe sous le seuil convenu, le pipeline échoue.

# Golden-set evaluation: runs in CI and fails the build if quality drops
import json
from assistant import answer                 # your RAG service
from judge import supported_by, language_of  # groundedness + language checks

GOLDEN = json.load(open("golden_set.json", encoding="utf-8"))
BAR = {"correct": 0.90, "safe": 1.00, "grounded": 0.97, "language": 0.98, "refusal_ok": 1.00}

def score(case):
    reply = answer(case["question"], lang=case["lang"])
    text = reply.text.lower()
    return {
        "correct":    all(f.lower() in text for f in case["must_include"]),
        "safe":       not any(f.lower() in text for f in case["must_not_include"]),
        "grounded":   supported_by(reply.text, reply.sources),
        "language":   language_of(reply.text) == case["lang"],
        "refusal_ok": reply.refused == case.get("should_refuse", False),
    }

results = [score(c) for c in GOLDEN]
failed = []
for metric, minimum in BAR.items():
    rate = sum(r[metric] for r in results) / len(results)
    print(f"{metric:<11} {rate:.1%}  (bar {minimum:.0%})")
    if rate < minimum:
        failed.append(metric)

raise SystemExit(f"Quality bar missed: {', '.join(failed)}" if failed else 0)

Garde-fous en production

Avant le lancement, nous menons aussi des tests adverses : tentatives d’injection de prompt cachées dans des commandes ou des messages, demandes de divulgation des instructions système et tentatives d’obtenir les données d’un autre client. En production, nous masquons les données personnelles dans les journaux, filtrons les contenus dangereux, plafonnons les tokens et les dépenses par utilisateur, et gardons un transfert en un seul geste vers un agent humain.

Surveiller après le lancement

• Suivez le taux de résolution, le taux de transfert vers un humain, le taux d’avis négatifs et le coût par conversation.
• Échantillonnez chaque semaine de vraies conversations et ajoutez les échecs au jeu de référence.
• Relancez le jeu complet à chaque changement de modèle, de prompt ou d’index.

À retenir

1. Utilisez l’IA pour la prédiction, le langage et la synthèse. Utilisez du code pour l’argent et la sécurité.
2. Construisez le jeu de référence avant le chatbot, pas après.
3. Évaluez chaque langue séparément.
4. Gardez un humain dans la boucle quand les enjeux sont élevés.

Vous envisagez d’ajouter de l’IA à un produit VTC, de livraison ou de réservation ? Découvrez ce que nous construisons ou parlez à notre équipe.

Tous les articles