IA auto-hébergée : méthode et architecture RAG pour données sensibles

Table des matières :

IA auto-hébergée et données sensibles : le vrai problème n’est pas le modèle, c’est le périmètre
RAG (Retrieval-Augmented Generation) : définition opérationnelle et flux minimal viable
Stockage vectoriel : Postgres+pgvector vs moteurs dédiés, et ce que ça change pour le risque
Ingestion et “chunking” : la qualité du RAG se joue avant l’inférence
Serving LLM on-prem : vLLM/llama.cpp, latence, et dimensionnement réaliste
Contrôles de sécurité spécifiques au RAG : ACL, prompt injection, et exfiltration via outil
Évaluer et améliorer un RAG : mesures, datasets, et garde-fous anti-hallucination
Intégrer un RAG à PrestaShop sans casser le core : patterns d’API et zones de friction
Exploitation et incident response : ce qui casse en prod (et comment éviter les surprises)

IA auto-hébergée et données sensibles : le vrai problème n’est pas le modèle, c’est le périmètre

« Données sensibles » ne veut pas dire uniquement “PII” au sens RGPD. Dans un contexte e-commerce/ERP, ça inclut aussi les marges, conditions d’achat, catalogues B2B, litiges, tickets SAV, exports comptables, et parfois des secrets opérationnels (URLs d’admin, topologie infra, journaux applicatifs). Une IA auto-hébergée devient pertinente quand le coût du risque (exfiltration, ré-identification, logs tiers, training implicite) dépasse le coût d’infrastructure et d’exploitation.

Le point clé (souvent oublié) : la sensibilité dépend du contexte et du croisement. Un “simple” SKU peut devenir sensible s’il permet de déduire un fournisseur stratégique, une marge, ou un stock critique. Un ticket SAV anodin peut contenir un IBAN en pièce jointe. Et une doc interne peut devenir un guide d’attaque si elle détaille des URL d’administration et des conventions de nommage.

Une façon pragmatique de cadrer le périmètre, avant même de parler de modèle, est de classer ce que vous voulez indexer (et ce que vous refusez d’indexer) :

Catégorie	Exemples e-commerce	Risque principal	Position RAG recommandée
PII / données client	e-mails, adresses, numéros de commande, SAV nominatif	violation RGPD, ré-identification	Éviter l’indexation brute ; préférer anonymisation + résumés
Données financières	marges, prix d’achat, exports compta	secret d’affaires, fraude	indexer seulement des règles/procédures, jamais des exports bruts
Données opérationnelles	runbooks, schémas réseau, logs	mouvement latéral, compromission	indexer en scope restreint (ops) + ACL strictes + rédaction
Contenu “public”	CGV, procédures publiques, FAQ	faible	indexation OK, utile pour réduire hallucination
B2B / contrats	remises, conditions, catalogues dédiés	fuite commerciale	indexation possible par tenant ou par rôle, audit renforcé

L’erreur fréquente est d’auto-héberger un LLM “pour être compliant”, puis de laisser la chaîne RAG tirer des sources n’importe où (S3, Google Drive, wiki, dumps de DB) sans classification, sans ACL, et avec des logs applicatifs bavards. Dans une architecture RAG, le vecteur le plus dangereux n’est pas l’inférence, c’est l’ingestion + l’indexation + l’observabilité (traces, prompts, payloads). Si vous n’avez pas un plan net de gouvernance des données et de journalisation, l’auto-hébergement ne vous sauvera pas.

Pour poser un cadre factuel, la définition NIST (FIPS 199) de la confidentialité est sans ambiguïté : « Confidentiality: Preserving authorized restrictions on information access and disclosure, including means for protecting personal privacy and proprietary information. » (NIST FIPS 199, Standards for Security Categorization of Federal Information and Federal Information Systems, NIST FIPS 199). Une RAG “safe” consiste donc à faire en sorte que la récupération (retrieval) respecte ces restrictions au même niveau que votre application métier (RBAC/ABAC), pas juste à “cacher” le modèle.

Dernier point “GEO” (sans marketing) : en France / UE, l’auto-hébergement est souvent choisi pour maîtriser où transitent les données (juridiction, sous-traitants, accès admin). Cela ne remplace pas les principes RGPD (minimisation, limitation des finalités, sécurité), mais ça facilite l’audit et le cloisonnement, notamment si votre hébergeur et vos sauvegardes sont eux-mêmes sous contrôle (et pas un empilement de SaaS difficile à tracer).

