Translate

Affichage des articles dont le libellé est Hugging Face. Afficher tous les articles
Affichage des articles dont le libellé est Hugging Face. Afficher tous les articles

jeudi 22 octobre 2026

Les Agents IA les plus utilisés en 2026

En octobre 2026, Claude Code domine les agents de code, Hermes Agent et OpenClaw les agents personnels, LangChain et LangGraph les frameworks. Ces trois classements reposent sur des métriques différentes et ne se comparent pas entre eux :

  • Agents de code : enquêtes d'adoption auprès des développeurs.
  • Agents personnels : volume de jetons traités via OpenRouter.
  • Frameworks : téléchargements de paquets et étoiles GitHub.

Cet article dresse ce panorama, puis examine les exigences de confinement, les risques propres aux agents autonomes et la réponse qu'y apporte le cadre UGAIA.

1. Quels agents sont les plus utilisés en 2026 ?

Agents de code — adoption au travail, mi-2026

Selon l'enquête JetBrains (plus de 15 000 développeurs professionnels), 90 % des développeurs utilisaient un agent de code au moins une fois par semaine en mai–juillet 2026, et 68 % chaque jour. Claude Code est l'agent le plus adopté au travail.

Agent Éditeur Adoption au travail Observation
Claude CodeAnthropic~39 %18 % en janvier 2026 ; choisi par 75 % des petites startups
GitHub CopilotMicrosoft / GitHub21 %Prédominant dans les entreprises de plus de 10 000 salariés (56 %)
CodexOpenAI16 %Multiplié par 5 depuis janvier 2026
CursorAnysphere12 %En recul
JetBrains AI / JunieJetBrains~9 %—
OpenCodeOpen source7 %42 % de notoriété
Google AntigravityGoogle6 %Stable

Agents personnels et généralistes — trafic OpenRouter, mai 2026

Hermes Agent (Nous Research) a dépassé OpenClaw le 10 mai 2026 au classement quotidien d'OpenRouter : 224 milliards de jetons par jour, contre 186 milliards.

Agent Éditeur Indicateur
Hermes AgentNous Research (licence MIT)N° 1 en volume quotidien depuis le 10/05/2026
OpenClawOpen source (Peter Steinberger)Devant en cumul au moment du dépassement : 9,17 billions de jetons, contre 6,35 pour Hermes
Kilo Code, Claude Code, pi, Cline, Roo Code, OpenHandsDiversRelevé du 21/05/2026 : Kilo Code 3e (163 Md/jour), Claude Code 5e (64,1 Md), pi 6e (58 Md), Cline 11e, Roo Code 12e, OpenHands 19e

Deux réserves s'appliquent. OpenRouter ne compte que les applications qui acceptent le suivi de leur trafic : Claude Code, Copilot ou Codex utilisés directement chez leur éditeur n'y figurent pas. Le classement varie aussi selon la fenêtre de mesure ; il faut vérifier la page en direct avant toute citation datée.

Frameworks pour construire des agents

LangChain et LangGraph dominent les installations : environ 309 millions et 66,5 millions sur 30 jours au 27 juillet 2026.

Framework Indicateur
LangChain / LangGraph~309 M (LangChain) et ~66,5 M (LangGraph) installations sur 30 jours
CrewAI~10,8 M installations sur 30 jours ; licence MIT ; ~51 000 étoiles GitHub
Mastra (TypeScript)~4,9 M installations par mois
Microsoft Agent FrameworkFusion d'AutoGen et de Semantic Kernel ; v1.0 en avril 2026
n8n (low-code)~190 000 étoiles GitHub, le plus étoilé du panel

Sont également cités : OpenAI Agents SDK, Google ADK, Pydantic AI, LlamaIndex, smolagents et Claude Agent SDK.

Modèles à poids ouverts

Les paramètres, la longueur de contexte, les licences et les besoins en GPU des principaux modèles à poids ouverts (Hermes 4, Llama 3.3, Phi-4, Mistral Small 4, Qwen3-Coder-Next, gpt-oss) sont réunis dans un tableau relevé sur les fiches Hugging Face au 22/10/2026 : consulter le tableau. Ses sources figurent dans l'onglet « Sources ».

2. Confinement réseau des agents IA

L'étanchéité réseau requise pour les agents IA repose sur un confinement strict en Couche 1 (réseau / système d'exploitation), résumé par la règle : « Le prompt exprime, le contexte filtre, le broker contraint, l'OS garantit. » Seule la Couche 1 garantit techniquement l'absence d'exfiltration de données.

Les exigences de confinement en Couche 1

Pour qu'un agent autonome, en particulier de niveau 3 ou 4, soit jugé conforme et gouvernable, son environnement d'exécution doit respecter les contraintes suivantes :

  • Namespace sans route sortante ni DNS : l'agent s'exécute dans un espace isolé, sans route vers Internet ou le réseau externe et sans résolution DNS.
  • Inférence en loopback : la communication entre l'agent ou l'orchestrateur et le modèle de langage (SLM local comme Mistral, Phi-4 ou Llama sous Ollama) passe exclusivement par la boucle locale.
  • Sandbox jetable sans accès réseau : toute exécution de code, de script ou d'outil a lieu dans un conteneur éphémère privé de réseau.
  • UID de service dédié : l'agent fonctionne sous un identifiant système non privilégié, aux droits strictement restreints sur le système de fichiers.

Fermeture systématique des surfaces réseau sortantes

Déployer un modèle local ne garantit pas la souveraineté si des passerelles réseau restent ouvertes. La gouvernance exige la désactivation explicite de toutes les surfaces réseau secondaires :

  • Recherche web et accès URL : retrait des outils de requête HTTP et de navigation web de la liste d'autorisations (allowlist).
  • Navigateurs automatisés : interdiction d'installer des agents de scraping ou de navigation dynamique.
  • Connecteurs inter-agents (A2A) et MCP distants : interdiction des serveurs MCP externes et des canaux d'agent à agent non contrôlés par le broker.
  • Gateways sortants : suppression des connecteurs d'envoi automatique (e-mails, webhooks, API externes).

Grille d'admissibilité et tests de contrôle (profil souverain « Andorre »)

Pour admettre un agent ou une plateforme agentique sur des données critiques (niveau 4), la DSI et le RSSI vérifient les critères bloquants suivants :

  • Test de coupure réseau complète : démontrer que le cycle d'exécution complet de l'agent fonctionne dans un namespace sans route sortante ni DNS.
  • Contrôle de télémétrie par capture nftables : capturer les flux au niveau du système d'exploitation pour prouver qu'aucune requête de licence, d'authentification en ligne ou de télémétrie ne sort.
  • Indépendance vis-à-vis du SaaS : les agents de code et assistants SaaS (Claude Code, Copilot, ChatGPT…) ne pouvant pas offrir ce confinement local en Couche 1, ils sont proscrits pour les données de niveau 4.

3. Risques des agents IA autonomes

Les limites et vulnérabilités des agents autonomes se structurent autour de cinq axes techniques, cognitifs et réglementaires.

Les quatre risques opérationnels majeurs

