## Pourquoi la souveraineté de l'IA ?

La souveraineté consiste à **garder la maîtrise** de trois actifs critiques : vos
**données**, vos **modèles** et l'**infrastructure** qui les exécute. Pour une
administration ou un grand groupe, déléguer ces trois éléments à une API tierce hébergée
hors de votre juridiction soulève des risques très concrets.

### Les trois enjeux, en détail

- **Données** — Tout prompt envoyé à une API externe **quitte votre périmètre**. Le
  fournisseur peut le conserver, l'utiliser pour entraîner ses modèles, ou y être contraint
  par une réquisition judiciaire étrangère. Pour des documents sensibles (dossiers fiscaux,
  données de santé, pièces d'un contrôle juridictionnel), c'est souvent juridiquement
  inacceptable.
- **Dépendance** — Un fournisseur peut **augmenter ses prix**, **déprécier un modèle** sur
  lequel repose votre service, modifier ses conditions d'utilisation, ou être soumis à des
  lois extraterritoriales (ex. *CLOUD Act* américain). Votre service en production en hérite,
  sans recours.
- **Conformité** — RGPD, lois nationales sur l'hébergement des données publiques, exigences
  d'**auditabilité** : beaucoup imposent que la donnée reste sur un territoire ou une
  infrastructure maîtrisée, et que l'on puisse **justifier chaque traitement**.

### Le spectre des options (la souveraineté n'est pas binaire)

On va du **100 % API publique** (rapide, aucune maîtrise) au **100 % on-premise
air-gapped** (maîtrise totale, coûteux), en passant par le **cloud privé** et le **cloud
souverain régional**. Le bon niveau dépend de la **sensibilité réelle** des données et du
budget — pas d'une posture idéologique.

> **📌 Cas concret — Cour des comptes**
> Une institution supérieure de contrôle veut un assistant qui interroge les rapports
> d'audit et les pièces des organismes contrôlés. Ces documents sont **confidentiels par
> nature** (un budget non encore publié, des constats avant contradiction). Les envoyer à
> une API publique reviendrait à exposer des données d'État à un tiers étranger. Verdict :
> **déploiement souverain obligatoire**, là où un simple chatbot de FAQ publique pourrait,
> lui, se contenter d'une API. → La **cartographie des données par sensibilité** décide de
> l'architecture, cas d'usage par cas d'usage.

> **À retenir** — La question n'est pas « API ou souverain ? » mais « **quel niveau de
> souveraineté pour quel cas d'usage ?** ». La cartographie des données par sensibilité est
> le préalable obligatoire à toute décision d'architecture.