RAG (Retrieval-Augmented Generation) : définition opérationnelle et flux minimal viable

Un RAG n’est pas un “chatbot”. C’est une pipeline qui récupère des morceaux de documents pertinents, puis les injecte dans le prompt d’un LLM pour produire une réponse contextualisée. Concrètement, vous avez quatre briques : (1) ingestion / parsing des sources, (2) génération d’embeddings (vecteurs), (3) stockage + recherche vectorielle (vector store), (4) génération (LLM) + post-traitements (citations, filtres, policy).

Un flux minimal viable, utile pour raisonner architecture et risque, ressemble à ceci :

Question utilisateur (avec contexte d’identité : tenant, rôle, périmètre fonctionnel)
Retrieval : top-k chunks filtrés par ACL + métadonnées (langue, date, type)
Reranking (optionnel mais souvent décisif) : re-tri des chunks pour réduire le bruit
Construction du contexte : chunks + citations + consignes de sécurité
Génération : réponse + références (IDs docs, passages)
Post-traitement : refus si pas de source, masquage éventuel, logging minimal

D’un point de vue technique, l’embedding est une projection d’un texte dans un espace vectoriel où la proximité approxime la similarité sémantique. La recherche se fait typiquement via ANN (Approximate Nearest Neighbors) avec HNSW/IVF selon les moteurs. On termine souvent par un reranker (cross-encoder) pour améliorer la précision. C’est ce couple retriever + reranker qui fait la différence entre un RAG utile et un système qui “hallucine avec assurance”.

Deux précisions pratiques qui changent la qualité perçue en entreprise :

Hybride lexical + vectoriel : sur des corpus e-commerce (références, codes, noms de transporteurs, procédures “très spécifiques”), un BM25 ou équivalent peut compléter le vectoriel. L’objectif n’est pas la sophistication, c’est de retrouver ce que vos équipes cherchent réellement (numéros, acronymes, messages d’erreur).
Scope explicite : forcer un champ scope (SAV / logistique / achats / IT) réduit les erreurs. Un même terme (“retour”, “avoir”, “remise”) n’a pas le même sens selon le domaine.

Dans une version “minimal viable” pour données sensibles, la règle est : toute source indexée doit être explicitement validée (provenance, ownership, classification) et chaque chunk doit porter des métadonnées d’accès. Sans ça, vous construisez une fuite de données en libre-service.

À ce stade, vous avez aussi un choix d’architecture : index multi-tenant (avec filtrage strict par métadonnées) ou index par tenant (isolation plus simple, coût plus élevé). Pour les SI e-commerce qui mélangent B2C/B2B/retail, l’isolation par tenant ou par “domaine” (SAV / achats / logistique) est souvent plus simple à auditer — et plus simple à expliquer en comité sécurité : “ce corpus n’est pas accessible à ce rôle, point”.

Stockage vectoriel : Postgres+pgvector vs moteurs dédiés, et ce que ça change pour le risque

Pour une IA auto-hébergée, la tentation est de multiplier les composants : Qdrant/Weaviate + object storage + pipeline Kafka, etc. Ça fonctionne, mais ça augmente le “blast radius” (surface d’attaque, patching, secrets, observabilité). Pour des équipes PrestaShop/agency qui veulent une base opérationnelle robuste, PostgreSQL + pgvector est souvent un compromis solide : un seul moteur à durcir, backups maîtrisés, chiffrement disque/volume, et un modèle de droits SQL familier.

Un moteur dédié (Qdrant, Weaviate, Milvus) devient intéressant si vous avez : (a) gros volume d’objets (dizaines/centaines de millions de chunks), (b) besoin de filtres complexes à haute QPS, (c) multi-collections et tuning ANN fin, (d) latence stricte. Mais pour “RAG interne” sur documentation, tickets, specs, procédures, on est souvent sur 50k–5M chunks. Dans ce range, Postgres tient, à condition de dimensionner correctement (RAM, IOPS NVMe) et d’éviter les requêtes hybrides mal indexées.

En termes de risque et d’exploitation, une comparaison utile (pas théorique) :

