Discussion :

[Michael Guilloux]

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

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

[redcurve]

ce code

[Guntha]

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.

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

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?

[marsupial]

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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
  ============================================================================*/

J'ai tilté sur GCOS...

wiki GCOS
extrait :

Les programmes sur ce système d'exploitation sont généralement écrits en COBOL, Fortran (voire ALGOL), et maintenant Java.

Et ils veulent migrer toute l'administration dans le cloud

Bon courage !

[landry161]

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?

Ah oui

[ShigruM]

pour la langue des commentaire je reste sceptique.
je considere l'anglais comme une norme en informatique, et perso tous les codes que je développe sans en anglais( commentaires + noms de variables)

d'un autre coté, il s'agit d'un code francais développer pour la france... le faire en français pure permet "d’être précis et pas ambiguë" dans ce que le code devrait faire, on peut le faire en anglais mais avec un bon niveau d'anglais, les dev n'ont peut etre pas voulue prendre le risque et ont voulue que leurs code soit compréhensible par d'éventuel "manager" (haut fonctionnaire de l'état)

quoiqu'il en soit, on ne connais pas les conditions de développement ni le cahier des charges, donc pour moi cette critique n'est pas valable... meme si j'aimerais bien une explication/justification officiel de ce choix


concernant les noms de variable avec ou sans majuscule en effet c'est quelque chose dont il faut faire attention mais ce n'est pas très grave si il n'ya que sa.

[Invité]

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

[Marco46]

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

Il est codé comme il y a 20 ans. C'est pas une histoire d'être psycho-rigide mais d'être propre et pro. Il y a une foultitude d'outils dans tous les langages pour gérer ça de manière automatique.

Des fichiers sources de 2000 lignes on se fout de qui sérieux ?

Ce qui me choque beaucoup c'est les 12 commits et le zéro tags, comme pour Parcoursup. Donc soit ils utilisent un SCM exotique ou obsolète en interne soit pire ils n'en utilisent pas et ils ont passé une version x de leur code sous git à cause de l'obligation légale de publier mais ce n'est pas leur base de travail.

Donc ça n'a aucune utilité.

Ce dont on a besoin c'est de savoir quel est le tag précis qui est utilisé pour calculer la taxe d'habitation de tel exercice et de pouvoir contribuer au code. L'état aurait tout à gagner à réellement opensourcer leurs logiciels, mais comme ils savent déjà pas utiliser git on peut se dire que le chemin pour gérer un projet en opensource est vraiment très long.

La constante inquiétante c'est que de projet en projet toujours fait complètement à l'arrache avec des pratiques du siècle dernier.

[Guntha]

Ce qui me choque beaucoup c'est les 12 commits et le zéro tags, comme pour Parcoursup. Donc soit ils utilisent un SCM exotique ou obsolète en interne soit pire ils n'en utilisent pas et ils ont passé une version x de leur code sous git à cause de l'obligation légale de publier mais ce n'est pas leur base de travail.

C'est la version 2017 uniquement, il n'était pas ouvert PENDANT son développement, il a été sorti sur github après coup (il faut éviter les pull-requests des gens qui veulent mettre tout à 0 pour leur ville :p )
EDIT: j'avais mal lu la suite du message

[valaendra]

Il est codé comme il y a 20 ans..

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... Il faut relativiser un peu et être un peu plus souple.

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 ?

Bonne journée.

[Marco46]

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 ?

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.

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.

[Pyramidev]

Avez-vous parcouru le code source ? Qu'en dites-vous ?

Qu'il est plutôt clair.

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 - Visualiser dans une fenêtre à part

 long somrc ; /* somme a recouvrer                      */

À la place, il aurait fallu écrire :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

 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.

[pmithrandir]

Les calculs avec des flottants ne donnent pas des résultats précis. Il faudrait utiliser un type qui supporte les nombres décimaux.

Ou parler en centimes... c'est souvent la solution la plus simple pour s'affranchir des problèmes de décimales et optimiser ses calculs pour la monnaie.
On arrive rarement a des sommes sortant d'un entier.

[strato35]

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.

[Edrixal]

Par exemple, dans TH-7KSTS.H, on peut lire :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

 long somrc ; /* somme a recouvrer                      */

À la place, il aurait fallu écrire :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

 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 ^^

[Marco46]

@Peut-êtreUneRéponse

Ok merci, donc 38 ans de dette technique non payée. Sympa.

[el_slapper]

@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.

[Marco46]

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 ^^

On utilise pas d’abréviation pour le nommage c'est un basique, point final. Peu importe les habitudes du métier. On doit être explicite quand on nomme des variables.

[Guntha]

On utilise pas d’abréviation pour le nommage c'est un basique, point final. Peu importe les habitudes du métier. On doit être explicite quand on nomme des variables.

Si on suit ta logique, le langage C lui-même n'obéit pas à cette règle "basique"

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
int //au lieu de "integer"
float //au lieu de "floating-point number
main //au lieu de "main function" ou "entry point"
char // au lieu de "character"

Et je ne parle même pas de la libc

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
strcmp
strcmp
strcat
memcpy
memchr
malloc
realloc
qsort
fopen
fclose
etc...//On utilise même des abréviations quand on parle français!

Et comment peut-on être plus explicite que le langage métier?

Et si le développement de ce code a vraiment commencé il y a plus de 20/30 ans sur GCOS, je trouve qu'il n'est pas si tarabiscoté que ce à quoi on pourrait s'attendre.

[Pyramidev]

Pour résumer mon avis sur les acronymes et abréviations, je vais m'appuyer sur un autre exemple de TH-7KSTS.H :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

double coeff_FAR_THS_s ; /* coefficient FAR THS du syndicat              */

Dans cet exemple, on devine que les acronymes FAR et THS sont connus du métier, puisqu'ils apparaissent même dans le commentaire.
Je ne suis pas du tout contre la présence des acronymes FAR et THS dans le nom de la variable. Autrement, le nom serait trop long.

Je ne suis pas contre non plus l'abréviation coeff. pour coefficient, car tout le monde la connaît.

Le s final comme abréviation de syndicat, par contre, me semble douteux.
Je pense que la variable aurait dû s'appeler soit coeff_FAR_THS_syndicat, soit coeff_FAR_THS_du_syndicat.