Sécurité, confidentialité et secrets

Les outils, les modèles et leurs politiques évoluent. Ce cours présente les réflexes stables à appliquer dans CEO-OS. Avant de traiter une donnée sensible, vérifie toujours les conditions du produit et de la route réellement utilisés.

Pourquoi ce sujet compte

Ton Business Brain peut contenir des informations stratégiques, financières, commerciales, RH ou liées à des clients. Le fait que les fichiers soient dans un workspace local donne un contrôle important sur le coffre. Cela ne signifie pas que chaque traitement reste local.

Une demande adressée à l’IA peut toucher quatre surfaces différentes :

1. les actions réalisées sur ton ordinateur ;
2. les contenus transmis au modèle ou à son provider ;
3. les données accessibles par un outil connecté ;
4. les secrets utilisés pour accéder à un service.

La sécurité consiste à comprendre ces quatre surfaces et à appliquer un niveau de contrôle proportionné à la donnée, à l’action et à ta responsabilité. Le but est de rendre l’usage fiable et gouvernable, sans transformer chaque tâche en procédure technique.

1. Ce que l’IA peut faire sur l’ordinateur

OpenCode est une interface et un harnais de travail. Selon sa configuration, il peut lire des fichiers, rechercher dans le workspace, modifier des notes, exécuter des commandes ou appeler des outils connectés.

Le comportement réel dépend de la version d’OpenCode, de la configuration active du workspace et des règles définies par l’équipe qui a installé le setup. Il ne faut donc pas retenir une promesse générale du type « l’IA demande toujours avant chaque action » ou « l’IA peut tout faire ». Il faut regarder les permissions effectives.

Les trois décisions classiques sont :

Décision	Effet
allow	L’action est autorisée sans nouvelle validation.
ask	OpenCode demande une validation avant l’action.
deny	L’action est bloquée.

Les trois postures de permission

Mode strict

Chaque action importante demande une validation. Cette posture maximise le contrôle et augmente la friction. Elle convient aux premières prises en main, aux sessions d’audit ou aux environnements très sensibles.

Mode équilibré

Les actions courantes et réversibles dans le workspace peuvent être autorisées. Les accès externes, les commandes destructrices, les publications, les envois et les connexions à des services restent soumis à validation ou bloqués. C’est la posture de référence pour CEO-OS.

Mode automatique

Les demandes qui auraient nécessité une validation sont acceptées automatiquement, sauf celles explicitement bloquées. Cette posture réduit la friction lors d’un travail intensif. Elle ne convient pas à une session contenant des données client, RH, des credentials ou un dépôt de production sans surveillance humaine.

Le réglage d’auto-accept n’est donc pas un réglage de confidentialité. Il concerne d’abord l’autorité donnée à l’agent sur la machine. Une session peut être très permissive localement tout en utilisant une route de modèle privée, ou très contrôlée localement tout en envoyant une donnée sensible à un provider inadapté. Ces deux décisions doivent être examinées séparément.

Ce qu’il faut contrôler dans la configuration

La configuration opencode.json peut préciser les permissions par type d’action, chemin ou outil. Les principes à suivre sont les suivants :

• lecture et écriture autorisées uniquement dans ton workspace ;
• accès aux autres dossiers soumis à validation ;
• commandes courantes non destructrices autorisées uniquement si leur effet est compris ;
• suppression, déplacement, publication, envoi externe et commandes réseau soumis à validation ou bloqués ;
• accès aux fichiers de secrets limité et explicite ;
• mode automatique réservé aux contextes surveillés et non sensibles.

La documentation officielle d’OpenCode reste la référence pour la syntaxe et le comportement de la version installée : Permissions OpenCode.

2. Ce qui est transmis au modèle

Le coffre reste sur ton ordinateur tant qu’aucune synchronisation, recherche ou action externe n’est déclenchée. Lorsqu’OpenCode lit un fichier pour répondre, le contenu lu peut être ajouté au contexte envoyé à la route de modèle choisie.

Une requête peut contenir :

• ta demande ;
• les instructions actives de l’agent et du workspace ;
• l’historique utile de la conversation ;
• le contenu ou des extraits des fichiers lus ;
• les résultats des outils utilisés ;
• des métadonnées techniques nécessaires au service.

Le workspace n’est pas forcément envoyé en bloc. La quantité réellement transmise dépend des fichiers que l’agent ouvre, des outils appelés, de la tâche et de la configuration. La bonne règle n’est donc pas « tout le coffre est uploadé » ni « ce qui reste sur le disque est invisible ». La bonne règle est : tout fichier lu par l’agent peut devenir une donnée transmise à la route de modèle.