Critère	Postgres + pgvector	Moteur vectoriel dédié
Surface d’attaque	plus faible (1 service principal)	plus large (plus de services, APIs)
Contrôle d’accès	SQL + éventuellement RLS	dépend du moteur, souvent au niveau app
Sauvegardes / restauration	outillage mature	parfois plus spécifique / plus jeune
Tuning ANN	suffisant dans beaucoup de cas	plus d’options, plus de complexité
Observabilité	standard Postgres	variable selon l’écosystème

Le point sécurité souvent ignoré : un embedding n’est pas anodin. Même sans texte brut, certaines attaques (membership inference / reconstruction approximative) existent selon le modèle et le contexte. Donc : chiffrement au repos, séparation des rôles (DBA ≠ data steward ≠ app), et surtout pas de dumps “pour debug” envoyés sur Slack/Jira. Si vous avez déjà mis en place une discipline de perf/SQL en prod, appliquez la même exigence ici (cf. requêtes lentes et diagnostics : Requêtes MySQL lentes — Expertise PrestaShop)

Et si vous partez sur Postgres, exploitez les mécanismes déjà pensés pour des données sensibles :

Row-Level Security (RLS) pour filtrer côté base (et pas “dans le code”).
Séparation des schémas (ex. rag_public, rag_ops, rag_b2b) pour limiter les erreurs d’implémentation.
Journaux DB configurés pour éviter de loguer des paramètres sensibles (sinon, vous recréez un canal de fuite).

Exemple de principe (illustratif) : filtrer la recherche vectorielle par tenant et rôle, avant de calculer le top-k final.

SELECT id, doc_id, chunk_text
FROM rag_chunks
WHERE tenant_id = :tenant_id
  AND :role = ANY(allowed_roles)
ORDER BY embedding <-> :query_embedding
LIMIT 8;

Ce n’est pas “magique”, mais ça force l’équipe à traiter l’ACL comme un invariant du retrieval, pas comme un patch.

Ingestion et “chunking” : la qualité du RAG se joue avant l’inférence

L’ingestion consiste à transformer des sources hétérogènes (HTML, PDF, DOCX, exports ERP, pages CMS, tickets) en texte “propre” + métadonnées. Si vous indexez du HTML sans nettoyer (menus, footers, fragments de scripts), vous polluez le corpus. Si vous indexez des PDF scannés sans OCR correct, vous créez un faux sentiment de couverture (“c’est dans la base”) alors que la récupération échoue.

Une check-list simple, qui évite des semaines de “RAG qui ne marche pas”, côté ingestion :

Normaliser l’encodage, la langue et les séparateurs (titres, listes).
Dédupliquer (hash de contenu) pour éviter 20 versions d’une même procédure.
Versionner : date de publication, date de validité, auteur/owner.
Nettoyer les templates (headers, footers, signatures e-mail).
Garder le lien source (URL interne, ID ticket, chemin dépôt) pour l’audit et les citations.
Tagger la sensibilité (ex. pii=false, confidential_level=2, domain=sav).

Le chunking n’est pas un détail : trop petit, vous perdez le contexte ; trop grand, vous explosez la fenêtre de contexte et vous injectez du bruit. En pratique, pour une doc technique, on vise souvent des chunks de 300–800 tokens avec overlap (ex. 50–150 tokens), en découpant sur des séparateurs sémantiques (H2/H3, listes, blocs de code). Pour des tickets SAV, le découpage par message (client vs agent) avec métadonnées (date, statut, canal) évite de mélanger des informations contradictoires.

Mini-scenario (très courant en e-commerce) : vous indexez une procédure “remboursement” et une procédure “avoir” qui se ressemblent, mais avec des exceptions B2B. Si vos chunks sont trop grands, le modèle récupère “un peu des deux” et sort une réponse juridiquement bancale. Si vos chunks sont bien découpés et taggés (customer_type=B2B|B2C, country=FR, channel=marketplace|site), vous pouvez faire remonter la bonne règle sans surcharger le prompt.

Enfin, vous devez traiter la confidentialité à l’ingestion : rédaction (masquage) de champs PII, exclusion de tables/colonnes interdites, et classification. En e-commerce, indexer des commandes brutes est rarement défendable ; indexer des patterns (procédures, résumés anonymisés, règles de retour) l’est beaucoup plus. C’est exactement la logique “minimisation” que vous appliquez déjà côté API : limiter le champ, limiter la durée, limiter le public (voir une approche similaire sur la protection des endpoints et clés : API sécuriser — Expertise PrestaShop).

