Skip to content

Bonnes pratiques de modélisation

DorineLam edited this page Sep 16, 2024 · 49 revisions

Ces lignes directrices documentent les consensus construits au sein de la communauté de personnes qui modélisent le modèle socio-fiscal français depuis des années, au fur et à mesure que des questions sont apparues.

Un point important d'étape date de 2021, où deux RFC, respectivement sur les variables et les paramètres ont été menées pour établir un consensus sur cette mise en forme. Les raisons des choix faits à l'époque sont détaillés dessus.


Variables

Nommage des variables

Préfixes

  • Si une variable décrit la réalité, sans interprétation législative, on ne préfixe pas son nom. Par exemple : distance entre domicile et lieu d'études (distance_domicile_etudes), âge (age) peuvent être décrites sans avoir besoin de faire référence à un autre concept.
  • Si une variable décrit la réalité dans une certaine interprétation définie par la loi, on ne préfixe pas selon le contexte de réutilisation mais on décrit l'interprétation retenue dans le nom de la variable. Par exemple : distance entre domicile et lieu d'études en kilomètres, distance orthodromique à l'hexagone (distance_orthodromique plutôt que aides_mobilite_distance).

Sinon, on a un risque de faible découvrabilité par les réutilisateurs, et de multiplication des variables qui seront redéfinies pour chaque contexte d'usage, ce qui a un coût mémoire.

Variables intermédiaires

  • Par défaut, on minimise le nombre de variables intermédiaires. Sinon, on a un risque de doublon, un coût mémoire et une perte de découvrabilité. Voir par exemple les variables créées dans le code M de la DGFIP.
  • Une variable intermédiaire peut être créée si la définition qu'elle modélise est réutilisable, complexe, ou si son implémentation est vraiment trop lourde. L'arbitrage se fait donc en priorité sur la complexité de la formule de calcul.






Paramètres

Champs obligatoires

Les paramètres OpenFisca représentent la loi le plus fidèlement possible. Chaque évolution de valeur doit être justifiée par une référence législative.

Ainsi, seuls 3 champs sont obligatoires lors de la création d'un paramètre: son label, sa value et la reference associée.

Par convention, les #commentaires sont interdits, et seront supprimés automatiquement à la validation. Il est recommandé de mettre ses annotations directement dans le champ documentation.

label

Ce champ obligatoire est une description en français du paramètre. Il n'est pas limité mais est auto-suffisant, c'est à dire que tout le contexte du paramètre ou le dispositif dans lequel il intervient doit être indiqué, ce qui le contraint automatiquement à une unicité dans le système socio-fiscal.

Par convention, il doit contenir le nom de l'ensemble des nœuds traversés dans l'arborescence depuis le dossier parameters. Il est toléré de raccourcir un peu le label s'il est vraiment trop long et que certaines choses sont explicites (par exemple, si l'on parle des "prestations pour la petite enfance", on ne sera pas obligé de répéter "prestations pour la petite enfance parmi les prestations familiales des prestations sociales").

Si la périodicité n'est pas triviale, alors il faut la préciser.

On demande aussi une expansion des abréviations et les abréviations entre parenthèses.

  • Nom : label
  • Type : Langage naturel non limité, sur une seule ligne, sans espace en début ni fin, unique dans le système socio-fiscal.
  • Échelle de déclaration : Racine du paramètre
  • Cas d'usage :
    • Désambiguer un paramètre dont le nom est une abréviation.
    • Rechercher et afficher un paramètre dans l'explorateur de législation.
  • Exemples :
    • Taux réduit de la Contribution sociale généralisée (CSG) imposable sur les allocations chômage
    • Montant minimum journalier de l'allocation retour emploi (ARE) hors Mayotte
    • Contribution exceptionnelle sur les hauts revenus



values / brackets

Le champ values contient les valeurs des paramètres à partir de leur date d'application dans le calcul.

En effet, la date associée à un paramètre étant celle appliquée pour les simulations, il s'agit de la date d'entrée en application du point de vue du CALCUL du dispositif. Or, cette date peut être différente de la date de publication du texte ou d'application (elle peut être mentionnée à la fin du texte officiel qui met en place la réforme, dans un décret d'application, etc.)

Dans le cas d'un barème, ce champ se nomme brackets et contient deux sous unités: un seuil (threshold) et une valeur (qui peut être un taux rate, un montant amount, ...)

