Politique d'entreprise

Pia applique une politique d’entreprise au démarrage. Les administrateurs informatiques l’utilisent pour définir des valeurs par défaut ou verrouiller certains paramètres sur les appareils gérés. Une politique peut provenir de deux sources : un fichier policy.json sur l’appareil, ou une politique que l’administrateur publie pour le groupe de l’utilisateur sur un serveur Pia.

Emplacement du fichier

Pia cherche policy.json à trois emplacements et utilise le premier qui existe. Les trois fichiers ne sont jamais fusionnés.

%ProgramFiles%\Pia.Wpf\current\policy.json    (le dossier depuis lequel Pia.exe s'exécute)
%ProgramFiles%\Pia.Wpf\policy.json            (la racine de l'installation)
C:\ProgramData\Pia.Wpf\policy.json

Placez le fichier à la racine de l’installation, à côté du lanceur avec lequel les utilisateurs ouvrent Pia. Le dossier depuis lequel Pia.exe s’exécute est remplacé à chaque mise à jour de Pia : une politique laissée là disparaît à la mise à jour suivante.

Les utilisateurs standard peuvent lire ces dossiers ; seuls les administrateurs peuvent y écrire. Les utilisateurs ne peuvent pas contourner le fichier depuis Pia.

Attention

Pia charge la politique une seule fois au démarrage. Une modification de policy.json — ou d’une politique publiée sur le serveur — ne prend effet qu’après que l’utilisateur a redémarré Pia.

Politique venant de votre serveur Pia

L’administrateur peut publier le même document pour un groupe entier depuis la console d’administration du serveur Pia ; il parvient au client par la synchronisation ordinaire. Une politique publiée par le serveur comporte les deux mêmes sections, defaults et enforce, avec exactement le sens qu’elles ont dans un fichier. Rien d’autre ne change dans cette référence.

Trois points à connaître sur une politique publiée par le serveur :

• Elle est mise en cache sur l’appareil. La politique continue de s’appliquer après un redémarrage et hors connexion, et elle n’expire pas : une politique que le serveur a confirmée pour la dernière fois il y a plusieurs jours s’applique toujours.
• Elle prend effet au démarrage suivant. Une politique publiée pendant que Pia tourne est récupérée par la synchronisation suivante, puis appliquée au démarrage suivant de Pia. C’est le comportement prévu.
• La déconnexion l’efface. Pia supprime la politique serveur mise en cache à la déconnexion, afin que la personne suivante à se connecter sur cette machine n’hérite pas de la politique du groupe de l’utilisateur précédent.

Note

La toute première connexion ne peut pas être restreinte : une liste de fournisseurs de connexion autorisés publiée sur le serveur ne peut pas filtrer la connexion même qui va la chercher. Un allowedSyncProviders venant du serveur ne prend donc effet qu’à partir du deuxième démarrage. Définissez-le dans policy.json si la première connexion doit être restreinte.

Une méthode de connexion absente de allowedSyncProviders est masquée dans l’assistant de configuration et les paramètres du compte, et une connexion par ce biais est refusée avec « Cette méthode de connexion est désactivée par la stratégie de votre organisation. » Un utilisateur déjà connecté avec une méthode que la politique n’autorise plus est déconnecté au prochain démarrage de Pia : sa session est aussi fermée sur le serveur, et la synchronisation reste désactivée jusqu’à ce qu’il se reconnecte. La déconnexion supprime aussi la politique serveur mise en cache, si bien que la connexion suivante n’est de nouveau pas restreinte — définissez allowedSyncProviders dans policy.json pour refuser une méthode de façon définitive.

Quelle source l’emporte

Une politique publiée par le serveur l’emporte sur le policy.json de l’appareil pour toute clé que les deux définissent. Au sein d’une même source, enforce écrase le choix de l’utilisateur, tandis que defaults ne comble que ce que l’utilisateur n’a pas choisi. L’ordre complet, le premier trouvé l’emporte :

1. enforce venant du serveur
2. enforce venant de policy.json
3. la valeur choisie par l’utilisateur
4. defaults venant du serveur
5. defaults venant de policy.json
6. le défaut intégré de Pia

Format du fichier

Une politique comporte deux sections de premier niveau, toutes deux structurées comme le schéma des paramètres utilisateur de Pia :

• defaults — une valeur de départ, appliquée tant que la valeur de l’utilisateur correspond encore au défaut intégré de Pia, ou encore à la valeur que la politique avait posée auparavant.
• enforce — valeurs verrouillées. Les contrôles correspondants dans l’interface des paramètres de Pia sont désactivés afin que l’utilisateur ne puisse pas les modifier. Si la même propriété apparaît dans les deux sections, enforce l’emporte.

Une valeur defaults modifiée est appliquée de nouveau

Lorsque l’administrateur modifie une valeur sous defaults, Pia applique la nouvelle valeur au démarrage suivant — sauf si l’utilisateur a entre-temps modifié ce paramètre lui-même, auquel cas son choix est conservé. Cette règle est la même pour les deux sources : elle change donc aussi le comportement des déploiements existants qui n’utilisent que policy.json, où une valeur defaults modifiée dans le fichier atteint désormais les appareils qui avaient déjà pris l’ancienne valeur.

Note

Une clé prend effet parce qu’elle est présente, non parce que sa valeur diffère du défaut intégré de Pia. "theme": "System" sous enforce verrouille le thème sur System et grise le contrôle, même si System est déjà le défaut. Seules les clés que vous omettez restent à la main de l’utilisateur.

Paramètres pris en charge

Tous les noms de propriétés utilisent camelCase. Les propriétés inconnues sont ignorées. Un JSON invalide est consigné comme avertissement et la politique n’est pas appliquée — consultez le journal de l’application si une politique ne semble pas prendre effet.

Propriété	Type	Par défaut	Description
theme	"System" | "Dark" | "Light"	"System"	Thème de l’interface
uiLanguage	"EN" | "DE" | "FR"	"EN"	Langue de l’interface
targetLanguage	"EN" | "DE" | "FR"	non défini	Langue de sortie par défaut pour Optimize
targetSpeechLanguage	"Auto" | "EN" | "DE" | "FR"	"Auto"	Langue de la reconnaissance vocale
defaultOutputAction	"CopyToClipboard" | "AutoType" | "PasteToPreviousWindow"	"CopyToClipboard"	Ce qui se passe après Optimize
autoTypeDelayMs	integer	10	Délai AutoType en millisecondes
defaultTemplateId	GUID	non défini	Modèle d’optimisation par défaut
whisperModel	"Tiny" | "Base" | "Small" | "Medium" | "Large"	"Base"	Taille du modèle Whisper
ttsEnabled	bool	false	Activer la synthèse vocale
ttsVoiceModelKey	string	"en_US-lessac-medium"	Identifiant de la voix TTS
startMinimized	bool	false	Démarrer masqué dans la barre des tâches
launchAtStartup	bool	true	Démarrer Pia avec Windows
showTodoPanelButton	bool	true	Afficher le bouton du panneau Todo dans la fenêtre principale
autoUpdateEnabled	bool	true	Autoriser la mise à jour automatique au démarrage
syncEnabled	bool	false	Activer la synchronisation Pia Cloud
serverUrl	string	non défini	URL du serveur Pia Cloud (pour l’auto-hébergement)
trustSelfSignedCertificates	bool	false	Accepter les certificats TLS auto-signés du serveur Pia configuré (son hôte et son port) uniquement, jamais d’autres hôtes
allowedSyncProviders	string[]	non défini (toutes autorisées)	Méthodes de connexion autorisées : "local", "google", "microsoft", "entraid". Voir Politique venant de votre serveur Pia
useSameProviderForAllModes	bool	true	Utiliser un seul fournisseur d’IA pour Optimize/Assistant
modeProviderDefaults	object	{}	Mappage du mode de conversation vers le GUID du fournisseur d’IA
privacy	object	voir ci-dessous	Paramètres de confidentialité (imbriqués)

privacy est un objet imbriqué :

Propriété	Type	Par défaut	Description
tokenizationEnabled	bool	true	Remplacer les données personnelles par des jetons avant d’envoyer le texte à l’IA

Gouverner l’assistant

Ce sont ceux qui méritent d’être épinglés sur les appareils gérés, car ils décident ce que Pia peut faire de son propre chef. Voir Permissions des outils et Exécutions d’agents.

Propriété	Type	Par défaut	Description
assistantFilesFolder	string	non défini	Le seul dossier auquel l’assistant peut accéder
assistantFileToolsEnabled	bool	true	Autoriser la lecture et l’écriture de fichiers dans ce dossier
assistantGitToolsEnabled	bool	true	Autoriser les commandes git dans ce dossier
agentRunAutoApproveBuiltInWrites	bool	false	Ignorer l’approbation pour les propres outils d’écriture de Pia lors des exécutions d’agents et du mode vocal
chatHistoryEnabled	bool	true	Enregistrer les conversations de l’assistant sur l’appareil
chatHistoryRetentionDays	integer	30	Supprimer les conversations non ouvertes depuis ce nombre de jours
enableMeetingDiarization	bool	true	Découper les transcriptions de réunions par intervenant
meetingSpeakerNaming	bool	true	Laisser la phrase de consentement et un renommage donner un nom à un intervenant, et ajouter la liste des participants aux résumés et aux notes enregistrées

Avec meetingSpeakerNaming défini à false, chaque intervenant garde une étiquette comme Intervenant 1. Le renommage est désactivé dans les deux fenêtres de transcript, les résumés n’ont pas de liste de participants, le formulaire d’enregistrement dans le coffre n’est pas pré-rempli avec les participants, et la note d’une réunion programmée n’en liste aucun. Une phrase de consentement compte toujours, mais le nom qui s’y trouve ne figure que dans la preuve du consentement, et la phrase elle-même reste en dehors de la transcription. Les utilisateurs voient le paramètre comme Nommer les intervenants dans Paramètres → Assistant → Réunion, verrouillé quand tu le définis sous enforce.

Limiter les fournisseurs et les outils

Définis ceux-ci sous enforce, pour que les utilisateurs ne puissent pas les assouplir.

Propriété	Type	Par défaut	Description
allowedProviderTypes	string[]	non défini (tous autorisés)	Types de fournisseurs que les utilisateurs peuvent utiliser : "OpenAI", "AzureOpenAI", "Ollama", "OpenRouter", "OpenAICompatible", "Mistral", "VLlm", "Anthropic". La casse n’a pas d’importance
allowedProviderEndpoints	string[]	non défini (tous autorisés)	Adresses que les fournisseurs peuvent utiliser : un hôte exact, ou *.domaine pour ses sous-domaines
allowProviderWebSearch	bool	true	Autoriser la recherche web propre des fournisseurs
allowLocalMcpServers	bool	true	Autoriser les serveurs MCP qui s’exécutent sur l’appareil

En omettant allowedProviderTypes ou allowedProviderEndpoints, ou en les définissant à null ou [], tu autorises tout. Pia Cloud n’est jamais limité par l’un ou l’autre.

Un type de fournisseur absent de allowedProviderTypes n’est pas proposé dans la boîte de dialogue du fournisseur ou l’assistant de configuration. Un fournisseur de ce type que l’utilisateur a déjà ne peut pas être enregistré, et Pia refuse toute demande à celui-ci avant que rien ne soit envoyé : le chat montre un message, et une exécution en arrière-plan se termine par une erreur. La raison donnée est « La stratégie de votre organisation n’autorise pas ce type de fournisseur. »

Une entrée dans allowedProviderEndpoints est un hôte exact comme llm.corp.example, ou un motif comme *.example.com, qui couvre chaque sous-domaine de example.com mais pas example.com lui-même. Une entrée écrite comme une URL compte par son hôte. Une adresse que la liste ne couvre pas ne peut pas être enregistrée, et la boîte de dialogue affiche « La stratégie de votre organisation n’autorise pas cette adresse. » Pia ne récupère aucun modèle à cette adresse et refuse les requêtes qui lui sont adressées.

allowProviderWebSearch défini à false désactive la recherche web propre des fournisseurs : OpenAI, OpenRouter, Anthropic et les agents Mistral. Le choix de l’utilisateur reste enregistré, et Activer la recherche Web est verrouillé. Pia Cloud n’est pas affecté, car sa recherche s’exécute sur le serveur.

allowLocalMcpServers défini à false verrouille Ajouter un serveur, refuse l’enregistrement et le test d’un serveur, et arrête les serveurs locaux en cours d’exécution. Chacun dit « La stratégie de votre organisation n’autorise pas de serveurs MCP locaux sur cet appareil. » Une fois les serveurs locaux autorisés à nouveau, Pia redémarre de lui-même ceux qui sont activés. Les serveurs MCP que l’administrateur distribue comme extensions ne sont pas affectés.

Paramètres que le serveur ne peut pas gérer

Deux groupes de clés sont exclus : le premier uniquement dans une politique publiée par le serveur, le second dans les deux sources.

Les paramètres de connexion — serverUrl, syncEnabled et trustSelfSignedCertificates. Ce sont eux qui permettent à Pia d’atteindre le serveur, et comme une politique publiée par le serveur l’emporte sur le fichier de l’appareil, une seule valeur erronée pourrait couper tout un groupe sans qu’il reste un moyen de le corriger à distance. Ces trois clés peuvent toujours être verrouillées dans le policy.json de l’appareil : c’est ainsi que l’on encadre un appareil avant même qu’il n’ait atteint un serveur.

La gestion interne de Pia — identifiants de connexion, curseurs de synchronisation et ETags, état du chiffrement, marqueurs de schéma et de migration, géométrie des fenêtres et textes de brouillon. Pia ignore ces clés quelle que soit leur source, dans le fichier comme depuis le serveur, et consigne un avertissement nommant la clé.

Exemple

{
  "defaults": {
    "uiLanguage": "DE",
    "targetLanguage": "DE",
    "whisperModel": "Small"
  },
  "enforce": {
    "theme": "Dark",
    "serverUrl": "https://pia.corp.example.com",
    "syncEnabled": true
  }
}

Dans cet exemple, l’allemand est la langue de démarrage, mais les utilisateurs peuvent basculer vers l’anglais ou le français. Le thème est verrouillé sur Dark, la synchronisation est obligatoire, et l’URL Pia Cloud est verrouillée sur le serveur auto-hébergé de l’entreprise. serverUrl et syncEnabled ne fonctionnent que dans un policy.json sur l’appareil — une politique publiée par le serveur ne peut pas les définir.

Déploiement

1. Créez ou modifiez policy.json à la racine de l’installation de Pia sur chaque appareil géré (par exemple via votre système de gestion des points de terminaison), ou publiez le document pour un groupe entier depuis la console d’administration du serveur Pia.
2. Validez le JSON.
3. Demandez aux utilisateurs de fermer et rouvrir Pia.

Les paramètres sous enforce apparaissent grisés dans l’interface des paramètres de Pia ; les valeurs par défaut apparaissent normalement.