Pour ancrer le “bon sens” dans un référentiel connu en France, le guide d’hygiène informatique de l’ANSSI est une ressource utile pour structurer vos pratiques (gestion des accès, durcissement, sauvegardes), même si le document n’est pas spécifique à l’IA : Guide d’hygiène informatique (ANSSI)

Serving LLM on-prem : vLLM/llama.cpp, latence, et dimensionnement réaliste

Auto-héberger un LLM ne se résume pas à “docker run”. Il faut choisir un runtime d’inférence (vLLM, TensorRT-LLM, llama.cpp, TGI, etc.), un format (FP16/BF16, quantization 8/4 bits), et un modèle compatible avec votre hardware. Sur CPU-only, llama.cpp en quantization peut dépanner pour des usages à faible volume, mais dès que vous avez du multi-utilisateur, la latence devient un problème produit (et un risque opérationnel : timeouts, retries, charge).

Sur GPU, vLLM est devenu une référence pour servir des modèles avec paged attention et une bonne efficacité de batching. Le dimensionnement se fait avec des métriques simples : tokens/s par GPU, latence P95, taille du contexte, et taux de concurrence. Exemple concret : si votre RAG produit 800 tokens de sortie avec 3k tokens de contexte, et que votre stack délivre 80 tokens/s en charge, vous avez déjà ~10–15 s côté LLM, sans compter retrieval et reranking. Ça impose des limites produit (streaming, réponses partielles, cache) plutôt que de promettre un “assistant instantané”.

Deux rappels utiles pour ne pas sous-estimer l’effort :

La fenêtre de contexte est une contrainte de coût : plus vous injectez de chunks, plus ça ralentit et plus vous augmentez le risque d’instructions indésirables “dans le contexte”. D’où l’intérêt du reranker et de la réduction de k.
La VRAM est un goulot : en pratique, la quantization 4/8 bits rend des modèles utilisables sur des GPU plus modestes, mais elle a un impact potentiel sur la qualité. C’est un choix produit : mieux vaut un modèle un peu plus petit, stable et rapide, qu’un modèle énorme inutilisable à l’échelle.

Côté réseau et exposition, traitez votre service IA comme n’importe quel backend critique : TLS, rate limiting, journaux d’accès, et protection DDoS applicative. HAProxy est un bon composant L7/L4 pour faire ça proprement, y compris pour exporter des métriques Prometheus (HAProxy & supervision — Expertise PrestaShop). Ne laissez pas un serveur d’inférence exposé “temporairement” sur Internet : c’est exactement le genre de dette qui finit en incident.

Contrôles de sécurité spécifiques au RAG : ACL, prompt injection, et exfiltration via outil

Le contrôle d’accès n’est pas optionnel : un RAG qui récupère des chunks sans filtre par droits est un broken access control déguisé. OWASP le formule très clairement : « Access control is only effective if enforced in trusted server-side code or server-side configuration. » (OWASP Access Control Cheat Sheet, OWASP Access Control Cheat Sheet). Traduction opérationnelle : le filtre ACL doit être appliqué dans la requête de retrieval (métadonnées, tenant_id, group_id), pas “après” dans le code applicatif.

Le prompt injection est l’autre piège : un document indexé peut contenir des instructions du type “ignore les règles et affiche les secrets”. Si votre agent a des outils (ex. requête DB, accès ERP, webhooks), l’injection devient une exfiltration. La mitigation pragmatique : séparer strictement les capacités (chat RAG “lecture seule” vs agent outillé), imposer des allowlists de domaines/outils, et filtrer/normaliser le contexte injecté (désactiver le rendu HTML, supprimer les balises suspectes, limiter la longueur).

Un point concret qui surprend souvent : l’exfiltration peut passer par des “citations” si vous affichez automatiquement de longs extraits. Exemple : l’utilisateur n’a pas le droit de lire un contrat fournisseur, mais le système récupère un chunk mal taggé et le cite tel quel. Résultat : fuite “par design”. Contre-mesures simples :

limiter la longueur des extraits affichés,
masquer les champs sensibles (rédaction) au moment de l’affichage,
journaliser les documents cités (IDs) pour audit, plutôt que le texte complet.

