Quand un comité de direction demande à son DSI « pouvons-nous déployer GPT-5 en interne ? », la réponse dépend moins des capacités du modèle que de cinq exigences opérationnelles rarement formulées à voix haute. Les voici, telles que nous les appliquons sur nos missions régulées.
1. L’infrastructure doit être contractualisée, pas découverte
Avant toute ligne de code, il faut savoir où tournent les poids, qui administre le cluster GPU et quelle est la juridiction de rattachement. On-premise, cloud souverain français (Outscale, Clever Cloud, OVHcloud AI Endpoints), cloud hyperscaler régionalisé (AWS Paris, Azure France Central) ou hybride — chaque option porte un profil de risque, de coût et de latence distinct.
La question à poser n’est pas « quel modèle ? » mais « quel contrat encadre la résidence des données d’inférence ? ». Un modèle exceptionnel opéré sur une infrastructure non maîtrisée reste un modèle dont on ne peut pas garantir le comportement.
2. Les modèles ouverts passent la barre, pour peu qu’on accepte de les opérer
Llama 4 Maverick, Mistral Large 3, DeepSeek V3 — l’écart de performance avec les modèles propriétaires s’est réduit au point que, pour la majorité des cas d’usage métier, le choix n’est plus entre « meilleur modèle » et « modèle souverain » mais entre « modèle opérable » et « modèle externalisé ».
Opérer un LLM en propre implique trois sous-projets souvent sous-estimés :
- Serving : vLLM, TGI ou Ollama selon la volumétrie, avec du batch continu et du PagedAttention pour tenir la charge
- Dimensionnement GPU : A100, H100 ou L40S, quantisation INT4/INT8, KV-cache sizing — chiffres concrets, pas estimations
- Supervision : tokens/seconde par user, latence p50/p99, taux de troncature, drift de qualité
Sans ce triptyque, un déploiement souverain devient un prototype permanent.
3. L’observabilité sémantique, pas uniquement technique
Un système RAG qui renvoie des réponses incorrectes avec un uptime de 99,99 % est un échec métier, pas une réussite technique. L’observabilité doit porter sur le contenu autant que sur la mécanique :
- traçage complet prompt → retrieval → génération → réponse
- évaluations périodiques sur un golden set figé et versionné
- détection automatique de régression qualitative entre deux releases
- journalisation des interactions avec pseudonymisation réversible pour l’audit
Les plateformes comme Langfuse, Phoenix ou Helicone adressent ce besoin en open source. Nous les intégrons systématiquement dès le premier sprint.
4. L’audit doit être possible avant même qu’il soit demandé
Trois questions que nous posons à chaque mise en production :
- Peut-on rejouer une réponse produite il y a 30 jours ? Version du modèle, snapshot du contexte, identifiant de la requête.
- Peut-on expliquer pourquoi une réponse donnée a été produite ? Sources RAG citées, confidence scores, guardrails déclenchés.
- Peut-on extraire toutes les données personnelles traitées par un utilisateur donné ? Pour honorer un droit d’accès ou d’effacement RGPD en moins de 30 jours.
Si la réponse à l’une de ces trois questions est « pas tout à fait », l’architecture n’est pas prête pour la production régulée.
5. La réversibilité doit être documentée dès le cadrage
L’enfermement vendeur (vendor lock-in) ne se mesure pas à la signature, mais le jour où l’on veut changer. Les vecteurs d’enfermement les plus fréquents :
- Poids propriétaires impossibles à migrer → exiger des modèles aux poids ouverts ou une clause de portabilité
- Formats de vector store spécifiques → préférer les standards (PostgreSQL + pgvector, Weaviate, Qdrant)
- Orchestration chaînée à un seul cloud → privilégier les runtimes portables (Kubernetes, OpenTofu)
- Données d’entraînement ou de fine-tuning non restituables → exiger un droit d’extraction
Nous livrons systématiquement un exit plan documenté avec chaque architecture IA — procédure d’extraction, délai estimé, coût de portage. Ce document ne sera peut-être jamais utilisé. Il rassure néanmoins les directions juridiques et financières bien au-delà de la valeur de son contenu.
Ces cinq exigences ne sont pas des fantasmes de sécurité. Elles correspondent à ce que les directions techniques régulées — banque, assurance, santé, défense, secteur public — réclament déjà pour tout projet critique. L’IA n’échappe pas à cette règle : elle l’amplifie.
Pour aller plus loin
- Notre offre de déploiement IA on-premise, cloud ou hybride : Solutions IA
- Le langage open source pour gouverner vos agents IA : PCL — Persona Control Language
- Budgéter sérieusement un LLM en production : Coût total de possession d’un LLM
- Le plan que vous n’avez pas encore écrit : Si votre fournisseur IA vous coupe l’accès demain
- Niveaux de service et engagements d’exploitation : Support IBIFACE
Si vous cadrez un déploiement IA et souhaitez une lecture argumentée de votre contexte, écrivez-nous — nous revenons sous 24 heures ouvrées.