## Choisir une famille de modèles

L'architecte doit savoir **quel type de modèle** recommander selon le contexte. Deux grandes
familles.

### Modèles propriétaires (fermés)
Accessibles **uniquement via une API** payante. Vous ne possédez pas le modèle.
- Exemples : **GPT** (OpenAI), **Claude** (Anthropic), **Gemini** (Google).
- ✅ Souvent les plus performants, aucune infrastructure à gérer, démarrage immédiat.
- ⚠️ Données envoyées chez le fournisseur, coût au token, dépendance, pas de souveraineté.

### Modèles ouverts (open weights)
Les poids sont **téléchargeables** : vous pouvez les héberger vous-même.
- Exemples : **Llama** (Meta), **Mistral**, **Qwen** (Alibaba), **DeepSeek**.
- ✅ Données maîtrisées, hébergement souverain possible, coût d'inférence maîtrisé à
  l'échelle, pas de dépendance.
- ⚠️ Vous gérez l'infrastructure (GPU), un peu en retrait des meilleurs propriétaires (mais
  l'écart se réduit vite).

### Le critère de décision
| Besoin | Recommandation |
|---|---|
| Prototype rapide, données non sensibles | Propriétaire (API) |
| Données sensibles, souveraineté | Ouvert, auto-hébergé |
| Très fort volume | Ouvert (coût maîtrisé) |

> **📌 Cas concret — deux projets, deux choix**
> Pour un chatbot de FAQ sur le site public d'une mairie, on part sur une **API
> propriétaire** : rapide, données non sensibles. Pour un assistant interne qui traite des
> **dossiers d'usagers**, on choisit un **modèle ouvert auto-hébergé** : les données ne
> doivent pas sortir. Le même architecte recommande **deux familles différentes** selon la
> sensibilité.

> **À retenir** — **Propriétaire** (API) : performant, immédiat, mais données externalisées.
> **Ouvert** : souverain et maîtrisé, mais infrastructure à gérer. Le choix dépend de la
> **sensibilité des données** et du **volume**.