# 10 000 avis d'app mobile : comment un modèle de décision et un LLM se partagent le travail

> Un modèle de décision classe 10 000 avis d'app mobile pour quelques centimes, un LLM n'écrit que la synthèse, et Laya auto-hébergé garde les données dans l'entreprise.

Source: https://www.bluewise.fr/fr/system-one-meets-llm  
Author: Marc Morel  
Published: 2026-09-29  
Category: Architecture

Le cas : dix mille commentaires libres sur une app mobile (avis sur les stores, retours in-app, enquêtes) :

> Depuis la dernière mise à jour je ne peux plus me connecter avec Face ID, je dois ressaisir mon code à chaque fois. Et le virement instantané à ma sœur a pris 2 heures.

Les questions sont toujours les mêmes : de quoi parlent les clients, que ressentent-ils, qu'est-ce qui a changé depuis la dernière release, et qu'est-ce qui ne peut pas attendre un rapport mensuel ?

L'approche par défaut est un appel LLM par commentaire, se terminant par « renvoie du JSON ». Au-delà de 10 000 commentaires, c'est lent, coûteux et fragile :
- La sortie est du texte généré, pas une réponse garantie : le même commentaire peut revenir en JSON propre, en JSON précédé d'un préambule, ou avec une catégorie que personne n'a déclarée. Chaque appel nécessite parsing, validation et un chemin de retry.
- Les catégories dérivent à chaque modification du prompt, et les IBAN collés partent chez le fournisseur.

## Répartir le travail

Un **modèle de décision** (un modèle *System One* : Jev, ou des alternatives ouvertes comme Decider, Kev et Laya) prend un texte et des questions typées : un **Choice** parmi vos options, un **Score** sur votre échelle, un **Noul** (la probabilité qu'une affirmation soit vraie). Il renvoie des valeurs avec des probabilités calibrées, pas de la prose à parser.

| Étape | Réalisée par |
|---|---|
| Rédiger la taxonomie à partir d'un échantillon anonymisé d'environ 300 commentaires | **LLM**, puis ratifiée par le produit et la relation client |
| Classer les 10 000 commentaires | **Modèle de décision** |
| Escalader les signalements de fraude, agréger les tendances par release | **Code** |
| Expliquer ce qui a bougé, avec des citations anonymisées | **LLM**, quelques dizaines de commentaires par thème |
| Proposer de nouveaux thèmes à partir de la catégorie `other` après chaque release | **LLM** |

Le LLM tourne quelques centaines de fois, uniquement là où l'écriture est le travail.

## Un appel, huit questions

Chaque commentaire fait l'objet d'un appel avec huit questions, traitées en parallèle :

- `topic` : un Choice parmi dix catégories versionnées (connexion et authentification, stabilité de l'app, virements, cartes, ouverture de compte, frais, support, épargne, fonctionnalités, autre) ;
- `sentiment` : un Score ;
- six Nouls : `actionable`, `churn_risk`, `fraud_or_scam`, `complaint`, `contains_personal_data`, `is_spam`.

Les questions supplémentaires n'ajoutent quasiment pas de latence et ne coûtent que leurs propres tokens.

Pour l'avis cité, les réponses sont : `topic = login_auth`, avec une part de la probabilité sur `transfers` ; sentiment très négatif ; actionnable ; pas de fraude. Il parle réellement des deux.

Ensuite, c'est le code, jamais le modèle, qui applique la politique et compte :

- **Escalader ce qui ne peut pas attendre.** `fraud_or_scam ≥ 0.5` part à l'équipe fraude le jour même. Le seuil bas est délibéré : un signalement de fraude manqué est l'erreur coûteuse. Savoir si les réclamations in-app entrent dans le processus formel de réclamation est décidé par la conformité, pas par le modèle.
- **Tendance par release.** Sommer les probabilités donne des effectifs attendus avec des bandes d'incertitude, au lieu d'étiquettes figées. Le rapport peut dire : *« `login_auth` est passé de 6 % à 19 % des commentaires sur la 5.12.0, iOS uniquement. »* C'est un signal de régression de release.
- **Tenir les données personnelles à l'écart du LLM.** Les commentaires marqués `contains_personal_data` sont anonymisés avant que le LLM n'écrive la moindre synthèse.

## Les gains par rapport à un appel LLM par commentaire

- **Coût.** Environ 5M de tokens en entrée à 0,042 $/M chez Jev, la sortie étant gratuite, soit environ **0,20 $**. Un LLM frontier coûte des dizaines de dollars pour le même volume (prix indicatifs). À ce ratio, relancer après chaque release, ou reclasser tout l'historique quand la taxonomie change, ne se discute même plus.
- **Vitesse.** La latence annoncée par l'éditeur est de 70 à 500 ms par appel, donc le jeu complet passe en quelques minutes et le pipeline peut traiter le flux en direct. À vérifier en charge.
- **Pas de parsing.** Les réponses ne peuvent être que vos options déclarées, votre échelle ou une probabilité : pas de catégorie inventée, pas de préambule, pas de JSON malformé, pas de boucle de retry. La couche de validation qui enveloppe chaque appel LLM disparaît, et ses échecs à 10 000 appels avec elle. Le mode de sortie structurée d'un LLM fixe la forme de la réponse, mais pas sa valeur : une étiquette valide peut encore changer d'une exécution à l'autre. Ici, c'est la question elle-même qui fixe ce que peut être la réponse.
- **Catégories stables.** Avec des critères versionnés et une version de modèle figée, « avant et après la 5.12 » est une comparaison honnête.
- **Arithmétique sur les probabilités.** Effectifs attendus, alertes tenant compte du bruit, seuils par risque et files de revue découlent tous des mêmes chiffres. Vérifiez d'abord la calibration sur un échantillon étiqueté.

## Confidentialité : Laya, auto-hébergé

Les commentaires d'app mobile peuvent contenir des informations très privées et sensibles (santé, finances, etc.). Les envoyer à une API hébergée hors de l'UE pose la question des transferts au sens du RGPD.

**Laya** (Convai Innovations, Apache 2.0) y répond. Il dispose d'un checkpoint multilingue, tourne sur une infrastructure que vous contrôlez, et expose le même format `/v1/systemone` que Jev. Pointez l'URL de base du SDK vers `laya-serve`, définissez `model="multilingual"`, et aucun commentaire ne quitte l'entreprise. Les poids ouverts règlent aussi la question de la stratégie de sortie DORA.

Avant de lui faire confiance :

- **Gardez des options courtes.** Les descriptions d'options d'une question partagent un budget de 192 tokens. Au-delà d'une vingtaine de catégories, passez à deux niveaux.
- **Découpez les longs verbatims d'enquête.**
- **Recalibrez les seuils,** en commençant par la fraude.

Les étapes LLM ne voient jamais que quelques centaines de commentaires anonymisés, et peuvent tourner sur un modèle hébergé dans l'entreprise si la politique l'exige.

## Ce qui change

L'analyse des retours clients, c'est un petit jugement répété des milliers de fois, plus un peu de synthèse. Confiez la répétition à un modèle de décision : rapide, bon marché, stable, et capable de repérer le signalement de fraude caché dans un avis une étoile.

Confiez la synthèse au LLM. Quand les clients sont ceux d'une entreprise régulée, faites tourner le modèle de décision sur Laya, sans changer une ligne du code de classification.