L’agent doit donc travailler avec le minimum de contexte nécessaire : ouvrir le document pertinent, extraire les éléments utiles, anonymiser lorsque c’est possible et éviter de transmettre un dossier complet lorsqu’un extrait suffit.

Le rôle du modèle local

Un modèle exécuté entièrement sur la machine évite l’envoi du prompt et du contexte à un provider LLM externe. Il ne rend toutefois pas toute la chaîne locale par défaut :

• une synchronisation du coffre peut créer un flux réseau ;
• un MCP peut envoyer une donnée vers son propre service ;
• une recherche web transmet une requête à un moteur ou à un provider ;
• une commande réseau peut contacter un service externe ;
• des logs locaux ou système peuvent conserver des traces.

« Local » désigne donc un périmètre précis. Il faut toujours demander : quelle partie de la chaîne est locale, et quel maillon reste externe ?

3. Les outils connectés ajoutent une deuxième chaîne de risque

Un MCP ou une API peut donner accès à une messagerie, un agenda, un CRM, une base de données, un espace documentaire ou un outil de gestion. La permission donnée à OpenCode et la permission donnée à cet outil sont deux contrôles différents.

Avant d’utiliser une connexion, il faut connaître :

1. le besoin métier couvert ;
2. les données que l’outil peut lire ;
3. les actions qu’il peut réaliser : lecture, écriture, suppression, envoi ;
4. le compte, le workspace ou l’entreprise concernés ;
5. les logs et la politique de conservation du service ;
6. la méthode de retrait ou de révocation de l’accès.

Une route LLM en ZDR ne protège pas une donnée transmise à un CRM, à Slack, à un moteur de recherche ou à un autre intermédiaire. La chaîne complète doit être considérée : fichiers locaux, OpenCode, intermédiaire éventuel, provider LLM, puis outils externes.

4. Classer une donnée avant de choisir un modèle

Pour un usage simple, on utilise trois niveaux. Cette classification ne remplace pas une politique de sécurité ou une obligation légale propre à l’entreprise. Elle fournit un réflexe de décision pour ton travail quotidien.

En cas de doute, on choisit le niveau le plus protecteur. Le niveau de sensibilité dépend du contenu, de la possibilité d’identifier une personne, de l’impact d’une fuite et des engagements pris envers un client ou un partenaire.

5. Confidentialité du provider : trois questions distinctes

Le nom d’un produit ne suffit pas à déterminer sa confidentialité. Il faut distinguer l’offre utilisée : chat grand public, offre entreprise, API, abonnement développeur ou route via un agrégateur.

La rétention

Le service conserve-t-il le prompt, les fichiers, la réponse ou des logs techniques ? Pendant combien de temps ? Les durées peuvent varier entre les produits d’une même entreprise et selon le type de compte.

L’entraînement

Les données peuvent-elles être utilisées pour entraîner ou améliorer de futurs modèles ? Désactiver l’entraînement est utile, mais cela ne signifie pas automatiquement que la donnée n’est pas conservée pour la sécurité, le support, la modération ou une obligation légale.

L’accès humain

Dans quelles situations une personne peut-elle consulter une requête ou une réponse ? Les cas possibles incluent la sécurité, la lutte contre les abus, le support, la qualité du service ou une demande légale.

Ces trois questions doivent être vérifiées séparément. Le chiffrement, le refus d’entraînement et le ZDR ne désignent pas la même protection.

Pourquoi la confidentialité dépasse la simple discrétion

La confidentialité protège une entreprise, ses salariés, ses clients et sa capacité à décider librement. Une information isolée peut sembler anodine. Une accumulation de conversations, de documents, d’intentions et de comportements peut cependant révéler une stratégie, une situation financière, une relation commerciale ou une vulnérabilité.

Quelques repères historiques expliquent pourquoi il faut conserver une posture prudente :

• les révélations de 2013 sur les programmes de surveillance ont montré que les communications stockées par de grandes plateformes pouvaient devenir accessibles à des agences publiques dans certains cadres légaux ;
• le Cloud Act américain de 2018 permet, sous certaines conditions, de demander à une entreprise américaine des données qu’elle contrôle, y compris lorsque l’infrastructure se trouve hors des États-Unis ;
• une politique de suppression n’implique pas nécessairement une disparition instantanée de toutes les copies, sauvegardes, métadonnées ou traces de sécurité ;
• la valeur économique d’une donnée vient aussi des inférences qu’elle permet sur les comportements, les intentions et les décisions.