Lorsqu'un dispositif est éteint, les values passent à null, et non pas à 0 qui indique juste la valeur du paramètre (on a vu certains paramètres passer à zéro pendant une année sans que le dispositif ne soit éteint pour autant).

Pour l'Impôt sur le Revenu, il y a une subtilité supplémentaire :
  • d'une part, l'IR est un dispositif annuel, donc sa date d'application pour le calcul de l'impôt ne peut être qu'un 1er janvier.
  • D'autre part, la convention actuelle dans Openfisca est en "année revenus", c'est-à-dire que la variable irpp pour une année N correspond, non pas à l'IR de la déclaration de revenus faite en année N, mais à l'IR au titre des revenus de l'année N (déclaration en N+1).

Donc, les paramètres de l'IR N+1 sur les revenus N sont à mettre systématiquement au 01/01/N. Une alternative serait une convention en "année paiement" (l'irpp de l'année N serait l'impôt effectivement payé en N), mais l'impôt sur les revenus N n'est pas forcément payé en N+1. N+1 n'est que la date de déclaration. Pour le paiement, il y a maintenant le prélèvement à la source et avant, il y avait un système d'acomptes et chaque contribuable pouvait choisir entre différentes options.

  • Nom : values ou brackets
  • Type : Float
  • Échelle de déclaration : Racine du paramètre
  • Exemple dans le cas d'un paramètre simple:
values:
    1995-01-01:
      value: null
    1994-07-01:
      value: 74.01
    1993-01-01:
      value: 72.92
    1992-07-01:
      value: 71.98
    1992-01-01:
      value: 70.71
  • Exemple dans le cas d'un barème:
brackets:
  - rate:
      1967-10-01:
        value: 0.095
      1970-08-01:
        value: 0.1025
      1981-11-01:
        value: 0.0545
      1984-01-01:
        value: null
    threshold:
      1967-10-01:
        value: 0.0
      1984-01-01:
        value: null
  - rate:
      1967-10-01:
        value: 0.02
      1976-01-01:
        value: 0.025
      1981-11-01:
        value: 0.08
      1984-01-01:
        value: 0.126
      1992-01-01:
        value: 0.128
      2016-01-01:
        value: 0.1284
      2018-01-01:
        value: 0.13
    threshold:
      1967-10-01:
        value: 1.0
      1984-01-01:
        value: 0.0



reference

Une référence législative est exigée à chaque ajout ou modification d'une valeur, afin d'identifier la loi d'où provient le paramètre et ainsi permettre la revue des modifications implémentées. La règle est de fournir une référence où l'on peut identifier la valeur concernée EN UN CLIC.

Ainsi, cette référence peut être un lien direct vers l'article en vigueur à date ou le lien vers le décret qui modifie la valeur (à condition que la valeur soit écrite directement sur le lien, pour cela on utilisera la version initiale du décret), ou, idéalement, les deux. Il est impératif que la référence soit officielle (lien LégiFrance vers un article ou un décret, circulaire officielle, etc.) et il est préférable de sélectionner un article de loi codifié.

On demande systématiquement un intitulé title et un URL url pour chaque référence législative. Exceptionnellement, on tolère un title seul dans les cas où l'url n'existe pas (paramètres très anciens).

Bonne pratique d'écriture et règles de syntaxe

Bonne pratique d'écriture du titre

Pour le titre title, il est utile de suivre les règles suivantes pour harmoniser l'écriture des références :

  • Mettre le nom de l’article avant le nom de la loi ou du Code qui l’englobe.
  • Toujours spécifier le Code si l’article est codifié.
  • Mettre une majuscule à « Code » et une minuscule pour les mots qui suivent.

Exemple : Article 197 du Code général des impôts

  • S’il est utile d’ajouter le paragraphe ou le numéro de l’article. Séparer par une virgule :

Exemple : Article 197, 1. du Code général des impôts

  • Si vous souhaitez ajouter le numéro de l’alinéa (pertinent uniquement si l’article est très grand, à éviter dans les autres cas, car ça alourdit beaucoup la référence) :
Exemple : 
- Article 197, 1. §5 du Code général des impôts
- Article 197, 1. §§5 à 10 du Code général des impôts

Bonne pratique d'écriture de l'URL Légifrance : sans date et sans section 

Retirer la date de votre consultation dans l'URL

Lorsque vous sélectionnez une URL sur Légifrance, celle-ci contient souvent par défaut la date du jour de la consultation. Cette date ne correspond à rien de légal, retirez-là.

