Andy Garcia · dev freelance
FRENES
Retour au blog
IA & Modération

La modération a désormais un modèle de décision qui lit ta politique en 35 millisecondes. Le seuil, c'est la politique

7 octobre 2026 6 min de lecture

Le mardi 6 octobre, une entreprise appelée Musubi a publié PolicyLM-1.7B, un modèle à poids ouverts sous licence Apache 2.0, conçu pour une seule tâche : la modération de contenu. Tu lui donnes un message et ta propre politique de contenu, écrite en règles courtes en langage naturel, et il renvoie un score entre 0 et 1 pour chaque catégorie de cette politique. Il ne génère aucun texte. Sur un seul NVIDIA L4 de 24 Go, Musubi mesure une médiane de 35 millisecondes par message de chat court, avec jusqu'à six catégories.

TechCrunch a présenté le lancement comme l'arrivée des modèles de décision dans la modération. La catégorie a trois semaines. TypeSafe a lancé Jev le 15 septembre. OpenAI a annoncé une Decisions API à la DevDay le 29 septembre, qui renvoie des réponses que les développeurs peuvent utiliser pour « classify content, route requests, or choose an agent's next action » (classer du contenu, router des requêtes ou choisir la prochaine action d'un agent). Le 1er octobre, Strands Labs d'Amazon a publié Strands Decider 2B en open source. Musubi ne cache pas la filiation : « If Jev caught your eye, PolicyLM-1.7B is the same kind of model, trained specifically for content moderation, that you can run yourself. » (Si Jev t'a tapé dans l'œil, PolicyLM-1.7B est le même genre de modèle, entraîné spécifiquement pour la modération de contenu, que tu peux faire tourner toi-même.)

J'utilise Jev tous les jours pour de petits appels oui/non, comme vérifier les affirmations de mes propres posts. Je ne modère pas une plateforme. Mais la modération est l'endroit où répondre par un nombre plutôt que par un verdict compte le plus.

Le plus gros problème de décision d'Internet

Le 7 octobre, la base de données de transparence du DSA européen, où les plateformes en ligne déposent l'« exposé des motifs » qu'elles doivent à un utilisateur chaque fois qu'elles suppriment ou restreignent son contenu, affichait 4 301 448 066 exposés soumis sur les 180 derniers jours par 374 plateformes. Quarante pour cent étaient des décisions entièrement automatisées.

Chaque exposé comporte un champ obligatoire indiquant si la décision était entièrement automatisée, partiellement automatisée ou non automatisée. Aucun des champs documentés n'enregistre à quel point la machine était sûre d'elle. La Commission européenne décrit l'exposé comme un outil pour aider les utilisateurs à « comprendre et éventuellement contester les décisions de modération de contenu ».

Jusqu'ici, la partie automatisée a surtout reposé sur deux outils. Les classifieurs fixes sont rapides et bon marché, mais ils notent leurs propres catégories intégrées : changer une règle suppose de ré-étiqueter des données et de réentraîner. Les grands modèles de langage lisent ta vraie politique, mais dans la comparaison de Musubi ils demandent en général des centaines de millisecondes ou plus par vérification, trop lent et trop cher pour du chat en direct.

Un modèle de décision se place entre les deux. Il lit la politique comme un LLM et répond à la vitesse d'un classifieur. Le plus intéressant n'est pas la vitesse. C'est que la réponse est un nombre.

Ce qui change quand celui qui décide est un nombre

Les seuils deviennent contextuels. PolicyLM est livré avec deux préréglages : « precision », celui par défaut, à 0,335, pour les surfaces où les violations sont rares comme le chat en direct, et « balanced » à 0,275, pour les files où une omission coûte plus cher qu'un faux signalement. Chaque catégorie peut avoir son propre seuil. La doc de TypeSafe dit la même chose : « A confidence threshold is not one number. » (Un seuil de confiance n'est pas un seul nombre.) Un nom d'utilisateur, un message privé et une annonce de marketplace ne méritent pas le même seuil, et une équipe politique peut désormais le déplacer sans cycle de réentraînement. Le seuil, c'est la politique, écrite dans la seule langue que le modèle respecte.

Avec le préréglage par défaut, un score de 0,34 signale un message. C'est un score, pas la promesse qu'un tiers de ces messages enfreint les règles. TypeSafe définit la calibration comme le fait que les résultats associés à 0,8 se produisent environ 80 % du temps « across many predictions » (sur de nombreuses prédictions). À toi de mesurer si les nombres d'un modèle veulent dire cela sur ton trafic ; Musubi lui-même recommande de calibrer sur ton propre contenu avant la mise en production.

Les recours peuvent rejouer une décision, si tu l'as conservée. Un recours pose une seule question : cette suppression était-elle juste au regard des règles en vigueur ce jour-là ? Si tu as stocké le score, la catégorie, la version de la politique, le seuil et la révision du modèle, tu peux répondre exactement, et dire si elle passerait aujourd'hui. J'ai défendu ce schéma dans Store the Probability, Never the Verdict. C'est en modération qu'il rapporte le plus.