Ces éléments ne signifient pas que chaque requête sera consultée ou conservée indéfiniment. Ils justifient une règle de gouvernance simple : une donnée envoyée à un provider externe doit être considérée comme sortie du périmètre strict de l’entreprise, avec une durée de conservation et des accès potentiels à vérifier.

6. Comprendre le ZDR

ZDR, ou Zero Data Retention, désigne un engagement de non-conservation du contenu après traitement, dans le périmètre défini par l’offre ou le contrat concerné.

Le ZDR est une garantie de provider, pas une propriété magique de l’interface. Il faut vérifier :

• le produit exact auquel l’engagement s’applique ;
• les prompts, réponses et fichiers réellement couverts ;
• les métadonnées et logs techniques exclus ;
• les outils ou fonctions qui sortent du périmètre ;
• les sous-traitants et le provider final ;
• les exceptions liées à la sécurité ou à la loi ;
• la preuve contractuelle ou documentaire disponible.

Le ZDR réduit la conservation chez le provider. Il n’empêche pas une mauvaise permission locale, un fichier envoyé au mauvais outil, une capture d’écran, une synchronisation ou une erreur humaine.

Les routes retenues comme exemples

Les options suivantes servent à comprendre les choix possibles. Les prix, modèles et conditions sont une photographie à vérifier avant publication et avant tout usage sensible.

Synthetic AI avec GLM 5.3 Flash

La formation le présente comme l’option d’abonnement développeur ZDR à privilégier pour un usage privé quotidien, lorsque l’offre et ses conditions sont confirmées. L’offre était annoncée autour de 30 USD par mois à la date de rédaction, sans que ce montant constitue un tarif garanti. L’intérêt est de disposer d’une route ZDR récurrente sans arbitrer le coût de chaque requête.

OpenRouter avec le mode Privacy et une route ZDR

OpenRouter permet de comparer de nombreux modèles et de payer à la consommation. Son mode Privacy peut limiter le routage aux providers déclarés compatibles avec les exigences ZDR. Cette option convient aux cas sensibles occasionnels, aux tests et aux situations où un abonnement n’est pas justifié. Il faut vérifier le provider final retenu, car l’agrégateur ajoute un maillon dans la chaîne.

Offres grand public

ChatGPT Plus ou Claude Pro peuvent proposer un réglage de refus d’entraînement. Cela ne constitue pas automatiquement un engagement ZDR. Pour une tâche sensible, vérifie l’offre exacte, la rétention, l’accès humain et les exceptions avant l’envoi.

Si ChatGPT est utilisé dans OpenCode pour des tâches non sensibles, désactiver Improve the model for everyone dans Settings > Data Controls réduit l’usage prévu pour l’entraînement. Cette action ne transforme pas l’offre en ZDR.

7. Les options européennes et le modèle local

Une entreprise peut préférer une infrastructure européenne pour des raisons de souveraineté, de localisation, de RGPD ou de politique client. Le lieu du data center ne suffit toutefois pas à établir la souveraineté : il faut aussi regarder l’entité contractuelle, les sous-traitants, le droit applicable et la rétention.

Parmi les routes à évaluer :

• Scaleway Generative APIs, avec une infrastructure française et des garanties à vérifier selon le service ;
• OVHcloud AI Endpoints, avec une offre européenne de modèles open source ;
• Mistral AI, à distinguer entre Le Chat et l’API, avec des conditions de rétention et de sous-traitance à vérifier au cas par cas.

Pour des données très sensibles, le traitement local est la route la plus directe : le modèle tourne sur le matériel de l’entreprise et le prompt ne quitte pas le réseau pour l’inférence. Cette solution demande davantage de matériel, de maintenance et parfois une qualité inférieure aux meilleurs modèles distants.

Ce que permet le matériel local

La RAM disponible détermine largement les modèles utilisables. Sur un Mac, la mémoire est unifiée entre CPU et GPU. Si le modèle dépasse la mémoire disponible et utilise fortement le disque, la vitesse devient inconfortable.

Environ 16 Go de RAM

Des modèles de 3 à 8 milliards de paramètres en Q4 conviennent au chat, à la rédaction et à des recherches simples. Ce niveau reste limité pour l’agentique avancée et les chaînes multi-étapes.

Environ 32 à 64 Go de RAM

Les modèles de 12 à 32 milliards de paramètres deviennent utilisables au quotidien. Sur 64 Go, certains modèles de 70B quantisés deviennent accessibles selon le contexte et les autres applications ouvertes.

128 Go et plus

Les modèles open source plus volumineux deviennent possibles. Le coût du matériel, la consommation, la maintenance et la difficulté de mise à jour doivent être comparés au coût d’une route distante sous contrat.

