Le fichier de configuration pss.json

Cette page décrit le format du fichier pss.json : comment le document est construit, ce que le service accepte à la lecture et ce qui se perd à l’écriture. Elle s’adresse à ceux qui modifient le fichier directement ou transportent les paramètres vers un autre nœud.

Une modification du fichier prend effet au prochain démarrage. Pour changer la configuration d’un service en fonctionnement, utilisez l’interface web ou l’API HTTP (Pilotage via l’API HTTP) — elles seules appliquent une modification immédiatement et en rendent compte.

Les procédures pas à pas de modification, de vérification et de transport — Modifier, vérifier et transporter les paramètres.

Ce qu’est ce fichier

pss.json est le fichier de configuration en service, dans le répertoire /opt/pss/config. L’ordre de chargement, le repli sur pss_back.json et pss_default.json ainsi que l’archive des fichiers endommagés dans le répertoire bad/ sont décrits dans Comportement au démarrage et en cas d’erreurs de configuration.

Une conséquence de cet ordre doit être gardée en tête avant d’ouvrir le fichier dans un éditeur : une seule valeur inacceptable coûte tous les flux. Le fichier n’est pas réparé par morceaux — il est rejeté en entier, et le repli mène à pss_default.json, qui ne contient aucun flux. La copie de sauvegarde pss_back.json n’existe que là où les paramètres ont été restaurés au moins une fois via l’interface web (Maintenance) ; le service ne tient pas de sauvegarde régulière. C’est précisément pour cela que le fichier se vérifie avant que le service ne le lise.

Le fichier n’est pas une description complète de la configuration : il ne conserve que les écarts par rapport aux valeurs avec lesquelles le produit a été compilé. Ce qui en découle figure dans la section suivante ; c’est le point le plus important à comprendre avant de modifier quoi que ce soit.

Dans le même répertoire se trouve pss.properties — les paramètres globaux du processus (chemins vers les données et les journaux, et ainsi de suite). C’est un fichier « clé=valeur » avec sa propre syntaxe, il n’a rien à voir avec JSON, et rien de ce qui est dit ici ne s’y applique.

Le fichier ne contient que les écarts par rapport aux valeurs par défaut

À l’écriture du fichier, le service omet toute valeur simple identique à la valeur par défaut. Seuls les écarts sont enregistrés.

Il en découle trois choses, dont chacune se rencontre en pratique :

• Le fichier ne permet pas de savoir comment le service est configuré. Une clé absente signifie la valeur par défaut, et cette valeur n’est écrite nulle part dans le fichier. Pour lire la configuration effective en entier, demandez-la au service en fonctionnement via l’API HTTP : toutes les clés y sont renvoyées, y compris celles restées à leur valeur par défaut.

• Écrire une clé avec sa valeur par défaut ne sert à rien. Une telle valeur est acceptée, et à l’enregistrement suivant du fichier elle disparaît.

• Un changement de valeur par défaut entre versions modifie le comportement en silence. Si le nœud n’a jamais redéfini cette clé, elle n’est pas dans le fichier — et après une mise à jour elle fonctionnera avec la nouvelle valeur par défaut dès le premier démarrage, sans que le fichier en dise rien. C’est le principal risque lors du transport des paramètres entre versions, et le fichier lui-même ne le révèle pas. Il n’y a qu’un seul moyen de voir un tel changement : lire la configuration effective des deux versions via l’API HTTP, où les valeurs par défaut sont également renvoyées.

L’omission ne concerne que les valeurs isolées. Les sections et les listes elles-mêmes sont toujours écrites, même lorsqu’il n’y reste rien : "user-default": {} est une section dont toutes les clés sont à leur valeur par défaut, et "accept-stream": [] une liste vide écrite selon la même règle. Des crochets vides ne disent ni que le paramètre a été défini, ni qu’il a été omis : reportez-vous au sens de la clé concernée.

Structure du document

Le document est un unique objet JSON. Ses membres de premier niveau sont les sections de paramètres :

