Architectures IA locales pour PME suisses : RTX Spark, DGX Spark, RTX PRO 6000, H100. TCO réel, ingénierie RAG, conformité nLPD. Procédures opérationnelles publiées progressivement.
View the Project on GitHub doit4everyone/ia-locale-pme-suisse
| Retour au sommaire | Section précédente : §16 Contrôle du cloisonnement et durcissement |
Ce que cette section documente : les sections précédentes installent et sécurisent la stack. Celle-ci porte sur ce qui la maintient digne de confiance dans le temps : qui est responsable de quoi, ce qui doit être renouvelé et à quelle échéance, ce qu’on indexe et ce qu’on refuse d’indexer, comment répondre à une demande d’effacement, et ce que la nLPD attend au-delà de la technique. Un RAG qui n’est pas gouverné se dégrade : les permissions dérivent, les certificats expirent, le corpus se périme, et les utilisateurs l’abandonnent ou, pire, lui font confiance à tort.
Cette stack est conçue pour faciliter la conformité à la nLPD. Elle ne la garantit pas, et aucun logiciel ne le peut. La nLPD encadre un traitement de données personnelles, mené par un responsable : l’entreprise. La loi lui impose des obligations qu’aucun outil ne remplit à sa place.
| Obligation nLPD | Ce que la stack apporte | Ce qui reste au responsable |
|---|---|---|
| Finalité et proportionnalité (art. 6) | Rien en soi | Décider pourquoi on indexe tel corpus, et si c’est proportionné |
| Protection dès la conception et par défaut (art. 7) | Cloisonnement, refus par défaut, chiffrement | Choisir le périmètre, et le tenir à jour |
| Sécurité des données (art. 8) | ACL, chiffrement au repos, journalisation, local | Les mesures organisationnelles de cette section |
| Devoir d’informer (art. 19) | Rien | Informer les collaborateurs que leurs documents sont traités par une IA |
| Analyse d’impact (art. 22) | Rien | La réaliser lorsque le risque est élevé, ce qui est plausible pour des données RH |
| Droit d’accès (art. 25) et demandes d’effacement | Journal et synchronisation aident | Les procédures pour y répondre (§17.5) |
| Annonce des violations (art. 24) | Journal aide à reconstituer | La procédure d’annonce au PFPDT |
À dire à un client, pas l’inverse. Présenter cette stack comme « conforme nLPD » exposerait l’auteur de cette affirmation : en cas de litige, elle se lirait comme une garantie. La formulation juste est « socle technique facilitant un traitement conforme », la conformité restant la responsabilité de l’organisation. Ce guide n’est pas un avis juridique ; une analyse par un juriste est recommandée dès que des données sensibles sont traitées.
Un RAG d’entreprise touche l’IT, la sécurité, les métiers et la direction. Sans attribution claire, chaque incident cherche un responsable qui n’existe pas. Cette matrice est un point de départ, à adapter à la taille de l’organisation ; dans une petite PME, une même personne peut tenir plusieurs rôles, mais aucun ne doit rester vacant. L’annexe §17.9 la détaille sous forme de matrice RACI, activité par activité.
| Action | Responsable type |
|---|---|
| Définir la finalité et le périmètre du corpus | Direction, avec les métiers |
| Décider quels dossiers sont indexés ou exclus (§17.4) | Propriétaires des données métier |
| Maintenir les permissions du serveur de fichiers et de SharePoint | IT, administration des droits |
| Exploiter la stack (synchronisation, mises à jour, sauvegardes) | IT, ou prestataire sous contrat |
| Renouveler les secrets et les certificats (§17.3) | IT |
| Lire les alertes de cloisonnement et de quarantaine | IT, avec escalade définie |
| Répondre aux demandes d’accès et d’effacement (§17.5) | Référent protection des données |
| Lire les journaux d’accès, conduire l’audit (§17.6) | Sécurité, ou référent désigné |
| Former les utilisateurs | IT, avec les métiers |
Sans responsable du corpus, le RAG se périme. C’est la défaillance la plus fréquente : la technique fonctionne, mais personne n’est chargé de retirer les documents obsolètes ni d’ajouter les nouveaux. Les réponses deviennent fausses sans que rien ne le signale, et la confiance s’effondre. Nommer ce responsable avant le déploiement, pas après.
La stack repose sur des secrets et des certificats qui ont tous une durée de vie. Un secret jamais renouvelé finit par être connu de trop de monde ; un certificat expiré coupe le service sans prévenir. Chacun doit avoir une échéance et un responsable.
| Élément | Où | Échéance conseillée | Effet à l’expiration |
|---|---|---|---|
Mot de passe de svc-rag |
AD (§5.2.4) | Selon la politique de l’organisation | L’indexation SMB échoue |
| Certificats des applications Entra (identité, Teams, SharePoint, Purview) | Entra ID, /etc/rag-certs |
2 ans, alerte à J-30 | La fonction concernée échoue (§11.5.2) |
ADMIN_TOKEN, API_TOKEN |
.env |
À chaque départ d’un administrateur, et périodiquement | n8n et les appels d’administration échouent (401) |
QDRANT_API_KEY, MIP_TOKEN, LOG_HMAC_KEY |
.env |
Périodiquement | Service interrompu jusqu’au report de la nouvelle valeur |
OWUI_JWT_SECRET (identité signée, §16.6) |
.env, lu par la RAG API et par Open WebUI |
Périodiquement, et si le .env a pu être lu par un tiers |
Si les deux services n’ont pas la même valeur, toutes les questions sont refusées (403). Recréer les deux : docker compose up -d rag-api open-webui |
| Certificat de la stack (Nginx, §9.8) | /etc/rag-tls |
Autorité interne, modèle Serveur Web : 2 ans ; auto-signé : 825 jours. Renouveler à J-30 au plus tard | Avertissement dans les navigateurs, sonde de supervision en alerte, n8n inaccessible sans passer l’avertissement. Procédure : §9.8.6 |
| Certificats de l’autorité interne (racine, intermédiaire) | ad-chain.pem, ad-subca.pem (§9.2.4) |
Selon la politique de la PKI | LDAP refusé (certificat non vérifiable) et chaîne de Nginx incomplète. Mettre à jour les deux fichiers, puis rag.crt (§9.8.6) |
Après toute modification du .env, recréer les conteneurs (docker compose up -d, et non restart, voir §15.3.6). Depuis la 2.21.0, une nouvelle valeur trop courte, identique à un autre jeton ou restée à l’exemple empêche la RAG API de démarrer (§16.6) : le contrôler par docker compose ps et docker logs rag-api. Le jeton d’administration se renouvelle en un seul endroit grâce à l’identifiant n8n (§16.7).
Les certificats Entra sont le point le plus facile à oublier, parce qu’ils ne gênent personne jusqu’au jour de l’expiration, deux ans plus tard. Un rappel planifié vaut mieux que la mémoire : le dépôt fournit un workflow n8n de rappel mensuel pour svc-rag, à décliner pour chaque certificat avec sa date d’échéance.
Pour relever les échéances, sur le poste d’administration (module Microsoft.Graph.Applications, chargé avant Connect-MgGraph -Scopes "Application.Read.All" dans une session neuve, comme en §14.4.3) :
foreach ($nom in "RAG-Identity-Resolver","RAG-Teams-Reader","RAG-SharePoint-Indexer","RAG-Purview-Decrypt") {
$app = Get-MgApplication -Filter "displayName eq '$nom'"
foreach ($c in $app.KeyCredentials) {
[pscustomobject]@{ Application = $nom; Expire = $c.EndDateTime }
}
}
Adapter les noms à ceux des applications réellement créées.
Le réflexe le plus coûteux est d’indexer « tout le serveur de fichiers ». Un RAG rend trouvable ce qui n’était que rangé dans une arborescence : un document mal classé, une copie oubliée, un export de données personnelles deviennent interrogeables en langage naturel par toute personne qui y a accès. La bonne question n’est pas « que peut-on indexer », mais « qu’a-t-on besoin d’indexer ».
Recommandations :
écarter les secrets techniques : clés, fichiers de configuration, exports de mots de passe n’ont pas leur place dans un corpus documentaire. Un contrôle avant indexation réduit le risque, sans le supprimer : la vraie protection est de ne pas les ranger dans les dossiers indexés.
Illustré en lab. Le corpus contenait deux contrats de maintenance pour le même client, l’un de 24 mois, l’autre d’un an, sur deux emplacements différents. Après un réglage de la recherche (§8.9), la même question a cité l’un puis l’autre : deux réponses ancrées, mais contradictoires.
Illustré en lab. Le serveur de fichiers de démonstration contenait un fichier nommé comme une clé TLS et des copies en clair de documents par ailleurs chiffrés. Ni l’un ni l’autre n’avait à être indexé. C’est le genre de résidu qu’un serveur ayant servi à des essais accumule, et qu’une politique de corpus écrite permet d’écarter avant qu’une IA ne le rende trouvable.
La nLPD donne à toute personne le droit de savoir quelles données la concernant sont traitées, et d’en demander l’effacement. Pour un RAG, cela se décline en deux questions concrètes.
« Quels documents me concernant sont indexés ? » Le RAG indexe des documents, pas des personnes : il n’y a pas d’index par personne. La réponse se construit à partir de la gestion documentaire de l’organisation (où sont rangés les documents concernant cette personne), le RAG n’indexant que ce que le serveur de fichiers contient déjà.
« Supprimez les documents me concernant. » La suppression se fait à la source, sur le serveur de fichiers ou SharePoint, jamais directement dans l’index. À la synchronisation suivante, l’indexeur constate l’absence du document et retire ses chunks de Qdrant. La chaîne à vérifier :
document supprimé à la source
↓ (synchronisation suivante)
chunks retirés de Qdrant
↓ (reconstruction en fin de synchronisation)
index BM25 régénéré sans le document
↓
sauvegardes : le document disparaît des sauvegardes postérieures,
reste dans les sauvegardes antérieures jusqu'à leur péremption
Le dernier maillon est important pour une réponse honnête : une suppression n’efface pas rétroactivement les sauvegardes déjà prises. La politique de rétention des sauvegardes (§15.5) doit être cohérente avec les engagements d’effacement de l’organisation.
Pour vérifier qu’un document a bien disparu de l’index après sa suppression :
CLE=$(grep '^QDRANT_API_KEY=' /root/rag-stack/.env | cut -d= -f2-)
curl -s -X POST http://localhost:6333/collections/documents/points/count \
-H "api-key: $CLE" -H 'Content-Type: application/json' \
-d '{"filter":{"must":[{"key":"source","match":{"value":"<chemin du document>"}}]}}'
# attendu après synchronisation : {"result":{"count":0}}
La journalisation (§9.4) enregistre qui a interrogé le RAG et quels documents ont été consultés. Elle n’a de valeur que si quelqu’un la relit, et si les permissions qu’elle reflète sont vérifiées.
| Contrôle | Fréquence conseillée | Outil |
|---|---|---|
| Les permissions dans Qdrant reflètent toujours celles de la source | À chaque synchronisation | Contrôle de cloisonnement automatique (§16.4) |
| Aucune application inattendue ne détient de droit de déchiffrement | Trimestrielle | Audit Content.SuperUser (§14.4.3) |
| Les droits du partage ne sont pas plus restrictifs que les NTFS | À chaque revue des droits | Set-AccesIndexationRAG.ps1 -Verifier (§16.5) |
| Les appartenances du compte d’indexation se limitent à son groupe dédié | Trimestrielle | Revue AD (§5.2.4) |
| Les certificats et secrets approchant de l’échéance | Mensuelle | §17.3, sonde de supervision (§16.10) |
| Les versions des composants : correctifs publiés, alertes de sécurité | Trimestrielle | Revue des versions (§16.8) |
| La supervision alerte réellement | Semestrielle | Essai : synchronisation suspendue, courriel reçu (§16.10) |
| Lecture des journaux d’accès : rien d’anormal | Selon le secteur | /var/log/rag/rag-queries.jsonl |
| Qualité des réponses sur un jeu de questions de référence | Périodique | À définir au §10 |
Un audit utile est un audit qui change quelque chose. Relever qu’une application détient un droit de déchiffrement injustifié, qu’un compte a gardé une appartenance obsolète, ou qu’un certificat expire dans trois semaines n’a d’intérêt que si une action suit. Chaque contrôle de ce tableau doit avoir un responsable (§17.2) et une suite définie en cas d’anomalie.
Ce guide documente un lab validé, pas une exploitation en entreprise. Plusieurs exigences de production dépassent son périmètre et feront l’objet d’une section « Du lab à la production ». La 2.21.0 en traite une partie :
| Exigence | État |
|---|---|
| Images Docker figées par version et empreinte, dépendances Python verrouillées | Fait (2.21.0, §16.8) |
| Intégration continue, inventaire des composants, analyse des vulnérabilités | À faire |
| Frontal HTTPS devant Open WebUI et n8n | Fait (2.21.0, §9.8) |
| Identité signée entre Open WebUI et la RAG API | Fait (2.21.0, §16.6) |
| Refus de démarrer sur une valeur d’exemple ou une clé absente | Fait (2.21.0, §16.6) |
| Réseau segmenté, ports de Nginx limités aux subnets autorisés | À faire (§9.1.2) |
| Sauvegardes chiffrées automatisées, avec restauration testée | Documenté, s’appuie sur l’outil de l’organisation ; restauration non testée (§15.5) |
| Supervision et alertes depuis un point extérieur à la stack | Contrôles définis, exemple validé en lab (§16.10) ; à intégrer à l’outil de l’organisation |
| Haute disponibilité si la continuité de service l’exige | Hors périmètre |
Les mentionner ici évite de laisser croire qu’un lab validé est prêt pour la production. Le passage de l’un à l’autre est un projet en soi.
| Point | Vérifié |
|---|---|
| Finalité et périmètre du corpus définis et écrits | |
| Collaborateurs informés du traitement par une IA | |
| Analyse d’impact réalisée si le risque est élevé | |
| Chaque rôle de §17.2 attribué à une personne nommée | |
| Responsable du corpus désigné | |
| Échéances des certificats et secrets planifiées, avec rappels | |
| Dossiers indexés désignés explicitement, dossiers sensibles exclus | |
| Procédure d’effacement documentée, chaîne jusqu’aux sauvegardes comprise | |
| Calendrier d’audit établi, chaque contrôle avec un responsable | |
| Politique de rétention des journaux et des sauvegardes définie | |
| Formulation « facilite la conformité », jamais « conforme » | |
| Matrice RACI (§17.9) adaptée et validée par la direction |
Modèle à adapter. Cette matrice reprend les activités de ce guide et les rôles de §17.2. Elle n’a pas été éprouvée dans une organisation réelle : c’est une base de discussion, à valider par la direction et à tenir à jour quand les personnes changent.
Légende : R réalise ; A rend compte et tranche (une seule personne par ligne) ; C est consulté avant ; I est informé après. A/R : le même rôle tranche et réalise.
Rôles : Dir. direction ; Mét. propriétaires des données métier ; IT exploitation, interne ou prestataire ; Séc. sécurité ou référent désigné ; PD référent protection des données.
| Activité | Dir. | Mét. | IT | Séc. | PD | Voir |
|---|---|---|---|---|---|---|
| Définir la finalité et le périmètre du corpus | A | R | C | C | C | §17.1 |
| Désigner les dossiers indexés et exclus | I | A | R | C | C | §17.4 |
| Maintenir les permissions NTFS et SharePoint | A | R | C | §5.2.4, §16.5 | ||
| Informer les collaborateurs, analyse d’impact | A | C | C | C | R | §17.1 |
| Déployer la stack, appliquer les mises à jour | I | A/R | C | §0, §16.8 | ||
| Revoir les versions des composants | A/R | C | §16.8 | |||
| Renouveler le certificat de la stack | A/R | I | §9.8.6 | |||
Renouveler les secrets et le mot de passe de svc-rag |
A/R | C | §17.3, §9.5 | |||
| Renouveler les certificats des applications Entra | A/R | I | §17.3 | |||
| Traiter une alerte de supervision (stack arrêtée, synchronisation absente) | I | A/R | I | §16.10 | ||
| Traiter une alerte de cloisonnement (fuite ou refus à tort) | I | I | R | A | I | §16.4 |
| Sauvegarder la VM et tester la restauration | I | A/R | C | §15.5 | ||
| Répondre à une demande d’accès ou d’effacement | C | R | A | §17.5 | ||
| Annoncer une violation de données au PFPDT | A | I | C | C | R | §17.1 |
| Conduire l’audit périodique, lire les journaux | I | C | A/R | I | §17.6 | |
| Former les utilisateurs | I | C | A/R | §17.2 |
Avec un prestataire. L’exploitation peut être confiée à un prestataire, qui devient R sur les lignes IT. Le A reste dans l’organisation : au sens de la nLPD, c’est elle le responsable du traitement (§17.1), et elle doit pouvoir trancher sans lui. Le contrat précise alors les délais de réaction, en particulier pour une alerte de cloisonnement et pour l’échéance d’un certificat.
Dans une petite PME, une même personne peut tenir les colonnes IT et Séc. Dans ce cas, l’audit périodique gagne à être relu par quelqu’un d’autre, la direction par exemple : celui qui exploite ne devrait pas être le seul à contrôler.
| Retour au sommaire | Section précédente : §16 Contrôle du cloisonnement et durcissement |
ℹ️ Références, structuration et aide à la rédaction assistées par IA, avec validation humaine finale.