Ollama propose une expérience en ligne de commande et un serveur local compatible avec de nombreuses interfaces. LM Studio propose une interface graphique et un serveur local compatible OpenAI. Ces outils sont des moyens d’exécuter un modèle local, pas des garanties automatiques sur les permissions, les fichiers ou les outils connectés.

Comprendre la quantisation

Un modèle stocke ses paramètres avec une certaine précision. La quantisation les compresse pour réduire la mémoire nécessaire.

Niveau	Effet général	Usage courant
Q5	Qualité proche d’une précision supérieure, modèle plus lourd	Lorsque la mémoire est disponible.
Q4	Bon compromis entre taille, vitesse et qualité	Niveau de départ généralement recommandé.
Q2	Forte compression et perte de qualité plus visible	Faire tenir un très gros modèle lorsque les autres options sont impossibles.

La quantisation réduit la taille du modèle. Elle ne résout ni la qualité des données, ni les erreurs de raisonnement, ni les risques liés aux outils autorisés.

8. Gérer les secrets

Une clé API, un token, un mot de passe ou une clé SSH permet d’agir au nom d’une personne ou d’une entreprise. Il faut le traiter comme un accès : un propriétaire, un périmètre, une durée de vie, un budget et une méthode de révocation.

La règle est volontairement simple : les credentials sont conservés hors du Business Brain, dans le gestionnaire de secrets prévu pour le setup, Bitwarden lorsque cette option est retenue. Les exemples et la documentation de formation ne contiennent aucune valeur réelle.

L’échelle de protection

Niveau de base

Un secret est stocké dans le gestionnaire de secrets ou dans le fichier de configuration local prévu par l’installation. Il n’est jamais placé dans une note du Business Brain, une conversation, un document partagé ou un dépôt Git.

Niveau recommandé

Tu utilises Bitwarden ou un mécanisme équivalent, tu privilégies OAuth lorsqu’il est disponible, tu utilises une clé distincte par service ou environnement et tu limites les droits ainsi que le budget de chaque clé.

Niveau avancé

Les secrets sont injectés au runtime dans des variables d’environnement ou des credentials intégrés. L’agent manipule la référence ou la variable sans que la valeur soit écrite dans un fichier persistant. Cette approche est surtout utile pour les projets techniques et les clés de production.

Le fait de récupérer un secret avec une commande comme bw get password ne garantit pas qu’il sera invisible pour l’agent : la valeur peut apparaître dans la sortie de commande ou dans les logs. L’injection directe ou le mécanisme de credentials natif doit être privilégié lorsque disponible.

Du principe à l’installation

Un coffre chiffre et stocke un secret. Il ne garantit pas à lui seul que l’agent ne lira pas. Pour une clé API ou un MCP, le chemin de référence consiste à injecter la valeur directement dans le processus autorisé, sans l’écrire dans la configuration ni la retourner au modèle. Le cours Gestionnaire de secrets et connexions sécurisées montre ce flux avec 1Password et l’alternative Bitwarden Secrets Manager.

Les règles non négociables

1. Ne jamais coller une clé dans un espace public, une session partagée, un forum, un ticket ou un canal de discussion.
2. Ne jamais commiter une clé dans un dépôt public ou dans un fichier suivi par Git.
3. Utiliser un fichier .env ignoré par Git pour les projets de code lorsque c’est le mécanisme prévu.
4. Activer l’authentification multifacteur sur les comptes critiques.
5. Révoquer immédiatement une clé exposée, même si le message ou le fichier a ensuite été supprimé.

Exemple minimal pour un projet de code :

# .gitignore
.env
.env.local
.env.*.local

Un fichier .env ignoré par Git protège contre un commit accidentel. Il ne protège pas contre une machine compromise, une session ouverte ou un agent autorisé à lire ce fichier. Les permissions et le stockage des secrets restent à traiter séparément.

9. Synchronisation et chiffrement

La synchronisation d’un coffre crée un autre flux de données. Il faut distinguer le stockage local, le transfert et le traitement par l’IA.

Obsidian Sync

Obsidian Sync peut utiliser un chiffrement de bout en bout lorsque cette option est activée et correctement configurée. Le contenu synchronisé est alors protégé contre la lecture par le service dans le périmètre documenté. Le coffre reste lisible sur la machine locale, et les métadonnées ou les réglages doivent être vérifiés séparément.

GitHub privé

Un dépôt privé limite l’accès public, sans constituer une souveraineté complète. Les données sont hébergées par un service tiers et restent soumises à ses conditions, à ses sous-traitants et au droit applicable.