Section	Type	Ce qu’elle décrit
server	objet	Nom et rôle du nœud, journalisation, maintenance.
cluster	objet	Meshwork : adresses, noms et secrets des nœuds voisins.
user-default	objet	Réservée, ne contient pas encore de clés.
user	tableau	Les comptes des destinataires de flux et des partenaires.
web-server	objet	L’interface web et ses comptes.
http-server	objet	La diffusion des flux en HTTP.
epg-server	objet	La diffusion du guide des programmes.
cs	objet	Serveurs externes de gestion des abonnés.
mosaic	objet	Activation de la mosaïque.
epg	objet	La collecte du guide des programmes et ses sources.
alerter	objet	Les seuils des alertes et les adresses de remise.
acme	objet	L’obtention automatique des certificats.
dvb-adapter	tableau	Cartes de réception DVB.
dvr-storage-list	objet	Stockages de l’archive DVR.
stream	tableau	Flux.
stream-adaptive	tableau	Groupes de débit adaptatif.

Les tableaux de premier niveau contiennent toujours des objets. À l’intérieur des sections et des entrées, on rencontre aussi de simples listes de valeurs — nombres et chaînes ; à leur sujet, voir Les tableaux appariés se correspondent par position. Les objets des tableaux contiennent à leur tour des tableaux d’objets imbriqués : la profondeur maximale du document est donc de trois niveaux :

stream[]  ->  input[]   ->  les clés d'une entrée
          ->  output[]  ->  les clés d’une sortie

Les clés des sections simples sont toutes facultatives, et l’absence d’une section entière n’est pas une erreur.

Les entrées de tableau font exception. Outre id, chaque entrée doit porter ses clés d’ancrage : un flux — stream-name, une entrée et une sortie — type et l’adresse ou le chemin du transport choisi, une carte de réception — name, un stockage — name et dir-path, un compte de l’interface web et du guide des programmes — login et password, une source du guide — name et source. En omettre une seule fait rejeter tout le fichier. Le schéma vérifie ces clés : un contrôle avant le démarrage attrapera donc une telle entrée.

La référence des clés prises une à une — type, plage et valeur par défaut de chacune — se trouve dans le document de référence de l’API HTTP (Documents de référence). Elle n’est délibérément pas reprise ici : deux copies d’une même référence divergent en une seule version.

Ce que fait le service à la lecture du fichier

La lecture est délibérément inégale : dans certains cas le service pardonne l’erreur, dans d’autres il rejette le fichier entier — sa première tâche est de faire démarrer le nœud. C’est exactement là que se situe la différence entre une faute que vous remarquerez et une faute que vous ne remarquerez pas.

Accepté, mais pas comme l’auteur de la modification l’entendait

Ce qui est dans le fichier	Ce que fait le service
Clé inconnue	Ignorée. Un avertissement est écrit dans le journal avec le nom de la clé et celui de la section à laquelle elle s’adresse (pour une entrée de tableau, c’est le tableau qui est nommé, non l’entrée elle-même). Le paramètre que vous vouliez changer ne change tout simplement pas, et une faute de frappe dans un nom de clé reste invisible tant que le journal n’a pas été lu. La clé disparaît du fichier au prochain enregistrement de la configuration, mais ne provoque pas elle-même d’enregistrement et peut y rester longtemps.
Une clé est absente	La valeur par défaut s’applique. Ce n’est pas une erreur.
Une section est absente	Toutes ses clés prennent leur valeur par défaut. Ce n’est pas une erreur.
La même clé deux fois dans une section	La dernière l’emporte en silence. Ni erreur ni avertissement.
Un nombre, ou true et false, entre guillemets	Accepté : la valeur est lue comme du texte puis analysée. Le schéma, en revanche, refusera une telle valeur ; les nombres et les indicateurs s’écrivent donc sans guillemets.
Un nombre hors plage	Ramené à la borne la plus proche, avec un avertissement dans le journal indiquant la clé, la valeur lue et la borne appliquée. Après le chargement, le service réenregistre le fichier avec la valeur corrigée : au démarrage suivant, l’avertissement ne se répète donc pas. La même valeur envoyée via l’API HTTP n’est pas corrigée mais refusée avec une erreur.
Un tableau là où une valeur unique est attendue	Entièrement ignoré, sans la moindre ligne dans le journal. Le paramètre reste à sa valeur par défaut et aucun diagnostic n’apparaît.

Les erreurs de forme autour des listes et une clé répétée sont les cas qui passent dans le silence complet : le journal n’en dira rien. Ce sont eux le principal argument en faveur d’une vérification du fichier avec le schéma avant le démarrage.

Note

Est également inconnue une clé que ce build ne prend pas en charge. Sur un nœud dont le build ne sait pas recevoir le DVB, la section dvb-adapter d’un fichier transporté devient inconnue en entier : un avertissement dans le journal — et au prochain enregistrement elle disparaît du fichier.

