search

leximpact / leximpact-server

Simuler l'impact des réformes socio-fiscales en moins d'une minute
https://leximpact.an.fr
GNU Affero General Public License v3.0
4 stars 0 forks source link

Spec requête dotations #18

Closed LoicPoullain closed 4 years ago

LoicPoullain commented 4 years ago

Je pose ça là pour l'instant. On pourra transférer l'issue dans un autre dépôt si besoin.

// POST /dotations

interface Request {
reforme: { 
  dotations: {
    // Article L1613-1 du CGCT
    montants: {
      dgf: number;
    }
    communes: {
      dsr: {
        // Article L2334-20 du CGCT
        eligibilite: {
          popMax: number;
          popChefLieuMax: number;
        }
        // Article L2334-21  du CGCT
        bourgCentre: {
          eligibilite: {
            partPopCantonMin: number;
            exclusion: {
              agglomeration: {
                partPopDepartementMin: number;
                popMin: number;
                popCommuneMin: number;
              }
              canton: {
                popChefLieuMin: number;
              }
              potentielFinancier: {
                rapportPotentielFinancierMoyen: number;
              }
            }
          }
          attribution: {
            popLimite: number;
            effortFiscalLimite: number;
            coefMultiplicateurRevitalisationRurale: number;
            pourcentageAttributionMin: number;
            pourcentageAttributionMax: number;
//            plafonnementPopulation: {
//              [recensement: number]: number;
//            }
          }
        }
        // Article L2334-22 du CGCT
        perequation: {
          eligibilite: {
            rapportPotentielFinancier: number;
          }
          attribution: {
            repartition: {
              ponderationPotentielFinancier: number;
              ponderationLongueurVoirie: number;
              ponderationNbreEnfants: number;
              ponderationPotentielFinancierParHectare: number;
            }
            pourcentageAttributionMin: number;
            pourcentageAttributionMax: number;
          }
        }
        // Article L2334-22-1 du CGCT
        cible: {
          eligibilite: {
            premieresCommunes: number;
            indiceSynthetique: {
              ponderationPotentielFinancier: number;
              ponderationRevenu: number;
            }
          }
        }
      }
    }
  };
}
}
LoicPoullain commented 4 years ago

Commentaire de @magemax :

C'est presque complet, On en parle quand tu veux, ci dessous mes remarques (après comparaison avec le code qui tourne sur la DSR) :

montants: {
 dgf: number;
}

===> Ca contiendrait quoi ? Les montants touchés? Donc ce serait que dans la réponse comme champ?

popmax et popcheflieumax : bon c un peu chelou cette phase : le 20000 n'apparaît que dans la description de la fraction bourg-centre, et est explicitement mentionnée à ce moment là. Je déplacerais le 20000 dans bourg-centre. Quand au 10000 dont la loi ne dit pas explicitement ce qu'il fait, je dirais qu'on le met effectivement ici, mais c'est pas clair pour l'usager. bourgcentre ==> bourgCentre

propPopCantonMax : C'est le 15%? Auquel cas je dirais plutôt que c'est une proportion minimum plutôt que maximum. part plutôt que prop ? partPopDepartementMin, propPopCantonMax Quelques "eligibilité" sont devenus "elibilite" (ça fait penser à https://www.youtube.com/watch?v=YcuE54E9coI )

Choses qui manquent :

LoicPoullain commented 4 years ago

C'est presque complet, On en parle quand tu veux, ci dessous mes remarques (après comparaison avec le code qui tourne sur la DSR) : montants: { dgf: number; } ===> Ca contiendrait quoi ? Les montants touchés? Donc ce serait que dans la réponse comme champ?

Le montant total de la DGF alloué par les députés. J'ai rajouté l'article.

popmax et popcheflieumax : bon c un peu chelou cette phase : le 20000 n'apparaît que dans la description de la fraction bourg-centre, et est explicitement mentionnée à ce moment là. Je déplacerais le 20000 dans bourg-centre. Quand au 10000 dont la loi ne dit pas explicitement ce qu'il fait, je dirais qu'on le met effectivement ici, mais c'est pas clair pour l'usager.

Pas de position fixe sur la question. J'imagine juste qu'avoir une structure de requête au plus proche de l'architecture des textes de loi sera plus maintenable sur le long terme (lisibilité, erreurs d'inattention).

