LiteLLM : QQOQCC.
LiteLLM, dans sa version Proxy Server, sert essentiellement à centraliser, sécuriser et simplifier l’accès à tous les modèles d’IA derrière une seule API compatible OpenAI. Il sera un pivot dans cette architecture.
Représentation du projet d'architecture sécurisée et IA P2DS.
LiteLLM, dans sa version Proxy Server, sert essentiellement à centraliser, sécuriser et simplifier l’accès à tous les modèles d’IA derrière une seule API compatible OpenAI.
🧩 Ce que fait LiteLLM (en version simple)
⚙️ Les fonctions essentielles (explication simple)
1) Accès unifié à 100+ modèles
- Vous appelez toujours la même API (format OpenAI).
- LiteLLM traduit automatiquement vers le bon fournisseur.
- Vous pouvez changer de modèle sans changer votre code.
2) Compatibilité totale OpenAI
- Endpoints
/chat/completions,/embeddings,/batches. - Vos outils existants fonctionnent sans modification.
3) Clés virtuelles pour utilisateurs/équipes
- Vous créez des API keys internes pour vos équipes.
- Vous contrôlez qui utilise quoi, et combien.
- Vous évitez de distribuer vos vraies clés OpenAI/Anthropic.
4) Suivi des coûts
- LiteLLM calcule automatiquement les dépenses :
- par modèle
- par utilisateur
- par équipe
- Très utile pour éviter les mauvaises surprises.
5) Budgets et limites
- Vous fixez des quotas :ex : 20€ par mois pour l’équipe marketing, 1000 requêtes/jour pour un service.
6) Interface d’administration
- Une UI web pour gérer :
- utilisateurs
- équipes
- clés
- modèles
- budgets
- logs
7) Fallbacks et load balancing
- Si un modèle tombe en panne, LiteLLM bascule vers un autre.
- Vous pouvez répartir la charge entre plusieurs fournisseurs.
8) Cache Redis
- Réduit les coûts et accélère les réponses.
- Très utile pour les prompts répétitifs.
9) Alertes
- Notifications Slack / Teams / Email quand :
- un budget est dépassé
- un incident survient
Fonctions avancées (version Enterprise)
Toujours en explication simple :
Authentification avancée
- SSO, OIDC, Azure AD, Keycloak.
- Gestion automatique des tokens temporaires.
Gestion d’organisations
- Structure hiérarchique : organisations → équipes → utilisateurs.
- Admins délégués.
- Modèles privés par équipe.
Observabilité avancée
- Métriques Prometheus.
- Logging vers Datadog, S3, GCS, Azure Data Lake.
Sécurité renforcée
- Guardrails (politiques de contenu).
- Rotation automatique des clés.
Comment ça fonctionne (simplement)
LiteLLM est un reverse proxy intelligent :
- Votre application envoie une requête au format OpenAI.
- LiteLLM la reçoit et regarde quel modèle utiliser.
- Il transforme la requête pour le fournisseur choisi.
- Il renvoie la réponse au format OpenAI.
Pourquoi les entreprises l’utilisent
- Pour centraliser l’accès aux IA.
- Pour sécuriser les clés et les accès.
- Pour maîtriser les coûts.
- Pour éviter le shadow IT.
- Pour changer de fournisseur facilement (multi-sourcing).
- Pour industrialiser l’usage des LLM.
- Pour ma part créer une architecture plus renforcée
Architecture D2S – Version RSSI (DMZ, Double Firewall, Flux contrôlés).
L’ajout d’un SIEM dans mon architecture :
c’est une exigence DSI/DPO/RSSI dès qu’on manipule des données sensibles, qu’on expose des API internes/externes, et qu’on introduit des briques comme LiteLLM, Presidio, Open WebUI ou des modèles IA.
L’idée clé : le SIEM n’est pas là pour l’IA, il est là pour la sécurité du SI dans lequel l’IA s’insère.
Pourquoi un SIEM dans cette architecture
1) Détection d’incidents de sécurité
Les flux IA (LiteLLM, Open WebUI, API Gateway, Presidio) deviennent de nouveaux vecteurs d’attaque :
tentatives d’accès non autorisé
exfiltration de données via prompts
appels massifs anormaux (DoS applicatif)
utilisation frauduleuse de clés virtuelles
contournement des règles DPO (ex : envoi de PII vers un modèle cloud)
Le SIEM permet de corréler ces événements avec le reste du SI.
2) Traçabilité réglementaire (DPO / RSSI)
Dans un contexte RGPD, santé, OIV ou souveraineté, il faut pouvoir répondre à :
Qui a accédé à quoi ?
Quand ?
Depuis où ?
Avec quel modèle ?
Sur quelles données ?
LiteLLM génère des logs riches (requêtes, modèles, coûts, utilisateurs). Presidio génère des logs de détection PII. Open WebUI génère des logs d’accès.
Le SIEM centralise et conserve ces traces pour audit.
3) Supervision de la chaîne IA (DSI)
L’IA devient une chaîne de production :
API Gateway
Presidio
LiteLLM
Providers (Cloud / On‑Prem / Ollama)
Open WebUI
Grafana / Prometheus
Le SIEM permet de détecter :
un modèle qui répond trop lentement
un provider qui tombe
un pic de consommation anormal
un comportement utilisateur suspect
C’est la vision transverse que Grafana seul ne fournit pas.
4) Conformité et souveraineté
Pour un DPO/RSSI, le SIEM est indispensable pour :
prouver que les données sensibles n’ont pas quitté le périmètre autorisé
tracer les appels vers les modèles cloud
détecter les violations de politiques (ex : modèle non autorisé)
conserver les logs pour les audits CNIL / internes
Sans SIEM, tu n’as aucune preuve en cas d’incident.
5) Corrélation avec les autres couches du SI
L’IA n’est qu’un composant du SI, le SIEM permet de corréler :
logs réseau
logs firewall
logs IAM / SSO
logs applicatifs
logs LiteLLM / Presidio / WebUI
Exemple :
Un utilisateur se connecte via SSO → appelle Open WebUI → envoie un prompt suspect → Presidio détecte des PII → LiteLLM bloque → SIEM corrèle → alerte RSSI.Comment le SIEM s’intègre dans mon schéma
Dans mon architecture, la brique Supervision & Audit inclut :
Grafana (métriques)
Logs (Loki / Elastic)
SIEM (corrélation + sécurité)
Le SIEM il est obligatoire dès que vous avez :
des données sensibles (santé, RH, finance)
des flux externes
des API exposées
des modèles IA (risque d’exfiltration)
des obligations réglementaires (RGPD, HDS, OIV)
Synthèse en une phrase
Le SIEM est indispensable pour détecter, corréler, tracer et auditer tous les événements de sécurité liés à la chaîne IA, et pour garantir la conformité DPO/RSSI dans un environnement où les modèles peuvent devenir des vecteurs d’attaque ou de fuite de données.
|
PRESIDIO → LiteLLM Fiche d'Intégration Opérationnelle —
Architecture IA Souveraine UGAIA |
|
Version |
1.0 — Mars
2026 |
|
Statut |
Appliquer dès
Phase 2 (J+30) |
|
Classification |
Données N3/N4
— Confidentiel |
|
Prérequis |
Ollama + Phi-4
installés, LiteLLM Gateway opérationnel |
|
Objectif |
Anonymisation
PII obligatoire avant tout flux vers le modèle d'inférence |
|
🎯 Contexte UGAIA Presidio
s'intègre comme middleware dans LiteLLM Proxy, garantissant qu'aucune donnée
personnelle (PII) ne transite en clair vers Ollama/Phi-4. Les journaux
produits sont « audit-ready » dès leur création — conformité RGPD Art. 5,
règle des 48h CNIL, et assurabilité cyber. |
1. Architecture de la chaîne d'anonymisation
Le schéma suivant représente le
flux Zero Trust IA avec Presidio en position de garde-frontière :
|
Utilisateur |
(prompt brut — peut contenir PII N3/N4) v Open WebUI | v [ PRESIDIO — Anonymisation PII ] <===
MIDDLEWARE LiteLLM |
(prompt anonymisé : <NOM_PERSONNE>, <EMAIL>,
<NIR>...) v LiteLLM Proxy (Gateway) |
(corrélation : mlflow_run_id injecté) v Ollama / Phi-4 (inférence locale — zéro dépendance cloud) | v OpenTelemetry Collector | +----> ELK Stack (journaux anonymisés — preuves forensiques) | +----> Langfuse (observabilité LLM — traçabilité
prompt/réponse) | +----> MLflow (registre modèle — version + run_id) |
|
⚠️ Règle d'or — Audit-by-Design Aucune donnée
nominative ne doit figurer dans les journaux d'audit. Presidio filtre le flux
en mémoire vive avant tout écrit dans ELK ou Langfuse. |
2. Installation de Presidio (Python)
Prérequis système : Python 3.9+,
pip, accès Docker optionnel. Déploiement recommandé en on-premise.
2.1 Installation des packages
|
# Installation des
composants Presidio pip install
presidio-analyzer presidio-anonymizer # Modèle NLP français
(support N3/N4 textes RH, santé, finance) python -m spacy download
fr_core_news_lg # Optionnel : modèle
anglais pour documents bilingues python -m spacy download
en_core_web_lg |
2.2 Test de validation post-install
|
from presidio_analyzer
import AnalyzerEngine from presidio_anonymizer
import AnonymizerEngine analyzer = AnalyzerEngine() anonymizer =
AnonymizerEngine() test_text = "Jean
Dupont, né le 15/03/1982, NIR : 1 82 03 75 108 045 28" results = analyzer.analyze(text=test_text,
language='fr') output = anonymizer.anonymize(text=test_text,
analyzer_results=results) print(output.text) # Attendu :
<PERSON>, né le <DATE_TIME>, NIR : <FR_NIR> |
|
✅ Cible de détection Taux de
détection cible : > 95% sur jeu de données représentatif métier. Valider
impérativement avant mise en production N3/N4. |
3. Configuration du middleware LiteLLM
Presidio s'intègre comme hook de
pré-traitement (pre-call hook) dans LiteLLM. Les données sont filtrées en
mémoire avant routage vers Ollama.
3.1 Classe middleware Presidio
|
# presidio_middleware.py from presidio_analyzer
import AnalyzerEngine from presidio_anonymizer
import AnonymizerEngine from
presidio_anonymizer.entities import OperatorConfig import litellm class
PresidioMiddleware: def __init__(self): self.analyzer = AnalyzerEngine() self.anonymizer = AnonymizerEngine() def anonymize(self, text: str, level: str
= 'N3') -> dict: """ Anonymise le texte et retourne le
texte filtré + la liste des entités détectées pour
journalisation. """ results = self.analyzer.analyze( text=text, language='fr', entities=[ 'PERSON', 'EMAIL_ADDRESS',
'PHONE_NUMBER', 'IBAN_CODE', 'CREDIT_CARD',
'DATE_TIME', 'LOCATION', 'IP_ADDRESS',
'NRP', 'FR_NIR', # Numéro de sécurité sociale FR 'MEDICAL_LICENSE', ] ) # Stratégie de masquage selon niveau
de classification operators = { 'PERSON': OperatorConfig('replace',
{'new_value': '<NOM_PERSONNE>'}), 'EMAIL_ADDRESS':
OperatorConfig('replace', {'new_value': '<EMAIL>'}), 'PHONE_NUMBER': OperatorConfig('replace', {'new_value':
'<TEL>'}), 'IBAN_CODE': OperatorConfig('hash', {'hash_type': 'sha256'}), 'CREDIT_CARD': OperatorConfig('mask', {'masking_char': '*', 'chars_to_mask':
12}), 'FR_NIR': OperatorConfig('hash', {'hash_type': 'sha256'}), 'DATE_TIME': OperatorConfig('replace', {'new_value':
'<DATE>'}), 'LOCATION': OperatorConfig('replace', {'new_value':
'<LOCALISATION>'}), 'IP_ADDRESS': OperatorConfig('replace', {'new_value':
'<IP>'}), } anonymized =
self.anonymizer.anonymize( text=text, analyzer_results=results, operators=operators ) return { 'anonymized_text':
anonymized.text, 'detected_entities':
[r.entity_type for r in results], 'pii_detected': len(results) >
0, } |
3.2 Hook LiteLLM — pré-traitement du prompt
|
# litellm_config.py import litellm import mlflow import json from presidio_middleware
import PresidioMiddleware from datetime import
datetime presidio =
PresidioMiddleware() def
pre_call_hook(kwargs, result, start_time, end_time): """ Hook exécuté avant chaque appel LiteLLM. Anonymise le prompt et journalise les
métadonnées d'audit. """ messages = kwargs.get('messages', []) run_id = mlflow.active_run().info.run_id
if mlflow.active_run() else 'no_run' for msg in messages: if msg.get('role') == 'user': raw_text = msg['content'] result = presidio.anonymize(raw_text) # Remplacement du contenu par la
version anonymisée msg['content'] =
result['anonymized_text'] # Journalisation des métadonnées
uniquement (jamais le texte brut) audit_meta = { 'mlflow_run_id': run_id, 'timestamp': datetime.utcnow().isoformat(), 'pii_detected': result['pii_detected'], 'entities_detected':
result['detected_entities'], 'anonymized': True, } # Envoi vers Langfuse / ELK (via
OpenTelemetry)
print(json.dumps(audit_meta)) #
remplacer par otel_logger litellm.pre_call_hook =
pre_call_hook |
3.3 Configuration litellm_config.yaml
|
# litellm_config.yaml model_list: - model_name: phi4-local litellm_params: model: ollama/phi4 api_base: http://localhost:11434 general_settings: presidio_enabled: true presidio_language: fr pii_masking: true log_decision_process: true # Traçabilité audit CNIL litellm_settings: success_callback: ["langfuse",
"mlflow"] failure_callback: ["langfuse"] telemetry: true |
4. Workflow opérationnel — 5 étapes
|
1 |
Réception
du prompt brut Open WebUI
reçoit la requête utilisateur. Le texte peut contenir des PII N3/N4 non
contrôlées. |
|
2 |
Anonymisation
Presidio (< 50ms) Le middleware
analyse le texte, détecte les entités PII, applique le masquage configuré. Le
prompt anonymisé remplace le texte original en mémoire. |
|
3 |
Injection
du mlflow_run_id Un identifiant
unique est généré et injecté dans les métadonnées de la requête. Ce run_id
devient l'identifiant pivot de toute la chaîne d'audit. |
|
4 |
Inférence
Ollama / Phi-4 Le modèle
reçoit uniquement le prompt anonymisé. Zéro PII ne transite vers le moteur
d'inférence. Conformité RGPD Art. 5 (minimisation) garantie. |
|
5 |
Journalisation
audit-ready ELK et
Langfuse reçoivent uniquement les métadonnées anonymisées + mlflow_run_id.
Les logs sont immédiatement utilisables pour réponse CNIL 48h ou rapport
assureur. |
5. Validation et contrôle qualité
5.1 Suite de tests de non-régression
|
#
test_presidio_validation.py import pytest from presidio_middleware
import PresidioMiddleware pii =
PresidioMiddleware() TEST_CASES = [ # (description, texte_brut,
entités_attendues) ('Nom complet FR', 'Mme Marie Curie signe le contrat.', ['PERSON']), ('Email professionnel', 'Contactez pierre.martin@entreprise.fr
pour confirmation.', ['EMAIL_ADDRESS']), ('NIR sécurité sociale', 'Mon numéro est 1 82 03 75 108 045 28.', ['FR_NIR']), ('IBAN bancaire', 'Virement sur FR76 3000 6000 0112 3456
7890 189.', ['IBAN_CODE']), ('Donnée de santé composée', 'Dr. Benoit, né le 12/06/1975,
consultation le 03/03/2026.', ['PERSON', 'DATE_TIME']), ] @pytest.mark.parametrize('desc,
text, expected_entities', TEST_CASES) def test_detection(desc,
text, expected_entities): result = pii.anonymize(text) assert result['pii_detected'], f'Aucune
PII détectée pour : {desc}' for entity in expected_entities: assert entity in
result['detected_entities'], \ f'{entity} non détecté pour :
{desc}' def
test_no_pii_preserved(): """Vérifie qu'aucun PII ne
subsiste après anonymisation.""" text = 'Marie Dupont, née le 01/01/1990' result = pii.anonymize(text) assert 'Marie Dupont' not in
result['anonymized_text'] assert '01/01/1990' not in
result['anonymized_text'] |
5.2 Matrice de conformité RGPD
|
Exigence RGPD |
Sans Presidio |
Avec Presidio |
|
Art. 5 —
Minimisation des données |
❌ Non conforme |
✅ Conforme |
|
Art. 25 —
Privacy by Design |
❌ Risque élevé |
✅ Implémenté |
|
Art. 32 —
Sécurité du traitement |
⚠️ Partiel |
✅ Garanti |
|
Art. 33 —
Notification 72h ANSSI |
❌ Impossible |
✅ Prêt |
|
Règle 48h CNIL
— Dossier d'audit |
❌ Manuel (jours) |
✅ Automatique |
|
Assurabilité
cyber 2026 |
❌ < 50 pts |
✅ +15 pts score |
6. Contribution au Score de Résilience UGAIA
L'intégration de Presidio comme
middleware actif contribue directement au score de résilience. Le tableau
ci-dessous détaille les points acquis par composant UGAIA :
|
Composant
UGAIA |
Sans Presidio |
Avec Presidio |
|
C1 —
Journalisation & Traçabilité |
6/12 |
11/12 |
|
C2 —
Protection des Données (RGPD) |
4/15 |
13/15 |
|
C3 — Sécurité
des Accès |
6/10 |
8/10 |
|
C4 —
Gouvernance & Conformité |
5/13 |
11/13 |
|
C5 —
Résilience Technique |
8/15 |
12/15 |
|
TOTAL / 100 |
44/100 ⚠️ Non assurable |
78/100 ✅ Assurable |
|
🏆 Seuils d'assurabilité 2026 Score ≥ 75/100
: éligibilité assurance cyber. Score ≥ 80/100 : statut SOUVERAIN+.
L'intégration de Presidio fait passer l'organisation de 44/100 (non
assurable) à 78/100 (assurable). |
7. Résolution des problèmes courants
|
Symptôme |
Cause
probable |
Solution |
|
Noms FR non
détectés |
Modèle spaCy
EN chargé |
Installer
fr_core_news_lg et spécifier language='fr' |
|
Latence
> 200ms |
Modèle NLP
trop lourd |
Utiliser
fr_core_news_md ou migrer vers rs-presidio (Rust) |
|
NIR non
reconnu |
Reconnaisseur
FR_NIR manquant |
Ajouter
recognizer FR personnalisé (regex NIR) |
|
Hook
LiteLLM ignoré |
Version
LiteLLM < 1.30 |
Mettre à jour
: pip install --upgrade litellm |
|
mlflow_run_id
absent |
MLflow non
initialisé |
Appeler
mlflow.start_run() avant le hook |
|
Taux
détection < 90% |
Jargon métier
non reconnu |
Ajouter des
reconnaisseurs personnalisés (contrats, IDs internes) |
8. Checklist de mise en production
|
VALIDATION PRE-PRODUCTION N3/N4 Toutes les cases doivent être cochées
avant activation |
▶ Installation
•
☐ presidio-analyzer
et presidio-anonymizer installés (pip)
•
☐ Modèle
spaCy fr_core_news_lg téléchargé et validé
•
☐ Test
unitaire de base exécuté avec succès
▶ Configuration
•
☐ PresidioMiddleware
instancié et configuré (entités FR activées)
•
☐ Hook
pre_call_hook enregistré dans LiteLLM
•
☐ litellm_config.yaml
: presidio_enabled: true et log_decision_process: true
•
☐ mlflow_run_id
injecté dans les métadonnées de chaque requête
▶ Validation
•
☐ Suite
pytest complète : taux de détection ≥ 95% sur jeu de test métier
•
☐ Contrôle :
aucun PII en clair dans les logs ELK et Langfuse
•
☐ Test règle
48h : dossier d'audit généré automatiquement sans donnée brute
•
☐ Fallback
testé : désactivation Presidio = rejet de la requête (pas de bypass)
▶ Documentation
•
☐ Fiche de
procédure archivée dans le système de gestion documentaire
•
☐ Score de
résilience UGAIA recalculé et validé (≥ 75/100)
•
☐ Rapport
d'audit CNIL préparé avec preuves d'anonymisation
Références et ressources
|
Documentation
officielle |
|
|
API
Reference |
|
|
Démo
Hugging Face |
https://huggingface.co/spaces/presidio/presidio_demo |
|
ModernBERT
PII classifier |
https://huggingface.co/llm-semantic-router/pii_classifier_modernbert-base_presidio_token_model |
|
rs-presidio
(Rust) |
https://github.com/posidron/rs-presidio |
|
LiteLLM
Proxy docs |
https://docs.litellm.ai/docs/proxy/quick_start |
|
Blog
GOUVERNANCES. — Art. 1 |
https://gouver2020.blogspot.com/2026/02/microsoft-presidio-est-le-framework.html |
|
Blog
GOUVERNANCES. — Art. 2 |
https://gouver2020.blogspot.com/2026/02/tests-installation-de-presidio.html |
|
Blog
GOUVERNANCES. — Art. 3 |
https://gouver2020.blogspot.com/2026/03/pii-de-identification-avec-microsoft.html |
|
Guide UGAIA
V10 — Chapitre 5 |
Gouv˙IA-Secu-Audit-IA_V10_2026.docx |
|
📋 Intégration dans le Passeport Souveraineté
UGAIA V4 Cette fiche
répond directement à la Question 6 du Passeport : traçabilité complète prompt
→ modèle → accès → évaluation qualité. Le mlflow_run_id est l'identifiant
pivot. Sa présence dans chaque enregistrement ELK, Langfuse et MLflow
constitue la preuve technique d'intégrité exigée par les auditeurs et les
assureurs. |
Ollama peut être utilisé à l’intérieur de LiteLLM comme un fournisseur de modèles locaux.
LiteLLM = Proxy multi‑fournisseurs + gouvernance + coûts
LiteLLM sert à :
unifier l’accès à tous les modèles (OpenAI, Anthropic, Azure, Bedrock, Ollama…)
gérer les clés virtuelles, quotas, budgets, équipes
suivre les coûts et les logs
appliquer des politiques de sécurité
faire du load balancing et du fallback
exposer une API OpenAI unique
LiteLLM n’exécute pas les modèles : il orchestrationne.
Ollama = Serveur local de modèles open‑source
Ollama sert à :
- télécharger et exécuter des modèles localement (Llama, Mistral, Phi, Qwen…)
- gérer le chargement en RAM, le quantization, le GPU
- fournir une API simple pour interroger un modèle local
Ollama n’a pas :
- de gestion d’utilisateurs
- de quotas
- de budgets
- de logs avancés
- de multi‑fournisseurs
- de compatibilité OpenAI complète
- de load balancing
- de sécurité d’entreprise
Comment ils s’articulent ensemble
Le schéma réel dans les entreprises
Application → LiteLLM → (OpenAI / Anthropic / Azure / Bedrock / Ollama local)
LiteLLM devient la couche de gouvernance, Ollama devient un fournisseur parmi d’autres.
Conclusion simple
Ollama = moteur local
LiteLLM = gouvernance + proxy multi‑modèles
Ollama ne remplace pas LiteLLM. Ollama complète LiteLLM.
1) Démarrer LiteLLM Proxy avec Docker, c'est fait
Autrement si tu as déjà téléchargé l’image.
Lance-la :
docker run -p 4000:4000 -e LITELLM_LOG=info docker.litellm.ai/berriai/litellm:main-latest
Cela démarre le proxy LiteLLM sur :
http://localhost:4000 voir copie écran ci-dessus
2) Tester avec l’API OpenAI (via LiteLLM)
Exemple :
curl http://localhost:4000/v1/chat/completions `
-H "Content-Type: application/json" `
-H "Authorization: Bearer votrecledetest" `
-d "{""model"":""gpt-4o-mini"", ""messages"":[{""role"":""user"",""content"":""Bonjour""}]}"
3) Ajouter Ollama comme fournisseur local (si tu veux)
Si tu as Ollama installé :
ollama run mistral
Puis dans LiteLLM, tu peux appeler :
curl http://localhost:4000/v1/chat/completions `
-H "Content-Type: application/json" `
-d "{""model"":""ollama/mistral"", ""messages"":[{""role"":""user"",""content"":""Bonjour""}]}"
Résumé clair
- La ligne “Application → LiteLLM → …” était un schéma, pas une commande.
- PowerShell a essayé de l’exécuter → erreur normale.
- Tu as bien installé LiteLLM.
- Prochaine étape : lancer le proxy et tester une requête.