À éviter : Une URL avec la date de votre consultation. https://www.legifrance.gouv.fr/codes/article_lc/LEGIARTI000044978323/2022-10-31/

Retirer le parcours de recherche et la section

Il faut retirer tout ce qui est après le numéro de l’article, qui correspond au parcours de recherche dans Legrifrance et qui n’apporte pas d'informations.

À choisir  : https://www.legifrance.gouv.fr/codes/article_lc/LEGIARTI000044978323

À éviter : Voici un exemple d’url qui n’a pas été nettoyée : https://www.legifrance.gouv.fr/codes/article_lc/LEGIARTI000044978323?init=true&nomCode=E92-7A%3D%3D&page=1&query=&searchField=ALL&tab_selection=code

Règles de la syntaxe YAML

Pour que la référence passe les tests et fonctionne, voici quelques éléments de syntaxe à respecter :

Ajouter plusieurs références au même paramètre

Pour mettre plusieurs références pour un même paramètre, il faut créer une liste avec des tirets. => Ce fichier yaml est un bon exemple de référence, où il peut y avoir plusieurs références pour une seule et même date.

À faire :

values:
  2003-07-01:
    value: 1000
    reference:
      - title: Article 197 du Code général des impôts
        url: https://www.legifrance.gouv.fr/URLdeLaPremiereReference 
      - title: Décret 2003-573 du 27/06/2003
        url: https://www.legifrance.gouv.fr/URLdeLaSecondeReference      
      

Ne fonctionne pas : Il faut veiller à garder la syntaxe ci-dessus, y compris l’indentation, sinon les tests ne passent pas. L'exemple ci-dessous ne fonctionnera pas car l'indentation n'a pas été respectée pour les 2 références ci-dessous :

values:
  2003-07-01: 
    value: 1000
    reference:
    - url: https://www.legifrance.gouv.fr/URLdeLaPremiereReference 
    title: Article 197 du Code général des impôts
      - url: https://www.legifrance.gouv.fr/URLdeLaSecondeReference         
      title: Décret 2003-573 du 27/06/2003

Les références sans url

On notera, qu'à l'heure actuelle, il existe aussi de nombreuses références sans url. Elles prennent alors la forme suivante:

  base:
    values:
      1979-07-01:
        value: 150
  metadata:
+   reference:
+     1979-07-01:
+      - Loi cadre 79-32 du 16/01/1979
+      - Arrêté du 02/05/1979 portant agrément de la convention du 27/03/1979

Cas particulier : Ajout d'une référence plus récente

Je suis dans une situation où j'ai besoin d'ajouter une référence dont la date est postérieure à la dernière valeur du paramètre :

  1. La référence (article) d'une valeur a changé, mais pas sa valeur.
  2. La seule référence en ma possession est postérieure à la dernière valeur.
  3. Le dispositif a changé (réforme) mais pas cette valeur.
  4. Je trouve une référence récente qui détaille un mécanisme ou une réforme.

Dans les cas 1, 2 et 3, on peut ajouter cette référence (à la date de la value) si celle-ci n'est pas redondante avec les références précédentes. (Par redondant, on entend: le même lien LégiFrance mais pas à la même date).

Dans le cas 4, cette référence étant un peu plus large que la value, il faudra plutôt l'ajouter dans le champ documentation.

On notera qu'il a été décidé de ne pas ajouter de values dans le futur (même si on a déjà des décrets publiés, car la loi peut changer d'ici-là et le risque serait de ne pas s'en aperçevoir).

  • Nom : reference
  • Échelle de déclaration : Champ value
  • Cas d'usage :
    • Vérifier la validité d'une formule en consultant son origine légale.
    • Afficher l'intitulé de la source légale dans l'explorateur de législation.
    • Automatiser la détection d'un changement législatif.
  • Exemples :
values:
  2021-01-01:
    value: 1592
    reference:
+     - title: Article 197, I.1. du Code général des impôts
+       url: https://www.legifrance.gouv.fr/codes/article_lc/LEGIARTI000042907517/2022-01-01/
+     - title: LOI n° 2021-1900 du 30/12/2021 de finances pour 2022, art. 2, I, b)
+       url: https://www.legifrance.gouv.fr/jorf/article_jo/JORFARTI000044637653
  2022-01-01:
    value: 1678
    reference:
