Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

Bercy publie le code source du calculateur de la taxe d'habitation
La DGFiP a choisi C comme langage, mais la qualité du code est remise en question

Le , par Michael Guilloux

254PARTAGES

23  0 
En collaboration avec la mission Etalab qui coordonne la politique d’ouverture et de partage des données publiques (open data), Bercy vient de publier le code source de la taxe d'habitation 2017. Rappelons que les initiatives d'ouverture de code source, de plus en plus fréquentes en France, s’inscrivent dans la mise en œuvre de la Loi pour une République numérique. Promulguée en octobre 2016, cette loi impose à l’État et aux collectivités territoriales de communiquer le code source des logiciels qui sont produits dans le cadre des services publics, sur demande. Les codes sources sont en effet désormais considérés comme des documents administratifs, ce qui les rend accessibles à tout citoyen qui en fait la demande à la Commission d'accès aux documents administratifs (Cada).


C'est ainsi qu'après avoir été interpellée sur la question, le 28 juin dernier, la Cada a invité le ministère de l'Economie et des Finances à publier le code source du calculateur de la taxe d'habitation. Celui-ci permettra de connaître précisément comment est calculée la taxe et donnera la possibilité aux internautes de tester différentes variables.

Le code de la taxe d'habitation, qui est produit par la Direction Générale des Finances publiques (DGFiP) a été publié il y a trois jours sur GitHub. On y trouve :
  • un dossier contenant les scripts C tels qu'utilisés par la DGFiP pour calculer la taxe d'habitation 2017 ;
  • un dossier documentation contenant 3 fichiers (données en entrée, données en sortie et liste des anomalies) ;
  • un dossier test permettant de tester le code sur quelques exemples et qui contient un exécutable, des fichiers d'exemples et une documentation expliquant comment faire fonctionner la calculette sur les jeux d'exemple.

