Mise à jour : si l’article posté était bien un poisson d’avril, le lien entre potentiels bugs et pratiques d’ouverture n’en reste pas moins intéressant.
Le code source de la calculatrice des impôts a été présenté ce matin. \o/ L’un des participants au hackathon #CodeImpots aurait découvert un bug d’arrondi qui pourrait engendrer des rappels si c’est réellement ce code qui est en production à la DGFiP.
Il va être intéressant de voir comment réagissent les autorités. Aux extrémités, je perçois deux postures :
- « L’erreur est humaine, si nous avions partagé ce code plus tôt nous n’aurions peut-être pas poussé cette erreur en production. Le partage donne l’occasion à nos agents d’améliorer continuellement nos applications et nous leur en donnerons les moyens. Ce changement de culture se fera progressivement mais il faut prendre le pas tout de suite. Cette nouvelle pratique est la suite logique des démarches de mutualisation des SI. »
- « Ce coup de com’ était sympa mais revenons à nos pratiques ancestrales et à une opacité totale où l’on peut imaginer faire les choses parfaitement sans que ce soit vérifiable. Nous utiliserons à l’avenir l’exception de sécurité nationale de la loi pour une République Numérique pour bloquer toute nouvelle tentative d’accès par la CADA (article 1 bis du texte présenté au sénat). La volonté politique de changement n’est pas assez forte. »
Je croise les doigts pour que le premier cas l’emporte durablement !
Petite satisfaction personnelle pour terminer : la DGFiP a décidé d’utiliser Python pour développer son interpréteur. Mon langage préféré se diffuse donc au delà d’OpenFisca dans la sphère publique. 😉
Tu ne crois pas que la découverte de ce bug soit liée avec la date d’aujourd’hui ? 😀
on ne retrouve pas cette fameuse ligne de code dans les dépots… (https://github.com/search?utf8=%E2%9C%93&q=org%3Aopenfisca+math.ceil&type=Code&ref=searchresults)
J’avoue m’être fait avoir comme un bleu ! Il est cependant probable que la question se posera à un moment ou un autre…