Providers IA

Statut

Document de doctrine IA — version initiale.

Objectif

DMV doit pouvoir utiliser plusieurs providers IA sans enfermer l'écosystème dans un fournisseur unique.

La cible est une orchestration multi-providers via l'AI Gateway : Claude, GPT, modèles low-cost et, plus tard, modèles locaux lorsque les usages et contraintes le justifient.

Providers cibles

Provider ou famille	Rôle possible	Statut
GPT	Assistant polyvalent, recherche, génération structurée, workflows métier.	Vision cible, intégration à confirmer.
Claude	Rédaction qualitative, synthèse, analyse de contexte long.	Vision cible, intégration à confirmer.
Modèles low-cost	Tâches simples, classification, reformulation courte, tags.	Vision cible.
Modèles locaux	Confidentialité, coût maîtrisé, souveraineté future.	Option long terme.

Principes de sélection

• Choisir le provider selon le besoin métier, pas selon l'effet de marque.
• Mesurer coût, qualité, latence et fiabilité.
• Prévoir un fallback lorsque c'est acceptable.
• Éviter de dépendre de formats propriétaires dans les prompts métier.
• Centraliser les secrets et clés API côté backend.
• Garder des contrats de réponse internes stables.

Abstraction provider

L'AI Gateway doit masquer les différences entre providers.

Les applications ne doivent pas savoir si une réponse vient de Claude, GPT, d'un modèle low-cost ou local. Elles doivent recevoir une réponse métier structurée.

Exemples de contrat interne :

• suggestion de publication ;
• liste de tags ;
• résumé ;
• score de risque ;
• plan de playlist ;
• réponse de recherche avec sources.

Données et conformité

Avant d'envoyer un contexte à un provider, DMV doit vérifier :

• que les données sont nécessaires ;
• que les données sensibles sont exclues ou minimisées ;
• que l'utilisateur a le droit d'utiliser ce contexte ;
• que les logs ne conservent pas inutilement des données personnelles ;
• que le provider est compatible avec les exigences du cas d'usage.

État actuel

Aucune intégration provider IA n'est confirmée dans le code inspecté. Cette page définit une cible d'architecture et de gouvernance.

Toute intégration future devra être documentée avec :

• provider utilisé ;
• cas d'usage ;
• modèle ;
• coûts estimés ;
• règles de sécurité ;
• politique de logs ;
• fallback.