+     - title: Article 197, I.1. du Code général des impôts
+       url: https://www.legifrance.gouv.fr/codes/article_lc/LEGIARTI000042907517/2023-01-01/
+     - title: LOI n° 2022-1726 du 30/12/2022 de finances pour 2023, art. 2, I, b)
+       url: https://www.legifrance.gouv.fr/jorf/article_jo/JORFARTI000046845640
values:
  2020-06-01:
    value: 200
    reference:
+       title: Décret n°2020-769 du 24/06/2020, art. 2
+       url: https://www.legifrance.gouv.fr/jorf/article_jo/JORFARTI000042032526
values:
  2020-10-01:
    value: 150
+   reference:
+     title: Décret n°2020-1453 du 27/11/2020, art. 2
+     url: https://www.legifrance.gouv.fr/jorf/id/JORFTEXT000042574431
metadata:



Champs facultatifs : metadata



short_label

La métadonnée short_label répond au besoin d'un nom non-ambigu avec un nombre connu (limité) de caractères. Ce nom court autorise les abréviations les plus connues. Il peut servir dans des interfaces graphiques (sites, tableaux, graphiques, etc.)

Il s'inscrit toujours dans un contexte de présentation reprenant l'arborescence du yaml, permettant ainsi de différencier deux paramètres ayant le même short_label.

Cette métadonnée est aussi introduite dans les index.yaml (cf. section ci-dessous).

Ce champ est optionnel.

  • Nom : short_label
  • Type : langage naturel limité à 70 caractères, sur une seule ligne, sans espace en début ni fin.
  • Échelle de déclaration : Champ metadata
  • Cas d'usage :
    • Afficher un nom reconnaissable par une personne non experte du modèle OpenFisca dans un espace d'affichage connu d'avance.
    • Faciliter la construction d'interfaces graphiques en ayant une contrainte connue de taille d'affichage.
  • Exemples :
    • Taux réduit
    • Fonds national d'aide au logement (FNAL)
Dans certains cas, le `short_label`, même présenté dans son contexte d'arborescence, peut prêter à confusion.

Exemple: Pour le paramètre parameters.prelevements_sociaux.contributions_sociales.csg.chomage.imposable.taux_reduit.yaml, l'arborescence des short_label (dans les index.yaml des noeuds, puis dans le paramètre final) devrait être le chemin suivant:

Prélèvements sociaux / Contributions de Sécurité sociale du régime général / CSG / Chômage / Imposable / Taux réduit

Cependant, on va s'autoriser un peu de redondance par souci de clarification:

Prélèvements sociaux / Contributions de Sécurité sociale du régime général / CSG / **Allocations** chômage / **CSG** imposable / Taux réduit

Ceci permet de souligner deux choses :

  • La CSG est prélevée sur les allocations chômage et non pas pour l'assurance chômage
  • Il s'agit de la part imposable de CSG et non pas d'une CSG prélevée sur la part imposable des allocations chômage


label_en

Le champ label_en est est affiché sur la version anglaise du site des Barèmes Ipp. Il s'agit de la traduction en anglais du champ label.

Ce champ est optionnel.



last_value_still_valid_on

Ce champ permet d'enregistrer une information: le fait que quelqu'un ai vérifié à la date XX que la dernière valeur (value) du paramètre était toujours la valeur en vigueur pour ce paramètre à la date XX.

Par définition, il ne permet de ne vérifier qu’une seule valeur de la série : la dernière en vigueur. Ainsi, la date de ce champ est forcément postérieure ou égale à la dernière valeur du paramètre (et ceci peut facilement être vérifié en CI).

En pratique, il est impératif de fournir la référence législative à date affichant directement la dernière valeur à jour. Si cet url est une information nouvelle (par exemple, changement d'emplacement de l'article dans le code), le contributeur peut décider de l’ajouter dans les références au niveau de la dernière date de value. On mettra l'url à date uniquement dans la merge request dans le cas où il est déjà dans les références, afin d'éviter les redondances.

Ce champ est optionnel et permet ainsi la capitalisation progressive de cette information dans la base de paramètres.

  • Nom : last_value_still_valid_on
  • Type : String contenant une date
  • Échelle de déclaration : Champ metadata
  • Cas d'usage :
    • Indiquer qu’un paramètre est à jour, même si sa valeur n’a pas changé depuis X années.
    • Indiquer en front la dernière date de validité du code
  • Exemple :
values :
  2020-04-01:
    value: 200
    reference:
      title: Décret n° 2020-769 du 24/06/2020, art. 2
      url: https://www.legifrance.gouv.fr/loda/id/JORFTEXT000042032514