Si l'initiative d'ouverture est à saluer, pour beaucoup de développeurs, c'est la qualité et l'utilité du code qui ont attiré leur attention :
  • noms de variables et commentaires en français (parce qu'ils devraient être en anglais ?) ;
  • convention de nommage incohérente dans toute la base de code. Exemples pour les noms composés de plusieurs mots : Determination_Plaf_Total (chaque mot commence par une majuscule), est_autre_allegement (chaque mot commence par une minuscule), cherche_Erreur (certains mots commencent par une majuscule et d'autres par une minuscule) ;
  • combinaison ou utilisation de plusieurs styles d'indentation dans la base de code ;
  • aucune instruction pour faire un build ;
  • etc.


Sources : Code source de la taxe d'habitation, Réseaux sociaux

Et vous ?

Que pensez-vous de l'ouverture du code source du calculateur de la taxe d'habitation ?
Avez-vous parcouru le code source ? Qu'en dites-vous ?
Comment pourrait-on expliquer la qualité du code ?

Voir aussi :

Bercy ouvre les codes sources des modèles économétriques Mésange, Opale et Saphir, sous la pression d'une association
Ouverture des codes source : la DINSIC lance un appel à commentaires sur la politique de contribution aux logiciels libres de l'État français
France : le code source des logiciels des administrations est communicable, sauf si cela pourrait porter atteinte à la sécurité de leurs SI
La CMP estime que les codes source des logiciels utilisés en administrations publiques sont communicables par principe, d'après l'avis de la CADA
Les députés adoptent un amendement imposant la communication des codes source de logiciels utilisés ou développés par l'administration

Une erreur dans cette actualité ? Signalez-le nous !

Avatar de Stérilux
Membre régulier https://www.developpez.com
Le 17/09/2018 à 16:12
Que pensez-vous de l'ouverture du code source du calculateur de la taxe d'habitation ?
C'est une bonne chose

Avez-vous parcouru le code source ? Qu'en dites-vous ?
Qu'il est plutôt clair.

Comment expliquez-vous la qualité du code ?
Qu'il est codé de façon à emmerder les psycho-rigides uniquement. Les amateurs auront beaucoup de facilité à le comprendre par rapport à ceux ayant tendance à péter une durite si une ligne a le malheur de compter 81 caractères

Evitez de trainer sur des sources de logiciels chinois, ils vont vous tuer
13  1 
Avatar de Guntha
Membre éprouvé https://www.developpez.com
Le 17/09/2018 à 16:02
Citation Envoyé par Michael Guilloux Voir le message

Que pensez-vous de l'ouverture du code source du calculateur de la taxe d'habitation ?
Plus de transparence, quel que soit le domaine, c'est toujours mieux.

Citation Envoyé par Michael Guilloux Voir le message

Avez-vous parcouru le code source ? Qu'en dites-vous ?
Rapidement: beaucoup de nombres magiques non expliqués et de noms de variable absconses, au final ça se rapproche presque d'un portage en C du code en TROLL auquel on a eu droit quelques jours plus tôt. Au moins, le choix du C plutôt que TROLL(j'ai cru que c'était une blague en lisant la news, mais c'est vraiment le nom de la techno) montre que dans la chaîne, il n'y a pas eu un fonctionnaire qui s'est bêtement fait avoir par un commercial pour acheter une technologie inutile.
Déjà, quand j'ai vu l'expression "scripts C" dans le readme sur github j'ai tiqué
Des noms de fichier qui font tous 8 lettres, comme si le programme avait été développé sous DOS???
C'est un peu dommage que toutes les data soient dans le code, on se retrouve avec tous ces nombres magiques sans explication. Si au moins des fichiers contenant ces chiffres avaient été générés depuis des fichiers Excel/csv (qui contiendraient toutes les explications nécessaires), ou carrément extraire ces chiffres à l'exécution, mais là les chiffres ont été semés dans le code sans explication.
Par contre, je ne comprends pas les gens qui s'offusquent du français; ce code n'est pas destiné à être distribué à l'internationale. Il y a peu de chances qu'un autre pays adopte le même calcul d'impôts que nous :p

Citation Envoyé par Michael Guilloux Voir le message

Comment expliquez-vous la qualité du code ?
Euh "expliquer" la qualité de ce code, je vois mal comment faire ça sans connaître le manager et l'équipe qui l'a fait, leurs contraintes, leur budget... On ne peut que constater le résultat. Ou spéculer et dire que ce sont des comptables de métier qui ont appris à programmer sur le tas?
8  0 
Avatar de el_slapper
Expert éminent sénior https://www.developpez.com
Le 19/09/2018 à 9:10
Citation Envoyé par Marco46 Voir le message
@Peut-êtreUneRéponse

Ok merci, donc 38 ans de dette technique non payée. Sympa.
on peut aussi regarder dans l'autre sens : 38 ans de corrections et d'ajustements qui font que ça marche dans tous les cas. J'ai moi-même travaillé sur du code de 36 ans d'âge, dans le privé, bien plus moche que ça (j'y fais parfois référence), et ça a beau être immonde, ça marche. Ca marche parce-que ça a été confronté au monde réel pendant des dizaines d'années. Ca marche parce-que toutes les erreurs du départ ont été corrigés par des verrues. Moches mais efficaces. Refondre un code pareil, ça n'a rien d'évident. D'ailleurs, j'avais laissé certains morceaux tels quels. Ca marche, ça ne change jamais, pourquoi prendre le risque? J'avais refondu, en plus propre, tout ce qui était susceptible de bouger, et en plus tout ce qui état refondable sans trop de risques. Mais un code de taxe d'assurances illisible, incompréhensible, dont les experts métiers ne savent pas comment il marche, mais qui n'a pas connu de bug depuis plus de 20 ans? Non, je n'allais pas me lancer là-dedans.

Il y a toujours un équilibre à trouver entre refaire au propre et garder ce qui marche. être extrémiste dans un sens ou dans l'autre est contre productif. Dans un sens, parce-qu'effectivement on termine avec des horreurs illisibles. Dans l'autre sens, parce-qu'on prend des risques parfois excessifs au nom de la pureté visuelle du code. Perso, un code un peu moche, un peu dépassé, mais qui s'intègre parfaitement dans un existant ancien et qui tourne comme du papier à musique, ça ne me choque pas. Même si ça n'est pas totalement satisfaisant.
8  0 
Avatar de Edrixal
Membre éclairé https://www.developpez.com
Le 17/09/2018 à 17:33
Citation Envoyé par Michael Guilloux Voir le message

Que pensez-vous de l'ouverture du code source du calculateur de la taxe d'habitation ?
C'est une très bonne chose.

Citation Envoyé par Michael Guilloux Voir le message

Avez-vous parcouru le code source ? Qu'en dites-vous ?
Les noms des variables semble étrange au premier abords, mais pas dénuée de logique quant on à quelques connaissance sur le sujet. Y'a beaucoup de commentaire et la manière de les mettre en place ne sont pas forcément les choix que j'aurais fait, mais honnêtement pour avoir repris des logiciels sans commentaire, ou juste le strict minimum, ici c'est le paradis !
Dans l'ensemble d'un avis personnel, je trouve le code clair et lisible. En voyant les commentaires et ce qui été dit ici, je m'attendais à un truc imbitable. Alors que non.

Les règles de nommage ne sont certes pas suivis, plusieurs personnes on visiblement travailler sur le projet sans s'accorder à 100% sur les manières de faire. Mais dans l'ensemble le code est lisible et propre, alors pourquoi faire polémique parce que les règles de nommage ne sont pas suivis ? La lecture n'en est pas rendu plus compliqué.
J'ai plus l'impression de voir des grammarnazi qui s'amuse à relever de manière plus ou moins agressive la moindre faute qu'ils vont trouvés pour faire valoir qu'ils sont supérieur. Mais façon codeur.

Citation Envoyé par Michael Guilloux Voir le message

Comment pourrait-on expliquer la qualité du code ?
Plusieurs personnes qui on travailler sur le projet. Potentiellement des stagiaires par ailleurs. Reste qu'après il faut aussi connaitre le management de l'équipe, le cahiers des charges, le temps alloué, savoir si les commentaires on été mis sur le coup ou après les dev, la précision du cahier des charges aussi, ect... Difficile de donner une réelle réponses au final.
8  1 
Avatar de survivals
Membre actif https://www.developpez.com
Le 18/09/2018 à 0:20
Ceux qui critique la langue dans le code sont juste des types qui veulent péter plus haut que leur cul. Ce code particulièrement, n'est pas destiné à être Internationale, et n'est surement pas maintenu depuis le début par les mêmes personnes, le Français est ce qu'il y a de plus facile à comprendre pour un Français, de même que les mainteneurs suivant ont du faire la même chose pour éviter d'avoir de l'Anglais et du Français, ils ne sont pas payé à reprendre tous le code pour une histoire de langue.
Par contre, à ce que vous dites, ils n'ont pas repris l'indentation des prédécesseurs, mais surement des développeurs qui ont voulu se la péter en utilisant leur indentation plutôt que de reprendre comme l'existant, quand on travail en équipe, on ne s'amuse pas à reprendre toute l'indentation au risque de ne plus voir les différences fonctionnelles mais au moins on respecte l’homogénéité du code, sinon ça devient bordélique pour les mainteneurs suivants.

Mais en conclusion, cela ressemble à beaucoup de code qui a vécu et a eu différentes personnes à travers le temps qui sont passé dessus, cela me fait penser à beaucoup de code que j'ai vu et dans divers domaines, ils ne sont pas plus mauvais élève que les autres, ceux qui disent le contraire ne doivent pas avoir beaucoup d'expérience de reprise de code et on surement comme expérience du code parti de zéro et même peut être sans avoir été dans des équipes de taille moyenne à grande sur le long terme, voir même aucune expérience en entreprise où ton chef va te demander pourquoi tu as repris du code existant au lieu de faire les tâches qui t'incombe, le temps que tu passe a reprendre le code avec son lot de risque de bugs, c'est la boite qui paye, c'est pas le monde communautaire ou le temps que tu passe est bénévole, et même si tu veux faire des heures sup pour le faire, ton chef préfèrera quand même que tu le passe à faire des évolutions et corrections identifié et planifié.
7  0 
Avatar de Peut-êtreUneRéponse
Membre éclairé https://www.developpez.com
Le 18/09/2018 à 16:39
Dans les années 80, une époque que vous n'avez sans doute pas connu , il existait une grande entreprise française, BULL SA, qui sous pilotage du gouvernement français concurrençait les grands fabricants d'infra informatique centralisée, dites Mainframe, avec ses machines DPS* qui tournaient sous GCOS Vs les systèmes MVS/ESA d'IBM (IBM z sous z/OS de nos jours). Tous les clients gouvernementaux et les sociétés industrielles nationalisées sous François Mitterrand (CGE qui deviendra plus tard Alcatel, Thompson, Saint Gobain, Honeywell...) étaient client de BULL SA. Plus de détail ici.

Mais quel rapport avec le schmilblick me diriez-vous? Mais tout!

Comme le souligne @Marsupial, le code de la taxe d'habitation fait référence au système d'exploitation GCOS dans ses commentaires:

Code : Sélectionner tout
1
2
3
4
5
/*============================================================================
   Contrôle de la signature
   la presence d'un commentaire dans la fonction permet de récupérer la valeur
   de la signature dans la compilation sous GCOS
  ============================================================================*/
Et mon petit doigt me dit que la remarque de @Guntha aussi :
Des noms de fichier qui font tous 8 lettres, comme si le programme avait été développé sous DOS???
Bref, le code ne date pas de cette année, et comme le disent certains il a peut-être 20 ans ou plus, avec un nombre incalculable de retouches et modifications par différentes personnes expertes ou pas.

Au final il fonctionne toujours et ma déception est grande chaque mois de novembre depuis tant d'année

Pour les personnes intéressées par l'archéologie voici le User Guide du langage C sous GCOS 7, une des des dernière mise à jour qui date de 2006, à peine 11 ans, une époque où le cloud n'existait que dans le ciel...
7  0 
Avatar de Edrixal
Membre éclairé https://www.developpez.com
Le 18/09/2018 à 16:54
Citation Envoyé par Pyramidev Voir le message
Par exemple, dans TH-7KSTS.H, on peut lire :
Code : Sélectionner tout
 long somrc ; /* somme a recouvrer                      */
À la place, il aurait fallu écrire :
Code : Sélectionner tout
 long somme_a_recouvrer;
Parfois, le commentaire est trop long pour entrer dans le nom de la variable, donc la présence du commentaire peut se justifier. Mais, indépendamment de la présence du commentaire, à moins qu'une variable n'ait une portée très courte, il faut lui donner un nom lisible.

Quand les variables sont mal nommées, ce qui est trop souvent le cas dans ce code, cela oblige à faire des allers-retours quand on lit le code.
Oui et non. Par exemple, quand tu travaille dans le monde de l'assurance, ITT, IPT, EXO, DCPTIA, RC, ect... sont des abréviations qui te parle. Ré-utiliser ses abréviations pour nommer ses variables n'est pas une chose absurde, à partir du moment ou le code écrit reste destiner au monde de l'assurance et donc pour des personnes qui connaissent ses abréviations.

Je ne connais pas spécialement le monde de la finance ou des taxes. Mais peut être qu'il est courant chez eux d'utiliser l'abréviation somrc pour définir une comme à recouvrer. (Pour ne reprendre que l'exemple cité).

Je suis d'accord que ce n'est pas clair au premier abords pour des néophytes de ce monde là. Que le code pourrait être plus lisible pour un plus grand nombre. Mais dans une optiques de travail en groupe qui peuvent avoir leur propre "langage", cela ne me choque pas outre mesure.

Maintenant si quelqu'un peut m'affirmer que somrc ou somme RC ne ce dit pas dans le domaine des taxes/finances et que c'est une abréviation totalement arbitraire ou personnelle au codeur, je rejoint ton avis ^^
6  0 
Avatar de Marco46
Modérateur https://www.developpez.com
Le 18/09/2018 à 11:41
Citation Envoyé par valaendra
Depuis toutes ces années, avez vous constaté des erreurs dans le calcul de votre Taxe d'habitation, un rappel ou quelque chose du genre ? Il y a relativement peu d'erreurs (à notre connaissance bien sur), n'est ce pas là le principal ?
Depuis quand c'est une option d'avoir un soft qui fonctionne ?

Citation Envoyé par valaendra
Il faut relativiser un peu et être un peu plus souple.
On peut aussi refactorer pour conserver une code base propre et à jour. Évidemment le terme "code base" est pas forcément approprié puisqu'on ne sait pas quelles sont leurs pratiques en terme de gestion de code (pas git en tout cas).

On parle d'un bien public payé par nos impôts, pas du torchon jetable d'un client lambda développé par des stagiaires de SS2I.

Citation Envoyé par valaendra
A mon avis, le code de base doit avoir plus de 20 ans d'âge avec des ajouts ici et là par des personnes différentes et peut-être à des années d'écart...
C'est précisément parce qu'il doit durer dans le temps et que ça doit être maintenu par un nombre inconnu d'intervenants différents que ça doit être impeccable.
5  0 
Avatar de Pyramidev
Expert confirmé https://www.developpez.com
Le 18/09/2018 à 12:12
Citation Envoyé par Stérilux Voir le message
Avez-vous parcouru le code source ? Qu'en dites-vous ?
Qu'il est plutôt clair.
Citation Envoyé par Edrixal Voir le message
Dans l'ensemble d'un avis personnel, je trouve le code clair et lisible.
Ce code est peut-être clair par rapport au code que vous subissez au quotidien. Par contre, par rapport à du bon code, non, ce code n'est pas clair.

Dans ce code, le plus gros problème de lisibilité vient du nommage des variables. Je ne parle pas des incohérences entre des majuscules et des minuscules, car ce n'est pas ce qui a le plus d'impact sur la lisibilité du code. Je parle de l'usage abusif des abréviations.

Parmi les bons principes du développement logiciel, il y en a un qui dit qu'il vaut généralement mieux bien nommer une variable que de mettre un commentaire pour compenser le mauvais nom de la variable.

Par exemple, dans TH-7KSTS.H, on peut lire :
Code : Sélectionner tout
 long somrc ; /* somme a recouvrer                      */
À la place, il aurait fallu écrire :
Code : Sélectionner tout
 long somme_a_recouvrer;
Parfois, le commentaire est trop long pour entrer dans le nom de la variable, donc la présence du commentaire peut se justifier. Mais, indépendamment de la présence du commentaire, à moins qu'une variable n'ait une portée très courte, il faut lui donner un nom lisible.

Quand les variables sont mal nommées, ce qui est trop souvent le cas dans ce code, cela oblige à faire des allers-retours quand on lit le code.
8  3 
Avatar de strato35
Membre actif https://www.developpez.com
Le 18/09/2018 à 13:29
Comment pourrait-on expliquer la qualité du code ?
Au fond leur code n'est pas si mauvais, certes ça ne respecte pas les normes de "bonne pratique" que l'on peut conseiller, mais si on regarde la construction ils ont simplement fait un algo avec des outils mathématique afin d'établir les règles de calcul, et l'on bêtement repris dans du code pour l'automatiser. Il y a des améliorations à faire mais ça reste lisible et mathématiquement compréhensible.
5  0