Rejeté avec tout le fichier

Chacun de ces cas interrompt le chargement. Le fichier est déplacé dans le répertoire bad/ et le service passe au fichier suivant dans l’ordre (Comportement au démarrage et en cas d’erreurs de configuration).

Ce qui est dans le fichier	Explication
Une erreur de syntaxe JSON	Quelle qu’elle soit.
Une valeur null	N’importe où et pour n’importe quelle clé. null n’est jamais accepté : pour ramener un paramètre à sa valeur par défaut, on supprime la clé.
Une forme de valeur incorrecte	Un objet là où une valeur unique est attendue ; une valeur unique là où un objet ou une liste d’objets est attendu.
Un nombre ou un mot étranger à la place d’un indicateur	Les clés booléennes n’acceptent que true et false — entre guillemets ou non. Ni 1 et 0, ni "yes" et "no" ne sont acceptés.
Une chaîne plus longue que permis	Les limites de longueur, contrairement aux plages numériques, ne sont jamais tronquées.
Un nombre fractionnaire là où un entier est requis	La valeur ne s’analyse pas comme un entier et le chargement s’interrompt. De même pour une chaîne qui ne se lit pas comme un nombre.
Une entrée de tableau sans clé d’ancrage	Outre id, une entrée doit porter ses propres clés obligatoires (Structure du document).
Une entrée de tableau sans id	L’identifiant est obligatoire. L’exception est le tableau stream : un id absent y est lu comme 0, valeur admissible, de sorte que seule la deuxième entrée sans identifiant sera rejetée, comme doublon.
Un id en double	Deux entrées d’un même tableau avec le même identifiant.
La répétition d’une valeur déclarée unique	Plusieurs tableaux exigent qu’une clé soit unique parmi leurs entrées : noms de comptes, noms et chemins des stockages, noms de flux, adresses des sources et d’autres encore.
Une valeur vide là où du texte est requis	À l’intérieur des entrées de tableau, cette exigence est stricte ; dans les sections simples elle n’est pas respectée partout, et il ne faut pas compter sur cette indulgence.
Une valeur qui n’a pas passé le contrôle de la section	Certaines sections vérifient leurs valeurs dans leur ensemble, et un tel contrôle interrompt lui aussi le chargement : caractères non admis ou dépassement de longueur dans le nom du nœud et le nom de domaine, niveau de journalisation inconnu, domaine supplémentaire mal écrit, nombre d’entrées discordant dans les tableaux appariés de Meshwork, longueur discordante des listes de noms et de valeurs des variables d’environnement.

Le journal fait partie de la procédure

Les erreurs du premier tableau n’empêchent pas le démarrage, celles du second l’interrompent. Le seul endroit où les premières sont visibles est le journal après le premier démarrage. Toute ligne à propos d’une clé ignorée ou d’une valeur ramenée à la borne signifie que le fichier dit autre chose que ce que vous y avez écrit.

Des règles invisibles dans le fichier

Ce sont des propriétés de la lecture, non de la syntaxe. Le fichier peut être du JSON irréprochable, passer tous les contrôles de la section précédente et signifier malgré tout autre chose que ce à quoi il ressemble.

L’ordre des clés à l’intérieur d’un objet a du sens

Les clés sont appliquées dans l’ordre où elles sont écrites. À plusieurs endroits, une clé détermine quelles clés existent en aval dans la même entrée, et doit donc les précéder. Une clé écrite au-dessus de sa clé déterminante n’est pas encore reconnue au moment de la lecture et se trouve écartée comme inconnue — avec un avertissement dans le journal et sans erreur de chargement.

Fonctionnent ainsi :

• type dans une entrée d’entrée ou de sortie — il choisit le transport et tout ce qui s’y rapporte ;

• mpts et stream-name dans une entrée de flux. mpts choisit le type de flux et doit précéder, entre autres, les tableaux input et output, tandis que stream-name ouvre les paramètres OTT, d’archive et de multiplex si la clé mpts est absente de l’entrée. La valeur par défaut de la clé enable-mosaic, héritée de mpts, est arrêtée au moment de la lecture de mpts (ou, à défaut, de stream-name) : un enable-mosaic explicitement défini au-dessus de ce point est écrasé par cette valeur, en dessous il est conservé ;

• type et mode dans une entrée de carte DVB — ensemble ils déterminent le jeu de paramètres de configuration, et tous deux doivent précéder la clé name.

