Skip to main content

​
Vue d’ensemble

system.json est un fichier de politique facultatif, applicable à l’ensemble de la machine, que les administrateurs déploient sur les appareils gérés (généralement via une solution MDM). Il est stocké dans un répertoire système auquel seul un administrateur peut écrire. Ainsi, contrairement à la configuration utilisateur située dans ~/.config/devin/config.json, les paramètres qu’il contient ne peuvent pas être modifiés ni supprimés par l’utilisateur. Utilisez-le pour :
  • Verrouiller l’authentification sur votre hôte Devin Enterprise et/ou votre compte, afin que devin auth login ignore le menu de sélection de la méthode de connexion et refuse tout compte extérieur à votre organisation.
  • Imposer un proxy HTTP sortant pour la CLI et son programme de mise à jour. Le paramètre Enterprise prévaut sur la configuration utilisateur. Un utilisateur ayant également une section proxy dans sa propre configuration doit la supprimer avant de pouvoir démarrer la CLI — consultez proxy avant de déployer cette configuration.
Le fichier est facultatif et cumulatif : lorsqu’il est absent, Devin CLI se comporte exactement comme sur un appareil non géré.

​
Emplacement du fichier

Il s’agit des mêmes répertoires à l’échelle de la machine, accessibles en écriture par les administrateurs, que Devin Desktop utilise pour les règles et les hooks au niveau du système. Déployez le fichier en le faisant appartenir à root/Administrator et en accordant aux utilisateurs standard des autorisations en lecture seule : la CLI le lit partout où elle le trouve, donc un emplacement accessible en écriture aux utilisateurs compromet l’objectif de la politique.

​
Exemple

system.json est analysé en tant que JSON strict : les commentaires et les virgules finales ne sont pas pris en charge ici, contrairement au fichier config.json de l’utilisateur, qui utilise du JSON avec commentaires. Le commentaire ci-dessus est affiché uniquement pour indiquer le chemin du fichier.

​
Référence des options

Chaque champ est indépendant : définissez uniquement ceux dont vous avez besoin. Les champs inconnus sont ignorés ; ainsi, une politique écrite pour une version plus récente de l’interface CLI applique toujours les paramètres qu’elle connaît à une version antérieure.

​
enterprise_host

Lorsqu’il est défini, devin auth login :
  1. Ignore le menu des méthodes de connexion et l’invite de saisie du sous-domaine, puis effectue l’authentification directement auprès de l’hôte configuré.
  2. Rejette toute connexion lorsque le compte associé appartient à un autre hôte (ou à aucune entreprise Devin) et affiche un message indiquant à l’utilisateur l’hôte approprié.
  3. Refuse entièrement l’ancien parcours de connexion à Windsurf.
La valeur est comparée sans tenir compte de la casse et du schéma. Ainsi, acme.devinenterprise.com, ACME.DevinEnterprise.com et https://acme.devinenterprise.com/ sont équivalents. Un schéma http:// explicite est conservé lors de la connexion (utile uniquement pour les tests) ; sinon, https:// est utilisé par défaut.

​
account_id

Lorsqu’il est défini, le compte authentifié doit correspondre à cet identifiant de compte, même si l’hôte correspond déjà. Utilisez-le pour épingler un tenant spécifique sur un hôte partagé. Toute connexion associée à un autre compte, ou à aucun compte, est refusée après vérification du compte. Contactez l’équipe en charge de votre compte Cognition si vous ne savez pas quel identifiant de compte utiliser. La définition de account_id bloque également le parcours de connexion ancien Windsurf, car un compte Windsurf ne peut pas respecter une politique de compte Devin.

​
proxy

Configure la manière dont la CLI achemine son propre trafic HTTP/HTTPS sortant (appels d’API, mises à jour, serveurs MCP). Cette configuration reprend la même structure que la section proxy du fichier de configuration utilisateur : Le binaire devin-updater lit le même paramètre. Les mises à jour en arrière-plan passent donc par le même proxy que la CLI.
Le proxy Enterprise prévaut sur la configuration utilisateur, et il est impossible de configurer un proxy dans les deux fichiers. Si un utilisateur possède également une section proxy dans son config.json, la CLI s’arrête au démarrage et lui demande de la supprimer, plutôt que d’ignorer silencieusement ce paramètre. Demandez à vos utilisateurs de supprimer toute section locale proxy avant de déployer la politique.

​
Comportement et modes de défaillance

Un fichier de politique corrompu ou partiellement interprété ne désactive jamais la CLI : aucune règle n’est appliquée. En revanche, une politique valide est toujours appliquée : Les règles de connexion sont appliquées lors de l’exécution de devin auth login. Les identifiants déjà stockés sur un appareil qui s’est connecté avant le déploiement de la politique ne sont pas revalidés. Déployez donc system.json avant de déployer la CLI, ou demandez aux utilisateurs concernés d’exécuter devin auth logout puis de se reconnecter. Le chemin vers system.json ne peut pas être redirigé par une variable d’environnement dans les builds stable, next ou Enterprise. Les utilisateurs ne peuvent donc pas configurer la CLI pour qu’elle utilise leur propre politique.

​
Vérifier la politique

Sur un appareil géré :
Avec enterprise_host défini, le menu des méthodes de connexion ne doit pas s’afficher et l’URL de connexion affichée doit utiliser l’hôte que vous avez configuré. Vérifiez ensuite la session obtenue :
Une tentative de connexion avec un compte non conforme à la politique échoue et affiche un message explicite indiquant l’hôte ou le compte exigé par votre organisation. system.json définit les politiques au niveau de l’appareil qui doivent être en place avant ou pendant la connexion. La plupart des autres contrôles à l’échelle de l’organisation — modèles, serveurs MCP et registres, autorisations du terminal, application du sandbox, Web Search — sont gérés côté serveur dans les Team Settings et s’appliquent automatiquement dès qu’un utilisateur se connecte.

​
Pour aller plus loin