metadata:
+  last_value_still_valid_on: "2023-01-24"



official_journal_date

Anciennement 'date_parution_journal_officiel' côté IPP, ce champ a été renommé en anglais lors de l'intégration à OpenFisca.

Il se compose des dates de publication dans le Journal Officiel, pour chaque value. S’il y a plusieurs publications par date, on fait un tableau [2019-01-01, 2019-01-04].

Ce champ est optionnel.

  • Nom : official_journal_date
  • Échelle de déclaration : Champ metadata
  • Cas d'usage :
    • Pouvoir retrouver la publication dans le journal officiel
  • Exemples :
values:
  2021-01-01 :
    value: 200
    reference:
      title: Décret n°2020-769 du 24/06/2020, art. 2
      url: https://www.legifrance.gouv.fr/jorf/article_jo/JORFARTI000042032526/
  2018-10-01 :
    value: 190
    reference:
      title: Décret n°2020-743 du 10/06/2018
      url: https://www.legifrance.gouv.fr/jorf/id/JORFTEXT000042032514
metadata:
+  official_journal_date : 
+     2021-01-01 : "2020-06-24"
+     2018-10-01 : [2018-06-12, 2018-06-10]



unit

Cette metadata indique l'unité du paramètre

Ce champ est optionnel et permet ainsi la capitalisation progressive de cette information dans la base de paramètres.

  • Nom : unit
  • Type : String
  • Échelle de déclaration : Champ metadata
  • Cas d'usage :
    • Harmoniser les unités entre paramètres
    • Indiquer en front une unité claire et documentée
  • Exemple :
metadata:
+  unit: currency

La liste des unités se trouve actuellement dans ce fichier units.yaml.



ipp_csv_id

Le champ ipp_csv_id est directement issu de l'harmonisation avec l'IPP, et sert à la génération de leur site.

Ce champ est optionnel et sera retiré à l'issue du chantier d'harmonisation avec les barèmes de l'IPP.



notes

Le champ notes contient des informations spécifiques à une date.

Ce champ est optionnel.

  • Nom : notes
  • Type : Texte libre
  • Échelle de déclaration : Champ metadata
  • Cas d'usage :
    • Ajouter une information spécifique à une value ou une année
    • Ajouter une note en bas de chaque fichier Excel des barèmes IPP.
  • Exemples :
  values:
    2021-01-01:
      value: 200
  metadata:
+    notes:
+     2021-01-01: Ce montant ne concerne plus les retraités



documentation

Ce champ de texte libre contient des informations relatives au paramètre, notamment des explications générales, l'extension des acronymes, ou encore des références législatives plus larges que des valeurs spécifiques (par exemple Service-Public ou l'Urssaf).

Ce champ est optionnel et vise à accueillir tous les #commentaires qui seront bientôt supprimés.

  • Nom : documentation
  • Type : Texte libre
  • Échelle de déclaration : Racine du paramètre
  • Cas d'usage :
    • Indiquer les limites ou les choix faits pour la modélisation.
    • Ajouter des information complémentaires.
  • Exemples :
documentation: |
   À partir de 2014, des seuils spécifiques (célibataire, couple) sont employés pour le calcul de la décote.
documentation: |
  La taxe d'apprentissage est créée par la Loi de finances du 13 juillet 1925. La loi 77-704 du 05/07/1977créé une cotisation supplémentaire de 0,2% pour financer la formation en alternance; elle doit être versée de manière exceptionnelle en 1977. Elle a été maintenue par la LFR pour 1978. En 1990, la contribution supplémentaire de 0,10% est remplacée par une cotisation pérenne de 0,10% pour la formation en alternance.
documentation: |
  Une incertitude subsiste sur le taux applicable en Alsace-Lorraine entre 1973 et 1978 inclus. Taxe d'apprentissage : CGI, art. 224 et s. et art. 140 A et s. de l'annexe I ; pour l'Alsace-Moselle, art. 1599 ter J.




Exemple d'un paramètre complet

description: Montant (en % de la BMAF) de l'Allocation d'adoption (AA), une des prestations sociales familiales pour la petite enfance
values:
  1995-01-01:
    value: 0.3
  1996-08-01:
    value: 0.4595
  2007-01-01:
    value: null
