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.

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
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

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.