Majoration du plafond AAH couple à modifier depuis la déconjugalisation + mécanisme transitoire

[kevinpolisano]

Hello !

Qu'ai-je fait ?

J'ai lancé le test suivant :

openfisca test tests/formulas/aah/aah_couple.yaml -n ", déconjugalisation"

qui simule les AAH versées pour un couple de bénéficiaires de l'AAH sans enfant dont l'un travaille (et perçoit 2000€/mois) et l'autre n'a pas de revenus.

Le résultat obtenu est [767.85, 971.37]

À quoi m'attendais-je ?

À ce que l'AAH versée pour le bénéficiaire qui travaille soit nulle ou à taux plein (971.37€).

En effet, il est stipulé que :

Le décret n°2022-1694 supprime, à compter du 1er octobre 2023, la prise en compte des revenus du conjoint pour le calcul de l'AAH et les abattements : Réduction forfaitaire ou proportionnelle appliquée sur la base de calcul d'un impôt (revenus, valeur d'un bien, etc.) applicables sur les revenus du conjoint s'il réduit ou cesse son activité.
La personne qui a un droit à l'AAH ouvert au titre du mois de septembre 2023 aura un calcul déconjugalisé de l'AAH sauf si cela lui est défavorable.
La personne qui a un droit qui s'ouvre à compter du 1er octobre 2023 aura un calcul déconjugalisé de l'AAH.

Autrement dit il faut distinguer dans la simulation 2 cas de figure :

1. La bénéficiaire entre dans le dispositif et est éligible à l'AAH à compter du 1er octobre 2023, auquel cas le calcul de son AAH est strictement individualisé (formula_2023_10_01 + aucune majoration de plafond couple).
2. Le bénéficiaire était déjà éligible à l'AAH avant le 1er octobre 2023, auquel cas il dispose d'un mécanisme transitoire (d'une durée de 10 ans) où le montant d'AAH versé est le max entre :
   • le calcul individualisé (formula_2023_10_01 + aucune majoration de plafond couple)
   • le calcul conjugalisé qui était en vigueur avant la déconjugalisation (formula_2022_01_01 issu de la réforme introduisant l'abattement_forfaitaire et supprimant l'abattement_proportionnel + une majoration de plafond couple de 0,81).

Dans le premier cas le bénéficiaire percevant 2000€/mois (soit 24000€ annuel) a une AAH nulle, tandis que dans le deuxième cas il touche l'AAH à taux plein.

Que s'est-il passé en réalité ?

Une erreur et une imprécision sont commises :

• L'erreur consiste à calculer l'AAH individualisée via formula_2023_10_01() mais avec un plafond de ressource qui reste conjugalisé. En effet ci-dessous vous pouvez constater que la variable plaf_ress_aah a pour valeur [1758.1797, 1758.1797] ce qui correspond à l'AAH taux plein affectée du coefficient multiplicateur : 971.37 x 1,81 = 1758. Il faut donc modifier le fichier majoration_plafond_couple.yaml en indiquant une valeur de 0 à la période débutant au 1er octobre 2023.
• Toutefois il faudrait également tenir compte de la date d'entrée du dispositif comme évoqué ci-dessus (et ici) en retenant le max des 2 modes de calcul conjugalisé/déconjugalisé selon le cas de figure.

Contexte

Je m'identifie plus en tant que :

• Contributeur·e : je contribue à OpenFisca France.
• Développeur·e : je crée des outils qui utilisent OpenFisca France.
• Économiste : je réalise des simulations avec des données.
• Mainteneur·e : j'intègre les contributions à OpenFisca France.
• Autre : vulgarisateur du fonctionnement de l'AAH.

[sylvainipp]

Bonjour et merci pour cette remarque ! Il était prévu de mettre à jour ce test qui avait été écrit en début d'année, donc avant d'avoir des exemples de référence à tester ; s'il y a des tests correspondant à des situations réelles qui sont maintenant disponibles, il serait donc bon de les ajouter pour détecter d'éventuelles autres erreurs.
En ce qui concerne la période transitoire, je ne suis pas sûr que nous soyons en mesure de la simuler de manière convaincante pour l'instant, d'autant plus dans des situations comme celle-ci où l'un des conjoints peut avoir intérêt à la conjugalisation et l'autre à la déconjugalisation, mais avant tout à cause du critère d'ancienneté qui va se complexifier avec le temps. En ce sens, mettre la majoration_plafond_couple à 0 à partir d'octobre 2023 serait une solution cohérente avec une déconjugalisation complète, et je propose de corriger l'erreur sans s'occuper de l'imprécision en l'absence d'une idée précise pour coder ce choix.

[kevinpolisano]

Bonjour Sylvain,

Merci pour ce retour rapide.

Je dispose de quelques tests en situation réelle (des amis m'ayant communiqué leur déclaration de revenus et versement d'AAH correspondant au mois de novembre), je peux vous fournir ces chiffres (que j'ai validé via une feuille excel).

Concernant la période transitoire, pourquoi le critère d'ancienneté devrait se complexifier avec le temps ? Il me semble qu'il suffit de demander à l'utilisateur de renseigner si l'ouverture de ses droits à l'AAH est postérieure ou non à la date du 1er octobre 2023. La péremption du mécanisme étant dans 10 ans, on a le temps de voir venir et ne pas coder cette éventualité future. En revanche, les couples qui seraient perdants avec une déconjugalisation complète ont actuellement une estimation au rabais de ce à quoi ils peuvent prétendre en réalité, ce qui est problématique... D'autant que les couples qui sont déjà dans le dispositif sont une majorité par rapport à ceux qui y entrent depuis le 1er octobre. Il me parait important que la simulation de leur prestation ne soit pas faussée et tienne compte du maintien de leur AAH à la hauteur de ce qu'ils percevaient avant la déconjugalisation. La question des perdants d'une réforme sans mécanisme de compensation était un point névralgique du débat politique, il ne faudrait pas que cet aspect passe à la trappe dans l'implémentation (qui a le remarquable avantage d'être ici totalement transparente ! Bravo pour le travail déjà réalisé !). Je vous propose que l'on réfléchisse à un moyen de coder cette distinction de cas, selon la date d'ouverture des droits. Êtes-vous partant ?

Bon week-end !

[sylvainipp]

Bonjour,
en ce qui concerne les tests, j'ajouterais volontiers des situations réelles (le test actuel est un test que j'avais calculé moi-même en février, et qui a du être modifié plusieurs fois à cause des modifications du smic, ce qui n'est pas un indicateur de grande fiabilité). L'idée des tests est de prendre les cas les plus complexes qu'on est censé calculer, afin de tester le plus de variantes avec le moins de tests possibles, mais aussi d'avoir une référence extérieure, donc si possible sur données réelles (tout le contraire du test que j'avais écrit !).
Pour en revenir à la période transitoire, je suis tout à fait d'accord 1) que c'est une disposition importante en pratique 2) qu'on aimerait bien la coder si cela peut se faire avec des calculs simples. Cependant, j'avais compris qu'il suffisait d'un mois où la déconjugalisation soit plus intéressante pour la personne concernée pour qu'elle soit obligée d'y souscrire toutes les périodes suivantes, même si son droit commençait avant octobre 2023 (voir l'article 2 de https://www.legifrance.gouv.fr/jorf/id/JORFTEXT000046830041). Le critère est donc que la personne ait intérêt à la déconjugalisation, et qu'elle ait eu intérêt à la déconjugalisation tous les mois depuis octobre 2023. Les deux manières de coder cela serait à mon sens soit de demander si la personne y avait droit le mois précédent, soit de calculer les droits (qui doivent avoir été demandés) tous les mois depuis la mise en oeuvre de la réforme.
Pour la possibilité de demander si la personne y avait droit le mois précédent, il s'agit dans le cas où on peut avoir une variable d'input d'avoir cette information, avec une valeur par défaut qui ne me semble pas évidente (d'autant plus lorsqu'on s'éloignera de la réforme), mais qui aura une vraie importance pour une partie des usages d'openfisca où on n'a pas de telles informations (après, on peut mettre en défaut un False qui reviendrait à la situation actuelle, donc sans détérioration au moins). Si ce droit est calculé, alors on se rapporte par récursion à la deuxième solution.
Le deuxième cas nécessite d'avoir toutes les informations de calculs de droit pour la personne concernée pour l'ensemble des mois entre septembre 2023 et le mois concerné, ce qui se révélera de plus en plus difficile avec le temps.
Nous pourrions également faire une situation intermédiaire, dans laquelle nous permettrions un choix pendant un temps plus réduit (par exemple jusqu'en 2025) en ayant moins ces problèmes de récursion. Cette solution a le désavantage d'induire en erreur au lieu simplement de ne pas simuler un dispositif (ce que l'on fait déjà pour nombre d'entre eux hélas).
Je suis à votre écoute si vous avez une autre idée, ou si vous pensez qu'une de ces deux méthodes serait suffisamment applicable pour être codée, ou si encore j'ai mal interprété le texte.

[kevinpolisano]

Bonjour,

Votre réponse n'apparait pas, sauf erreur.

[sylvainipp]

Désolé, j'avais mal envoyé en effet. La MSA a fait un code gérant cette déconjugalisation de son côté dans #2048, mais j'ai l'impression qu'elle ne s'attaque pas directement à ce problème d'éligibilité (pour leur besoin, ils ont probablement une information fiable sur l'éligibilité à la conjugalisation des bénéficiaires, y compris sur longue période. Leur idée est également d'afficher les deux cas si j'ai bien compris).

[kevinpolisano]

Bonjour Sylvain,

Oui vous avez raison concernant le critère du droit d'option, c'est d'ailleurs regrettable puisque le gouvernement avait assuré de la continuité de ce droit d'option... Ce problème ci se règle sur le versant politique. En ce qui nous concerne ici il faut implémenter la législation actuelle, où effectivement si le/la conjoint(e) perçoit ne serait-ce qu'une seule fois des revenus pour lesquels le mode conjugalisé n'est plus avantageux, alors le mécanisme transitoire prend fin de manière irréversible, quand bien même le mois suivant le/la conjoint(e) ne perçoit plus aucun revenu.

Les deux propositions que vous suggérez sont pertinentes mais me paraissent en effet compliquées du point de vue de l'utilisateur : la seconde puisque comme vous le relevez celle-ci nécessiterait de renseigner tout l'historique; et la première étant compliquée également car le bénéficiaire ne sait pas nécessairement s'il a bénéficié ou non le mois précédent du mode de calcul préférentiel (ce n'est pas mentionné sur relevé du versement de l'AAH de la CAF si je ne m'abuse).

Je suggère comme troisième voie que l'on déduise la situation du bénéficiaire – sans la lui demander ouvertement donc – à partir d'un minimum d'information supplémentaire – c'est-à-dire sans demander tout l'historique à l'utilisateur – de la manière suivante :

• Si le bénéficiaire n'a jamais perçu l'AAH au moment de la simulation, plus exactement eu de droits ouverts, ou que ces droits sont postérieurs au 1er octobre 2023, cas simple : il rentre d'office dans le mode de calcul individualisé.
• Si le bénéficiaire était déjà dans le dispositif avant le 1er octobre 2023, alors nous ne sommes pas obligé de posséder tout l'historique depuis cette date pour savoir s'il est sorti du mécanisme transitoire. Nous pouvons en réalité le deviner à partir de son dernier versement d'AAH et des revenus déclarés s'y rapportant pour ce mois-ci. En effet, à partir de ces revenus déclarés nous sommes en mesure de simuler les deux scénarios (conjugalisé / déconjugalisé), donc si le calcul conjugalisé lui était profitable et que l'AAH versée correspond au calcul déconjugalisé, alors on en déduit qu'il est sorti du mécanisme transitoire; sinon les deux coincident et on en déduit qu'il dispose toujours du mécanisme transitoire.

Qu'en dites-vous ?

PS : une autre solution plus économique encore consisterait à afficher simultanément les deux informations (scénarios conjugalisé / déconjugalisé) comme étant 2 hypothèses de versement selon la situation du bénéficiaire. Situation qu'il peut lui-même inférer en réitérant la simulation avec les revenus correspondant au dernier versement de l'AAH, puis en comparant ce dernier versement aux deux scénarios suggérés par le résultat de la simulation.

[sylvainipp]

Bonjour,
la troisième option est effectivement intéressante, mais elle me semble avoir deux défauts possibles : le premier est que l'AAH du mois précédent n'est pas forcément disponible, notamment pour tous les usages hors API web personnalisée (ce qui n'est pas complétement bloquant, les autres pouvant utiliser une valeur par défaut avec déconjugalisation, soit la situation actuelle). Le second est qu'il va falloir déterminer une gestion des cas où l'AAH calculé ne correspond ni au montant calculé pour la déconjugalisation, ni à celui calculé avec conjugalisation. Cela peut être dû à des situations particulières imparfaitement codées dans openfisca, mais aussi simplement à des différences d'arrondis, à des nomenclatures dans les catégories de revenus qui ne sont pas parfaitement respectées... Or, à partir du moment où on n'a pas une correspondance exacte, il faut savoir trancher sur les cas intermédiaires, sachant qu'un éloignement important témoignerait d'erreurs importantes. Cela demanderait également de remplir des informations pour un mois supplémentaire afin qu'on puisse calculer ce premier montant qui serait aussi fourni. Pour moi, ce type d'astuces n'a pas vocation à être codée dans openfisca, mais dans des utilisations de celui-ci. Ce qu'on pourrait faire serait de mettre une variable eligible_conjugalisation qu'on utiliserait dans le calcul (avec un défaut False), et qui à son tour pourrait être calculée par certaines API l'utilisant typiquement, par exemple en demandant le montant du mois précédent.
Pour l'option de post-scriptum, le constat est identique : c'est a priori quelque chose à coder pour les API (et incidemment l'option que semble avoir choisi la MSA).
Pour l'instant, il est donc possible d'ajouter cette variable eligible_conjugalisation, ce qui aurait l'avantage de mettre clairement le dispositif dans le code, mais le désavantage de l'alourdir (et de rajouter une variable d'input) sans que l'option ne soit utilisée par qui que ce soit. Or, je ne suis pas sûr qu'il y ait beaucoup de monde qui aille regarder le code 1) sans être déjà au courant de la législation 2) sans faire de recherches annexes ni lire les commentaires du code qui évoquent ce point.
Merci en tout cas pour cette proposition !

[kevinpolisano]

Bonjour,

J'avais également en tête la seconde limitation due aux approximations/erreurs potentielles, et automatiser la sélection du résultat le plus proche peut s'avérer hasardeux tant les deux estimations peuvent être dans un mouchoir de poche. Il y a donc besoin de la participation de l'utilisateur au niveau de l'usage de l'API pour instancier la variable eligible_conjugalisation. Par exemple sur le simulateur 1jeune1solution on pourrait imaginer un arbre de décision de ce type :

  flowchart TD;
      A[Bénéficiez-vous de l'AAH avant 1er octobre 2023 ?] -- Oui --> B[Êtes-vous actuellement éligible au calcul conjugalisé <br/> dans le cas où celui ci est supérieur au calcul déconjugalisé ?];
      A -- Non -->C[Formule déconjugalisée]; 
      B -- Je ne sais pas --> D[Déclarez vos revenus <br/> correspondant au dernier versement d'AAH <br/> depuis le 1er octobre 2023];
      B -- Oui --> F[Formule conjugalisée];
      B -- Non --> E[Formule déconjugalisée];
      D -- Calcul des scénarios --> G[Le montant d'AAH qui vous a été versé <br/> est-il plus proche de : <br/> 1. Résultat conjugalisé ? <br/> 2. Résultat déconjugalisé ? <br/> 3. Je ne sais pas.];
	  D -- Plus accès à ces informations --> K[Suggestion des 2 scénarios];
      G -- cas 1 --> H[Formule conjugalisée];
      G -- cas 2 --> I[Formule déconjugalisée];
      G -- cas 3 --> J[Suggestion des 2 scénarios];
      H --> L[Déclaration des revenus du mois courant];
      I --> L;
      J --> L;
      L -- Simulation de l'AAH --> M[Résultat]

Loading

[sylvainipp]

Je vais donc laisser les personnes travaillant sur des API prendre en charge l'option de conjugalisation, puisqu'à priori la solution qui semble la plus implémentable ne concerne qu'elles (et n'est pas directement inscrite dans la loi, donc à mettre a priori en aval d'openfisca en bonne partie). Pour ma part, je vais finir de corriger l'erreur sur le plafond, et je peux implémenter un test sur cas réel si vous êtes toujours disposé à nous en communiquer.

[guillett]

Il y a effectivement des règles de calculs compliquées, en revanche, je pense que l'utilisation d'une variable pour l'application du maximum entre les deux versions peut être fait et directement dans OpenFisca. Avec une valeur par défaut à false ce qui est habituel ça marcherait bien. Dans un premier temps cette variable pourrait uniquement être une input variable puis si une personne se motive lui ajouter une formule.

[sylvainipp]

Cela ne me pose pas de problème de l'ajouter (je vais le faire dans #2218), mon inquiétude vient simplement du fait que personne ne va l'utiliser et qu'on alourdit (un peu) le code sans bénéfice immédiat. Après, si cela peut inciter quelqu'un d'autre à l'utiliser, le jeu en vaut la chandelle.

[sylvainipp]

Je vais bientôt merger ma branche, j'en profite pour noter ici que nous partons du principe pour l'instant que, si une personne a droit à la déconjugalisation mais que son conjoint n'y a pas intérêt, alors on peut avoir un membre du couple de personnes handicapées qui a un AAH déconjugalisé et l'autre non. Je n'ai pas trouvé de document rejetant la possibilité de ce cas de figure, mais si quelqu'un sait si cette situation est réellement possible je l'invite à communiquer la réponse pour une éventuelle correction.