Utilisation de l’IA pour la mise à jour de paramètres OpenFisca

Introduction

LexImpact est un service de l’Assemblée nationale depuis 2020, rattaché à la Direction du Contrôle et de l’évaluation, spécialisé dans le chiffrage et la gestion de données. Le produit principal du projet est un simulateur socio-fiscal : https://socio-fiscal.leximpact.an.fr/ qui repose sur OpenFisca.

LexImpact sert d’interface pour OpenFisca, permettant à tout citoyen d’interagir avec le simulateur d’OpenFisca et de visualiser les résultats des calculs. La plateforme https://socio-fiscal.leximpact.an.fr/accueil, en plus des résultats des calculs, affiche les valeurs des paramètres, les dates, les références légales et le statut de mise à jour. Le volume important de paramètres rend les mises à jour manuelles fastidieuses, ce qui a motivé l’exploration de l’automatisation assistée par LLM.

Le projet vise à automatiser la récupération et la mise à jour des paramètres fiscaux utilisés dans OpenFisca, un logiciel de microsimulation. L’objectif principal est de partir d’un identifiant OpenFisca, comme marche_travail.salaire_minimum.smic.smic_b_horaire pour le SMIC horaire, et d’extraire automatiquement les informations pertinentes, tel que :

La description du paramètre : Smic brut (horaire)
Sa valeur actuelle : 11.65€ au 1er janvier 2024
La référence légale correspondante : Décret du 20/12/2023

Ce processus présente plusieurs difficultés :

Gestion des cas où les références légales sont manquantes ou imprécises
Mise à jour de l’historique des paramètres
Traitement de textes juridiques longs et complexes
Nécessité d’un modèle de langue performant en français et particulièrement en vocabulaire juridique
Conversion des valeurs textuelles en format numérique

Pour relever ces défis, le projet combine des méthodes déterministes avec l’utilisation de grands modèles de langage (LLM).

L’approche a évolué au fil du temps :

Juin 2023 : Premiers essais avec des modèles de langue libres, avec des résultats limités (environ 5% de réussite)
Juillet-Août 2023 : Tentatives de fine-tuning et d’utilisation de modèles pour vérifier les valeurs existantes
Avril 2024 : Mise en place d’un système de lecture/écriture des paramètres OpenFisca et intégration d’une base de données de textes législatifs
Juillet 2024 : Implémentation d’agents de recherche basés sur des LLM avancés (comme GPT-4) pour trouver les références manquantes, avec des résultats prometteurs

Le projet vise à terme à créer un système robuste et efficace pour maintenir à jour les milliers de paramètres fiscaux d’OpenFisca, tout en explorant les possibilités offertes par l’intelligence artificielle dans le domaine juridique et administratif.

La problématique

Sur la capture d’écran du simulateur LexImpact ci-dessous, concernant la CSG, on peut voir à gauche les paramètres de ce dispositif :

En rouge les éléments qui nécessitent une mise à jour régulière :

La valeur : 5,9%
La date du dernier changement de valeur : janvier 2018
Le fait que la valeur est bien la valeur actuellement en vigueur par l’indication “à jour”. C’est un élément important pour les utilisateurs du simulateur car un paramètre peut ne pas avoir changé depuis des années. Cette mention indique qu’il a tout de même été vérifié depuis moins d’un an.
La liste des références légales qui justifient la valeur du paramètre. Ici, l’article Article 67 de la loi de finance pour 2018 a modifié l’article 154 quinquies du Code général des impôts.

Le simulateur permet aussi d’accéder à l’historique des valeurs du paramètre, avec les dates de changement et les valeurs correspondantes.

L’objectif est donc de maintenir à jour ces informations, et de les enrichir. En effet, parfois la référence légale est manquante ou l’historique incomplet.

Utilisation des LLM

L’approche la plus simple est d’interroger un LLM en lui posant la question suivante : Quelle est la valeur du SMIC horaire en août 2024 ?“.