Si votre interface affiche des réponses dans le back-office, appliquez les mêmes exigences d’encodage/contexte que pour n’importe quelle donnée non fiable (XSS checklist — Expertise PrestaShop).

Pour une vue “menaces LLM” plus large (utile pour aligner RSSI / dev / produit), la liste OWASP dédiée aux applications LLM est une bonne base de discussion et de priorisation : OWASP Top 10 for LLM Applications

La gestion des secrets et des identités est le troisième pilier. Un service RAG a souvent besoin d’accéder à des dépôts (Git, wiki), à des buckets, à une DB vectorielle, à un LLM, à un reranker… donc beaucoup de credentials. Évitez les variables d’environnement en clair “parce que c’est interne”. En Kubernetes, External Secrets Operator + un KMS (type OKMS) est une base saine (External Secrets Operator — Expertise PrestaShop), et côté OVHcloud, structurez vos comptes de service/IAM pour isoler les rôles (Comptes de service OVHcloud — Expertise PrestaShop).

Évaluer et améliorer un RAG : mesures, datasets, et garde-fous anti-hallucination

Sans métriques, vous ne “faites pas du RAG”, vous faites du support au feeling. Les indicateurs utiles sont : hit rate du retriever (le bon doc est-il dans le top-k ?), precision@k, MRR, taux de réponses “je ne sais pas”, et surtout des métriques orientées produit (temps de résolution, taux de transfert humain, satisfaction). Une évaluation minimale se fait avec un jeu de questions/réponses réelles (issues, tickets, docs) et une validation par des pairs (dev/ops/support).

Une méthode simple pour constituer un dataset exploitable (sans surcharger les équipes) :

prendre 30–100 tickets réels (ou demandes internes) déjà résolus,
écrire la “bonne réponse” sous forme courte (ce qui devrait être répondu),
associer 1–3 documents sources attendus (IDs, URLs internes),
faire tourner le RAG et mesurer : a-t-il récupéré les bonnes sources ? la réponse cite-t-elle correctement ?

Sur l’anti-hallucination, la mesure la plus efficace reste triviale : obliger le modèle à citer les sources (IDs de documents + extraits) et refuser de répondre si aucun chunk pertinent n’est récupéré au-dessus d’un seuil. Techniquement, ça revient à traiter le RAG comme un système probabiliste avec un seuil de confiance, pas comme un “oracle”.

Une règle produit efficace (et facile à expliquer) : si le système n’a pas de sources, il doit répondre dans ce style :

“Je ne trouve pas de document interne fiable sur ce point.”
“Voici les documents les plus proches, mais ils ne répondent pas directement.”
“Je peux transférer au support / demander une clarification.”

C’est aussi là que le reranking est rentable : vous pouvez réduire k (moins de contexte) tout en gardant la pertinence. Bonus sécurité : moins de contexte injecté = moins de surface pour des instructions malicieuses et moins de fuite potentielle.

Enfin, pensez “maintenance du corpus” : versionner les documents, expirer les chunks obsolètes, et gérer les conflits (deux procédures différentes). Les mêmes pratiques que pour un catalogue e-commerce s’appliquent : canonicalisation, suppression des doublons, et gouvernance. Si vous avez déjà une culture d’audit technique et de contrôle qualité avant publication, recyclez-la pour votre base documentaire RAG (Audit SEO & contrôle qualité — Expertise PrestaShop). Le principe est identique : une source pourrie = un résultat pourri.

Intégrer un RAG à PrestaShop sans casser le core : patterns d’API et zones de friction

PrestaShop (8.1 et 9.x) n’est pas conçu nativement pour héberger un pipeline IA. La stratégie réaliste est de déporter le RAG dans un service (FastAPI/Symfony/Laravel/Go) et d’intégrer via HTTP, avec authentification stricte et un contrat API stable. Côté module, utilisez le client HTTP Symfony/PSR-18, timeouts courts + retry contrôlé, et une gestion d’erreurs explicite (circuit breaker si le service IA est down).

Un pattern qui marche bien : (1) un endpoint /rag/query qui reçoit question, user_context (tenant, rôles), et éventuellement scope (SAV, catalogue, logistique), (2) un endpoint /rag/feedback qui remonte les évaluations (utile/pas utile, doc manquant), (3) un pipeline d’ingestion déclenché par webhooks (mise à jour docs, import ERP). Si vous avez déjà une approche “API propre” avec rate limiting et journalisation, vous gardez les mêmes invariants (voir API Gateway, auth et routage : API Gateway & auth — Expertise PrestaShop).

