Quelques semaines après l'ouverture du code source du calculateur des impôts, l'administration française poursuit son effort d'ouverture avec le modèle Ines de l'Insee et la Drees, libéré mardi 14 juin 2016 sous licence CeCILL v2.1. Ce modèle, ou simulateur, est utilisé pour produire des analyses statistiques sur la structure des prélèvements et prestations sociales sur le niveau de vie des ménages.
La seconde partie de la dépêche détaille l'intérêt d'Ines et les possibilités qui sont désormais ouvertes et celles qui ne le sont pas.
Qu'est-ce que le modèle Ines ?
Le modèle Ines, écrit en SAS (langage propriétaire), sert à simuler les prélèvements et prestations des ménages, en utilisant un échantillon représentatif (ERFS). Il calcule notamment l'impôt sur le revenu, la CSG, les cotisations, les prestations familiales, le RSA, etc. Depuis 2 ans, il permet de dresser un bilan des mesures sociales et fiscales de l'année révolue, décliné en fonction du niveau de vie des ménages. Il est également utilisé pour produire des estimations précoces de l'évolution du taux de pauvreté.
Par ailleurs, il sert à effectuer des chiffrages d'éventuelles réformes pour le pouvoir politique (notamment les cabinets ministériels).
La libération
Si le modèle fête son vingtième anniversaire, il n'est sous gestionnaire de version que depuis quelques années. L'historique des commits générés depuis est disponible dans sa totalité : le dépôt libéré est une vraie copie complète du dépôt de travail (et contient donc également les mises à jour quotidiennes).
La documentation est également disponible que ce soit pour le prendre en main en tant qu'utilisateur ou développeur.
Le code est en licence CeCILL v2.1, tandis que le fichier de paramètres est en ODbL. Le tout est disponible sur la forge d'Adullact, pour l'instant sous condition de créer un compte.
Les limites
Le code écrit en SAS, fréquent toutefois chez les statisticiens, en limitera plus d'un.
L'ouverture ne concerne que la branche principale, et notamment pas le code spécifique à chaque étude ou commande ministérielle.
L'accès aux données ERFS (contenant des déclarations fiscales réelles) n'est possible qu'après examen d'un projet au comité du secret statistique. Sans cette démarche, les curieux ne pourront que lire le code. Libre à eux de l'adapter pour le faire tourner sur des sources différentes, par exemple les données du site Pour une révolution fiscale de Landais, Piketty et Saez.
Les projets proches
Le projet OpenFisca, soutenu aujourd'hui par Etalab, simule également les prestations et prélèvements sociaux et fiscaux. Écrit en Python et sous licence AGPL, il est notamment utilisable avec une interface web pour estimer sa situation personnelle. Ils travaillent sur une première version stable, qui contiendrait notamment la documentation.
Le code des impôts, écrit en langage M, propre à l'administration fiscale, a été ouvert le 1er avril 2016 dans sa version ayant calculé l'impôt sur les revenus perçus en 2014.
En 2011, les économistes C. Landais, T. Piketty et E. Saez avaient à l'occasion de leur ouvrage Pour une révolution fiscale ouvert un site web permettant de simuler sa propre réforme et proposant l'ensemble de leurs programmes et données, sans licence explicite.
Aller plus loin
- Le site du projet Ines libre (357 clics)
- Description complète d'Ines (133 clics)
- Communiqué de presse de l'Insee et de la Drees (166 clics)
- Un article sur NextInpact (118 clics)
# Yes
Posté par Guillaume Maillard (site web personnel) . Évalué à -2.
J'aime bien ce côté "rien a foutre des standards" de nos institutions.
Vive les langages SAS et M, ouvrons nos esprits à ces langages, voyons!
Une réécriture en BF financée par nos impôts s'impose…
Je vous laisse admirer le beau HTML 'Microsoft Word 12' de cette page https://ines-libre.adullact.net/
Misérable.
[^] # Re: Yes
Posté par lolop (site web personnel) . Évalué à 10.
Ils ont un logiciel qui a 20 ans, et qu'ils maintiennent, et qu'ils publient. Avant de critiquer ainsi le choix du langage, il faudrait peut-être regarder ce qu'il y avait de reconnu et capable de répondre à leurs besoins à l'époque.
Quant à une réécriture, si leur logiciel actuel est stable, tourne de façon sûre et connue, mettre des fonds pour le re-développer et vérifier de A à Z dans un autre langage peut être une décision qui n'est pas prioritaire…
Votez les 30 juin et 7 juillet, en connaissance de cause. http://www.pointal.net/VotesDeputesRN
[^] # Re: Yes
Posté par Guillaume Maillard (site web personnel) . Évalué à 2.
Humm… parce que pour écrire ça : https://github.com/openfisca/calculette-impots-m-source-code/blob/master/src/chap-87.m
les langages qui existaient en 1996 : Java, C, C++, Python et j'en passe…
n'étaient pas assez adaptés et cela justifiait de créer un beau langage tout en français, son compilateur et 20 ans de maintenance… sans compter la formation des petits nouveaux.
Pour les lecteurs pressés, voici un extrait de code M écrit avec nos impôts (https://github.com/openfisca/calculette-impots-m-source-code/blob/master/src/coc2.m , fin de fichier) :
On applaudira chaudement le style.
[^] # Re: Yes
Posté par lolop (site web personnel) . Évalué à 5. Dernière modification le 16 juin 2016 à 21:57.
C'est du SAS dont ils parlent, un langage proprio et commercial. Et les langages que tu cites étaient plutôt… jeunes ou pas adaptés. J'ai fais le choix Python en 1995, et à l'époque c'était un pari dont je peux comprendre que certains ne l'aient pas fait. C'est toujours facile de revenir a postériori sur des choix.
Même en 2012 SAS semblait avoir encore son intérêt face à son concurrent "naturel" R:
http://stats.stackexchange.com/questions/33780/r-vs-sas-why-is-sas-preferred-by-private-companies.
Votez les 30 juin et 7 juillet, en connaissance de cause. http://www.pointal.net/VotesDeputesRN
[^] # Re: Yes
Posté par arnaudus . Évalué à 1.
Mouais, à la lecture des réponses, ça me parait loin d'être évident. La plupart des raisons évoquées sont assez bidon.
[^] # Sur M
Posté par lolop (site web personnel) . Évalué à 10. Dernière modification le 17 juin 2016 à 10:04.
https://forum.openfisca.fr/t/code-source-de-la-calculette-impots-et-outils-connexes/37
Je ne connaissais pas M, mais de ce que j'en lis dans le lien ci-dessus, c'est un langage dédié au domaine des règles fiscales et calcul des impôts (un DSL), dont la syntaxe est suffisamment simple pour que des outils de parsing et de traduction permettant de l'exécuter sur du Python, voir Python parallélisé aient pu être développés…
Et quand on regarde les sources, ça ressemble beaucoup à une reprise des champs de déclarations d'impôts intégrés dans les (nombreuses et trop complexes) règles fiscales pondues par nos législateurs. Dans l'exemple que tu donnes:
https://github.com/openfisca/calculette-impots-m-source-code/blob/master/src/coc2.m
Une logique administrative compilable et compréhensible par les gens qui ont à travailler dessus, que le style ne te plaise pas n'est pas grave, ça n'est pas toi qui travaille avec.
Bref, l'administration s'est dotée d'un outil dont elle avait besoin, sa syntaxe est en français et très simple, et alors, si ça leur permet de répondre à leurs besoins en permettant d'exprimer les règles de calcul fiscal, ça ne me choque pas, c'est peut-être plus productif que d'essayer de faire rentrer un langage générique dans leur besoin particulier.
Votez les 30 juin et 7 juillet, en connaissance de cause. http://www.pointal.net/VotesDeputesRN
[^] # Re: Sur M
Posté par Guillaume Maillard (site web personnel) . Évalué à -2.
Evidemment!
positif(COD2FA + 0) + positif(RCMHAB + 0) > 1
C'est tellement simple que tu vas nous expliquer la rationalité de la chose… un expert pour décoder ce test?
Je dois vraiment fatigué en ce moment, j'ai du mal à voir l’intérêt de traduire le M et Python plutôt que d'écrire des 'if' en Python en sacrifiant le 'si'.
En 1985, j'utilisais déjà un truc facile d'accès qui s'appelait le BASIC, alors vouloir m'expliquer qu'en 1996 on n'avait rien pour coder, c'est en avoir dans le pantalon.
[^] # Re: Sur M
Posté par lolop (site web personnel) . Évalué à 6.
Faudrait peut-être que tu lises un morceau ce M un peu plus long, il semble y avoir un système de règles activées, de contrôles, de références numériques (peut-être à des textes législatifs). Ça peut probablement se goupiller en Python (et perso c'est ce que je ferais).
Mais tu juges sans savoir: de quand date le langage M à l'origine, quel était le public cible et sa culture informatique / développement, qu'est-ce qui était autorisé dans les services info des finances à l'époque, qu'est-ce qu'il y avait avant, sur quoi étaient exécutés les programmes en M, etc.
Quand au BASIC, regarde l'age du langage SAS, lis les discussions stackexchange de 2012 que je t'ai donné en lien, mesure la pérennité du langage (quel Basic… j'ai pu faire du GW-Basic, du Basic ApppleSoft, il y avait aussi le Quick Basic… (Borland je crois), depuis il y a eu Visual Basic, etc).
Bref, je comprendrais des questions sur le pourquoi de certains choix, mais pas une condamnation vindicative envers les personnes qui ont développé ces outils de calcul sans avoir tous les éléments (si certains connaissent le pourquoi du comment…).
Votez les 30 juin et 7 juillet, en connaissance de cause. http://www.pointal.net/VotesDeputesRN
[^] # Re: Sur M
Posté par lolop (site web personnel) . Évalué à 5.
Trouvé un doc sur M:https://forum.openfisca.fr/uploads/default/original/1X/f345439aa9396939ee640dba77359677f4b85bdf.pdf
Vraiment très lié aux besoins métier. Et ça date des années 90, l'open source n'était pas développé et reconnu comme il l'est actuellement.
Votez les 30 juin et 7 juillet, en connaissance de cause. http://www.pointal.net/VotesDeputesRN
[^] # Re: Sur M
Posté par Guillaume Maillard (site web personnel) . Évalué à 1.
Evidemment qu'entre utiliser un langage qui existe (C/C++/Basic/Java/Python/Cobol/…) et créer le fameux M (et son compilateur) parce que peut être que 20 ans plus tard certains de ces langages pourraient être moins utilisés, c'est très intelligent.
Pour rebondir sur la qualité de ce langage et ses qualité, les slides de présentation nous apprennent que :
positif(a) se traduit par Si a > 0 alors 1 sinon 0
Ce qui fait que le petit exemple :
démontre au combien nous avons des stars de la programmation. Car le code :
est strictement équivalent en M.
Les questions à se poser sont aussi pourquoi en 2016, M n'a pas disparu… et pourquoi on se félicite de cela, quitte à défendre comme tu le fais ce Machin. As tu des amis dans ces milieux ou apprécies tu que tes impôts soient utilisés à maintenir ce genre de blague tout en se félicitant dans la presse de l'ouverture du code?
Mes remarques ne sont pas vindicatives, je ne suis pas non plus sur mon petit nuage du tout est merveilleux. Je passe peut être trop de temps à dealer avec toutes les aberrations informatique que nous pondent URSSAF, DGI et autres. Ces formats à colonne fixe, à transtypage inutiles, les formats où les caractères sont '7bits' + exceptions, les formats ou les lignes ne doivent pas dépasser 256 caractères : j'en ai ma claque.
Tu penses bien que l'XML ou JSON et l'UTF8 sont trop récents ou pas assez badass.
Seulement cela ne concerne pas de vieux trucs, mais la DSN qui rentre en application ce juillet, ou encore l'export FEC pondu il y a 1 an…
Il y de quoi alimenter http://thedailywtf.com/ pendant des années.
[^] # Re: Sur M
Posté par lolop (site web personnel) . Évalué à 8.
Très bas. Non.
Pour M, penses-tu qu'une réécriture dans un langage "commun" de toutes les règles + la vérification que ça tourne à l'identique + formation des utilisateurs + réécriture des codes qui communiquent avec d'autres systèmes, reviendrait moins cher que le simple maintien fonctionnel des moulinettes de calcul ?
Je n'en suis franchement pas sûr. Le
M— avec ses défauts que tu relèves¹ — permet une écriture simple des règles d'imposition. Tout bug dans ce système pourrait toucher potentiellement 37,1 millions de contribuables et conséquemment le budget de l'état… une décision de réécriture d'un tel système ne se fait pas à la légère (cf l'échec du projet Louvois pour la rémunération des militaires, et autres grands échecs).On aurait un article disant que l'IRS publie un DSL pour le calcul des impôts aux États-Unis, tout le monde trouverait ça très bien et moderne (faire un langage qui permet d'exprimer simplement tes contraintes sous formes de règles que tu peux lier au code législatif et aux champs des documents de saisie des déclarations d'impôts…), il y aurait des 'if' et probablement ils auraient évité les petits trucs qui te turlupinent tant.
Je peux comprendre ton ras le bol sur des normes et des trucs anciens que tu te coltines encore maintenant (encore plus lorsque la définition de trucs modernes reprennent ces contraintes). Il y a des choses qui évoluent très très lentement, des installations certifiées auxquelles tu ne veux pas toucher… et aussi la résistance au changement de la part des gens. L'informatique a le grand inconvénient d'être en perpétuelle mutation avec beaucoup d'effets de modes ou de technos éphémères, ça complique nettement la construction de choses pérennes pour les gens qui doivent voir plus loin que le mois qui viens, et ça ralentit la prise en compte des nouveaux standards (note: je ne justifie en rien les raisons qui ont conduites à faire "DSN" et "FEC", je ne sais pas ce que c'est et je n'ai pas les billes pour me faire un avis) .
¹ J'ai regardé le code de la moulinette Python, l'implémentation du
posifitf()fait réellement unreturn int(value > 0). Je trouva ça con aussi, mais je n'étais pas devant le clavier au moment où il a fallu coder l'interpréteur M dans je ne sais quel langage d'origine, et je ne connais pas l'expérience du développeur au moment où il a écrit son code.Votez les 30 juin et 7 juillet, en connaissance de cause. http://www.pointal.net/VotesDeputesRN
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à -10.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Sur M
Posté par lolop (site web personnel) . Évalué à 4.
C'est le rôle des legislateurs de définir les règles, pas des fonctionnaires en charge du recouvrement des impôts.
Votez les 30 juin et 7 juillet, en connaissance de cause. http://www.pointal.net/VotesDeputesRN
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à -10.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Sur M
Posté par barmic . Évalué à 3.
Je suis à peut prêt sûr du contraire. Je ne pense pas qu'il faille faire une réécriture from scratch, mais aller dans une direction où :
f (fiche impôt) → montant de l'impôt.Ferrait gagner de l'argent à tout le monde (État et contribuable).
Faire un choix qui 20 ans plus tard ne paraît pas très pertinent ce n'est pas grave. Ce qui est grave c'est de ne pas éponger sa dette et éponger une dette ça ne consiste pas à la siphonner en 3 mois en refaisant un projet from scratch à 4 millions d'euros.
Utiliser les techniques actuelles de lien de suivi des exigences. Ça demande pas de changer de techno, juste de changer sa façon de fonctionner et ça permet d'utiliser ensuite toutes les techniques de qualité actuelles. Ça crée la possibilité d'avoir un découplage entre la manière dont tu t'assure que le logiciel fais ce que tu veux et la techno de ton logiciel. Bref c'est un travail préparatoire à un changement de technologie au final. C'est pas une question de prix ou de risque, juste de volonté et de gestion.
Ce code est pourri dans le sens où il est inutilisable. Je n'ai pas l'impression que ce code puisse servir à faire des simulations simples par exemple (histoire de pouvoir tester des lois).
Bref personnellement je me fou de savoir qu'ils sont parti au début sur M, lisp ou Fortran, si leur choix ne paraît pas judicieux aujourd'hui et si le coût et si élevé c'est de la faute d'un architecte et/ou de la gestion du projet.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Sur M
Posté par lolop (site web personnel) . Évalué à 2.
Personne n'a donné le coût du projet et de sa maintenance actuelle.
Votez les 30 juin et 7 juillet, en connaissance de cause. http://www.pointal.net/VotesDeputesRN
[^] # Re: Sur M
Posté par barmic . Évalué à 3.
Quand tu commence a devoir former de 0 tous tes nouveaux employés sur ta techno, quand tu galère à trouver des experts de cette techno, quand tu vois que ces logiciels n'ont pas de prix public, tu peux t'attendre à des prix exorbitant, quand tu va être contraint de faire une partie de la formation chez ton presta,…
Je peux imaginer qu'il y a un coût en trop assez élevé. Et je ne parle que de ce qui est chiffrable, il y a la dépendance forte à une entreprise qu'on engraisse bon gré mal gré depuis 20 ans, il y a les éventuels bugs d'un logiciel peu diffusé, il y a les bugs du fait que ton équipe se retrouve avec des noobs de la techno, le fait que tu forme ton équipe à une techno qu'ils ne réutiliseront jamais autre part, il y a le manque de motivation pour ton équipe d'apprendre quelque chose d'aussi peu utile,… Tout ça va nuir à la qualité ou à la productivité sans que ce soit chiffré quelque part
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Sur M
Posté par lolop (site web personnel) . Évalué à 4.
Au ministère des finances, les nouveaux employés ne sont peut-être pas tous informaticiens, il est probablement plus simple de les former à l'expression des règles législatives en M qu'à l'expression de ces mêmes règles dans un langage générique.
Y'a la moulinette (une fois qu'elle tourne, quelque(s) personne(s) pour l'entretenir — et vu comment les traducteurs ont pu être créés lors d'un hackaton, le fonctionnement semble suffisamment logique et documenté).
Pour le reste, tu n'auras pas besoin d'experts, juste de fonctionnaires des finances qui apprennent à traduire leurs règles dans un langage formel adapté.
On ne parle pas d'un framework web, mais d'un outil pour permettre au ministère des finances de faire les calculs d'imposition. Si ça a été développé en interne, y'a pas de "prix public", y'a au mieux du temps passé par une petite équipe pour le développer, et ensuite par une plus grosse pour traduire en M toutes les règles législatives relatives à l'imposition.
Où a-t-il été question de prestataire?
Tu ne peux rien du tout, tu ne connais rien du cadre de développement et de la maintenance de M et des programmes des règles d'imposition en M (quels profils, combien de temps…).
Laquelle?
Encore une fois, c'est l'outil du ministère des finances pour le calcul des impôts, pas un framework web. 1) ce sont eux qui sont là pour interpréter le texte donc pour "informatiser" la loi, 2) les autres suivent ce qu'ils font. Et s'il y a des bugs… ça a un impact réel et rapide chez 37,1 millions de contribuables ; je pense qu'ils doivent un peu faire relire les programmes en M avant de mettre en production.
Hé bien, probablement moins que si ça avait été développé avec un langage générique au lieu du DSL M. Celui-ci donne des capacités d'expression adaptées aux besoins. Si tu avais à réécrire tout ça (M + les programmes en M), tu devrais le faire avec des outils génériques et je suis sûr que tu aurais au final plus de bugs car la sémantique de tes expressions serait plus éloignées des règles métier.
Où, autre part, est-on chargé d'être maître de l'interprétation des règles législatives en matière d'imposition?
Paradoxalement, devoir se limiter à apprendre un langage dédié au domaine que l'on maîtrise et pas un truc générique plein de choses dont on n'a pas besoin, est peut-être plus motivant pour les gens qui traduisent les règles financières.
Et… je ne pense pas qu'ils soient informaticiens (ou alors, en effet ça doit être démotivant et ils ne doivent pas rester longtemps en poste).
… tu es libre de le penser, mais repenses-y en regardant dans quel cadre on est dans ce cas précis …
Votez les 30 juin et 7 juillet, en connaissance de cause. http://www.pointal.net/VotesDeputesRN
[^] # Re: Yes
Posté par NeoX . Évalué à 6.
oui sauf que là c'est probablement un article redigé par l'ADULLACT plus que par l'INSEE
donc l'INSSE n'est pas à critiquer sur ce coup là.
quand aux langages, comme le dit l'autre post, faut voir ce qui existait au lancement du projet, il y a 20 ans.
# Bonne idée
Posté par Nicolas Chevallier (site web personnel) . Évalué à 4.
On va pas critiquer pour une fois que nous allons dans le bon sens ! Parce que je sais pas si vous êtes au courant, mais on est plutôt dans la mode du "la data c'est du caviar" et chacun pense que sa BD d'utilisateurs, d'interactions … vaut de l'or.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.