GitLab self-hosted ou Gitea

L’auto-hébergement donne davantage de contrôle sur l’infrastructure. Il ajoute des responsabilités d’administration, de sauvegarde, de mise à jour et de sécurité. Il ne doit être choisi que lorsqu’un besoin réel le justifie.

Le chiffrement protège un stockage ou un transfert. Il ne rend pas le contenu invisible à l’agent pendant une session ouverte et ne transforme pas une requête envoyée à un provider en traitement local.

10. Le modèle mental à retenir

Avant une tâche, pose quatre questions :

1. Autorité locale : qu’est-ce que l’agent peut lire, modifier ou exécuter sur la machine ?
2. Flux de données : quels fichiers et quels extraits peuvent partir vers le modèle ?
3. Chaîne externe : quels providers, intermédiaires et outils reçoivent la donnée ?
4. Accès : quels secrets permettent à l’agent d’agir, et comment les révoquer ?

La classification par sensibilité aide ensuite à choisir un modèle :

• Donnée non sensible : abonnement ChatGPT ou route OpenRouter habituelle ;
• Donnée potentiellement sensible : abonnement ChatGPT si aucune donnée client, sinon OpenRouter avec contexte réduit et anonymisation ;
• Donnée sensible : uniquement une route ZDR, via Synthetic AI ou OpenRouter en mode Privacy.

En cas d’incident

Si une donnée sensible ou un secret a été envoyé au mauvais endroit :

1. arrête la session ou l’intégration concernée ;
2. révoque le secret exposé, sans attendre la suppression du message ;
3. crée une nouvelle clé avec les droits minimaux ;
4. identifie les données, les personnes et les services concernés ;
5. préviens le responsable interne sans recopier le secret ;
6. documente l’incident et la correction ;
7. vérifie les obligations contractuelles, réglementaires ou de notification.

La suppression d’un message ne remplace jamais la révocation d’une clé. Si la route de traitement est inconnue, considère la donnée comme potentiellement transmise et applique la procédure la plus protectrice.

Synthèse

Question	Réponse recommandée
L’IA peut-elle tout faire sur l’ordinateur ?	Cela dépend des permissions actives. La posture recommandée est équilibrée, avec validation pour les actions externes ou destructrices.
Le coffre quitte-t-il l’ordinateur en bloc ?	Non, le workspace n’est pas nécessairement envoyé en bloc. Tout fichier lu par l’agent peut toutefois entrer dans le contexte transmis.
Un workspace local signifie-t-il traitement local ?	Non. Le modèle, les outils, la synchronisation et les recherches peuvent créer des flux externes.
ZDR signifie-t-il qu’aucune trace n’existe ?	Non. Le ZDR concerne le périmètre contractuel défini. Métadonnées, outils externes et exceptions doivent être vérifiés.
Le refus d’entraînement suffit-il pour une donnée sensible ?	Non. Il faut aussi vérifier la rétention et l’accès humain.
Quelle route pour une donnée sensible ?	Une route explicitement approuvée et documentée, idéalement ZDR ou locale selon le niveau de risque.
Où stocker les secrets ?	Hors du Business Brain, dans le gestionnaire de secrets prévu. Ne jamais les placer dans une conversation ou un dépôt public.
Que faire après une fuite de clé ?	Révoquer immédiatement, recréer avec des droits minimaux et signaler l’incident.

Ressources

• OpenCode : permissions
• OpenRouter : politiques de rétention des providers
• OpenRouter : Privacy
• Obsidian Sync : sécurité et chiffrement
• Bitwarden CLI
• Scaleway Generative APIs
• OVHcloud AI Endpoints
• Comprendre et choisir son modèle IA

Ce qu’il faut retenir

• L’IA peut agir sur la machine, transmettre un fichier au modèle, passer par un outil connecté et utiliser un secret ; quatre surfaces à contrôler séparément.
• La posture équilibrée (validation pour les actions externes ou destructrices) est la référence recommandée.
• Un workspace local ne veut pas dire traitement local : tout fichier lu par l’agent peut entrer dans ce qui est transmis à un provider.
• La classification Vert / Orange / Rouge détermine la route à utiliser, en cas de doute prendre le niveau le plus protecteur.
• Le ZDR protège un périmètre contractuel défini, il ne garantit ni l’absence de métadonnées ni la couverture des outils externes.
• Un secret vit toujours hors du Business Brain, dans le gestionnaire prévu ; jamais dans une note, une conversation ou un dépôt Git.

Suivant : Comprendre et choisir son modèle IA