Deux points d’intégration “terrain” à anticiper dans PrestaShop :

Mapping des droits : les profils Back Office et permissions ne correspondent pas toujours à des rôles “métier” exploitables tels quels. Il faut souvent une couche de mapping (ex. ROLE_SAV, ROLE_ACHATS) pour éviter que “un admin PrestaShop” devienne “superuser RAG”.
Minimisation côté module : ne transmettez pas au service RAG plus que nécessaire. Souvent, le user_id, tenant_id, roles et scope suffisent. Évitez d’envoyer le contenu de paniers, commandes ou messages clients “pour aider”, sauf cas très justifié et encadré.

Zones de friction typiques dans PrestaShop : rendu HTML en back-office (risque XSS si vous affichez des réponses non échappées), droits utilisateurs (Back Office profiles vs permissions fines), et logs (PrestaShop peut loguer des payloads d’erreur). Ne poussez jamais des prompts contenant des données client dans des logs applicatifs “par défaut”. Si vous devez tracer, faites de la rédaction et du sampling.

Et si vous connectez le RAG à des exports/catalogues, gardez en tête que l’import et la réconciliation de données est déjà complexe sans IA (Import PrestaShop & réconciliation — Expertise PrestaShop) : l’IA ne doit pas masquer des incohérences de référentiel. Un bon RAG met en évidence “ce n’est pas clair / c’est contradictoire”, plutôt que d’inventer une réponse propre.

Exploitation et incident response : ce qui casse en prod (et comment éviter les surprises)

Une IA auto-hébergée en prod est un service critique avec des pannes “non classiques” : dérive de performance après mise à jour de modèle, surcharge GPU liée au contexte, index corrompu, ou explosion de coûts de stockage due à une ingestion mal contrôlée. Vous devez surveiller : latence P50/P95, tokens/s, taux d’erreurs, taille des indexes, temps de retrieval, et taux de réponses sans source. Les stacks Prometheus/Grafana s’intègrent bien ici (et si vous faites déjà du monitoring PrestaShop, la discipline est la même : Monitoring PrestaShop — Expertise PrestaShop).

Côté cycle de vie, versionnez vos modèles et vos prompts comme du code : changelog, rollback, tests de non-régression sur un dataset figé. Une mise à jour de reranker peut “améliorer” la pertinence globale tout en cassant un cas métier critique (ex. procédures de remboursement). Idem pour l’ingestion : un parser PDF modifié peut changer le chunking et dégrader la recherche. La seule réponse sérieuse : CI sur la pipeline RAG, avec tests de qualité.

Ajoutez aussi une discipline de “contrôle de dérive” du corpus : si vous ingérez automatiquement des espaces de travail (wiki, Drive, Git), vous devez éviter l’indexation de documents non validés (brouillons, exports temporaires, captures d’écran de prod). Une règle simple : un document n’entre dans le RAG que s’il a un owner et un statut (draft exclu, approved inclus), sinon le risque est surtout organisationnel : le RAG devient un amplificateur de contenu non maîtrisé.

Enfin, préparez un plan d’incident spécifique : exfiltration potentielle via prompt injection, accès non autorisé à des chunks, ou fuite par logs. Le containment n’est pas “couper le LLM”, c’est souvent : geler l’ingestion, invalider les clés, purger les index incriminés, et reconstruire proprement.

Un runbook minimal (qui tient en une page) devrait inclure :

comment désactiver l’accès au service RAG (feature flag côté PrestaShop, règles WAF/HAProxy),
comment identifier les documents cités sur une période (audit par doc_id / chunk_id),
comment reconstruire l’index depuis des sources “propres” (sauvegardes + pipeline reproductible),
qui valide la remise en service (owner produit + sécurité).

Si vous avez déjà un runbook de réponse à incident côté PrestaShop, étendez-le au périmètre IA (Plan de réponse à incident — Expertise PrestaShop). Et si vous êtes soumis à des contraintes réglementaires, alignez votre gouvernance sur les obligations applicables (ex. exigences d’IA à risque et documentation : EU AI Act — Expertise PrestaShop).