Une exception à la règle générale : si les tableaux input et output sont placés au-dessus de mpts, les entrées et les sorties sont construites comme pour un flux à programme unique, et un type admissible uniquement pour un flux à plusieurs programmes entraîne le rejet de tout le fichier et non un avertissement.

Un fichier écrit par le service lui-même satisfait toujours ces règles : le service émet les clés dans un ordre fixe et sûr. Seul un fichier dont l’ordre a été modifié à la main est vulnérable. JSON Schema n’a pas la notion d’ordre : le schéma ne vérifie donc pas ce point. La règle pratique est simple : ne déplacez rien — conservez l’ordre dans lequel le service a écrit le fichier.

Les identifiants se posent à la main

Chaque entrée de chaque tableau possède une clé id. Les identifiants ne sont attribués automatiquement que lors de la création d’une entrée via l’API HTTP ; à la lecture du fichier, personne ne les attribue.

Une entrée ajoutée à la main doit donc porter un id explicite :

• il est obligatoire dans tout tableau — sans lui, tout le fichier est rejeté ;

• il doit être unique à l’intérieur de son tableau ;

• la plus petite valeur admissible est 1 partout, sauf dans le tableau stream, où 0 est également admis.

Pour le tableau stream, il en découle un piège : un id absent y est lu comme 0, c’est-à-dire comme un véritable identifiant. La première entrée sans id passera, la deuxième entrera en collision avec elle et fera rejeter tout le fichier. Pour la même raison, un flux dont l”id vaut 0 s’écrit dans le fichier sans aucune ligne id — ce n’est pas une erreur d’écriture mais la conséquence du fait que zéro est ici la valeur par défaut.

L’unicité des identifiants n’est pas exprimable en JSON Schema : c’est donc l’une des rares règles que le schéma ne vérifiera pas à votre place. Une commande toute prête pour trouver les doublons figure dans Les contrôles que le schéma n’effectue pas.

L’ordre des entrées dans un tableau n’est pas conservé

Le service trie les grandes listes à chaque lecture, chacune selon sa propre clé : les flux par nom affiché, les entrées et sorties d’un flux par la clé d’ordre, les comptes par identifiant, les stockages et les cartes de réception par nom. Quel que soit l’ordre dans lequel vous écrivez ces entrées, le fichier enregistré sera différent. Ne prêtez aucun sens à leur ordre : là où la séquence compte, il existe une clé dédiée.

La règle n’est pas générale, et deux exceptions méritent l’attention :

• quelques listes conservent l’ordre du fichier — en particulier les groupes de débit adaptatif et les serveurs de gestion des abonnés ;

• les listes simples de valeurs ne sont jamais réordonnées. C’est essentiel : c’est précisément sur leur ordre que reposent les tableaux appariés (Les tableaux appariés se correspondent par position).

Les tableaux appariés se correspondent par position

Plusieurs paramètres s’expriment par des tableaux parallèles mis en correspondance par numéro : l’entrée N d’un tableau se rapporte à l’entrée N des autres. Ainsi fonctionnent les adresses, noms et secrets des nœuds Meshwork voisins, les noms et valeurs des variables d’environnement, ainsi que les listes « avant — après » lors de la réattribution d’identifiants. Supprimer une entrée d’un tableau sans supprimer l’entrée correspondante des autres décale tout ce qui suit.

Le schéma vérifiera que chaque tableau contient des éléments du bon type, mais pas que les longueurs des tableaux coïncident. Le service le vérifie lui-même et rejette tout le fichier lorsque les longueurs diffèrent pour les pairs Meshwork, pour les variables d’environnement, pour les listes « avant — après » de la réattribution des PID (mpegts-pid-old et mpegts-pid-new), pour les listes de changement de langue (mpegts-lang-set-pid et mpegts-lang-set) et pour les clés de désembrouillage (biss-pnr et biss-key). Pour le quatuor d’adresses RIST (rist-addr-*), un écart de longueur n’interrompt pas le chargement, mais l’entrée ne s’ouvre pas et la raison est consignée dans le journal. Une commande de vérification toute prête figure dans La longueur égale des tableaux appariés.

Les commentaires sont lus mais non conservés

La lecture admet les commentaires de bloc de la forme /* ... */ — ils sont commodes pendant le travail sur le fichier. Cette forme uniquement : le commentaire de ligne // n’est pas pris en charge et rend le fichier syntaxiquement incorrect, c’est-à-dire le fait rejeter en entier. Pour la même raison, n’écrivez pas la séquence /* à l’intérieur d’une valeur textuelle — elle serait prise pour un début de commentaire.

