fix(llm): ordre des modèles imposé par l'admin, diagnostic des 429 et descriptions plus complètes

[ijdan]

Regroupe toutes les corrections apportées depuis le merge de la #60. Sept commits, issus du diagnostic de la panne Gemini de début août.

Contexte

La panne d'origine était un blocage de facturation (prepayment credits are depleted), pas un dépassement de quota — Google renvoie un 429 dans les deux cas, ce qui expliquait l'écart avec les compteurs de la console. Les commits suivants corrigent ce que ce diagnostic a mis au jour.

1. L'ordre des modèles est celui de la page admin, littéralement

Règle : aucune déduction du code. 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.

resolve_model_priority() remplace l'ancien mécanisme de migration (MODEL_PRIORITY_VERSION, merge_model_priority(), champ model_priority_version), entièrement supprimé. Son 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 ne réécrit plus model_priority en base, seul le PUT le fait.

Les trois chemins qui lisent ce réglage (page admin, collecte/synthèse, bouton « Régénérer le résumé IA ») passent désormais tous par la même fonction. Le troisième lisait l'ordre brut de Firestore sans contrôle : il pouvait solliciter un autre modèle que la collecte.

Conséquence assumée : modifier DEFAULT_MODEL_PRIORITY n'a plus aucun effet sur un projet existant, et un nouveau modèle ajouté côté code n'apparaît pas tout seul dans la liste.

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

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 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.

3. Diagnostic et robustesse de la cascade

• Un 429 de facturation est libellé comme tel, avec l'action corrective, et arrête la cascade — aucun modèle ne peut aboutir, inutile de rejouer 4 fois le même refus.
• La validité du JSON est vérifiée dans _call_llm. Elle était contrôlée en aval : une réponse malformée ne déclenchait aucune montée d'un cran et faisait basculer tout le run vers save_raw_articles.
• Les motifs de montée sont journalisés distinctement : « dépassement » (429 de quota ou de débit, cas nominal) contre « anomalie » (modèle inconnu, requête invalide, réponse illisible — défaut à corriger).

4. Descriptions d'articles trop courtes

• MAX_ARTICLE_CONTENT_FOR_BATCH passe de 1500 à 4000 caractères : le modèle n'avait pas assez de matière source pour développer les 4 à 6 phrases attendues. Surcoût de l'ordre de 0,006 $ par run.
• Longueurs minimales rendues impératives dans le prompt d'enrichissement.
• Les Gemma quittent la tête de la liste d'amorçage : les moins chers du catalogue, mais trop laconiques pour la fiche article. La cascade ne bascule que sur erreur, jamais sur qualité — un modèle trop bref traiterait tout le flux sans que rien ne l'indique.

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.

Limite connue

La cascade ne bascule que sur erreur, jamais sur qualité. Si un modèle renvoie du JSON valide mais médiocre, il traitera tout le flux sans alerte. Les libellés de l'admin affichent le coût par million de tokens pour arbitrer.

Tests

31 tests ajoutés : diagnostic des erreurs, distinction facturation / débit sur les messages réels de production, interruption de cascade, ordre appliqué littéralement, amorçage sur liste vide, non-divergence des copies, montée sur JSON malformé.

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).