metadata:
  order:
  short_label: Montant
  last_value_still_valid_on: "2022-02-22"
  description_en: "Adoption allowance (AA): General conditions and amounts"
  ipp_csv_id: aa_montant
  unit: BMAF
  reference:
    1996-08-01:
    - title: Article 197, I.1. du Code général des impôts
      url: https://www.legifrance.gouv.fr/codes/article_lc/LEGIARTI000042907517
    - title: Décret n°2020-769 du 24/06/2020, art. 2
      url: https://www.legifrance.gouv.fr/jorf/id/JORFTEXT000042032514
    2007-01-01:     
    - title: Décret n°2020-1453 du 27 novembre 2020
      url: https://www.legifrance.gouv.fr/jorf/id/JORFTEXT000042574431
  official_journal_date:
    1995-01-01: "1995-02-17"
    1996-08-01: "1996-07-06"
    2007-01-01: "2003-12-19"
  notes:
    1995-01-01:
    - title: Pas cumulable avec l'ASF. Pour les enfants nés à partir du 01/01/1995; Le décret 95-165 du 16/02/1995 crée l'Allocation à l'Adoption
    1996-08-01:
    - title: Loi qui assure la parité des droits sociaux attachés à la naissance et à l'adoption.; Loi qui aligne l'allocation d'adoption sur l'APJE. Mêmes montants et mêmes plafonds (par contre, durée de l'aide, à fixer par décret).
documentation: |
  Après 2007, la PAJE remplace en partie l'allocation d'adoption. Mais, transition progressive, jusqu'à fin 2006 (cf. art. 60, VIII de la loi)



FAQ - Cas particuliers et questions ouvertes

Selon les paramètres, il arrive de rencontrer des cas un peu particuliers. Voici une liste des décisions prises pour chacun de ces cas. À noter qu'elles n'ont pas fait l'objet d'une RFC, et ne sont donc pas le résultat d'un consensus, mais plutôt de bonnes pratiques observées.



1 - Ajout de références 'récentes'

Est-ce que je peux ajouter une reference qui a une date postérieure à la dernière valeur du paramètre ?

Exemples:

  1. La référence (article) d'une valeur a changé, mais pas sa valeur.
  2. La seule référence en ma possession est postérieure à la dernière valeur.
  3. Le dispositif a changé (réforme) mais pas cette valeur.
  4. Je trouve une référence récente qui détaille un mécanisme ou une réforme.

Dans les cas 1, 2 et 3, on peut ajouter cette référence si celle-ci n'est pas redondante avec les références précédentes. (Par redondant, on entend: le même lien LégiFrance mais pas à la même date)

Dans le cas 4, cette référence étant un peu plus large que la value, il faudra plutôt l'ajouter dans le champ documentation.



2 - Le short_label peut porter à confusion

Dans certains cas, le short_label, même présenté dans son contexte d'arborescence, peut prêter à confusion.

Exemple: Pour le paramètre parameters.prelevements_sociaux.contributions_sociales.csg.chomage.imposable.taux_reduit.yaml, l'arborescence des short_label (dans les index.yaml des noeuds) devrait être le chemin suivant:


Prélèvements sociaux / Contributions de Sécurité sociale du régime général / CSG / Chômage / Imposable / Taux réduit


Cependant, on va s'autoriser un peu de redondance par souci de clarification:


Prélèvements sociaux / Contributions de Sécurité sociale du régime général / CSG / Allocations chômage / CSG imposable / Taux réduit


Ceci permet de souligner deux choses:

  • La CSG est prélevée sur les allocations chômage et non pas pour l'assurance chômage
  • Il s'agit de la part imposable de CSG et non pas d'une CSG prélevée sur la part imposable des allocations chômage



/// FIN DE LA PARTIE EN DRAFT ///





Index

Dans le dossier parameters, chaque sous-dossier doit contenir un fichier index.yaml, qui explicite le noeud correspondant. La création d'un tel fichier est obligatoire lors de l'ajout d'un dossier.

Ce fichier se compose ainsi:

label: Cotisations du régime d'assurance maladie
metadata:
  short_label: Assurance Maladie
  description_en: SSCs of the sickness scheme

Chacun de ces champs respecte les mêmes règles que pour les paramètres (cf. ci-dessus).





Tests

  • Les tests doivent être faits sur les variables le plus en aval possible. Les différents cas doivent être distingués par des différences d'attributs en amont et non avec des valeurs différentes pour les variables intermédiaires. Sinon, le risque est de ne pas arriver à tester des situations réelles mais des abstractions partielles.