Contrairement aux chatbots, qui produisent du texte, les agents agissent directement sur les systèmes d'information. Cette capacité d'action introduit quatre risques spécifiques :

  • L'action irréversible : l'agent exécute des opérations (écriture, envoi d'e-mails, suppression de fichiers, modification de droits) sans validation humaine à chaque étape.
  • L'enchaînement d'outils imprévu : une suite d'appels, chacun légitime pris isolément, peut produire un effet global inattendu ou contraire à l'intention initiale.
  • L'exfiltration via les outils : des outils de sortie légitimes (messagerie, requêtes HTTP, webhooks) peuvent devenir des canaux de fuite de données ou relayer des injections de prompt indirectes.
  • La boucle non bornée : l'agent s'enferme dans un cycle d'essais et d'erreurs, consomme des ressources (jetons, puissance GPU) et fait exploser les coûts sans converger.

Les cinq défaillances de gestion du contexte

Gartner et le cadre UGAIA identifient la gestion du contexte comme l'une des principales sources d'échec des agents autonomes :

  • Information perdue : oubli d'instructions ou de données clés situées au milieu d'une longue fenêtre de contexte.
  • Empoisonnement par hallucination répétée : l'agent réinjecte ses propres hallucinations dans sa mémoire à long terme, ce qui aggrave les erreurs futures.
  • Distraction par excès de contexte : une surabondance d'informations perturbe le raisonnement.
  • Confusion par contenu non pertinent : l'agent ne sépare plus les données utiles du bruit.
  • Conflit entre sources : blocage ou décision incohérente face à des sources contradictoires.

L'inefficacité des règles rédigées uniquement dans le prompt

Une règle de sécurité rédigée comme consigne système (dans le prompt ou un fichier SKILL.md) n'est qu'une recommandation : une injection de prompt documentaire suffit à la neutraliser. Par ailleurs, les moteurs de règles sans état (par exemple OPA/Rego) jugent un appel d'outil isolé, sans pouvoir vérifier s'il respecte l'ordre des étapes précédentes.

L'immaturité de la remédiation et du rollback automatisé

Les garde-fous actuels sont préventifs : ils bloquent ou demandent une approbation, mais ne défont pas automatiquement les conséquences d'une action exécutée. Gartner estime que le rollback automatisé des actions d'agents reste embryonnaire, avec un plateau d'adoption à 5–10 ans. La réversibilité doit donc reposer sur des procédures organisationnelles : sauvegardes avant action, transactions compensatoires.

Les limites d'auditabilité et de gouvernabilité

  • L'agent non auditable : un agent dont les appels d'outils et les décisions ne sont pas tracés de façon immuable est non auditable, donc non conforme.
  • L'agent non gouvernable : sans arrêt d'urgence persistant (kill switch) capable d'interrompre immédiatement l'exécution, un agent ne peut pas satisfaire l'exigence de contrôle humain de l'article 14 de l'AI Act pour les systèmes à haut risque.

4. La réponse de la gouvernance UGAIA

Le cadre UGAIA oppose à chacune de ces limites un point d'application vérifiable, selon le principe directeur « Le prompt exprime, le contexte filtre, le broker contraint, l'OS garantit. » Ces contrôles réduisent les risques ; ils ne les annulent pas.

Face aux quatre risques opérationnels

  • Action irréversible : le broker (Couche 2) classe les actions en quatre catégories (READ, DRAFT, SEND, DESTRUCTIVE). Les actions à impact externe (SEND) exigent une validation humaine simple ; les actions critiques (DESTRUCTIVE), une double validation humaine et une sauvegarde préalable obligatoire.
  • Enchaînement d'outils imprévu : AgentLTL contrôle la séquence temporelle de la trace. Il impose un ordre d'exécution (déployer en préproduction avant la production) et lie les variables entre appels (appliquer exactement l'artefact relu). Le broker réévalue les autorisations à chaque décision.
  • Exfiltration via les outils : Presidio pseudonymise les données personnelles avant tout appel d'outil ou envoi externe. Le confinement en Couche 1 enferme l'agent dans un namespace sans route sortante ni DNS, et le broker applique une liste blanche stricte des destinations autorisées.
  • Boucle non bornée et explosion des coûts : le garde-fou « Bornage de la boucle et kill switch » fixe des plafonds d'étapes, de durée et de budget. En cas de dépassement, la passerelle bloque l'exécution et le kill switch persistant interrompt l'agent.

Face aux cinq défaillances de gestion du contexte

  • Contexte surchargé, distrait ou confus : le registre des sources de contexte (phase 4) garantit qu'un agent ne lit que des sources enregistrées, vérifiées et adaptées à son niveau d'habilitation. Le broker applique une allowlist d'outils et de sources restreinte par tâche.
  • Empoisonnement par hallucination et conflits : la provenance est obligatoire en mémoire durable (aucun contenu non sourcé ne devient persistant) ; le principe cite-or-abstain s'ajoute à la détection automatique des contradictions.

Face aux règles « prompt-only »

  • Bascule vers des contrôles appliqués : une consigne dans le prompt ou un SKILL.md reste une recommandation vulnérable aux injections. UGAIA déplace la contrainte vers le broker (Couche 2), via des politiques externes OPA/Rego, et vers l'OS (Couche 1).
  • Règles temporelles opposables (AgentLTL, TR-070) : les instructions sont converties en règles formelles exécutées en modes bloquants (block, ask, stop). Les commandes masquées ou non analysables (eval, variables de commande $CMD) sont refusées pour empêcher tout contournement par reformulation.

Face à l'immaturité du rollback automatisé

Garde-fou 7 — Remédiation par procédure : faute de rollback automatisé mature, UGAIA compense par l'organisation. Aucune action SEND ou DESTRUCTIVE n'est autorisée sans plan de rollback documenté, instantané d'état préalable ou transactions compensatoires testées.

Face aux limites d'auditabilité et de gouvernabilité

  • Garde-fou 5 — Journalisation via mlflow_run_id étendu : chaque décision consigne l'outil appelé, ses paramètres pseudonymisés, la version du modèle, la validation humaine horodatée et l'effet produit. Les journaux sont exportés sur un volume append-only en Couche 1, hors d'atteinte de l'agent.
  • Garde-fou 3 — Kill switch persistant : le RSSI peut interrompre le système en temps réel. Le coupe-circuit désactive les outils, survit au redémarrage et bloque le lancement de tout nouveau run.
  • Garde-fou 8 — Évaluation continue : suites de tests automatisées (hallucination, toxicité, dérive) en intégration continue et en production, avec seuils bloquants.
https://docs.google.com/spreadsheets/d/1W4a7ewpndGUHdSBVBrrIOl_pfqxyOKyfaIz8hWAXOEI/edit?usp=sharing

Sources

L'orchestration de l'IA sur l'ensemble du cycle de développement logiciel (SDLC — Software Development Lifecycle) repose sur un principe fondateur : la séparation stricte entre la construction (production du code, des tests, des compétences et des définitions) et l'exploitation (exécution en production).
Read more »
Posted by at Aucun commentaire:
Labels: , , , , , , ,

dimanche 1 mars 2026

PII De-Identification avec Microsoft Presidio démonstration anonymisation

Exemple d'utilisation de Presidio et tests.




Presidio est un framework open source personnalisable pour la détection et l'anonymisation des données personnelles.

Code | Tutoriel | Installation | FAQ | Commentaires |Utilisez cette démo pour :

Expérimenter différents modèles prêts à l'emploi et packages de traitement automatique du langage naturel (TALN). Explorer les différentes options d'anonymisation, notamment la rédaction, le masquage, le chiffrement, etc. Générer du texte synthétique avec Microsoft Presidio et OpenAI.

Configurer des listes d'autorisation et de blocage.

Ce site web de démonstration présente certaines des fonctionnalités de Presidio. Visitez notre site web pour plus d'informations, des exemples et des options de déploiement.

Exemple rendu :

https://huggingface.co/spaces/presidio/presidio_demo



https://huggingface.co/spaces/presidio/presidio_demo

Sélectionnez la manipulation à appliquer au texte après l'identification des données personnelles.

Masquer : Supprimer complètement les données personnelles.

Remplacer : Remplacer les données personnelles par une constante, par exemple <PERSON>.

Synthétiser : Remplacer par des valeurs fictives (nécessite une clé OpenAI).

Surligner : Afficher le texte original avec les données personnelles surlignées en couleur.

Masquer : Remplacer un nombre de caractères par un astérisque (ou un autre caractère de masque).

Hacher : Remplacer par le hachage des données personnelles.

Chiffrer : Remplacer par un chiffrement AES des données personnelles, permettant ainsi une restauration.

Masquer les données personnelles.

Rendu des fenêtres Presidio dans Presidio Demo - a Hugging Face Space by presidio

Détails des textes dans les fenêtres ci-dessus :

Here are a few example sentences we currently support:

Hi, my name is David Johnson and I'm originally from Liverpool.
My credit card number is 4095-2609-9393-4932 and my crypto wallet id is 16Yeky6GMjeNkAiNcBY7ZhrLoMSgg1BoyZ.

On 11/10/2024 I visited www.microsoft.com and sent an email to test@presidio.site,  from IP 192.168.0.1.

My passport: 191280342 and my phone number: (212) 555-1234.

This is a valid International Bank Account Number: IL150120690000003111111 . Can you please check the status on bank account 954567876544? 

Kate's social security number is 078-05-1126.  Her driver license? it is 1234567A.

Here are a few example sentences we currently support:

Hi, my name is <PERSON> and I'm originally from <LOCATION>.
My credit card number is <CREDIT_CARD> and my crypto wallet id is <CRYPTO>.

On 11/10/2024 I visited www.microsoft.com and sent an email to <EMAIL_ADDRESS>,  from IP <IP_ADDRESS>.

My passport: 191280342 and my phone number: (212) 555-1234.

This is a valid International Bank Account Number: <IBAN_CODE> . Can you please check the status on bank account 954567876544? 

<PERSON>'s social security number is 078-05-1126.  Her driver license? it is 1234567A.

Source  


 

Échantillons :

SujetType de donnéesRessourceExemple

PII, PHI et Microsoft Presidio, un guide complet en français.

1. Vocabulaire fondamental : PII, PHI, PCI

Trois acronymes structurent la protection des données dans les systèmes d'IA :

PII (Personally Identifiable Information) — Données à caractère personnel au sens du RGPD. Toute information permettant d'identifier directement ou indirectement une personne physique : nom, prénom, adresse email, numéro de téléphone, adresse postale, numéro de sécurité sociale, numéro de passeport, adresse IP, données de localisation, etc.

PHI (Protected Health Information) — Sous-catégorie américaine (HIPAA) des données de santé protégées. En droit européen, ces données relèvent de l'article 9 du RGPD (données sensibles à protection renforcée) : diagnostic médical, antécédents, ordonnances, résultats d'analyses, numéro de patient, etc. Leur traitement exige une base légale spécifique et des garanties techniques renforcées.

PCI-DSS (Payment Card Industry Data Security Standard) — Données de cartes de paiement : numéros de carte, CVV, dates d'expiration. Soumises à un cadre de sécurité sectoriel strict.

Ces trois catégories forment le cœur de ce que Presidio détecte et anonymise dans vos pipelines IA.

2. Microsoft Presidio — Le framework de référence

Presidio est un framework open source Microsoft conçu pour détecter, anonymiser et pseudonymiser les données sensibles dans des textes, images et documents. Il s'intègre parfaitement dans une architecture UGAIA/souveraineté car il tourne 100% en local, sans envoi vers un cloud externe.

Architecture modulaire de Presidio

Presidio se compose de quatre services principaux :

presidio-analyzer (port 5002) — Moteur de détection : il identifie les entités sensibles via des règles regex, des modèles NLP (spaCy), du machine learning et des recognizers contextuels. Il retourne un score de confiance pour chaque entité détectée (entre 0 et 1).

presidio-anonymizer (port 5001) — Moteur de transformation : il applique les opérations de protection sur le texte brut selon les résultats de l'analyzer. Il supporte plusieurs modes : mask (***), redact (suppression), replace (substitution), hash (SHA256), encrypt (AES) et FPE (format-preserving encryption).

presidio-image-redactor — Caviardage d'images via OCR + Tesseract, utile pour les documents scannés et les captures d'écran contenant des PII.

presidio-ocr — Pipeline complet pour les PDF : extraction OCR puis passage dans l'analyzer/anonymizer.

Installation Docker (testée et validée)

# Téléchargement des images officielles
docker pull mcr.microsoft.com/presidio-analyzer
docker pull mcr.microsoft.com/presidio-anonymizer
# Lancement des conteneurs
docker run -d -p 5002:3000 mcr.microsoft.com/presidio-analyzer:latest
docker run -d -p 5001:3000 mcr.microsoft.com/presidio-anonymizer:latest
# Vérification
docker ps
curl http://localhost:5002/analyze
curl http://localhost:5001/anonymize

Pour un usage professionnel DSI/DPO/RSSI, la variante recommandée fixe les versions et isole le réseau :

docker network create presidio-net
docker run -d --name presidio-analyzer \
  --network presidio-net \
  -p 5002:3000 \
  mcr.microsoft.com/presidio-analyzer:1.0.0
docker run -d --name presidio-anonymizer \
  --network presidio-net \
  -p 5001:3000 \
  mcr.microsoft.com/presidio-anonymizer:1.0.0

3. Intégration dans un pipeline Ollama + Presidio

L'architecture "Gouvernance augmentée" repose sur une séparation nette des rôles :

Composant Rôle Caractéristique
Presidio Détection et anonymisation PII/PHI/PCI Déterministe, traçable, RGPD-compliant
Ollama (Phi-4/Mistral) Analyse sémantique et gouvernance Contextuel, non déterministe — à encadrer
PowerShell/Python Orchestration et audit Reproductible, scriptable

Le flux en 5 étapes

Étape 1 — Ingestion : le document brut (TXT, DOCX, PDF après OCR) entre dans le pipeline.

Étape 2 — Détection Presidio : appel à l'API analyzer pour identifier toutes les entités PII/PHI/PCI avec leur position, type et score de confiance. Résultat : un JSON structuré.

Étape 3 — Anonymisation Presidio : appel à l'anonymizer avec le texte brut et les résultats de détection. Résultat : un texte propre où toutes les données sensibles sont masquées ou pseudonymisées.

Étape 4 — Analyse sémantique Ollama : le LLM local reçoit uniquement le texte anonymisé (jamais les données brutes) plus un résumé des entités détectées. Il produit une classification de sensibilité, une évaluation des risques et des recommandations de gouvernance pour DPO/RSSI/COMEX.

Étape 5 — Sortie : trois artefacts sont générés : le document anonymisé, l'audit JSON horodaté (hash SHA256, versions des modèles, entités détectées), et le rapport de gouvernance en Markdown.

Exemple d'appel Python

import requests
# Appel Presidio Analyzer
analyze_response = requests.post(
    "http://localhost:5002/analyze",
    json={
        "text": "Jean Dupont, IBAN FR76 1234 5678, tél. 06 12 34 56 78",
        "language": "fr"
    }
)
entities = analyze_response.json()
# Appel Presidio Anonymizer
anonymize_response = requests.post(
    "http://localhost:5001/anonymize",
    json={
        "text": "Jean Dupont, IBAN FR76 1234 5678, tél. 06 12 34 56 78",
        "analyzer_results": entities
    }
)
clean_text = anonymize_response.json()["text"]
# Résultat : "<PERSON>, IBAN <IBAN_CODE>, tél. <PHONE_NUMBER>"
# Appel Ollama (Phi-4 ou Mistral)
ollama_response = requests.post(
    "http://localhost:11434/api/generate",
    json={
        "model": "phi4",
        "prompt": f"Analyse de gouvernance du document suivant : {clean_text}\n"
                  f"Entités détectées : {entities}\n"
                  f"Fournis une classification de sensibilité et des recommandations RGPD.",
        "stream": False
    }
)
governance_report = ollama_response.json()["response"]

4. Matrice de criticité des entités (pour le scoring UGAIA)

Entité Criticité Réglementation Action Presidio
Email 1 RGPD art. 4 Mask
Téléphone 2 RGPD art. 4 Mask
Adresse 2 RGPD art. 4 Redact
Nom complet 3 RGPD art. 4 Pseudonymiser
NIR (sécu) 4 RGPD art. 9 Hash/Encrypt
IBAN 4 PCI-DSS Encrypt
Données santé 5 RGPD art. 9 Encrypt + accès restreint
Carte bancaire 5 PCI-DSS FPE

Ce score de criticité alimentera directement le Score de Résilience UGAIA (composante Data Classification) dans votre framework de gouvernance.

5. Avantages pour UGAIA et la souveraineté numérique

Presidio + Ollama constitue une brique essentielle du pipeline de conformité UGAIA pour plusieurs raisons : aucune donnée ne sort du périmètre maîtrisé (déploiement on-premise Docker), la traçabilité est complète avec hash SHA256 et versionnage des modèles. 

Le LLM n'accède jamais aux données brutes ce qui respecte le principe de minimisation du RGPD, et la solution est auditée et vérifiable par les DPO/RSSI sans dépendance à un fournisseur cloud externe.

C'est exactement le type d'architecture qui permet d'atteindre le niveau SOUVERAIN+ dans le scoring UGAIA (≥80 points), notamment sur les composantes "Traçabilité" et "Classification des données" (N1-N4).

Mon Blog documente une installation réussie avec détection de numéro de téléphone validée. L'étape suivante naturelle serait d'ajouter le modèle spaCy français (fr_core_news_lg) pour améliorer la détection des entités francophones, et d'intégrer des recognizers custom pour les identifiants spécifiques au contexte français (NIR, SIRET, numéros de permis).

Intégration de Grafana et Open WebUI dans l'architecture UGAIA + Presidio

Mon Architecture existante (Ollama + Presidio + Promtail + Loki) est déjà à 73/100 dans le scoring UGAIA. L'intégration correcte de Grafana et Open WebUI, avec les sécurisations nécessaires, vous permet d'atteindre ≥85/100 — niveau SOUVERAIN+, et donc l'éligibilité aux produits d'assurance UGAIA.

La règle fondamentale de cette architecture : Open WebUI est le seul point d'entrée des utilisateurs (port 3000), Grafana est réservé aux administrateurs (port 3001). 

Tous les autres ports (Ollama 11434, Loki 3100, Presidio 5001/5002) restent strictement internes au réseau Docker.

1. Architecture cible — Vue d'ensemble.

Contenu du schéma ci-dessus :

  • Zones colorées :

    • 🔴 Internet (Utilisateurs – HTTPS 443)

    • 🟠 DMZ (Reverse Proxy / WAF – TLS)

    • 🔵 Zone interne Docker ai_network

      • Open WebUI

      • Presidio (anonymisation PII)

      • Ollama (modèles locaux)

      • Promtail

      • Loki

    • 🟢 Zone Administration (Grafana – VPN)

  • Flux réseau principaux (443 / 3000 / Admin)

  • Cartouche RSSI :

    • Segmentation réseau

    • Zero Trust

    • Privacy by Design

    • Modèles non exposés

    • Journalisation souveraine

La règle fondamentale de cette architecture : 

Open WebUI est le seul point d'entrée des utilisateurs (port 3000), Grafana est réservé aux administrateurs (port 3001). Tous les autres ports (Ollama 11434, Loki 3100, Presidio 5001/5002) restent strictement internes au réseau Docker.

2. docker-compose.yml complet et sécurisé.

version: '3.8'

networks:
  ai_network:
    driver: bridge
    internal: false  # Permet l'accès internet pour les mises à jour
    ipam:
      config:
        - subnet: 172.20.0.0/16

volumes:
  ollama_data:
  loki_data:
    driver: local
    driver_opts:
      type: none
      device: /data/loki  # Monter sur un volume chiffré LUKS
      o: bind
  open_webui_data:
  grafana_data:
  presidio_data:

services:

  # ─── COUCHE L1 : INTERFACE UTILISATEUR ─────────────────────────────

  open-webui:
    image: ghcr.io/open-webui/open-webui:main
    container_name: open-webui
    networks: [ai_network]
    ports:
      - "3000:8080"     # SEUL port exposé aux utilisateurs
    environment:
      - OLLAMA_BASE_URL=http://ollama:11434
      - WEBUI_AUTH=true               # Authentification obligatoire
      - WEBUI_SECRET_KEY=${SECRET_KEY} # À définir dans .env
      - DEFAULT_USER_ROLE=user         # RBAC : rôle minimal par défaut
      - ENABLE_SIGNUP=false            # Désactiver l'auto-inscription
      - WEBUI_NAME=UGAIA IA Souveraine
      # Intégration Presidio via pipeline
      - PRESIDIO_ANALYZER_URL=http://presidio-analyzer:3000
    volumes:
      - open_webui_data:/app/backend/data
    depends_on:
      ollama:
        condition: service_healthy
      presidio-analyzer:
        condition: service_started
    healthcheck:
      test: ["CMD", "curl", "-f", "http://localhost:8080/health"]
      interval: 30s
      timeout: 10s
      retries: 3
    restart: unless-stopped

  # ─── COUCHE L2 : INFÉRENCE SOUVERAINE ──────────────────────────────

  ollama:
    image: ollama/ollama:latest
    container_name: ollama
    networks: [ai_network]
    # CRITIQUE : PAS de port exposé vers l'hôte
    volumes:
      - ollama_data:/root/.ollama
    environment:
      - OLLAMA_KEEP_ALIVE=24h
      - OLLAMA_NUM_PARALLEL=2
    healthcheck:
      test: ["CMD", "curl", "-f", "http://localhost:11434/api/tags"]
      interval: 30s
      timeout: 10s
      retries: 5
    restart: unless-stopped

  # ─── COUCHE L3 : ANONYMISATION PII (Presidio) ───────────────────────

  presidio-analyzer:
    image: mcr.microsoft.com/presidio-analyzer:latest
    container_name: presidio-analyzer
    networks: [ai_network]
    # PAS de port exposé — uniquement accessible depuis Open WebUI
    restart: unless-stopped

  presidio-anonymizer:
    image: mcr.microsoft.com/presidio-anonymizer:latest
    container_name: presidio-anonymizer
    networks: [ai_network]
    restart: unless-stopped

  # ─── COUCHE L4 : COLLECTE LOGS + PII SCRUBBING ─────────────────────

  promtail:
    image: grafana/promtail:latest
    container_name: promtail
    networks: [ai_network]
    volumes:
      - /var/log:/var/log:ro
      - /var/lib/docker/containers:/docker:ro
      - ./config/promtail-config.yaml:/etc/promtail/config.yaml:ro
    depends_on: [loki]
    restart: unless-stopped

  loki:
    image: grafana/loki:latest
    container_name: loki
    networks: [ai_network]
    # CRITIQUE : PAS de port 3100 exposé vers l'hôte
    volumes:
      - loki_data:/loki
      - ./config/loki-config.yaml:/etc/loki/local-config.yaml:ro
    healthcheck:
      test: ["CMD", "wget", "-q", "--spider", "http://localhost:3100/ready"]
      interval: 30s
      timeout: 10s
      retries: 5
    restart: unless-stopped

  # ─── COUCHE L5 : MONITORING & DASHBOARD UGAIA ──────────────────────

  grafana:
    image: grafana/grafana:latest
    container_name: grafana
    networks: [ai_network]
    ports:
      - "3001:3000"     # Accès ADMIN uniquement — restreindre par IP si possible
    environment:
      - GF_SECURITY_ADMIN_PASSWORD=${GRAFANA_ADMIN_PASSWORD}
      - GF_SECURITY_DISABLE_GRAVATAR=true
      - GF_ANALYTICS_REPORTING_ENABLED=false  # Pas de telemetrie externe
      - GF_ANALYTICS_CHECK_FOR_UPDATES=false
      - GF_SERVER_DOMAIN=localhost
      - GF_AUTH_ANONYMOUS_ENABLED=false
      - GF_USERS_ALLOW_SIGN_UP=false
    volumes:
      - grafana_data:/var/lib/grafana
      - ./config/grafana/dashboards:/etc/grafana/provisioning/dashboards:ro
      - ./config/grafana/datasources:/etc/grafana/provisioning/datasources:ro
    depends_on:
      loki:
        condition: service_healthy
    restart: unless-stopped

3. Configuration Promtail avec PII Scrubbing (RGPD Art. 25).

C'est la pièce maîtresse de conformité. Sans ce filtre, des données personnelles transitent vers Loki en clair. Fichier config/promtail-config.yaml :

server:
  http_listen_port: 9080
  grpc_listen_port: 0

positions:
  filename: /tmp/positions.yaml

clients:
  - url: http://loki:3100/loki/api/v1/push

scrape_configs:
  - job_name: ollama-containers
    docker_sd_configs:
      - host: unix:///var/run/docker.sock
        refresh_interval: 5s
    relabel_configs:
      - source_labels: [__meta_docker_container_name]
        target_label: container
      - source_labels: [__meta_docker_container_image]
        target_label: image

    # ─── PIPELINE PII SCRUBBING ────────────────────────────────────
    pipeline_stages:
      # 1. Parser les logs JSON d'Ollama
      - json:
          expressions:
            prompt: prompt
            model: model
            duration: total_duration

      # 2. Masquer emails
      - replace:
          expression: '([a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+\.[a-zA-Z]{2,})'
          replace: '[EMAIL_REDACTED]'

      # 3. Masquer numéros de téléphone français
      - replace:
          expression: '(\+33|0)[1-9]([0-9]{8})'
          replace: '[PHONE_REDACTED]'

      # 4. Masquer IBAN
      - replace:
          expression: '[A-Z]{2}[0-9]{2}[A-Z0-9]{4}[0-9]{7}([A-Z0-9]?){0,16}'
          replace: '[IBAN_REDACTED]'

      # 5. Masquer NIR (numéro sécurité sociale)
      - replace:
          expression: '[12][0-9]{2}(0[1-9]|1[0-2])[0-9]{8}[0-9]{2}'
          replace: '[NIR_REDACTED]'

      # 6. Labels pour requêtes LogQL dans Grafana
      - labels:
          model:
          container:

      # 7. Timestamp
      - timestamp:
          source: time
          format: RFC3339Nano

4. Configuration Loki avec rétention RGPD.

Fichier config/loki-config.yaml :

auth_enabled: false

server:
  http_listen_port: 3100

ingester:
  lifecycler:
    ring:
      kvstore:
        store: inmemory
      replication_factor: 1

schema_config:
  configs:
    - from: 2024-01-01
      store: boltdb-shipper
      object_store: filesystem
      schema: v11
      index:
        prefix: index_
        period: 24h

storage_config:
  boltdb_shipper:
    active_index_directory: /loki/boltdb-shipper-active
    cache_location: /loki/boltdb-shipper-cache
    shared_store: filesystem
  filesystem:
    directory: /loki/chunks

# ─── RÉTENTION RGPD Art. 5e ─────────────────────────────────────────
limits_config:
  retention_period: 720h    # 30 jours maximum (adapter selon politique DPO)
  ingestion_rate_mb: 4
  max_query_series: 500

compactor:
  working_directory: /loki/compactor
  shared_store: filesystem
  retention_enabled: true   # Active la suppression automatique
  retention_delete_delay: 2h
  retention_delete_worker_count: 150

5. Datasource Grafana → Loki (auto-provisioning).

Fichier config/grafana/datasources/loki.yaml :

apiVersion: 1
datasources:
  - name: Loki
    type: loki
    access: proxy
    url: http://loki:3100
    isDefault: true
    jsonData:
      maxLines: 1000
      timeout: 60

6. Dashboard Grafana — 5 panneaux UGAIA essentiels.

Voici les requêtes LogQL à construire pour votre tableau de bord UGAIA Score en temps réel.

Panneau 1 — Volume de requêtes IA par heure

sum by (model) (
  rate({container="ollama"}[1h])
)

Indicateur de charge et d'utilisation par modèle (Phi-4 vs Mistral).

Panneau 2 — Détections PII par Presidio (taux de conformité)

sum(
  count_over_time({container="presidio-analyzer"} |= "entity_type" [1h])
) by (entity_type)

Affiche le volume et les types d'entités détectées : PERSON, EMAIL, PHONE, IBAN, NIR. Alerte si le volume dépasse un seuil (ex. >100 détections/heure = risque de fuite de données structurelle).

Panneau 3 — Latence P95 des inférences Ollama

quantile_over_time(0.95,
  {container="ollama"} | json | unwrap total_duration [5m]
) by (model)

SLA de performance : alerte si P95 > 10 secondes.

Panneau 4 — Tentatives de prompt injection détectées

count_over_time(
  {container="open-webui"} |= "injection" or |= "jailbreak" or |= "ignore previous" [1h]
)

Indicateur de sécurité critique pour le scoring UGAIA (composante "Protection contre les attaques adversariales").

Panneau 5 — Score de Résilience UGAIA (jauge 0-100)

Ce panneau central agrège les métriques en un score composite. Il se construit via un panneau de type "Stat" avec une expression qui calcule :

  • Loki actif et ingérant : +15 pts
  • Promtail PII scrubbing actif : +20 pts
  • Presidio détections > 0 (preuve d'utilisation) : +15 pts
  • Latence P95 < 10s : +10 pts
  • Zéro erreur d'authentification Open WebUI : +10 pts
  • Rétention Loki configurée ≤30j : +10 pts
  • Alertes actives configurées : +10 pts
  • Aucun port sensible exposé (Ollama/Loki) : +10 pts

7. Sécurisation Open WebUI — Configuration avancée.

Open WebUI joue un rôle clé au-delà d'une simple interface : c'est le point d'application de la politique de gouvernance pour les utilisateurs finaux.

Configuration du System Prompt de gouvernance (à définir dans Open WebUI > Settings > Models) :

Tu es un assistant IA souverain déployé par [Organisation] dans le cadre 
du dispositif UGAIA. Tu opères dans un environnement conforme RGPD.

RÈGLES ABSOLUES :
- Ne jamais demander ni stocker de données personnelles (NIR, IBAN, données médicales).
- Ne jamais transmettre d'informations vers des systèmes externes.
- Si l'utilisateur semble partager des PII, l'informer que ces données 
  sont automatiquement anonymisées avant traitement.
- Toutes tes réponses sont journalisées à des fins d'audit UGAIA.

Classification des données autorisées : N1 (public) et N2 (interne).
Pour les données N3/N4, contacter le DPO.

Pop-up de consentement au premier login : configurer via Open WebUI > Admin > Banners un message imposant l'acceptation de la charte d'usage UGAIA avant accès. Cela constitue une preuve de consentement exploitable en audit.

RBAC recommandé dans Open WebUI :

Rôle Permissions Modèles accessibles
user Chat uniquement Phi-4, Mistral (données N1/N2)
power_user RAG + fichiers + modèles spécialisés
admin Gestion complète Tous les modèles
auditor (lecture seule) Historique conversations Aucun

8. Alertes Grafana — 3 alertes critiques UGAIA.

Alerte 1 — PII non scrubées détectées dans Loki

# Si des emails passent le scrubbing → défaillance critique
count_over_time(
  {container="loki"} |~ "[a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+\\.[a-zA-Z]{2,}" [5m]
) > 0

Sévérité : CRITIQUE — notification immédiate DPO + RSSI.

Alerte 2 — Ollama injoignable depuis Open WebUI

absent(rate({container="ollama"}[5m])) == 1

Sévérité : HAUTE — indisponibilité de service.

Alerte 3 — Volume anormal de détections PII

sum(count_over_time({container="presidio-analyzer"} [1h])) > 500

Sévérité : MOYENNE — possible tentative de fuite de données massives.

9. Impact sur le Score UGAIA.

Composant Score avant Score après intégration complète
Open WebUI (RBAC + SSO + System Prompt) 14/20 18/20
Grafana (Dashboard UGAIA + alertes) 13/20 18/20
Promtail (PII scrubbing actif) 12/20 17/20
Loki (rétention RGPD configurée) 15/20 17/20
Ollama (métriques exposées) 16/20 17/20
Docker (réseau isolé) 13/20 16/20
SCORE TOTAL 73/100 ≥ 85/100 ✅ SOUVERAIN+

10. Plan d'implémentation en 3 sprints.

Sprint 1 (Semaine 1-2) — Fondation sécurisée
Déployer le docker-compose.yml avec réseau isolé + activer PII scrubbing Promtail + configurer la rétention Loki 30j + activer RBAC Open WebUI. Gain : +12 pts → 85/100.

Sprint 2 (Semaine 3-4) — Dashboard et alertes
Construire les 5 panneaux Grafana UGAIA Score + configurer les 3 alertes critiques + ajouter le System Prompt de gouvernance Open WebUI + bannière consentement. Gain : observabilité complète, preuve d'audit ≤48h.

Sprint 3 (Semaine 5-6) — Corrélation et traçabilité EU AI Act
Intégrer Langfuse avec mlflow_run_id comme clé pivot + relier les traces Langfuse au dashboard Grafana + documenter la procédure Droit à l'effacement (Loki Delete API) pour le DPO. Gain : conformité EU AI Act Art. 12 complète.

Le résultat est une architecture où chaque interaction utilisateur via Open WebUI génère une trace complète et auditée dans Grafana, sans qu'aucune donnée personnelle ne soit exposée dans les logs, tout en maintenant une souveraineté totale sur l'ensemble de la pile.

Read more »
Posted by at Aucun commentaire:
Labels: , , , , ,

samedi 28 février 2026

Microsoft Presidio est le framework open source de référence pour la détection et l'anonymisation

Presidio Python la référence open source.

1. Microsoft Presidio — Anonymisation PII

🌐 URL Home - Microsoft Presidio https://microsoft.github.io/presidio/

🏢 Éditeur Microsoft Corporation (Industry Solutions Engineering)

📄 Licence Open Source (MIT) — Auto-hébergement gratuit

📅 Depuis 2019

Description :

Microsoft Presidio est le framework open source de référence pour la détection et l'anonymisation des données personnelles (PII) dans les textes libres. Il utilise la bibliothèque NLP spaCy pour la reconnaissance d'entités nommées, combinée à des reconnaisseurs par expressions régulières et à des analyseurs de contexte. Presidio supporte nativement le français et peut être étendu avec des reconnaisseurs personnalisés pour des formats métier spécifiques (numéros de contrats, identifiants internes). https://microsoft.github.io/presidio/installation/#install-from-source

Cas d'usage UGAIA :

Filtre obligatoire en amont de tous les flux N3/N4 dans l'architecture UGAIA. Anonymisation avant envoi au modèle Ollama/Phi-4. Preuve de minimisation des données (Art. 5 RGPD). Support natif du français avec le modèle fr_core_news_lg de spaCy.

Presidio Demo - a Hugging Face Space by presidio YouTube https://youtu.be/RPJ3-kEUybU

  

llm-semantic-router/pii_classifier_modernbert-base_presidio_token_model · Hugging Face

https://huggingface.co/llm-semantic-router/pii_classifier_modernbert-base_presidio_token_model


2. rs-presidio — L'implémentation Rust haute performance

🔧 rs-presidio — Anonymisation PII en Rust

🌐 URL https://github.com/posidron/rs-presidio

🏢 Éditeur Communauté open source (projet non officiel Microsoft)

📄 Licence Open Source (MIT) — Projet communautaire

📅 Depuis 2024 (projet jeune)

Description :

rs-presidio est une implémentation complète et non officielle de Microsoft Presidio, développée en Rust par la communauté. Elle reproduit l'intégralité des fonctionnalités de la version Python (presidio-analyzer, presidio-anonymizer, presidio-structured, presidio-image-redactor) tout en tirant parti des garanties de sécurité mémoire et de performance du langage Rust. Les benchmarks montrent des performances 10 à 100 fois supérieures à la version Python pour le filtrage par expressions régulières (latence : 1 ms en mode regex pur, 50 ms avec NLP ONNX).

Cas d'usage UGAIA :

Déploiement en Couche 1 (infrastructure) pour les organisations traitant de gros volumes. Latence minimisée pour les pipelines temps réel de niveau N3/N4. Option ONNX avec modèles spaCy/Stanza pour une précision NLP équivalente à Python. Journalisation des décisions de détection pour les dossiers d'audit CNIL.


3. Le tableau suivant compare les deux implémentations de Presidio.

Ce tableau est essentiel pour les architectes qui doivent choisir entre les garanties de maturité de la version Python et les performances de la version Rust.

https://microsoft.github.io/presidio/api-docs/api-docs.html

 




Recommandation UGAIA :

La version Python reste la référence pour la majorité des déploiements. rs-presidio est recommandé uniquement pour les organisations traitant plus de 1 000 requêtes par seconde ou nécessitant une latence inférieure à 10 ms. Dans tous les cas, des tests de non-régression approfondis sont indispensables avant tout déploiement en production de rs-presidio.

Figure Architecture IA Souveraine FAST-TRACK PRESIDIO.

Dans le cadre de l'architecture souveraine, Presidio est l'outil open source essentiel pour respecter la "règle des 48 heures", qui stipule que tout dossier d'audit doit pouvoir être généré automatiquement dans ce délai pour un régulateur (CNIL) ou un assureur.

4.  Comment Presidio contribue concrètement à la gouvernance souveraine des données

1.  Application du principe « Audit-by-Design »

Presidio intègre la traçabilité dès la conception en appliquant la règle d’or de l’audit : séparer la donnée brute (le risque) de la trace d’exécution (la preuve). En anonymisant les données personnelles (PII) avant leur stockage, il garantit qu’aucune donnée nominative ne réside dans les journaux d’audit. Les logs sont ainsi immédiatement exploitables sans nécessiter de retraitement manuel ultérieur.

2.  Automatisation de la conformité pour les niveaux N3/N4

Pour les données sensibles (RH, santé, finance), le déploiement de Presidio est considéré comme obligatoire avant toute mise en conformité.

Sans Presidio : une demande de la CNIL imposerait de nettoyer manuellement des milliers de lignes de journaux pour éviter tout transfert de données personnelles, rendant le respect du délai de 48 heures impossible.

Avec Presidio : les mécanismes d’anonymisation sont vérifiés et effectifs avant tout envoi au modèle. Les traces d’exécution (prompt anonymisé, version du modèle, réponse) sont « audit-ready » dès leur création.

3.  Preuve technique d’intégrité

Presidio s’intègre dans la phase de structuration (J+30 à J+120) aux côtés d’outils comme Langfuse et MLflow. En filtrant les flux capturés par le collecteur central (OpenTelemetry), il permet de corréler chaque interaction à un identifiant unique (mlflow_run_id). Cette corrélation constitue la preuve technique d’intégrité qu’auditeurs et assureurs exigent pour valider la maîtrise du risque et le score de résilience.

4.  Facilitation de l’assurabilité

Un système dont le score de résilience est inférieur à 50/100 est jugé non-assurable. Presidio contribue à atteindre et à maintenir un score cible compris entre 75 et 80/100, niveau exigé par les assureurs cyber à compter de 2026. Sa capacité à fournir instantanément des rapports prouvant l’absence de fuite de données — grâce à des journaux propres et anonymisés — constitue un argument décisif pour l’obtention d’un contrat d’assurance cyber.

En résumé :

Presidio agit comme un filtre automatisé qui transforme un flux de données à risque en une piste d’audit conforme et sécurisée, rendant la génération du rapport d’incident ou de conformité quasi instantanée.


5.  Fiche de procédure : anonymisation PII (niveaux N3/N4)

Cette fiche décrit en cinq étapes la mise en œuvre de l’anonymisation des données de niveaux N3 et N4 au sein de votre architecture IA souveraine, conformément au principe d’Audit-by-Design : séparer la donnée brute (le risque) de la trace d’exécution (la preuve).

1.  Objectif et périmètre

Objectif : garantir qu’aucune donnée nominative ou sensible ne réside dans les journaux d’audit (ELK/Langfuse), tout en assurant une traçabilité complète des interactions.

Classification visée :

•       N3 (Sensible) : données RH, contrats clients, bilans comptables.

•       N4 (Très Sensible) : données de santé, infrastructures critiques, données classifiées.

Outil de référence : Presidio ou rs-presidio (0 € de licence).

 

Note sur rs-presidio :

implémentation communautaire de Presidio en langage Rust, offrant de meilleures performances pour les environnements à forte volumétrie ou sans dépendance Python. En raison de sa relative jeunesse (< 1 an), un fallback vers la version Python officielle est recommandé avant tout déploiement en production sur des données N3/N4.

2.  Déploiement stratégique (Phase 2 : J+30 à J+120)

L’anonymisation intervient lors de la phase de structuration de l’architecture d’audit.

•       Étape 1 : installer Presidio comme middleware entre l’interface utilisateur (Open WebUI) et la passerelle (LiteLLM).

•       Étape 2 : configurer le collecteur OpenTelemetry pour centraliser les flux et assurer la corrélation par mlflow_run_id.

3.  Configuration technique de l’anonymiseur

Pour les données N3/N4, la configuration doit être stricte :

•       Analyseur PII : activer la détection automatique des entités (noms, adresses e-mail, numéros de sécurité sociale, coordonnées bancaires).

•       Mécanisme de masquage : privilégier le remplacement par des balises (ex. : <NOM_PERSONNE>) ou le hachage cryptographique, afin de conserver la structure du texte sans exposer la donnée brute.

Règle d’or :

aucune donnée nominative ne doit figurer dans les journaux d’audit.

4.  Workflow opérationnel (Zero Trust IA)

Enchaînement des traitements :

Utilisateur

    ↓  (prompt brut)

Open WebUI

    ↓

[ Presidio — Anonymisation PII ]

    ↓

LiteLLM / Ollama  (inférence — prompt anonymisé)

    ↓  (corrélation mlflow_run_id)

OpenTelemetry

    ↓

ELK  (journaux anonymisés — preuves forensiques)

    ↓

Audit CNIL / Assurance

Tableau 1 Workflow opérationnel Zero Trust IA

5.  Contrôle et validation (Audit-Ready)

•       Test de la règle des 48 heures : vérifier que le dossier d’audit généré automatiquement à destination de la CNIL ou de l’assureur ne contient aucune donnée brute de niveau N3/N4.

•       Score de résilience : le déploiement effectif de Presidio est une condition nécessaire pour atteindre un score UGAIA ≥ 75/100 (seuil d’assurabilité) et ≥ 80/100 (statut SOUVERAIN+).

•       Audit trimestriel : réaliser des tests de type « Red Team » (via Garak ou PyRIT) pour vérifier que le filtre d’anonymisation ne peut pas être contourné par des injections de prompts.

 

Résultat attendu : une conformité proactive à l’AI Act et au RGPD, garantissant une traçabilité totale tout en neutralisant le risque de fuite de données personnelles dès la conception.

 

6.  Impact de Presidio sur le score de résilience UGAIA

L’intégration de Presidio agit directement sur cinq leviers du score de résilience. Le tableau ci-dessous en présente la synthèse :


Cette infographie complète dédiée aux fonctions et avantages de Presidio pour la gouvernance de l'IA dans votre entreprise.


Cette représentation met en avant les piliers stratégiques identifiés dans les sources :

  • Fonctions Clés : L'anonymisation des données personnelles (PII), la mise en œuvre du principe d'Audit-by-Design (séparation du risque et de la preuve) et son rôle de middleware dans une architecture Zero Trust IA.

  • Protection et Sécurité : La sécurisation des flux de données de niveaux N3 et N4 (données sensibles à très sensibles) avant leur traitement par les modèles.

  • Avantages pour l'Audit : Sa contribution cruciale au respect de la "règle des 48 heures" pour la génération de rapports de conformité CNIL ou assureur.

 

  • Gouvernance de l'IA : Son impact direct sur le score de résilience UGAIA (cible ≥ 75/100) pour garantir l'assurabilité de vos systèmes, le tout avec un coût de licence de 0 €.

 


 open-webui/open-webui: User-friendly AI Interface (Supports Ollama, OpenAI API, ...)

microsoft/presidio-research: This package features data-science related tasks for developing new recognizers for Presidio. It is used for the evaluation of the entire system, as well as for evaluating specific PII recognizers or PII detection models.

 Install from source

To install Presidio from source, first clone the repo:

  • using HTTPS

git clone https://github.com/microsoft/presidio.git

  • Using SSH

git clone git@github.com:microsoft/presidio.git

Then, build the containers locally.

Note

Presidio uses docker-compose to manage the different Presidio containers.

From the root folder of the repo:

docker-compose up --build

Alternatively, you can build and run individual services. For example, for the presidio-anonymizer service:

docker build ./presidio-anonymizer -t presidio/presidio-anonymizer

And run:

docker run -d -p 5001:5001 presidio/presidio-anonymizer

For more information on developing locally, refer to the setting up a development environment section.

7. Installation - Microsoft Presidio

https://microsoft.github.io/presidio/installation/#using-docker

Ce paquet propose des tâches liées à la data science pour développer de nouveaux reconnaisseurs pour Presidio. Il est utilisé pour l’évaluation de l’ensemble du système, ainsi que pour évaluer des reconnaisseurs spécifiques de PII ou de modèles de détection de PII.

Je lance des tests dans Docker :  

Ce sera l'objet de mon prochain article.
Application → Presidio (mask PII) → OpenTelemetry Collector → Loki/Tempo → Grafana


8. Apprendre Presidio

Presidio est une suite d’outils permettant de détecter et de dé-identifier les informations personnelles dans le texte, les images et les données structurées.

Le point de départ recommandé est de suivre le tutoriel qui vous guidera dans le processus de configuration et d’utilisation de Presidio. Pour en savoir plus sur les différents concepts de Presidio, consultez la page des concepts.

  • Pour approfondir chaque composant, consultez la documentation correspondante 
  • Pour l’analyseur Presidio, consultez la documentation de l’analyseur.
  • Pour Presidio Anonymizer, consultez la documentation Anonymizer.
  • Pour le Presidio Image Redactor, consultez la documentation Image Redactor.
  • Pour la structure Presidio, consultez la documentation Structurée.
  • Les diagrammes suivants offrent une compréhension générale des composants du Presidio 

 Analyzer

Anonymizer

Image Redactor

Standard Image Types

DICOM Images



Made with Material for MkDocs

https://microsoft.github.io/presidio/recipes/

Site web de démonstration simple pour Presidio

Voici une application simple, écrite en Python pur, pour créer un site de démonstration pour Presidio. L’application est basée sur le package Streamlit.

Une version live est disponible ici : https://huggingface.co/spaces/presidio/presidio_demo

Exigences

  1. Clonez le dépôt et déplacez-le dans le dossierdocs/samples/python/streamlit

  2. Installer des dépendances (de préférence dans un environnement virtuel)

https://microsoft.github.io/presidio/samples/python/streamlit/

 


9. Galerie de recettes

Home - Microsoft Presidio https://microsoft.github.io/presidio/recipes/

Bienvenue dans la galerie de recettes du Presidio !

Cette section propose des exemples soigneusement sélectionnés, de bout en bout, montrant comment personnaliser Microsoft Presidio pour des scénarios spécifiques de confidentialité des données et de désidentification.

Qu’est-ce que les recettes ?

Les recettes sont des exemples complets et reproductibles, adaptés aux domaines de données et cas d’usage courants. Chaque recette va au-delà de la documentation de base pour fournir :

  1. Contexte concret : Axé sur des scénarios spécifiques comme des conversations avec des chatbots financiers, des notes cliniques, des journaux de l’API REST ou du contenu multilingue

  2. Génération de données synthétiques : méthodes pour créer des données de test réalistes qui imitent votre environnement de production

  3. Benchmarks de performance : métriques d’évaluation (précision, rappel, score F₂ et latence) entre différentes configurations de Presidio

  4. Complexité progressive : Exemples allant de l’utilisation prête à l’emploi à la personnalisation avancée avec transformateurs, LLM ou approches hybrides

Pourquoi utiliser des recettes ?

Bien que la documentation de Presidio couvre les fondamentaux, les recettes font le lien entre les exemples génériques et les implémentations prêtes à la production. Ils vous aident à :

  • Évaluer la performance : Comprendre la précision et la rapidité de Presidio pour votre domaine spécifique avant le déploiement

  • Personnaliser efficacement : Apprenez quels reconnaisseurs, modèles et configurations fonctionnent le mieux pour différents types de données

  • Comparez les approches : Voir des comparaisons côte à côte de différentes stratégies de mise en œuvre

  • Réduisez le temps de développement : commencez par un exemple fonctionnel proche de votre cas d’usage au lieu de construire à partir de zéro

Structure de la recette

Chaque recette comprend généralement :

  • Description du scénario : Le domaine et le type de données

  • Synthèse des données : Méthodes pour générer des données de test en utilisant Presidio Evaluator ou des méthodes personnalisées

  • Configuration : Configuration Presidio avec tout type de reconnaissance ou modèle personnalisé

  • Évaluation : Indicateurs de performance (précision, rappel, score F₂, latence)

  • Implémentation : notebook Jupyter ou scripts Python montrant le flux de bout en bout (voir exemple)

  • Constats clés : quand utiliser cette approche et compromis à considérer

Pour des flux complexes, envisagez de diviser plusieurs carnets ou scripts pour une meilleure organisation.

Recettes disponibles

Actuellement, la galerie de recettes est en cours de création. Revenez bientôt pour découvrir les recettes couvrant :

  • Domaine financier : conversations de chat, journaux de transactions, interactions avec le service client

  • Domaine des soins de santé : notes cliniques, dossiers patients, rapports médicaux

  • Retail/E-commerce : données clients, informations de commande, tickets de support

  • Enterprise : journaux d’API REST, exportations de bases de données, communications internes

  • Multilingues : exemples pour l’espagnol, le français, l’allemand et d’autres langues

Home - Microsoft Presidio https://microsoft.github.io/presidio/samples/

Tableau de performance des recettes (à venir bientôt)

Nous élaborons un tableau de référence complet qui montrera les performances de Presidio à travers différents domaines et niveaux de mise en œuvre. Le tableau comprendra :

Chaque cellule contiendra : - P = Précision - R = Rappel
- F₂ = score F₂ (score F pondéré par rappel) - Latence = Temps moyen de traitement par échantillon (millisecondes) - Notebook = Lien vers le carnet Jupyter interactif

Comment utiliser une recette

  1. Parcourez les recettes pour en trouver une qui correspond à votre domaine ou à votre cas d’utilisation

  2. Passez en revue le carnet pour comprendre l’approche et les résultats

  3. Faites tourner le carnet dans votre environnement pour reproduire les résultats

  4. Adaptez la configuration à vos données et exigences spécifiques

  5. Évaluez les performances sur votre propre jeu de données de test

  6. Déploie la configuration qui répond le mieux à tes besoins de précision et de performance

Contribuer à une recette

Nous accueillons volontiers les contributions de la communauté ! Consultez nos directives de contribution pour plus de détails.

Exemples de référence : - Évaluer l’analyseur Presidio - Flux de travail complet d’évaluation de bout en bout - Générer des données synthétiques - Générateur de données Presidio Evaluator

Suivez le schéma : Synthèse des données → Configuration → Évaluation

Pour des flux complexes, divisez-vous en plusieurs carnets ou scripts. Concentrez-vous d’abord sur la mise en place du code fonctionnel – nous aiderons à affiner la documentation lors de la révision.

10. Ressources connexes

Des questions ou des retours ?

Si vous avez des questions sur des recettes ou des suggestions de nouveaux scénarios à couvrir, s’il vous plaît :

Note :

La galerie de recettes illustre la flexibilité et les capacités de personnalisation de Presidio. L’objectif est de montrer que Presidio est conçu pour être adapté à vos besoins spécifiques, et non utilisé comme une solution universelle. Chaque recette illustre les meilleures pratiques de personnalisation dans différents contextes.

Recherche sur le presidio

Ce package fournit des capacités d’évaluation et de science des données pour les modèles de détection Presidio et PII en général.

Il inclut également un générateur de données fausses qui crée des phrases synthétiques à partir de modèles et de fausses informations personnelles.

Qui devrait l’utiliser ?

  • Toute personne intéressée par le développement ou l’évaluation de modèles de détection des PII, une instance Presidio existante ou un reconnaisseur Presidio PII.

  • Toute personne intéressée par la génération de nouvelles données basées sur des ensembles de données ou des modèles de phrases précédents (par exemple, pour augmenter la couverture des valeurs des entités) pour les modèles de Reconnaissance d’Entités Nommées ?

Début

Utilisation des carnets

La façon la plus simple de commencer est de revoir les carnets.

  • Carnet 1 : Montre comment utiliser le générateur de données personnelles (PII).

  • Cahier 2 : Montre une analyse simple de l’ensemble de données PII.

  • Notebook 3 : Fournit des outils pour diviser le jeu de données en ensembles train/test/validation tout en évitant les fuites dues à l’apparition du même motif dans plusieurs plis (applicable uniquement aux données générées synthétiquement).

  • Cahier 4 : Montre comment utiliser les outils d’évaluation pour évaluer la capacité de détection des PII par Presidio. Notez que cela utilise le Presidio vanilla, et les résultats ne sont pas très précis.

  • Notebook 5

presidio-research/README.md à master · Microsoft/Presidio-Research

Contributions

Ce projet accueille les contributions et suggestions. La plupart des contributions exigent que vous acceptiez un Accord de licence de contributeur (CLA) déclarant que vous avez le droit de, et que vous l’avez effectivement, nous accorder les droits d’utilisation de votre contribution. Pour plus de détails, rendez-vous sur https://cla.opensource.microsoft.com.

Lorsque vous soumettez une pull request, un bot CLA déterminera automatiquement si vous devez fournir un CLA et décorer la PR de manière appropriée (par exemple, vérification du statut, commentaire). Il suffit de suivre les instructions fourni par le bot. Vous n’aurez à le faire qu’une seule fois sur tous les dépôts en utilisant notre CLA.

Ce projet a adopté le Code de conduite Open Source de Microsoft. Pour plus d’informations, consultez la FAQ sur le Code de conduite ou Contactez opencode@microsoft.com pour toute question ou commentaire supplémentaire.

Avis de droits d’auteur :

Les identités du Fake Name Generator par le Fake Name Generator sont sous licence Creative Commons Attribution-Share Alike 3.0 États-Unis. Fake Name Generator et le logo Fake Name Generator sont des marques déposées de Corban Works, LLC.


semantic-router/README.md at main · vllm-project/semantic-router

https://github.com/vllm-project/semantic-router/blob/main/README.md


Un seul tissu. Beaucoup d’esprits. Nous introduisons MoM (Mixture of Models) — une famille de modèles de routage spécialisés qui alimentent la prise de décision intelligente du vLLM-SR.

Pourquoi MoM ?

vLLM-SR résout un problème critique : comment acheminer les requêtes LLM vers le bon modèle au bon moment. Toutes les requêtes ne nécessitent pas les mêmes ressources — « Quel temps fait-il ? » ne devrait pas coûter autant que « Analyser ce contrat légal ».

llm-semantic-router (vLLM Semantic Router)

https://huggingface.co/llm-semantic-router


Mon prochain article sur son installation dans Docker 


Presidio sur Docker 

---

Erol GIRAUDY

Mes 2 derniers livres : 

 Chez AMAZON mon 15ème livre sur la dictature de l’IA : 

https://amzn.eu/d/04kdxfV6

Chez AMAZON mon livre sur la gouvernance et audit de l’IA : 

  https://amzn.eu/d/065lTcaL 

 et mes 13 livres A la BNF : 13 livres Bibliothèque nationale de France

Recherche simple "Giraudy Erol" : liste de notices | BnF Catalogue général







Posted by at Aucun commentaire:
Labels: , , , , , , ,
Inscription à : Articles (Atom)