feat(llm): l'ordre des modèles choisi dans l'admin est appliqué littéralement

[ijdan]

Suite de la #61. Quatre commits, rebasés sur main après son merge.

1. L'ordre de la page admin fait autorité, sans aucune déduction

C'est le cœur de cette PR. L'ordre défini dans /admin est sollicité tel quel à chaque appel LLM : ni tri, ni purge des modèles inconnus, ni insertion automatique des nouveaux.

Le mécanisme de migration introduit dans la #61 est entièrement supprimé — MODEL_PRIORITY_VERSION, merge_model_priority() et le champ model_priority_version (Firestore, API, frontend). resolve_model_priority() le remplace, avec un seul comportement par défaut : amorcer un projet neuf sur DEFAULT_MODEL_PRIORITY quand aucun ordre n'a encore été choisi.

GET /admin/settings redevient en lecture seule : il restitue l'ordre stocké sans le réécrire. Seul le PUT (boutons ▲▼) modifie model_priority.

Un modèle hors catalogue est signalé dans les logs mais tout de même sollicité — c'est le choix de l'administrateur, pas au code de l'écarter.

Conséquences assumées :

• modifier DEFAULT_MODEL_PRIORITY n'a plus aucun effet sur un projet existant ;
• un nouveau modèle ajouté côté code n'apparaît pas tout seul dans la liste.

2. Les trois lecteurs de model_priority sont alignés

get_model_priority() (bouton « Régénérer le résumé IA ») lisait l'ordre brut de Firestore sans contrôle : il pouvait solliciter un autre modèle que la collecte tant que la page admin n'avait pas été ouverte.

Les trois chemins — page admin, collecte/synthèse, résumé à la demande — passent désormais par la même fonction. Vérifié par simulation sur un ordre volontairement contraire au classement par coût, pour s'assurer que rien ne le « corrige » :

Choisi dans l'admin : ['gemini-3.5-flash', 'gemma-4-26b-a4b-it', 'gemini-3.1-flash-lite']
Page admin          : identique
Bouton Résumé IA    : identique
Collecte/synthèse   : identique

3. Un 429 de débit n'est plus pris pour un compte bloqué

Régression introduite par la #61 : le marqueur billing était trop large. Tous les 429 de Gemini contiennent « check your plan and billing details », y compris un simple dépassement de débit. Un projet correctement crédité voyait donc sa cascade interrompue au premier modèle, avec un message l'invitant à recharger son compte.

Marqueurs restreints aux signaux spécifiques (crédits prépayés épuisés, compte suspendu), plus un veto explicite : un message nommant une métrique de quota décrit un débit dépassé, la cascade doit monter d'un cran. En cas de doute, on ne bloque pas.

Dette réduite au passage

DEFAULT_MODEL_PRIORITY existait en quatre exemplaires, dont un non documenté (article_summarizer.py) resté sur un ordre périmé. Il n'en reste que deux — un par service — et un test vérifie qu'ils ne divergent pas. admin.py, collector/main.py et analyze_logs.py importent.

Après le déploiement

L'ordre stocké en base est celui de juillet (gemini-3.5-flash en tête). Puisque plus rien ne le réécrit, il restera tel quel : le régler depuis la page admin est désormais le seul moyen de le changer.

Tests

11 tests ajoutés ou réécrits : ordre appliqué littéralement, aucun modèle inséré ni retiré, amorçage sur liste vide, distinction facturation / débit sur le message réel de production. Deux tests qui figeaient l'ancien comportement de migration sont remplacés.

87 passed sur la suite hors acceptance. Les 14 échecs restants sont identiques avant et après ces commits, vérifié par diff nom par nom — ils viennent de l'environnement de développement (absence de .env, d'émulateur Firestore et de réseau).

---

Generated by Claude Code