Aller au contenu principal

Routing des modèles

Statut

Document de doctrine IA — version initiale.

Objectif

Le routing des modèles doit choisir le bon modèle IA selon la tâche, le coût, la qualité attendue, la sensibilité et les quotas de l'utilisateur.

DMV ne doit pas dépendre d'un seul modèle pour tous les usages. Certaines tâches simples doivent utiliser des modèles low-cost ; d'autres peuvent justifier Claude, GPT ou un modèle plus avancé.

Critères de décision

CritèreImpact
Type de tâcheRecherche, rédaction, résumé, classification, génération multi-format, modération.
Niveau de sensibilitéPlus le risque est élevé, plus le contrôle et la qualité attendue augmentent.
Coût estiméLe modèle doit rester cohérent avec l'offre, les crédits et la valeur produite.
Longueur du contexteCertains modèles gèrent mieux les contextes longs.
Langue et tonLes contenus DMV doivent être en français clair et local.
LatenceCertaines interactions doivent rester rapides.
Disponibilité providerLe routing doit prévoir fallback ou dégradation contrôlée.

Classes de modèles

ClasseUsage cible
Modèles low-costReformulation courte, tags, classification simple, suggestions rapides.
GPTRédaction structurée, recherche conversationnelle, assistants polyvalents.
ClaudeSynthèse, rédaction longue, contexte plus riche, qualité éditoriale.
Modèles locaux futursTâches simples, souveraineté, confidentialité, coût maîtrisé.

Ces classes sont une doctrine cible, pas une liste d'intégrations confirmées.

Exemples de routing cible

TâcheModèle probableJustification
Suggestion de tagsLow-costTâche courte, faible risque.
Reformulation d'une publicationLow-cost ou GPTQualité utile, coût à maîtriser.
Assistant mairie sur contenu sensibleGPT ou ClaudeBesoin de clarté et supervision humaine.
Recherche conversationnelle localeGPT, Claude ou modèle spécialiséCompréhension d'intention et contexte local.
Pré-modérationModèle fiable + règles métierRisque de faux positifs, décision humaine finale.
Génération PlayLoop multi-formatGPT ou ClaudeStructuration, adaptation écran, ton local.

Règles de fallback

Le fallback doit être contrôlé :

  • si le modèle principal échoue, utiliser un modèle compatible ;
  • si aucun modèle fiable n'est disponible, retourner une erreur claire ;
  • ne pas remplacer un modèle de modération par un modèle non adapté sans validation ;
  • ne pas consommer les crédits si la requête échoue avant génération utile, selon règle à définir.

Gouvernance

Le routing doit être configurable sans modifier les interfaces applicatives.

Chaque cas d'usage doit définir :

  • modèle principal ;
  • modèle fallback ;
  • coût maximal ;
  • limite de tokens ;
  • niveau de log ;
  • politique de sécurité ;
  • comportement en cas de quota dépassé.