bourgcentre ==> bourgCentre

Merci. Corrigé.

propPopCantonMax : C'est le 15%? Auquel cas je dirais plutôt que c'est une proportion minimum plutôt que maximum

Bien vu ! Corrigé.

part plutôt que prop ? partPopDepartementMin, propPopCantonMax

Les deux me vont. Modifié.

Quelques "eligibilité" sont devenus "elibilite"

Bien vu. Corrigé.

  • le seuil max d'habitants (10000) est précisé explicitement dans la partie "fraction cible",

J'imagine qu'on peut rajouter premieresCommunesPopMax. Mon questionnement : est-ce que ce seuil devrait être éditable ? N'est-il pas de facto dotations.communes.dsr.eligibilite.popMax ?

  • le seuil maximum du PFI par habitant pour être éligible à la fraction de péréquation (mais comme tu as mis un "todo" j'imagine que ça vient. En tout cas le seul nombre qui est dans la loi est celui là (200%), la description des différentes strates est pas précisée dedans

Complété.

  • Niveau de garanties : Certains niveaux (pour la fraction bourg-centre et péréquation) figurent dans la loi mais pas dans le json, genre les niveaux de garantie pour les communes nouvellement inéligibles, mais je suis pas sûr qu'on les rende modifiables.

Oui, je pense qu'on peut les laisser de côté (du moins dans un premier temps). On peut d'ailleurs se demander si les résultats affichés prennent en compte ces garanties (étant donné qu'elles sont temporaires). Est-ce le cas ?

magemax commented 4 years ago

J'imagine qu'on peut rajouter premieresCommunesPopMax. Mon questionnement : est-ce que ce seuil devrait être éditable ? N'est-il pas de facto dotations.communes.dsr.eligibilite.popMax ?

Je suis d'accord, je pense que dans un premier temps, on devrait pas trop se prendre la tête et faire que tous les "10000 habitants" et "20000 habitants" des textes soient liés à la même variable, je crois pas que ce soit un use case fréquent.

Oui, je pense qu'on peut les laisser de côté (du moins dans un premier temps). On peut d'ailleurs se demander si les résultats affichés prennent en compte ces garanties (étant donné qu'elles sont temporaires). Est-ce le cas ?

Là dessus je pense que la doctrine est de ne pas inclure les garanties dans les résultats (i.e. plutôt dire "voici vers quel montant on converge avant et après la réforme" et mettre d'éventuelles astérisques pour expliquer le système de garanties. C'est à mon sens plus simple que le contraire qui poserait des problèmes de calcul et ne montrerait pas les effets long terme du premier coup)

J'ai fait figurer la version actuelle du JSON dans le data dictionary.

Autres remarques variées (certaines concernent plus les questions en suspens sur l'interface et les formules que cette paramétrisation) :

LoicPoullain commented 4 years ago
  • plafonnement de la population : je ne suis pas sûr de bien parler json, ce que tu as écrit veut dire que ce sera un dictionnaire ? La valeur courante du paramètre serait { 100 : 500, 499 :1000 , 1499: 2250 } ?

Yes c'est ça

sandcha commented 4 years ago

Afin de suivre le modèle du /calculate/compare et tel que discuté avec @magemax nous aurions la modification de la racine de la requête comme suit pour l'endpoint /dotations :

Avant :

  dotations: {
    // Article L1613-1 du CGCT
    montants: {
      dgf: number;
    },
    communes: {
    }
}

Après :

reforme: {
  dotations: {...}
}
description_cas_types: {...}

Qui contiennent les éléments discutés plus haut dans cette issue : 

reforme: {
  dotations: {
    // Article L1613-1 du CGCT
    montants: {
      dgf: number;
    }
    communes: {
    }
  }
}
description_cas_types: {
  // Communes types (cartes d'impact individuelles)
}

Ok pour vous ? Remarque auxiliaire : il y a peut-être une ambiguïté sur la clef communes qui pourrait faire penser à un cas type. Peut-être que dsr, son enfant, suffirait ?

LoicPoullain commented 4 years ago

Afin de suivre le modèle du /calculate/compare et tel que discuté avec @magemax nous aurions la modification de la racine de la requête comme suit pour l'endpoint /dotations :

Mot-clé reforme ajoutée.

Remarque auxiliaire : il y a peut-être une ambiguïté sur la clef communes qui pourrait faire penser à un cas type. Peut-être que dsr, son enfant, suffirait ?

Je crois qu'il y a des dotations qui portent le même nom mais qui ont des destinations différentes (département, commune, etc). Cela pourrait être pratique dans ce cas-là. Je ne suis pas sûr que cela soit vrai toutefois, à vérifier... @magemax qu'en penses-tu ?

LoicPoullain commented 4 years ago

Là dessus je pense que la doctrine est de ne pas inclure les garanties dans les résultats (i.e. plutôt dire "voici vers quel montant on converge avant et après la réforme" et mettre d'éventuelles astérisques pour expliquer le système de garanties. C'est à mon sens plus simple que le contraire qui poserait des problèmes de calcul et ne montrerait pas les effets long terme du premier coup)

Je suis d'accord également.

  • popLimit et effortFiscalLimit : on veut pas mettre Limite plutôt ? tous les autres semblent en français

Les deux me vont. Modification apportée.

plafonnement de la population : je ne suis pas sûr de bien parler json, ce que tu as écrit veut dire que ce sera un dictionnaire ? La valeur courante du paramètre serait { 100 : 500, 499 :1000 , 1499: 2250 } ? Aussi, on le change ce truc là dans l'interface actuelle ?

Oui. Oui. Oui.

  • Le "ParHab" est uniquement spécifié dans la variable ponderationRevenuParHab . Je le supprimerais (ou le rajouterais dans toutes les phases sur le potentiel financier )

Modification apportée aux trois endroits où il y avait ParHab notamment :


              potentielFinancier: {
                rapportPotentielFinancierMoyen: number;
              }
LoicPoullain commented 4 years ago

Concernant la description des cas types, j'imagine que chaque commune a un code d'identification. Proposition:

interface Request {
  reforme: { ... },
  // This an array.
  descriptionCasTypes: {
    code: string; // OR id, I'm ok with both.
    // Potentialité d'ajouter davantage de propriétés dans le future si l'on souhaite éditer les communes
  }[]
}

J'ai plutôt une préférence pour le camelCase pour être cohérent avec le reste de la requête et ne pas avoir d'underscores qui se baladent dans l'état redux

LoicPoullain commented 4 years ago

Proposition de réponse suivant la maquette de Dorine :

interface Response {
  amendement: {
    communes: {
      dsr: {
        eligibles: number;
        // This is an array.
        strates: {
          // Borne supérieure de la strate
          habitants: number;
          // Représentation de la strate dans la population totale
          partPopTotale: number;
          // Potentiel financier moyen par habitant
          potentielFinancierMoyenParHab: number;
          // Nombre de communes éligibles
          eligibles: number;
          // Dotation moyenne par habitant
          dotationMoyenneParHab: number;
          // Part des dotations accordées à cette strate dans la dotation totale.
          partDotationTotale: number;
        }[],
        // This is an array.
        communes: {
          code: string; // OR id, I'm ok with both.
          eligible: boolean;
          dotationParHab: number;
        }[]
      }
    }
  }
  base: {
    // Même contenu qu'amendement
  }
  plf: {
    // Même contenu qu'amendement.
  }
  baseToPlf: {
    communes: {
      dsr: {
        nouvellementEligibles: number;
        plusEligibles: number;
        toujoursEligibles: number;
      }
    }
  }
  plfToAmendement: {
    communes: {
      dsr: {
        nouvellementEligibles: number;
        plusEligibles: number;
        toujoursEligibles: number;
      }
    }
  }
}

La décomposition en trois parties distinctes amendement, plf et base est vraiment pratique pour le frontend.

LoicPoullain commented 4 years ago

Concernant la requête de recherche des communes, voici une proposition:

Request

GET /communes?search=Pari
# Sur Flask :
request.args.get('search', '')

Response

interface Response {
  // This is an array
  communes: {
    code: string; // OR id.
    name: string;
    departement: string;
    habitants: number;
    potentielFinancierParHab: number;
  }[]
}
LoicPoullain commented 4 years ago

@magemax dans la réponse j'ai mis des parHab. Je suis assez partagé : d'un côté je n'aime pas quand le code est pas cohérent. De l'autre, j'ai peur que l'on se confonde avec des valeurs totales si on ne met pas des parHab.

magemax commented 4 years ago

Ok quelques points :

Sur la réponse :

Pour la fonctin de recherche (j'avais zappé qu'on l'avait dès maintenant) :

Question subsidiaire : Où est la dernière version des requêtes que tu prépares (genre avec toutes les modifs déjà intégrées) ? dans une de tes branches leximpact-client? Si oui laquelle ?

LoicPoullain commented 4 years ago

Question subsidiaire : Où est la dernière version des requêtes que tu prépares (genre avec toutes les modifs déjà intégrées) ? dans une de tes branches leximpact-client? Si oui laquelle ?

La dernière version se situe dans cette issue, je mets à jour à chaque fois la description.

magemax commented 4 years ago

Autre petit commentaire, pendant que j'implémente les montants des fractions cible et péréquation : il y a aussi une limite de prise en compte à l'effort fiscal (qui est fixée à 1.2). Donc soit on crée une variable spécifique pour ça (par exemple dotations.communes.dsr.perequation.attribution.effortFiscalLimit), soit on dit que le 1.2 plus haut concerne tout le monde (auquel cas faut remonter d'un cran l'effort fiscal limite de la fraction bourg-centre)

LoicPoullain commented 4 years ago

Il semble que tous les "impacts" soient par rapport à la base et non en fonction du plf. Si ça tombe au PLF, y a moyen qu'ils veulent plus comparer leur amendement au PLF qu'au projet initial. Il y a déjà des maquettes avec PLF? Ca va avoir des impacts sur le format probable.

Bonne remarque. Pour l'IR, on comparait l'amendement au PLF et le PLF par rapport au code existant. J'ai fait une proposition de modification dans l'issue (commentaire édité). On aurait 5 grandes parties : amendement, plf, base, baseToPlf et plfToAmendement. Ca nous permettrait de mieux documenter les comparaisons et d'en supporter plusieurs.

On ne sort que le nombre de communes éligibles à au moins une des trois fractions ? Ca simplifie mais ça risque de donner lieu à des informations moins intéressantes in fine, vu que 97% des communes de moins de 10000 hab sont éligibles à la péréquation.

Peut-être que dans un premier temps on pourrait partir là-dessus car c'est plus simple (au moins une des trois fractions). Et ensuite il faudrait voir avec @DorineLam si cela intéresse les utilisateurs et, si oui, comment on gère ça côté UI.

Pour l'identification de la commune : le nom ne suffit pas (par exemple il y a 12 Sainte-Colombe en France), il faudra aussi qu'on mette le code INSEE avec. Toi j'imagine que tu n'auras pas de table de correspondance donc il faudrait qu'on te mette les 2 à chaque fois, non ?

Tout à fait d'accord pour l'identification d'une commune via le code INSEE (c'est les propriétés code dans la spec). Pour répondre à ta question concernant nom/code, voici comment je verrais l'architecture :

// GET /communes?search=:name
// Recherche des communes dont le nom contient :name.

// Retourne un tableau dans la limite de n éléments (n=5 par exemple)
[
  {
    "code": "code INSEE 1",
    "name": "Sainte-Colombe",
    "departement": "Auvergne",
    "habitants": 2,
    "potentielFinancierParHab": 3
  },
  {
    "code": "code INSEE 2",
    "name": "Sainte-Colombe"
   // ...
  } 
  // ...
]

Lorsqu'ensuite le front envoie la requête au serveur, il y inclut les codes INSEE dans un tableau:

// POST /dotations
interface Request
{
  reforme: { ... }
  descriptionCasTypes: Array<{ "code": string }>
}

Pour l'identification des strates, j'ai une préférence pour la borne inférieure du nombre d'habitant, qui nous évitera de nous embêter avec l'infini

Hmm, j'ai une préférence pour la bonne sup car c'est elle que l'on affiche sur chaque ligne du tableau (on pourrait choisir -1 comme convention pour l'infini). Ensuite, si c'est vraiment gênant pour toi, on peut passer à la borne inf et je referai un post-traitement à réception de la réponse.

  • Il peut y avoir beaucoup de résultats, qui peuvent faire quelques mega à transmettre. Si c'est à chaque touche, ca fait beaucoup. On peut limiter le nombre de résultats, ou pas lancer la recherche à chaque fois, mais je ne sais pas comment est l'UI. Y a une description de cette fonctionnalité quelque part?
  • J'imagine qu'en terme de recherche, on veut chercher une string et renvoyer toutes les communes dont le nom contient cette string ? y a quelques feintes (est ce qu'on est indulgent sur les accent foireux, les tirets), mais à moins d'un truc très complexe ça devrait pas être sorcier

Pas de description actuellement. Généralement dans ce type de situations, on peut utiliser un autocomplete. La requête n'est envoyée qu'après que l'utilisateur est fini d'écrire (on rajoute un délais de 0.5s après la fin d'écriture par exemple) et on limite le nombre d'éléments retournée.

Du même avis concernant la recherche : le nom de la ville doit contenir la string envoyée.

On doit problablement pouvoir s'en tirer simplement en SQL avec un LIKE et un LIMIT.

LoicPoullain commented 4 years ago

Question subsidiaire : Où est la dernière version des requêtes que tu prépares (genre avec toutes les modifs déjà intégrées) ? dans une de tes branches leximpact-client? Si oui laquelle ?

Je mets à jour cette issue à chaque modif de la spec.

LoicPoullain commented 4 years ago

Autre petit commentaire, pendant que j'implémente les montants des fractions cible et péréquation : il y a aussi une limite de prise en compte à l'effort fiscal (qui est fixée à 1.2). Donc soit on crée une variable spécifique pour ça (par exemple dotations.communes.dsr.perequation.attribution.effortFiscalLimit), soit on dit que le 1.2 plus haut concerne tout le monde (auquel cas faut remonter d'un cran l'effort fiscal limite de la fraction bourg-centre)

J'imagine que tu parles des fractions bourg-centre et péréquation et non pas cible. Oui, le 1,2 est actuellement éditable dans bourg centre et pas péréquation. Je pense que le plus simple serait de rajouter une variable spécifique dans la péréquation sinon on aurait besoin de réfléchir un peu plus si la manière de rendre ça compréhensible dans l'UI (le fait qu'une variable concernerait tout le monde).

DorineLam commented 4 years ago

@LoicPoullain Pour répondre à cette question :

On ne sort que le nombre de communes éligibles à au moins une des trois fractions ? Ca simplifie mais ça risque de donner lieu à des informations moins intéressantes in fine, vu que 97% des communes de moins de 10000 hab sont éligibles à la péréquation.

Peut-être que dans un premier temps on pourrait partir là-dessus car c'est plus simple (au moins une des trois fractions). Et ensuite il faudrait voir avec @DorineLam si cela intéresse les utilisateurs et, si oui, comment on gère ça côté UI.

Toutes les cartes sont amenées à avoir bientôt une série d'onglets permettant de passer en revue les impacts selon les dotations, DSR, DSU, DF et total :

Capture d’écran 2020-07-08 à 14 29 15 Capture d’écran 2020-07-08 à 14 30 30

(⚠️ les maquettes montrées ci-dessus ne sont pas fidèles, elles sont trop anciennes mais montrent néanmoins le composants "onglets")

LoicPoullain commented 4 years ago

@DorineLam le commentaire faisait mention aux fractions (les trois de la DSR) et non aux différentes dotations (DSR, DSU, etc).

DorineLam commented 4 years ago

@LoicPoullain sorry, j'avais mal lu...

voici une proposition concernant la carte nb communes éligibles :

Capture d’écran 2020-07-08 à 15 23 02

Une proposition pour le tableau, qui s'appuie sur un composant material ui :

Capture d’écran 2020-07-08 à 15 31 33 Capture d’écran 2020-07-08 à 15 25 37
LoicPoullain commented 4 years ago

@magemax je rajoute toujoursEligibles dans la réponse.