Les commentaires ne survivent pas à un enregistrement : le service reconstruit le document à chaque fois à partir de ce qu’il garde en mémoire, si bien que le premier enregistrement les efface tous. Considérez-les comme des annotations le temps de la modification, et écrivez ce qui doit subsister dans la clé note, présente dans la plupart des sections et des entrées.

Les outils JSON stricts — dont le validateur de Modifier, vérifier et transporter les paramètres — n’analyseront pas un fichier comportant des commentaires. On supprime les commentaires avant la vérification.

Jeux de clés conditionnels

Deux clés font office d’interrupteurs et déterminent quelles clés sont admissibles à leurs côtés :

• Dans les entrées d’entrée et de sortie, type choisit le transport. Chaque transport a son propre jeu de clés ; une clé d’un autre transport n’est pas reconnue.

• Dans les entrées de carte DVB, type choisit le système de diffusion et mode le mode de fonctionnement. Ensemble ils déterminent le jeu de clés de configuration, jusqu’à savoir s’il existe des clés de convertisseur.

Le schéma reproduit ces conditions et refusera une clé n’appartenant pas à la variante choisie. Le seul cas qu’il ne peut pas exprimer est celui d’une clé dont la forme dépend d’un interrupteur dans l’objet englobant : dans un flux à plusieurs programmes, la clé de désembrouillage (biss-key) s’écrit sous forme de liste, et dans un flux à programme unique, en valeur unique. Le schéma accepte les deux formes partout où cette clé apparaît ; seul le service choisit la bonne.

Des valeurs à ne pas transmettre

Le fichier conserve les mots de passe et les clés en clair. Avant de transmettre la configuration à qui que ce soit — un collègue, une demande de support, un système de tickets, un dépôt public — remplacez les valeurs :

• des mots de passe des comptes dans les sections de l’interface web, du guide des programmes et des destinataires de flux, du mot de passe du serveur de gestion des abonnés, ainsi que de l’identifiant et du mot de passe de la source du guide ;

• du secret propre du nœud et des secrets des nœuds Meshwork voisins ;

• des phrases secrètes des transports et des mots de passe client des entrées PS1 et SRT, du mot de passe de l’entrée RTSP, de l’identifiant et du mot de passe de l’entrée HLS/HTTP ;

• des clés et identifiants de clé de la protection du contenu et des secrets partagés ;

• des clés de désembrouillage ;

• du jeton du bot du service de messagerie et du mot de passe du compte de courrier ;

• de la clé de liaison de l’autorité de certification.

Deux clés ne portent pas de nom évoquant un secret mais en contiennent régulièrement : l’adresse de publication d’une sortie vers une plateforme externe et l’adresse source d’une entrée, si les identifiants sont écrits directement dans le lien.

La liste s’allonge avec chaque nouveau transport : ne la tenez pas pour exhaustive. Avant d’envoyer le fichier, recherchez-y password, secret, key, token et passphrase, et passez chaque lien en revue.

Le fichier n’est pas la seule voie vers ces valeurs : via l’API HTTP, elles sont lisibles par n’importe quel compte du nœud, y compris un rôle en lecture seule (Accès).

Avertissement

Remplacer un secret par une chaîne vide n’est pas toujours sans risque : certaines de ces clés n’acceptent pas la valeur vide et le fichier sera rejeté en entier. Mettez un remplacement manifeste, de longueur plausible.

Vérification avec le JSON Schema

Une description lisible par machine du fichier de configuration au format JSON Schema est publiée avec la documentation. Elle attrape toute une classe d’erreurs que le service lui-même avale en silence — au premier chef une faute de frappe dans un nom de clé et un tableau écrit à la place d’une valeur unique.

Deux fichiers de schéma

Fichier	Rôle
pss.schema.json	Strict. Chaque clé doit figurer parmi celles déclarées par le produit. S’emploie pour un fichier destiné à la version indiquée dans l’en-tête du schéma.
pss.compat.schema.json	Permissif. Les types, les plages, les énumérations et les clés obligatoires sont toujours vérifiés, mais les clés que le produit ne connaît pas sont ignorées. C’est la première passe lors du transport de paramètres depuis une autre version, où des clés inconnues sont attendues et non suspectes.

