Le panneau de modèle par défaut et la bulle ⓘ n'affichaient aucun modèle Mistral
« Vision capable » alors que GET api.mistral.ai/v1/models en déclare 28 : la table
de capacités était entièrement statique et aucun de ses motifs ne correspondait aux
familles Mistral actuelles (seul `pixtral`, retiré de l'API, les matchait).
- backend/provider_capabilities.py (nouveau) : capacités déclarées par le
fournisseur (Mistral `capabilities`, OpenRouter `architecture`), détectées par
la forme du payload, snapshot en cache process-wide (TTL 30 min, surchargeable
par AI_CAPABILITIES_TTL_SECONDS) rempli par GET /api/config/ai-models.
- backend/model_capabilities.py : une déclaration prime sur la table statique
pour chaque drapeau mentionné ; la table ne comble que le reste (Mistral ne
déclare jamais `embedding`). Table corrigée pour le repli hors ligne : familles
vision Mistral (ministral, magistral, mistral-small, mistral-medium,
mistral-vibe-cli, labs-leanstral), mistral-ocr = vision sans chat, et défaut du
fournisseur Mistral sans `embeddings` (mistral-large / codestral n'étaient plus
des « embedders »).
- backend/ai_routes.py : GET /api/ai/model-capabilities reste sans appel réseau
(cache froid → table statique).
- Tests : tests/test_provider_capabilities.py (nouveau), TestMistralFamilies et
TestDeclaredCapabilities (bout en bout via l'API).
- Docs : CHANGELOG [Unreleased], registre + journal ISSUES_TODOLIST,
fiche docs/features/ai-provider-picker.md (§L).
Vérifié : 28/28 modèles vision déclarés par Mistral détectés (0 avant), 0 écart
dans les deux sens ; pytest 1007 passed / 6 skipped ; ruff 0 (backend) ; mypy 0 ;
tests frontend unit 9/9 + IA 66/66 + validate-imports 37 modules ; instance de test
reconstruite et vérifiée sur http://localhost:2020.
bruno