Ne rejoue pas en relançant le modèle. La fiche du modèle PolicyLM note que des lectures en bfloat16 sur CUDA et sur Apple silicon différaient jusqu'à 0,083, et que le float32 sur CPU changeait quelques décisions ; pour des scores exacts et répétables, elle recommande le float32. TypeSafe a fait passer une grille de modération sur un post limite 15 fois : Jev a gardé son étiquette principale 90,8 % du temps et a basculé sur 2 questions sur 8. Sa doc ajoute qu'un seuil « does not make the model deterministic » (ne rend pas le modèle déterministe). Le journal fait foi. Le modèle, non.

L'auditabilité devient plus honnête. Un modèle de décision n'écrit aucune raison, et Musubi range « No reasons provided » (aucune raison fournie) parmi ses limites. Pour les exposés des motifs, je pense que c'est plus proche d'une qualité. Un enregistrement comme « échange hors plateforme, politique version 14, score 0,71, seuil 0,335 » est une raison que n'importe qui peut vérifier. Une justification générée après coup ne décrit peut-être pas comment le verdict a été atteint.

Le coût par décision s'effondre. Jev coûte 42 $ par milliard de tokens en entrée, et les sorties sont gratuites. Un appel de 2 000 tokens, politique plus message, coûte 0,000084 $, donc un million de décisions coûtent 84 $. La fiche de PolicyLM indique qu'un L4 a tenu 34,4 messages par seconde avec un p95 de 150 millisecondes ou moins ; cela fait presque trois millions de messages par jour sur une seule carte. L'argument de Musubi : « score all of your traffic instead of sampling it » (note tout ton trafic au lieu de l'échantillonner). La modération passe de l'échantillon au recensement.

Là où ça casse encore

Les utilisateurs adverses. La fiche du modèle classe « a security boundary against adversarial users » (une frontière de sécurité contre les utilisateurs adverses) hors périmètre. Le nettoyeur de texte fourni annule les caractères qui se ressemblent, les lettres espacées et le base64, et a attrapé 10 à 12 points de plus de violations déguisées sur le jeu de test de Musubi, mais « leetspeak mostly gets through » (le leetspeak passe en grande partie). Ceux qui cherchent à contourner un filtre itèrent plus vite que n'importe quelle équipe politique.

La dérive. La fiche prévient que les scores bougent avec « policy wording, language, device and numeric format » (la formulation de la politique, la langue, l'appareil et le format numérique). Modifier la politique n'est pas gratuit non plus : sur le benchmark de Musubi, environ une modification d'une seule clause sur deux changeait réellement la décision. Les modèles hébergés bougent aussi : l'alias jev-latest de Jev pointe actuellement vers jev-1.13.0, et chaque réponse nomme la version qui a répondu. Et lis la fiche à côté de l'article de blog. L'article dit qu'un PolicyLM affiné sur mesure tourne sur une plateforme qui traite plus d'un million de messages par jour. La fiche des poids publiés dit « Not yet tested on live traffic » (pas encore testé sur du trafic réel).

La précision s'achète encore avec du temps. Sur le benchmark de politiques personnalisées de Musubi, le gpt-oss-safeguard-20B d'OpenAI, à poids ouverts, obtient 0,909 de précision contre 0,842 pour PolicyLM et suit 0,716 des modifications de politique contre 0,528, avec une médiane de 349 millisecondes par message contre 22, les deux sur un seul H100. La comparaison de Musubi elle-même envoie les recours, les bannissements et les retraits vers des modèles plus gros.

La file humaine. Dans le test de cas limite de TypeSafe, un plancher à 0,60 a fait monter l'accord à 99,2 %, mais seulement 74,2 % des réponses étaient automatiques ; le reste partait en revue humaine. C'est un seul post difficile, pas un taux. La leçon tient quand même : un décideur bon marché ne supprime pas la file. Tes seuils décident de sa taille, donc fixe-les avec le nombre de tes relecteurs sur la table.

Ce que je ferais lundi

Journaliser chaque décision automatisée en une ligne : score, catégorie, version de la politique, seuil en vigueur, révision du modèle, format numérique. Fixer des seuils par surface, pas par plateforme. Définir une zone d'incertitude explicite et suivre son volume quotidien par rapport à ce que tes relecteurs peuvent absorber. Constituer un échantillon étiqueté à partir de ton propre trafic et vérifier chaque mois que les messages notés autour de 0,7 sont des violations à peu près aussi souvent que tu le supposais. Épingler les versions du modèle. Répondre aux recours depuis le journal.

Ensuite, demander qui fait tourner le modèle. Dans la LegalTech que je construis, les documents clients sont sensibles : où tourne un modèle est une question que je pose avant la précision. Pour la modération de messages privés, des poids ouverts sur ta propre infrastructure ne sont pas un détail.

Le modèle te donne un nombre. Ce que ce nombre veut dire reste une décision de politique, et elle mérite désormais la même relecture que le texte de la politique.

Sources

Un projet du même genre ?

Je conçois et déploie des produits comme celui-ci. Parlons-en.

Discutons