Les deux schémas portent la version du produit pour laquelle ils ont été générés. Une configuration ne se vérifie utilement qu’avec le schéma de la version qui la lira. Une vérification avec le schéma d’une autre version donne une réponse assurée et fausse.

Avertissement

Le schéma permissif ne laisse pas passer que les clés inconnues. L’appartenance d’une clé à la variante choisie (Jeux de clés conditionnels) repose dans le schéma sur le même mécanisme : lors d’une vérification permissive passe donc aussi une clé authentique écrite dans le mauvais type d’entrée, le mauvais mode de carte ou le mauvais type de flux — et avec elle, sa propre plage n’est pas vérifiée non plus. Le schéma permissif n’est que la première passe ; le dernier mot revient toujours au strict.

Note

Les schémas font partie de la documentation, non du produit : il n’y en a pas de copie dans le répertoire de configuration d’un nœud en fonctionnement, et il n’en faut pas. Ils sont publiés sur le site de la documentation — https://doc2.pstreamer.tv/schema/, un répertoire par version. Prenez le schéma de votre version et gardez-le sur la machine où vous modifiez le fichier.

L’adresse inscrite dans le schéma lui-même, dans la clé $id, est son identifiant et non une consigne de téléchargement : la vérification d’un fichier fonctionne aussi sans accès au réseau.

Ce que le schéma vérifie

• les noms des clés — une faute de frappe devient une erreur au lieu d’un silence ;

• les types des valeurs, y compris un tableau écrit à la place d’une valeur unique ;

• les plages numériques et les limites de longueur du texte ;

• les ensembles fermés de valeurs admissibles ;

• la présence des clés obligatoires, au premier chef id et type ;

• l’appartenance à une variante — une clé d’un autre transport ou d’un autre système de diffusion sera signalée.

Ce que le schéma ne vérifie pas

• l’ordre des clés à l’intérieur d’un objet (L’ordre des clés à l’intérieur d’un objet a du sens) ;

• l’unicité des identifiants et des clés déclarées uniques (Les identifiants se posent à la main) ;

• la longueur égale des tableaux parallèles (Les tableaux appariés se correspondent par position) ;

• la forme d’une clé dépendant d’un interrupteur dans l’objet englobant (Jeux de clés conditionnels) ;

• les références entre sections — si le stockage, la source ou la carte désignés par un numéro existent réellement ;

• tout ce qui dépend de la machine : si le chemin est accessible en écriture, si le port est libre.

Tout ce qui est énuméré est vérifié par le service lui-même à la lecture du fichier, et l’essentiel interrompt le chargement. Le schéma réduit l’écart sans le combler : une vérification réussie signifie que le fichier est correct et vraisemblable, non que le service l’acceptera.

Note

L’API HTTP comporte une famille de requêtes /schema qui renvoient des listes de valeurs admissibles et du matériel détecté — les types d’entrée et de sortie pris en charge par ce build, les langues, les cartes détectées, les périphériques de transcodage. Elles n’ont aucun rapport avec le fichier pss.schema.json, et l’un ne remplace pas l’autre. La coïncidence des noms n’est qu’une coïncidence.

Compatibilité entre versions

Avertissement

La compatibilité ascendante n’est pas garantie. Une mise à jour peut modifier aussi bien le fichier de configuration que le schéma et l’API HTTP : la composition et les noms des clés, les plages de valeurs, la forme des requêtes et des réponses. Une mise à jour ne transpose pas les paramètres et n’avertit pas des écarts. Revérifiez le fichier après chaque mise à jour, et les scripts qui travaillent avec l’API HTTP — après chaque mise à jour également.

Des clés isolées sont ajoutées, renommées et supprimées d’une version à l’autre, et les plages admissibles se resserrent. Une clé supprimée devient inconnue et est ignorée : le paramètre cesse simplement d’agir ; une clé nouvelle agit avec sa valeur par défaut tant qu’elle n’est pas écrite ; une valeur sortie d’une plage resserrée est ramenée à la borne. Le service ne signale aucun des trois.

Le fichier ne porte aucune marque de version. Rien à l’intérieur n’indique la version qui l’a écrit, et le service n’effectue aucune conversion en lisant un fichier issu d’un build plus ancien ou plus récent. Joint à la parcimonie du fichier, cela signifie qu’un fichier transporté s’applique tel quel.

Le schéma est donc le seul moyen pratique de savoir quelles clés d’un fichier existant cette version ne comprend plus. Revérifiez le fichier après chaque mise à jour ; la marche à suivre est Transporter les paramètres vers une autre version.