Voici la réponse de [Claude 3.5 Sonnet(https://claude.ai)] : “Au 1er janvier 2024, le SMIC horaire brut était fixé à 11,65 euros.”

Ce qui est exacte, mais pour des questions plus pointues comme Quelle est la valeur du “Taux médian” pour le “Taux de CSG déductible appliqués à l’assiette des pensions retraite” ?

La réponse n’est pas systématiquement correcte, Par exemple GPT-4o répond La valeur du “Taux médian” pour le “Taux de CSG déductible appliqué à l’assiette des pensions retraite” est de 5,9%. alors que c’est la valeur du taux plein et non du taux médian.

Il faut donc aider le modèle en lui fournissant le texte de référence et des explications sur ce que l’on attend de lui:

Vous êtes un juriste travaillant à l’Assemblée Nationale. Votre travail consiste à peupler et mettre à jour une base des données nécessaires pour réaliser des simulations fiscales et sociales. Pour cela, vous devez prendre les textes réglementaires dans lesquelles figurent les informations à jour que l’on vous fourni, et d’extraire précisément l’information spécifique dont vous avez besoin.

Notez bien que les pourcentage sont exprimés sous forme mathématique, donc une valeur de 25% dans le texte de loi sera noté 0.25 dans notre système. Si vous ne trouvez pas la réponse dans le texte vous devez chercher une correspondance approchante. S’il n’y en a vraiment pas, il faut le dire et ne pas chercher à en fournir une autre.

Avant de répondre, vérifier que la réponse se trouve bien dans le texte indiqué. Le langage utilisé est juridique, il faut réfléchir par étape car la compréhension est parfois difficile.

Par exemple la phrase “La déduction à effectuer du chef des frais professionnels est calculée forfaitairement en fonction du revenu brut, après défalcation des cotisations, contributions et intérêts mentionnés aux 1° à 2° ter ; elle est fixée à 10 % du montant de ce revenu.” signifie qu’une déduction de 0.1 * le revenu brut est effectuée avant de calculer le montant de l’impôt. Utilisez le point comme séparateur des décimales et pas de séparateur de millier. Si la valeur est en lettre, il faut la mettre en chiffre, par exemple cinquante-six devient 56. Une “demi-part” devient 0.5. La réponse doit toujours être en format JSON, par exemple : { “valeur”: 56, } Si vous n’avez pas la réponse indiquer null.

Dans le texte suivant, quelle est la valeur de ‘Taux médian de la contribution sociale généralisée (CSG) déductible sur les pensions de retraite et d’invalidité’ ?

“““I. – Pour la détermination des bases d’imposition à l’impôt sur le revenu, la contribution prévue à l’article L. 136-1 du code de la sécurité sociale au titre des revenus d’activité et de remplacement ou celle afférente aux revenus mentionnés au 3° du I de l’article L. 136-7 du code précité est, à hauteur de 6,8 points ou, pour les revenus mentionnés au II de l’article L. 136-8 du même code, à hauteur de 3,8 points lorsqu’elle est prélevée au taux de 3,8 % ou 6,2 %, à hauteur de 4,2 points lorsqu’elle est prélevée au taux de 6,6 % et à hauteur de 5,9 points lorsqu’elle est prélevée au taux de 8,3 %, admise en déduction du montant brut des sommes payées et des avantages en nature ou en argent accordés, ou du bénéfice imposable, au titre desquels la contribution a été acquittée. La contribution due sur l’avantage mentionné au I de l’article 80 bis ainsi que sur l’avantage mentionné au I de l’article 80 quaterdecies lorsque ce dernier est imposé à l’impôt sur le revenu selon les règles de droit commun des traitements et salaires est admise en déduction du revenu imposable de l’année de son paiement.”“”

La réponse de GPT-4o-mini est alors :

Le texte fournit les taux et les points associés à la contribution sociale généralisée (CSG) déductible sur les pensions de retraite et d’invalidité, mais il n’indique pas directement la valeur du taux médian de cette contribution pour ces pensions spécifiques.

Pour déterminer le taux médian, il faut considérer les valeurs spécifiques mentionnées :

6,8 points pour un taux de 3,8 % ou 6,2 % 4,2 points pour un taux de 6,6 % 5,9 points pour un taux de 8,3 %

Aucun taux spécifique n’est directement attribué aux pensions de retraite et d’invalidité dans le texte. Donc, il est impossible de déterminer le taux médian de la CSG déductible sur ces pensions de retraite et d’invalidité uniquement à partir des informations fournies dans ce texte.

On voit ici toute la difficulté de la tâche : La réponse du modèle contient la réponse mais la façon dont est rédigée l’article de loi ne permet pas de le déterminer avec certitude. En effet, le taux médian n’est pas directement indiqué dans le texte, il faut le déduire des informations de taux.

On peut aider le modèle en lui fournissant la valeur précédente puisqu’on la connait, en ajoutant la phrase suivante : Sachant que la valeur précédente était ‘0.042’

Maintenant la réponse est correcte :

{
  "valeur": 0.042
}

Mais ça n’est pas une solution fiable car si l’on change la valeur de l’exemple par ‘0.040’ il n’y arrive pas.

Il y a donc des cas où même en donnant le texte de loi il n’est pas possible d’obtenir une réponse fiable.

Cependant des cas qui peuvent paraître complexes pour un humain sont traités de façon satisfaisante. C’est le cas des textes longs avec beaucoup de chiffre, ou encore des tableaux à double entrée, qui portant sont vu comme du texte sous cette forme par le modèle :

<p>Les plafonds de loyers visés au 2° de l'article D. 823-16 du même code sont fixés comme suit (en euros) :</p><p></p><center><div class="table-responsive"><table border="1"><tbody><tr><th><br>
            Zone</th><th><br>
            Personne seule</th><th><br>
            Couple sans personne à charge</th><th><br>
            Personne seule ou couple<br><p> <br>
            ayant une personne à charge</p></th><th><br>
            Par personne à charge<br><p> <br>
            supplémentaire</p></th></tr><tr><td align="center"><br>
            I</td><td align="center"><br>
            319,30</td><td align="center"><br>
            385,09</td><td align="center"><br>
            435,24</td><td align="center"><br>
            63,15</td></tr><tr><td align="center"><br>
            II</td><td align="center"><br>
            278,28</td><td align="center"><br>
            340,62</td><td align="center"><br>
            383,28</td><td align="center"><br>
            55,79</td></tr><tr><td align="center"><br>
            III</td><td align="center"><br>
            260,82</td><td align="center"><br>
            316,17</td><td align="center"><br>
            354,51</td><td align="center"><br>
            50,81</td></tr></tbody></table></div></center><p></p><p><br></p><p> </p><p></p>

Qui donne le tableau suivant :

Zone	Personne seule	Couple sans personne à charge	Personne seule ou couple ayant une personne à charge	Par personne à charge supplémentaire
I	319,30	385,09	435,24	63,15
II	278,28	340,62	383,28	55,79
III	260,82	316,17	354,51	50,81

La réponse à la question `Quelle est la valeur de “Plafond de loyer pris en compte dans le calcul du montant des aides au logement pour un couple sans personne à charge en zone 1 (après la réforme de 2001)” ?_ est correctement donnée par le modèle : 385.09.

Pour arriver à ce résultat, il faut que nous soyons capable de fournir le texte LégiFrance. Or la référence indiquée dans OpenFisca peut ne concerner que la valeur déjà présente. Ce qui ne nous intéresse pas. Nous avons créé une librairie Python exploitant la base de données de Tricoteuses qui est une mise en forme de l’open data de la DILA, qui sert de base à LégiFrance.

Ainsi, partant du lien présent dans OpenFisca, nous pouvons récupérer les différentes versions d’un texte, sa date d’application, les decrets modificatifs, etc…

Tout le projet ne repose donc pas sur les LLM, il a fallut fournir un travail conséquent pour mettre en place les outils nécessaires à l’exploitation des LLM. A la fois pour préparer les textes mais aussi pour manipuler les paramètres OpenFisca afin de les mettre à jour.

Une brique a aussi été créée pour créer la description d’un paramètre à partir de son arborescence en demandant à un LLM de la reformuler.

Un autre appel à un modèle est fait pour trouver la date d’application à partir de la note de la DILA, qui peut être différente de la date de publication du texte ou du décret.

Par contre, quand la référence n’existe pas, cela devient complexe. Nous avons alors opté pour ue approche par agent qui consiste à créer des outils que l’on rend disponible à un LLM pour qu’il les utilise. En réalité il va nous demander de les utiliser pour lui et de lui renvoyer le résultat. Ensuite il va décider de la prochaine étape à suivre. Par exemple nous lui permettons d’effectuer une recherche sur le web, puis de lire le contenu d’une page.

Ainsi, il va pouvoir parcourir le web à la recherche de la référence manquante. Ce procédé c’est montré efficace. Voici un exemple d’amélioration d’un paramètre existant par ce système, les ajouts sont en vert :

Source : PR #2332

Nous allons maintenant détailler ces deux approches que nous avons utilisées.

Approche LLM guidée

Cette approche consiste à guider le modèle en lui fournissant des informations supplémentaires pour l’aider à répondre correctement. Il faut donc commencer par récupérer l’article de loi indiqué dans le paramètre OpenFisca.

Nous pouvons partir de la liste complète agrégés des paramètres, raw_processed_parameters.json pour de la mise à jour en masse. Ou bien du fichier d’un paramètre spécifique, comme marche_travail.salaire_minimum.smic.smic_b_horaire. La librairie openfisca_param.py a été développée pour faciliter cette tâche.

Ensuite nous avons créé une librairie LegiDB qui exploite la base de données de Tricoteuses, qui est une mise en forme de l’open data de la DILA, qui édite LégiFrance. C’est une étape important car il faut réussir à exploiter au mieux ces données pour obtenir le texte pertinent.

En combinant ces informations dans un prompt, comme vu dans le chapitre précédent nous arrivons à obtenir des réponses correctes dans la plupart des cas.

Il faut ensuite mettre à jour le fichier de paramètre dans le source OpenFisca-france avec la réponse obtenue.

Puis une demande de mise à jour est effectuée auprès de la communauté OpenFisca pour que la modification soit intégrée dans la prochaine version, après une validation. Il y a donc toujours une validation humaine de la pertinence de la modification.

Voici un schéma récapitulatif de cette approche :

graph TD
    A(Articles légaux) -->F
    E(Un paramètre OpenFisca) --> F[Article de loi pour ce paramètre]
    F --> |Description du paramètre + article de loi| B[Construit le prompt]
    B --> C[Demande à un LLM]
    C --> D[Met à jour le fichier de paramètre]
    D --> G{Revue humaine}
    G --> |yes|I[Mise à jour de OpenFisca-France]
    G --> |no|H[Rejeté]

Approche Agents Intelligents (LLM Autonome)

Comme vu dans le premier chapitre cette approche donne plus de liberté au LLM, qui peut demander des actions à effectuer. Cela permet de traiter des cas plus complexes, comme la recherche d’une référence manquante.

Une reformulation de la description du paramètre est faite en première étape car les descriptions des paramètres OpenFisca ne sont pas toujours explicites pour les paramètres qui n’ont pas de références : ce sont des paramètres moins souvent manipulés par la communauté. Cette reformulation est faite par un LLM à partir de l’arborescence des descriptions. L’objectif est d’avoir une description autoporteuse et un short_label qui est utilisé dans l’interface web LexImpact. Par exemple pour L’imposition des rentes viagères l’ancienne description était Moins de 50 ans, le LLM la reformulé en Taux imposable pour les rentes viagères des personnes de moins de 50 ans et ajouté un libellé court Moins de 50 ans.

Pour que l’agent puisse effectuer des actions, il faut lui fournir des outils. Nous avons ajouté des outils comme Google ou Tavily, un moteur de recherche optimisé pour les LLM, et la possibilité de récupérer le contenu d’une page web. Ces outils sont mis à disposition du LLM qui peut les utiliser pour effectuer des actions. Par exemple, il peut demander à Google de chercher une référence légale manquante, puis de lire le contenu d’une page web faisant parti du résultat.

Le LLM peut aussi demander à un autre LLM de vérifier la réponse qu’il a obtenu. Cela permet de valider la réponse obtenue.

Il peut effectuer ces étapes dans l’ordre qu’il souhaite et autant de fois qu’il le souhaite. Il y a cepandant une limite du nombre d’appels pour éviter de tourner en rond pour rien. Et un mot clef que le LLM doit utiliser pour indiquer qu’il a terminé.

Les agents ne sont en fait que des instances de simples LLM comme dans le chapite précédent, mais qui ont la possibilité de demander des actions à effectuer.

Pour organiser ces appels nous utilisons la librairie Python LangGraph qui permet de décrire des processus de décision. Voici le schéma récapitulatif de cette approche :

graph TD
    E(OpenFisca parameter) --> F[Reformule la description<br/> avec un LLM]
    F --> |Description| B[Fabrique le prompt]
    B --> Lawer_reference_specialist
    Lawer_reference_specialist["Agent chercheur"] --> Lawer_checker["Agent vérificateur"]
    subgraph "Préparation"
        E
        F
        B
    end
    subgraph "LLM Agents&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp"
        Lawer_reference_specialist
        Lawer_checker
    end
    Lawer_checker --> fin["Réponse finale"]
    Lawer_checker --> call_tool["Outils"]
    Lawer_reference_specialist --> call_tool
    Lawer_checker --> Lawer_reference_specialist
    call_tool --> Lawer_checker
    call_tool --> Lawer_reference_specialist
    Google["Recherche sur le web"] --> call_tool
    WebCrawler["Récupérateur de page web"] --> call_tool
    subgraph "Outils à disposition"
        call_tool
        Google
        WebCrawler
    end
    fin --> D[Met à jour le paramètre]
    D --> G{Revue humaine}
    G --> |oui|I[Met à jour OpenFisca-France]
    G --> |non|H[Rejeté]
    subgraph "Finalisation"
        fin
        D
        G
        I
        H
    end

Coûts récurents

Le fait de recourir à des modèles hébergés par des entreprises privées comme OpenAI et accessible par des API facilite beaucoup les choses mais entraine des dépenses car il faut payer chaque appel à ces API, il n’y a pas d’offre gratuite comme avec les versions web grand public.

Et les prix varient fortement en fonction du modèle utilisé, même chez un même fourniseur, ici OpenAI, au 3 septmebre 2024 :

Modèle	Coût / 1M input tokens
gpt-4	$30.00
gpt-4o-2024-08-06	$2.50
gpt-4o-mini-2024-07-18	$0.150

Source : OpenAI API Pricing

Voici un extrait de montants facturés pour notre usage :

Le 23 mai 2024 nos tests de GPT-4 avaient coûtés 7$ pour 215 appels, soit 3.2 centimes par appel. Alors que 63 appels à GPT-4o-mini le 23 juillet 2024 ont coûtés 3 centimes, soit 0.05 centime par appel, une réduction d’un facteur 64 !

Si l’on considère que nous avons besoin de faire 2 000 appels par mois pour maintenir à jour les paramètres, cela représente un coût mensuel de 100$ pour GPT-4o-mini.

Orientations futures

L’intégration dans le flux de travail d’OpenFisca est en cours. L’objectif initiale du projet envisageait une mise à jour automatique en masse, cependant la nécessité d’une revue humaine laisse penser qu’il serait préférable d’avoir une interface web pour demander des mises à jour ciblées, qui seraient ensuite validées par la communauté.
Des préoccupations de coût et de souveraineté se pose, d’où le besoin d’explorer des alternatives LLM open-source, telles que les modèles Llama 3 ou Mistral.

Dans ce cadre les ressources de Jean-Zay ont été exploitées pour entraîner des modèles ouverts. Le code source de fine-tuning est disponible sur le GitLab de LexImpact . Cependant, cette partie a été mise en pause pour ce concentrer sur l’intégration dans les processus de travail afin de valider la faisabilité sur toute la chaîne. Pour cela nous avons utilisé l’API OpenAI qui a permis des résultats supérieurs aux modèles ouverts disponibels en 2023.

Maintenant que nous avons validé la faisabilité du projet, nous souhaitons reprendre ces travaux en 2025 pour être en mesure d’utiliser des modèles ouverts, dont les performances ne cessent de s’améliorer.

Conclusion

L’expérience démontre le potentiel des LLM dans l’automatisation de tâches juridiques et administratives complexes. Bien que des défis subsistent, les progrès rapides des capacités des LLM laissent présager un avenir prometteur pour la maintenance assistée par IA de systèmes comme OpenFisca.

Le projet a montré des progrès significatifs au cours de l’année écoulée, avec un taux de réussite inexploitable en début de projet à plus de 90% aujourd’hui, cela montre la vitesse à laquelle la technologie évolue. Il est donc important de maintenir une veille constante sur les avancées à la fois en matière de modèle mais aussi d’outils pour les exploiter.

Sur le très long terme il pourrait être envisagé de maintenir de cette façon non plus seulement les paramètres fiscaux mais aussi la traduction des textes en code Python.

Remerciements

Ces travaux ont bénéficié d’un accès aux moyens de calcul de l’IDRIS au travers de l’allocation de ressources 2023-AD011014553 attribuée par GENCI. Nous avons eu accès au supercalculateur Jean Zay pour sur-entraîner (fine-tuning) des modèles existants et évaluer des gros modèles OpenSource comme Llama.
La participation au programme 10% d’Etalab a permis de bénéficier de l’émulation du groupe autour de ces technologies.