Bercy ouvre le code source de la taxe foncière

Bercy ouvre le code source de la taxe foncière

Le Git et le couvert

Avatar de l'auteur
Xavier Berne

Publié dans

Droit

26/08/2019
75

Bercy ouvre le code source de la taxe foncière

La Direction générale des finances publiques (DGFiP) vient de mettre en ligne le code source utilisé pour le calcul de la taxe foncière. Une initiative qui fait suite à une procédure « CADA » lancée par Next INpact, il y a près d’un an et demi.

Alors que les propriétaires recevront d’ici quelques semaines leur avis de taxe foncière, Bercy a effectué un sérieux pas en faveur de la transparence, vendredi 23 août. Après avoir ouvert le code source de son logiciel de calcul de l’impôt sur le revenu, en 2016, puis de celui de la taxe d’habitation, fin 2018, l’administration fiscale a publié sur « data.gouv.fr » le code source des taxes foncières.

Le fameux prélèvement est en effet composé de plusieurs taxes : la taxe sur les propriétés bâties, la taxe sur les propriétés non bâties, et enfin différents « frais de gestion de la fiscalité directe locale » (notamment la taxe d’enlèvement des ordures ménagères).

Les codes sources, des documents administratifs « communicables »

Les fichiers proposés par la DGFiP ayant été publiés sous licence CeCILL v2.1, la société civile peut librement s’en saisir : une entreprise qui voudrait éditer un simulateur, un particulier désirant vérifier qu’il n’y a pas de bug ou de règle différente à celles posées par la loi, etc.

En pratique, ce sont surtout les informaticiens qui pourront lire et comprendre ces nombreuses lignes de code, rédigées essentiellement en Cobol (un langage plutôt ancien, mais encore répandu dans les systèmes d’information de certaines administrations).

Pour le grand public, Bercy a préparé une notice détaillant le calcul de la taxe foncière, étape par étape (PDF). On peut ainsi y lire qu’à partir de la valeur locative des locaux, le logiciel chiffre la base imposable, qu’il multiplie aux taux d’imposition votés par les collectivités territoriales.

taxe foncière

Si Bercy a annoncé que ce pas en faveur de la transparence s’inscrivait dans le mouvement d’ouverture des données publiques prévu par la loi pour une République numérique de 2016, l’institution oublie toutefois de dire qu’il aura fallu la bousculer un peu pour qu’elle se plie à ses obligations légales...

En janvier 2018, afin de voir si les acteurs publics respectaient la « loi Lemaire » (qui a fait expressément entrer les codes sources dans la liste des documents administratifs communicables de plein droit au citoyen, sur demande), nous avions notamment sollicité la DGFiP, afin qu’elle ouvre les codes sources utilisés pour le calcul de la taxe d’habitation et de la taxe foncière.

Face au silence de l’administration fiscale, nous nous étions tournés vers la Commission d’accès aux documents administratifs (CADA), laquelle avait finalement conclu, en juin 2018, que les deux codes sources sollicités étaient bien communicables.

L’autorité indépendante avait même insisté sur le fait qu’une telle ouverture ne portait « pas atteinte à la recherche des infractions fiscales » – l’un des motifs permettant aux acteurs publics de refuser l’accès à un document administratif.

Bien que la DGFiP ait promis à la CADA de publier les deux codes sources « dans les meilleurs délais », celui de la taxe foncière manquait encore à l’appel, plus d’un an après le feu vert de l'institution...

Des efforts qui demeurent insuffisants

Bien que les efforts de Bercy méritent d’être salués, difficile pour l’heure de savoir ce qu’il en ressortira exactement. « Je doute que quelqu'un puisse y comprendre quelque chose, mais sait-on jamais », nous glisse ainsi un informaticien chevronné, visiblement décontenancé par la complexité des fichiers mis en ligne par la DGFiP.

Contrairement à ce qui avait prévalu pour la taxe d’habitation, aucune documentation détaillée du code source de la taxe foncière n’a été mise en ligne. Ce qui pourrait susciter différentes interrogations, notamment quant au « couplage » avec les taux d’imposition locaux, susceptibles d’évoluer chaque année.

L’administration fiscale doit d’ailleurs encore faire de sérieux efforts en matière de transparence. Contrairement à ce que prévoit la loi pour une République numérique, aucune « mention explicite » ne vient informer les contribuables que leurs impôts et autres taxes ont été calculés à l’aide d’algorithmes.

Or depuis le 1er septembre 2017, toutes les administrations qui prennent des décisions individuelles « sur le fondement d'un traitement algorithmique » doivent en informer chaque usager. Et éventuellement lui expliquer, sur demande :

  • Quelles ont été « les données traitées et leurs sources ».
  • Quel est le « degré et le mode de contribution du traitement algorithmique à la prise de décision » (afin d’indiquer par exemple s’il y a eu une intervention humaine).
  • Quelles ont été les « opérations effectuées par le traitement ».
  • Quels ont été les paramètres du traitement et leur pondération, « appliqués à la situation de l'intéressé ».

Faute d’apposer cette « mention explicite » d’ici au 1er juillet prochain, les décisions administratives 100 % automatisées seront automatiquement considérées comme nulles. Un choix fait l’année dernière par le législateur, étant donné que la plupart des administrations rechignent à mettre en œuvre cette obligation de transparence pourtant applicable depuis près de deux ans (pour en savoir plus, voir notre article).

75

Écrit par Xavier Berne

Tiens, en parlant de ça :

Sommaire de l'article

Introduction

Les codes sources, des documents administratifs « communicables »

Des efforts qui demeurent insuffisants

Le brief de ce matin n'est pas encore là

Partez acheter vos croissants
Et faites chauffer votre bouilloire,
Le brief arrive dans un instant,
Tout frais du matin, gardez espoir.

Commentaires (75)


Furanku Abonné
Le 26/08/2019 à 12h 59

Du COBOL… Ils ont pas plus récent et compréhensible à utiliser comme langage ? <img data-src=" />


Le 26/08/2019 à 13h 02

Amusant, à chaque fois que l’état ouvre son code source, on les dev pleurent le manque de notice et de comment claire de leurs codes.


Arkeen Abonné
Le 26/08/2019 à 13h 12

C’est cool d’ouvrir le code d’un truc aussi important, mais c’est quand même sacrément dommage de sortir ça dans un langage aussi vieux, sans vraie doc. Je suis allé fouiller un peu, et j’ai effectivement rien pigé. J’espère qu’une asso ou un citoyen éclairé pourra décortiquer ça, j’y verrais bien en open-source en Python ou en JS (des trucs simples et très utilisés), pour qu’un public + large se s’approprie.

&nbsp;

Anecdote inutile du jour : le parseur Cobol pour Visual Studio Code est installé sur 212 839 postes. C’est environ 10 000 fois plus que ce que je pensais.


Furanku Abonné
Le 26/08/2019 à 13h 21

Parce que le strict minimum est fait.

Il n’y aucun commentaire, aucune doc accompagnant le code pour en comprendre les intentions (vu comme c’est codé à “l’ancienne” dans la majorité des cas). Le COBOL est un vieux langage que seul une minorité sait lire/manipuler, on trouve peu de ressources pour se former dessus. Ça réduit donc le nombre de relectures possibles.



Là c’est une ouverture du code en demie-teinte, comme à chaque fois. Si encore il y avait de la doc en parallèle, mais même pas…

Perso j’appelle ça limite de l’obfuscation volontaire.



Edit : heureusement encore qu’il y a des sites comme Zeste de Savoir.


Le 26/08/2019 à 13h 26

Alors l’ouverture de l’algo de la taxe foncière je ne pensais pas voir ça un jour, étant donné que personne ne sait vraiment comment ce machin est calculé.

Par contre si c’est du cobol c’est la merde, il va nous falloir un expert


Le 26/08/2019 à 13h 27

Pour être intervenu sur des environnement de ce type, je pense qu’il y a une réelle probabilité que les commentaires n’aient pas été supprimé, simplement qu’il n’y en a jamais eu (même chose pour la doc … ).


hellmut Abonné
Le 26/08/2019 à 13h 27

vu la complexité y’a forcément de la doc quelque part.


Le 26/08/2019 à 13h 29

Je ne comprends pas bien ?

Pourquoi vous dites que ce n’est pas commenté ?

Toutes les lignes qui commencent par * sont des commentaires


Furanku Abonné
Le 26/08/2019 à 13h 30

Rien sur le site de data.gouv ni sur le Git en tout cas.

Je ne doute pas qu’il y en ait mais elle n’est pas fournie avec le code. D’où mon constat que c’est volontaire pour réduire fortement le nombre de relectures, tout en respectant la loi et les injonctions de la CADA.









InnerJ a écrit :



Pour être intervenu sur des environnement de ce type, je pense qu’il y a une réelle probabilité que les commentaires n’aient pas été supprimé, simplement qu’il n’y en a jamais eu (même chose pour la doc … ).





Oui, d’où mon “codé à l’ancienne” dans mon commentaire précédent.

Le turn-over en entreprise et dans le public n’était pas aussi important à l’époque où tout cela a été codé. Les développeurs passaient parfois leur carrière sur un même projet, donc les commentaires avaient moins d’intérêt à leurs yeux. Puis les pratiques ont aussi évolué.



Par contre fournir une doc n’aurait pas fait de mal…







Tandhruil a écrit :



Je ne comprends pas bien ?

Pourquoi vous dites que ce n’est pas commenté ?

Toutes les lignes qui commencent par * sont des commentaires





<img data-src=" />



hellmut Abonné
Le 26/08/2019 à 13h 32







Furanku a écrit :



Rien sur le site de data.gouv ni sur le Git en tout cas.

Je ne doute pas qu’il y en ait mais elle n’est pas fournie avec le code. D’où mon constat que c’est volontaire pour réduire fortement le nombre de relectures, tout en respectant la loi et les injonctions de la CADA.





+10. quand je dis “quelque part”, je sous entend “à la DGFIP”. ^^



Arwendil Abonné
Le 26/08/2019 à 13h 32

Visiblement, la majorité des commentateurs n’ont pas regardé le code, par exemple dans le fichier EFITA3B8 décrit comme

“CE SOUS-PROGRAMME EST LA CALCULETTE DES COTISATIONS BATIES DE TAXE FONCIERE DE L’ANNEE 2018”,



dans la partie où il y a les calculs pratiquement une ligne sur deux est du commentaire.

Certes, ce n’est pas forcement très explicite pour des personnes qui ne

connaissent ni le cobol ni le calcul des impôts, mais ca reste

commenté.

Par contre il effectivement pas les spécifications fonctionnelles de disponible.


hellmut Abonné
Le 26/08/2019 à 13h 33

ah non j’ai pas regardé, je tiens à mes yeux. <img data-src=" />


Furanku Abonné
Le 26/08/2019 à 13h 35







hellmut a écrit :



+10. quand je dis “quelque part”, je sous entend “à la DGFIP”. ^^





Aaaaah ! Mal compris <img data-src=" />







Arwendil a écrit :



Visiblement, la majorité des commentateurs n’ont pas regardé le code, par exemple dans le fichier EFITA3B8 décrit comme

“CE SOUS-PROGRAMME EST LA CALCULETTE DES COTISATIONS BATIES DE TAXE FONCIERE DE L’ANNEE 2018”,



dans la partie où il y a les calculs pratiquement une ligne sur deux est du commentaire.

Certes, ce n’est pas forcement très explicite pour des personnes qui ne

connaissent ni le cobol ni le calcul des impôts, mais ca reste

commenté.

Par contre il effectivement pas les spécifications fonctionnelles de disponible.





Ouais enfin, il y a commentaire et commentaire hein…

Le but d’un commentaire utile est que la logique du code puisse être comprise par n’importe quel développeur, qu’il soit un néophyte ou un expert dans un langage donné. Donc il doit en quelques sorte décrire l’intention, le fonctionnel, quand cela est nécessaire. Et là c’est plus que nécessaire, surtout quand il n’y a aucune doc fonctionnelle fournie à côté.



Franchement, vu le petit projet Git que c’est et le peu de fichiers, ça leur aurait coûté quoi de faire cela au passage avant de “libérer” le code publiquement ?

A moins que personne ne sait vraiment expliquer comment tout cela fonctionne ? Auquel cas ça met le doigt sur un autre problème, très critique.



Le 26/08/2019 à 13h 42

bah en même temps, ils n’allaient pas s’embêter à réécrire le code dans un autre langage (en introduisant potentiellement des bugs et/ou erreurs de calcul) juste pour le fournir en open source…



Je préfère avoir un code moche dans un “vieux” langage mais qui est identique à celui réellement utilisé qu’un code propre et lisible dans un langage “moderne” mais qui est une simple réinterprétation de ce qui est utilisé. Certes ça reste peu accessible aux gens qui veulent voir comment ça fonctionne mais au moins on a les vraies données.


Arwendil Abonné
Le 26/08/2019 à 13h 49

Visiblement ils n’ont mis que les fichiers correspondant à l’année 2018, il doit y avoir pas mal d’autres fichiers pour les années précédentes, et suivante.



À mon avis les commentaires, on été fait uniquement pour permettre aux développeurs cobol de la ddfip de reprendre le code et de pouvoir le modifier chaque année en fonction des modifications de la loi, en disposant en plus des spécifications fonctionnelles, pas vraiment pour permettre à tout à chacun de comprendre le fonctionnement de l’algorithme.



Je suppose qu’ils n’ont pas demandé au dev de refaire tous les commentaires pour publication, mais on juste publier les fichiers utilisés en vrai.



C’est toujours le problème quand on demande la publication du code source, quoi publier, la loi, les specs, le code, le code compilé, quel version de tous ces fichiers?


Le 26/08/2019 à 13h 54

Mouais… Moyennement utile puisque la plupart des informations servant à ce calcul, comme les taux, sont décidées par les collectivités locales (sur aucun autre élément que celui de faire rentrer des sous dans la caisse un peu plus chaque année) et parfois même “à la tête du client” comme la valeur locative (dont les éléments sont aussi subjectifs que le “confort du local” - cf :https://www.impots.gouv.fr/portail/particulier/base-de-calcul).

&nbsp;

Bref, pas de quoi fouetter un chat, juste de quoi occuper le terrain.


Citan666 Abonné
Le 26/08/2019 à 13h 59







Arkeen a écrit :



C’est cool d’ouvrir le code d’un truc aussi important, mais c’est quand même sacrément dommage de sortir ça dans un langage aussi vieux, sans vraie doc. Je suis allé fouiller un peu, et j’ai effectivement rien pigé. J’espère qu’une asso ou un citoyen éclairé pourra décortiquer ça, j’y verrais bien en open-source en Python ou en JS (des trucs simples et très utilisés), pour qu’un public + large se s’approprie.



  &nbsp;        

Anecdote inutile du jour : le parseur Cobol pour Visual Studio Code est installé sur 212 839 postes. C'est environ 10 000 fois plus que ce que je pensais.











Furanku a écrit :



Parce que le strict minimum est fait.



  Il n'y aucun commentaire, aucune doc accompagnant le code pour en comprendre les intentions (vu comme c'est codé à "l'ancienne" dans la majorité des cas). Le COBOL est un vieux langage que seul une minorité sait lire/manipuler, on trouve peu de ressources pour se former dessus. Ça réduit donc le nombre de relectures possibles.        






  Là c'est une ouverture du code en demie-teinte, comme à chaque fois. Si encore il y avait de la doc en parallèle, mais même pas...         

Perso j'appelle ça limite de l'obfuscation volontaire.






  Edit : heureusement encore qu'il y a des sites comme Zeste de Savoir.








  Vous vous attendiez à quoi sérieusement ? <img data-src=">  

Au lieu de cracher dessus, vous feriez mieux d'avoir une pensée de compassion pour les équipes internes qui bossent dessus. Ils n'ont probablement aucune info de plus que vous, mais c'est sur eux que le marteau tombe quand il y a une couille...






 Et vu que les budgets continuent déjà de se réduire pour l'entretien ou la refonte de projets en général, vous êtes bien naïfs si vous croyiez qu'ils allaient dépenser un centime pour améliorer la qualité de la doc avant publication...       

&nbsp;

(Si les décideurs étaient prêts à faire ça, ils seraient prêts à mettre les moyens EN AMONT au moment de la conception et ce serait pas autant la crispation dès qu'on demande un peu de visibilité sur le code -ou simplement qu'une évol est demandée XD-. <img data-src=">)






Quant au fait que c'est écrit dans un vieux langage...      

1. Tous les langages "compréhensibles" (de plus haut niveau / plus moderne, compilé ou pas) c'est de la merde en rapport en termes de perfs, pour ce que j'en sais (quoique j'admets ne rien connaître aux langages les plus récents type Go &amp; co, qui changent peut-être la donne).

2. Dans la mesure où c'est un truc critique de chez critique, et eu égard justement à la complexité de maintenance/évolutions, je vous prie de croire qu'avant qu'un mec ait les couilles de lancer un projet de refonte, les poules auront des dents grâce à la troisième guerre nucléaire (info : c'est pareil dans la finance et de manière générale tout ce qui touche aux thunes ^^)


Le 26/08/2019 à 14h 02

Moi ce sont les commentaires qui me dépassent

Vous demandez le code utilisé pour calculer un truc et vous hurlez que c’est du cobol

Vous semblez demander à ce qu’on réécrive les millions de ligne de code Cobol qui calculent votre retraite vos impots ou vos allocations en Python en perl ou en C++

Putain mais merde ça fait 50 ans que ça existe ça fait 50 ans que cest écrit et ça fait 50 ans qu’on rajoute des modifs , quant à huler que ce n’est pas facile de trouver ou apprendre le cobol, je suis désolé mais à chaque fois que des boites veulent former des gens en cobol , ces jeunes embauchés refusent généralement car “ça va les bloquer dans leur carrière”

En attendant ceux qui acceptent d’en faire, on les paye un peu plus épicétou, et ça ne les bloque pas du tout


Le 26/08/2019 à 14h 09

Moi quand je vois “ * ENTETE DU TAUDIS - CLEFS D’APPEL POUR LES COLLOCS”, je me dit qu’ils ont de l’humour (noir) quand même.





Bref, les codes sources sont à l’image de nos Code (travail, pénal, fistable, etc.), poussiereux et vieux mais comme dit plus haute, une refonte entité par entité va “coûter un pognon de dingue” aisément chiffrable en milliard d’euros et quand on voit les désastres que sont Chorus et Louvois…



Et la question à se poser est : est-ce que cela va vraiment faciliter la maintenance et augmenter les perfs ?


Furanku Abonné
Le 26/08/2019 à 14h 23







Citan666 a écrit :



Vous vous attendiez à quoi sérieusement ? <img data-src=" />





A rien pour ma part.







Citan666 a écrit :



Au lieu de cracher dessus, vous feriez mieux d’avoir une pensée de compassion pour les équipes internes qui bossent dessus. Ils n’ont probablement aucune info de plus que vous, mais c’est sur eux que le marteau tombe quand il y a une couille…





J’ai justement une pensée pour eux, vu que je sais exactement ce que ça fait de bosser avec du code mal documenté (voire pas du tout) et des spec fonctionnelles manquantes. Je le vis plus ou moins au quotidien.

Donc non ce n’est pas sur les dev que je rejette la faute mais bien sur ceux qui sont au-dessus et qui, eux, ne sont pas impactés.







Citan666 a écrit :



Et vu que les budgets continuent déjà de se réduire pour l’entretien ou la refonte de projets en général, vous êtes bien naïfs si vous croyiez qu’ils allaient dépenser un centime pour améliorer la qualité de la doc avant publication…





Je ne croyais rien. Je constate juste une situation.

Et restriction budgétaire ou pas cela reste du foutage de g*le de fournir un code de la sorte, en vrac, sans plus d’informations pour le comprendre. Ce alors même justement que les équipes internes doivent déjà s’arracher les cheveux avec un code datant de Mathusalem et non documenté. C’est justement l’occasion de mettre du propre dans tout ça avant publication. Et d’avoir des potentiellement des retours pertinents par la suite pour améliorer le code (et mettre le doigt sur des erreurs de calcul).

Mais là encore je vois que mes impôts ne servent pas où il faudrait…



         







Citan666 a écrit :



(Si les décideurs étaient prêts à faire ça, ils seraient prêts à mettre les moyens EN AMONT au moment de la conception et ce serait pas autant la crispation dès qu’on demande un peu de visibilité sur le code -ou simplement qu’une évol est demandée XD-. <img data-src=" />)





En amont sur du code qui a sûrement près de 30 ans ou plus ? <img data-src=" />

Faudra m’expliquer comment reprendre la conception sur un code que l’on perpétuer depuis tout ce temps sans avoir à faire de gros changements et risquer de tout casser…









Citan666 a écrit :





  1. Tous les langages “compréhensibles” (de plus haut niveau / plus moderne, compilé ou pas) c’est de la merde en rapport en termes de perfs, pour ce que j’en sais (quoique j’admets ne rien connaître aux langages les plus récents type Go & co, qui changent peut-être la donne).





    En effet, tu n’y connais rien concernant certains langages plus récents (Ocaml, Rust…) :)







    Citan666 a écrit :



  2. Dans la mesure où c’est un truc critique de chez critique, et eu égard justement à la complexité de maintenance/évolutions, je vous prie de croire qu’avant qu’un mec ait les couilles de lancer un projet de refonte, les poules auront des dents grâce à la troisième guerre nucléaire (info : c’est pareil dans la finance et de manière générale tout ce qui touche aux thunes ^^)





    A aucun moment on a dit qu’il fallait tout casser pour repartir sur un nouveau langage (ou alors tu as mal compris l’ironie de mon premier commentaire ?). Juste que publier du code de la sorte, sans documentation ni commentaires pertinents, ça n’a quasi aucun intérêt.

    Dans le cas présent il s’agit juste de respecter une injonction de la CADA au pied de la lettre et basta. Comprendra qui pourra par la suite.







    JoePike a écrit :



    Vous demandez le code utilisé pour calculer un truc et vous hurlez que c’est du cobol

    Vous semblez demander à ce qu’on réécrive les millions de ligne de code Cobol qui calculent votre retraite vos impots ou vos allocations en Python en perl ou en C++





    Nooooon ? :)

    On hurle sur rien hormis le manque de documentation. On sait pertinemment, du moins en ce qui me concerne, que le COBOL est un héritage dont il est difficile de se défaire. Si cela a un réel intérêt de le faire (ça pourrait créer des emplois ceci-dit).

    Par contre cela ne doit pas empêcher de profiter d’une diffusion publique du code pour justement le documenter.







    JoePike a écrit :



    Putain mais merde ça fait 50 ans que ça existe ça fait 50 ans que cest écrit et ça fait 50 ans qu’on rajoute des modifs , quant à huler que ce n’est pas facile de trouver ou apprendre le cobol, je suis désolé mais à chaque fois que des boites veulent former des gens en cobol , ces jeunes embauchés refusent généralement car “ça va les bloquer dans leur carrière”





    Plutôt parce que tu sais que tu vas tomber sur du code mal documenté/commenté comme celui-ci et que donc ça va être une carrière non épanouissante. Ce même si les profils de dev COBOL sont très recherchés et grassement payés, la thune ne fait pas tout.







    JoePike a écrit :



    En attendant ceux qui acceptent d’en faire, on les paye un peu beaucoup plus épicétou, et ça ne les bloque pas du tout





Rhebian Abonné
Le 26/08/2019 à 14h 23

“Faute d’apposer cette «&nbsp;mention explicite&nbsp;» d’ici au 1er juillet prochain, les décisions administratives 100 % automatisées seront automatiquement considérées comme nulles.”



Donc sur la taxe foncière 2020, si c’est pas mentionné, je ne paye pas ? <img data-src=" />


Le 26/08/2019 à 14h 24

J’avais pas vu ton post <img data-src=" />

mais il y a eu une exception notable … le projet “usine retraite”

Pour oser il fallait oser maais ils ont osé

mais le plus marrant c’est que la partie fonctionelle a été réécrite en grande partie … en cobol

ça a pris 10 ans ( à peu près) et ça marche


Le 26/08/2019 à 14h 30

j’avais pas osé mettre “beaucoup plus” par timidité , mais en fait une fois on avait un presta jeune bac+5 en imagerie qui avait accepté de faire du cobol et qui se débrouillait bien

Au bout d’un moment on lui a fait une proposition malhonnète pour un CDI et je ne sais pas pourquoi mais les 10k€ en plus par an amenait sur son visage un sourire béat

<img data-src=" />


Furanku Abonné
Le 26/08/2019 à 14h 43

Perso, même pour +10K€ par an, j’hésiterais grandement quand même <img data-src=" />

Si c’est pour avoir une carrière de pantouflard, non épanouissante, à maintenir un code datant de Mathusalem pendant toute la durée de celle-ci… je préfère aller voir ailleurs et faire quelque chose de plus stimulant ^^

Et surtout pas pour du provisoire : tu accèdes ensuite potentiellement à un niveau de vie qui va en effet te bloquer sur ta carrière (tu fais quoi le jour où tu en as marre de faire du COBOL et que tu risque de perdre 10k/an ? Tu es prêt à revoir ton niveau de vie fortement à la baisse ?).



Je vois cela, dans une moindre mesure, avec les dev de WinDev dans ma boite pour la partie historique. Je préfère largement mon poste, plus stimulant intellectuellement (nouvelles techno, etc), quitte à avoir une paye légèrement en-deçà. Sachant que derrière je trouverais toujours facilement ailleurs si besoin.



Mais c’est une question de caractère et d’objectifs de vie :)


Le 26/08/2019 à 14h 54

Une chose que vous semblez ignorer: s’agissant en particulier de ces applications historiques du monde fiscal écrite en Cobol, il faut savoir que les développeurs sont pour la plupart eux-mêmes des experts du domaine (de la législation, et donc de l’aspect fonctionnel). Rappelons que l’essentiel des 4000 informaticiens de la DGFiP sont contrôleurs ou inspecteurs des finances publiques (ex-des impôts ou du Trésor Public) avant d’être analystes ou&nbsp; programmeurs. Certains sont même dans la maison depuis des dizaines d’années - en tout cas, assez longtemps pour maitriser totalement leur code, et particulièrement sur ces “applications-maison”, faisant rarement l’objet d’un support prestataire. Vous comprendrez que dans ces conditions, ça ne facilite pas la lisibilité du code-source et son appropriation par des tiers!


Le 26/08/2019 à 14h 58

Je pense que c’est la que tu te trompes peut-être

Le projet Usine Retraite dont je parlais précedemment a demandé plus de gens cobol qu’on en avait , les boites presta on donné des cours à plein de DEV pour qu’ils puissent travailler en cobol sur le projet

Gros projet puisqu’il y avait 700 presta dessus ainsi que beaucoup d’internes aux différents groupes de retraite

Le projet a duré 10 ans pour passer en prod .

Il est en prod depuis quelques années et maintenant l’agirc/arrco travaille sur le remplaçant qui lui ne sera pas du cobol mais un langage beaucoup plus moderne sous plateforme LINUX au lieu de z/OS

Donc en fait ces gens qui se sont fait très bien payer pour faire du Cobol vont ( peut-être) maintenant bosser sur un projet de même envergure mais en faisant du C ou du je ne sais quoi ( je ne suis plus actif )

mais ils vont garder leur salaires <img data-src=" />

( et en plus si la réforme des retraites a lieu comme elle a l’air prévue, leur job sera 100 fois plus facile que le gros merdier qui existe aujourd’hui avec les 45 regimes et les milliers d’exceptions que nous trainons depuis des années)

Pas une mauvaise affaire si ça se trouve <img data-src=" />


vexal Abonné
Le 26/08/2019 à 14h 58







Citan666 a écrit :



Vous vous attendiez à quoi sérieusement ? <img data-src=" />



  Au lieu de cracher dessus, vous feriez mieux d'avoir une pensée de compassion pour les équipes internes qui bossent dessus. Ils n'ont probablement aucune info de plus que vous, mais c'est sur eux que le marteau tombe quand il y a une couille...        






  Et vu que les budgets continuent déjà de se réduire pour l'entretien ou la refonte de projets en général, vous êtes bien naïfs si vous croyiez qu'ils allaient dépenser un centime pour améliorer la qualité de la doc avant publication...        

&nbsp;

(Si les décideurs étaient prêts à faire ça, ils seraient prêts à mettre les moyens EN AMONT au moment de la conception et ce serait pas autant la crispation dès qu'on demande un peu de visibilité sur le code -ou simplement qu'une évol est demandée XD-. <img data-src=">)






 Quant au fait que c'est écrit dans un vieux langage...       

1. Tous les langages "compréhensibles" (de plus haut niveau / plus moderne, compilé ou pas) c'est de la merde en rapport en termes de perfs, pour ce que j'en sais (quoique j'admets ne rien connaître aux langages les plus récents type Go &amp; co, qui changent peut-être la donne).

2. Dans la mesure où c'est un truc critique de chez critique, et eu égard justement à la complexité de maintenance/évolutions, je vous prie de croire qu'avant qu'un mec ait les couilles de lancer un projet de refonte, les poules auront des dents grâce à la troisième guerre nucléaire (info : c'est pareil dans la finance et de manière générale tout ce qui touche aux thunes ^^)







Exactement.

Je trouve que&nbsp;




  1. Il y a des commentaires

  2. Le code est très clair et bien écrit.&nbsp;

    Bien que je n’ai jamais vu de cobol avant, c’est quand même très compréhensible !

    &nbsp;



tazvld Abonné
Le 26/08/2019 à 15h 07

Je ne comprends pas les gens qui ralent que ce soit écrit en Cobol. Historiquement, les administrations ont étés les premières à automatiser ces genres de tache, ça tombé bien Cobol était justement fait pour ça (acronyme pour COmmon Business Oriented Language, merci Wikipédia).

Du coup, oui, les projets projets historiques sont maintenues dans ce langage. Le code fonctionne, pourquoi le réécrire dans un autre langage ? tu risques d’introduire des erreurs et de toutes façon, tu seras obligé de faire des “adaptations” car certaines fonctions n’auront pas exactement les même spécificités (exemple pour l’opération modulo).



Après, la documentation, j’ai envie de dire qu’elle n’a rien à envier à plein de projet open-source (j’ai essayé une fois à regardé GNU grep, j’ai fait demi-tour)







En jetant un oeil, je vois dans les sources une variable qui fait même référence à un fichier “TAUDIS”. Je suis sûr qu’il y a d’autre perles comme celle-ci


ashlol Abonné
Le 26/08/2019 à 15h 18

J’ai regardé 2-3 fichiers mais le code est quand même propre et bien documenté je ne vois pas le problème et tout ce foin.

Il manque clairement l’architecture détaillée les blocs diagrammes pour bien comprendre comment tout le code se relie ensemble mais a pars ça c’est ok.

La procédure cada demande le code et vous avez le code. Si vous n’avez pas demandé les documents autours (plan de développement, architecture détaillée, plan de tests, rapport de tests…) je comprends qu’il ne les filent pas après peut être qu’il n’y en a pas car c’est pas non plus un programme énorme et très compliqué (6 fichiers de codes et 16 de taux).


ashlol Abonné
Le 26/08/2019 à 15h 19

+1


ajangot Abonné
Le 26/08/2019 à 15h 35

+1 ashlol



Le code est assez “lisible” mais le calcul de la taxe est plutôt simple.



Ce qui manque clairement, c’est un joli site avec en open-data remis à jour tous les ans, le taux de CHAQUE COMMUNE !!

Certain taux sont calculé à partir des taux de l’année précédent multiplier par un coef, celui-ci est décidé par la mairie puis envoyé aux impôts. Pourquoi ne pas mettre ce taux en ligne et ainsi faire une petite carte comparative des taxe d’habitation en France.



Avoir des grosses différences entre une ville à l’autre, ou d’un quartier, pour choisir son lieu de résidence c’est important, surtout que l’on ne connait pas forcement le montant des taxes habitation / foncière avant que les impôts nous les envoient.


Le 26/08/2019 à 15h 46

Insert thankyou.gif


ashlol Abonné
Le 26/08/2019 à 15h 51

+1 très bonne idée clairement


Romain_Ph Abonné
Le 26/08/2019 à 15h 54

Pour info, chez nous au SI de la DGFIP, tous les contrôleurs programmeurs qui ont le concours ( l’équivalent de développeur en privé) ont une formation cobol assez importante



Moi du coup je m’étais amuse a faire une calculatrice des moyennes de l’école de formation en cobol.



En interne on a beaucoup beaucoup de documents bien réalisé pour maîtriser cobol


Jarodd Abonné
Le 26/08/2019 à 16h 05

Bientôt on va découvrir que les taxes et impôts divers sont calculés en fonction du nom de famille et de l’âge du capitaine <img data-src=" />



Sinon, gros lol à ceux qui critiquent le vieux langage et l’idée (de génie !) de refaire ce code dans un langage récent. Allez-y, lancez-vous, on vous regarde <img data-src=" />


Le 26/08/2019 à 16h 19

Tout de même:https://www.impots.gouv.fr/portail/actualite/taxe-dhabitation-et-taxe-fonciere-f…



Pas de donnée en Opendata, mise à jour trop ponctuelle, mais les taux peuvent être suivis également via https://www.impots.gouv.fr/cll


Carboline Abonné
Le 26/08/2019 à 16h 38

J’ai beaucoup de mal à comprendre l’intérêt qu’a eu Next Impact à demander la communication de ces programmes ? Par désœuvrement ? Pour faire dans le sensationnalisme ? J’en ai DL un ou deux, juste pour voir (avec mes lunettes de 42 ans de carrière IT). Ils ne présentent, bien évidemment, aucun intérêt. Je ne renouvellerai pas mon abonnement.


behemothe Abonné
Le 26/08/2019 à 17h 00

Dommage, on ne peut pas coller des images, pour un problème de taille, je suppose, parce que je vous aurai montré le papier que j’ai reçu des impôts et qui m’annonce que depuis le temps mon appartement a certainement évolué, qu’il y a des toilettes, une baignoire, etc et que donc la base de calcul de la taxe foncière est modifié de façon non rétro active (à partir de quand il me font rire ?) et cela correspond à une augmentation de taxe d’habitation de 108 €. Je suppose que c’est pour se récupérer de la suppression de la taxe d’habitation qu’ils font cela. Et c’est fait pour tous les appartements de Grenoble. Ça va fulminer dans les chaumières…. On vit vraiment une époque formidable


behemothe Abonné
Le 26/08/2019 à 17h 12
Le 26/08/2019 à 17h 15

Bof ça fait un moment que ça existe , j’ai déja eu ça à Nantes il y a quelques années et la taxe d’haabitation n’avit pas été supprimée ou diminuée


Patch Abonné
Le 26/08/2019 à 17h 28







Furanku a écrit :



Du COBOL… Ils ont pas plus récent et compréhensible à utiliser comme langage ? <img data-src=" />



Méthode de fonctionnement de l’Administration (ainsi que des banques et de la majorité des grosses boîtes) : tant que ca fonctionne, on touche pas <img data-src=" />



Z-os Abonné
Le 26/08/2019 à 19h 09







Furanku a écrit :



Du COBOL… Ils ont pas plus récent et compréhensible à utiliser comme langage ? <img data-src=" />





Allez juste avant d’aller manger : dernièrement j’ai expliqué en 14 d’heure à ma maitrise d’ouvrage (non informaticienne) comment lire un programme pour qu’elle me réponde “c’est facile en fait”.

Donc, à mon humble avis, ceux d’entre vous qui hurlent à la vue d’un langage qu’ils ne connaissent pas devraient se remettre en question…



Le 26/08/2019 à 20h 08







JoePike a écrit :



Moi ce sont les commentaires qui me dépassent



&nbsp;

Moi je trouve ça logique, impossible de lâcher “une bombe pareil” sans documentation / commentaire / notice d’utilisation. Si ça existe mais pas diffusé c’est de l’abus et si ça n’existe pas c’est aussi de l’abus. La différence entre les deux c’est la cible. Et même si c’était pas du cobol mais du python ou du JS sans doc / commentaire / notice ça sera à la limite de l’inutilisable.



alex.d. Abonné
Le 26/08/2019 à 21h 38

C’est marrant de voir plein de monde ici être outré que ce n’est pas en Python ou en Javascript. Eh, sérieux, vous avez déjà vu comment est fait un vrai code industriel, qui doit encore tourner dans 30 ans ? Et un code dont on doit avoir confiance dans les résultats, parce que c’est quand même un peu critique, et qu’il ne faut pas avoir l’ombre d’un doute sur ce que ça fait réellement si jamais on vient de passer de python 2 à python 3… Ça ne me surprend pas que ce soit en COBOL, c’est assez adapté pour cette tâche.

&nbsp;


alex.d. Abonné
Le 26/08/2019 à 21h 39







skankhunt42 a écrit :



&nbsp;

Moi je trouve ça logique, impossible de lâcher “une bombe pareil” sans documentation / commentaire / notice d’utilisation. Si ça existe mais pas diffusé c’est de l’abus et si ça n’existe pas c’est aussi de l’abus. La différence entre les deux c’est la cible.



Il me semble que la requête CADA portait sur le code, pas sur les documentations internes.

&nbsp;



Le 26/08/2019 à 22h 12

Je suis presque certain qu’il y a des morceaux de code dans certaine banques et certaines administrations qui n’ont aucun commentaire sur un support magnétique quelconque

L’espace mémoire et disque ne permettait pas de laisser les commentaires sur un support magnétique.

Une fois le listing imprimé sur un bon vieux papier à chaque compil/linkedit , il était effacé.

Au pire le source était mis sur bande mais il n’y a plus de HW pour lire ces bandes qui croupissent peut-être encore dans les sous-sols des archives.

Il ne faut pas oublier non plus que certains morceaux de code tournent depuis 40 ans et servent tous les jours Sauf qu’ls ont été conçus quand on parlait en kbytes et en mégabytes ..

Me trompe peut-être mais une demande de prestation demandée à des ex collègues il n’y a pas si longtemps que ça me fait penser à encore pire <img data-src=" />


Pseudooo Abonné
Le 26/08/2019 à 22h 15

Je lis du COBOL pour la première fois, et franchement je trouve ça assez beau. C’est même bluffant de voir l’état avancé de l’informatique des années 60.


Citan666 Abonné
Le 26/08/2019 à 23h 07







Furanku a écrit :



A rien pour ma part.





J’ai justement une pensée pour eux, vu que je sais exactement ce que ça fait de bosser avec du code mal documenté (voire pas du tout) et des spec fonctionnelles manquantes. Je le vis plus ou moins au quotidien.

Donc non ce n’est pas sur les dev que je rejette la faute mais bien sur ceux qui sont au-dessus et qui, eux, ne sont pas impactés.





Je ne croyais rien. Je constate juste une situation.

Et restriction budgétaire ou pas cela reste du foutage de g*le de fournir un code de la sorte, en vrac, sans plus d’informations pour le comprendre. Ce alors même justement que les équipes internes doivent déjà s’arracher les cheveux avec un code datant de Mathusalem et non documenté. C’est justement l’occasion de mettre du propre dans tout ça avant publication. Et d’avoir des potentiellement des retours pertinents par la suite pour améliorer le code (et mettre le doigt sur des erreurs de calcul).

Mais là encore je vois que mes impôts ne servent pas où il faudrait…



  &nbsp;        





En amont sur du code qui a sûrement près de 30 ans ou plus ? <img data-src=" />

Faudra m’expliquer comment reprendre la conception sur un code que l’on perpétuer depuis tout ce temps sans avoir à faire de gros changements et risquer de tout casser…





Franchement ? Belle hypocrisie.&nbsp;

Déjà, “j’ai une pensée pour eux”, c’est risible considérant le ton de tes commentaires.

Ensuite, je parlais du manque d’investissement en général depuis des années sur les projets, qu’il s’agisse de refonte d’anciens, d’évolutions ou nouveaux projets.&nbsp;



En clair : vous pensez que c’est la merde dans les entreprises privées ? Sachez que c’est LARGEMENT PIRE dans l’administration.&nbsp;



Alors, oui, espérer qu’ils allaient consacrer la moindre minute à revoir le code pour mieux le documenter (rappel : pour 99% des chefs de projets commentaire/doc = perte de temps, aussi triste que ça soit), quand les équipes n’ont déjà pas le temps de maintenir / faire évoluer proprement… C’est d’une naiveté sans nom pour rester poli.&nbsp;



Les projets seront (peut-être) menés proprement dans 20 ans, quand les générations actuellement jeunes et nettement plus intéressées en moyenne par l’informatique que leurs aînés à âge comparable (et plus conscientes de l’immense valeur ajoutée que ça apporte, à fortiori quand la qualité suit) auront pris le pouvoir.

Et encore ,s’ils ne se bouffissent pas d’orgueil en cours de route comme les autres.

Et éventuellement, espérons, que les multiples couches de bureaucrates inutiles auront été compressées.

En attendant faut souffrir en silence.

Pareil pour le côté “échanges avec la communauté”&nbsp; : l’état d’esprit que ça requiert est à des années-lumières de ce qui règne. Et ça demandera le même changement générationnel.



Quant au passage sur “je préfère éviter de m’encroûter dans du COBOL”… Lol.&nbsp;

Ca fait 30 ans que ça fait le taff, et ça continuera pour au moins les 30 prochaines années (ce qui implique que l’écosystème se maintiendra et que donc si t’es costaud tu pourras toujours trouver de nouvelles missions).

Passons sur le fait que les langages plus anciens étant “roots” obligent le développeur à gérer bien plus de choses par lui-même que les langages “modernes”. Côté pile, c’est super casse couille parce qu’on est plus livré à soi-même et la moindre erreur se paye très cher. Côté face, tu peux réellement affirmer que tu piges les ordinateurs.&nbsp;

&nbsp;

Ce qui fait qu’un développeur est encroûté, ce n’est pas le langage, c’est son état d’esprit.

Et soit dit en passant les projets mal documentés (et/ou mal branlés), en PHP et Javascript (les langages que je pratique un minimum au quotidien) c’est pas ce qui manque non plus…&nbsp;&nbsp;

&nbsp;

—&nbsp;

Rappel pour les gens qui rêvent éveillés : le MINEFI gère vos thunes (et donc celles de l’Etat). Le MINEFI gère la publication des textes qui régissent les taxes et l’impôt. Le niveau de criticité n’est pas loin de celui du ministère de la Défense.



En conséquence, jamais les applications critiques ne seront refondues dans un autre langage dans la dynamique actuelle et qui se poursuivra sur le siècle sauf remise en cause systémique du pays/monde. Parce qu’aucun langage ne pourra fournir suffisamment d’avantages pour justifier une refonte qui coûtera au bas mot 50 millions d’euros (actuels) en accaparant des centaines de gens pendant des mois, sans réelle garantie de résultats sur l’exploitation et la migration, par rapport à un langage qui est parfaitement adapté pour ça.&nbsp;

Il faudrait un personnage avec des couilles en acier trempé pour soutenir et gagner un projet de ce type plus de 2 mois avant qu’un logiciel “actif” soit sur le point de se crasher définitivement (oui on est d’accord c’est approximativement 5 ans trop tard).

Ce n’est vraiment pas plus compliqué que ça. C’est scandaleux, triste, révoltant, tout ce qu’on veut… Mais on n’y peut rien pour le moment.



alex.d. Abonné
Le 27/08/2019 à 07h 29







Citan666 a écrit :



Les projets seront (peut-être) menés proprement dans 20 ans, quand les générations actuellement jeunes et nettement plus intéressées en moyenne par l’informatique que leurs aînés à âge comparable (et plus conscientes de l’immense valeur ajoutée que ça apporte, à fortiori quand la qualité suit) auront pris le pouvoir.



Au risque de passer moi-même pour un vieux con, ce que je constate chez les “jeunes” actuellement, c’est qu’ils se jettent sur des langages qui ont 2 ans d’existence et bâtissent tout un projet sur un framework trouvé sur github avec 0.25 mainteneur, dont on ne sait pas ce qu’il sera dans 3 mois.

Je ne suis pas sûr d’avoir envie de leur confier une application critique de calcul des impôts. Il faut qu’ils mûrissent un peu d’abord.

&nbsp;



Furanku Abonné
Le 27/08/2019 à 07h 53







Z-os a écrit :



Allez juste avant d’aller manger : dernièrement j’ai expliqué en 14 d’heure à ma maitrise d’ouvrage (non informaticienne) comment lire un programme pour qu’elle me réponde “c’est facile en fait”.

Donc, à mon humble avis, ceux d’entre vous qui hurlent à la vue d’un langage qu’ils ne connaissent pas devraient se remettre en question…





C’était de l’ironie hein… je l’ai déjà précisé un peu plus haut.

Surtout quand je suis le premier à apprendre de nouveaux langages dès que j’en ai l’occasion (ou simplement par plaisir sur mon temps libre).









Citan666 a écrit :



Franchement ? Belle hypocrisie. 

Déjà, “j’ai une pensée pour eux”, c’est risible considérant le ton de tes commentaires.





Hypocrisie de quoi ?

Ensuite c’est toi qui dis et trouve que c’est risible.



Tu vois, dans ma boîte certains aiment dev en WinDev (ils s’occupent de la version historique de notre produit), alors que c’est un langage particulièrement horrible (et ce n’est pas que subjectif). Je n’ai rien contre ça même si je ne le comprends pas. Leurs attentes ne sont pas les mêmes que les miennes tout simplement.

Reste que j’ai une pensée pour eux quand je vois comment ils s’arrachent les cheveux avec. Bah là c’est pareil.







Citan666 a écrit :



En clair : vous pensez que c’est la merde dans les entreprises privées ? Sachez que c’est LARGEMENT PIRE dans l’administration.





Pas toutes les administrations de ce que j’ai pu lire dans différents commentaires (pas qu’ici). Cela dépend encore une fois grandement des décisionnaires, des chefs de projet et de l’environnement (dette technique, etc). Que ce soit dans le privé comme dans le publique. Donc aucune distinction de ce type à faire.







Citan666 a écrit :



Alors, oui, espérer qu’ils allaient consacrer la moindre minute à revoir le code pour mieux le documenter (rappel : pour 99% des chefs de projets commentaire/doc = perte de temps, aussi triste que ça soit), quand les équipes n’ont déjà pas le temps de maintenir / faire évoluer proprement… C’est d’une naiveté sans nom pour rester poli.





C’est être naïf que de s’attendre à ce que nos impôts servent aussi à payer le développement d’un code de qualité bien documenté ? Ah…

N.B : je ne remets pas la qualité du code en question ici, ne maîtrisant pas le COBOL. Mais bien le manque de documentation, qui fait aussi partie de la QA.







Citan666 a écrit :



Les projets seront (peut-être) menés proprement dans 20 ans, quand les générations actuellement jeunes et nettement plus intéressées en moyenne par l’informatique que leurs aînés à âge comparable (et plus conscientes de l’immense valeur ajoutée que ça apporte, à fortiori quand la qualité suit) auront pris le pouvoir.





Là c’est toi qui est naïf vu la tournure que prend le monde du dev en général, avec des usines à gaz “pour faciliter le dev”, non maintenable à long terme sans tout “casser” régulièrement, le changement régulier de techno, etc.

Il y a une forme de savoir-faire qui est en train de se perdre sous le couvert de la rentabilité et de la rapidité. Et les formations ont tendance à enfoncer le clou.







Citan666 a écrit :



Quant au passage sur “je préfère éviter de m’encroûter dans du COBOL”… Lol. 

Ca fait 30 ans que ça fait le taff, et ça continuera pour au moins les 30 prochaines années





J’ai dit le contraire ?







Citan666 a écrit :



Passons sur le fait que les langages plus anciens étant “roots” obligent le développeur à gérer bien plus de choses par lui-même que les langages “modernes”. Côté pile, c’est super casse couille parce qu’on est plus livré à soi-même et la moindre erreur se paye très cher. Côté face, tu peux réellement affirmer que tu piges les ordinateurs.





+1 sans pour autant tomber sur l’idée qu’un bon dev est forcément un barbu.

 





Citan666 a écrit :



Ce qui fait qu’un développeur est encroûté, ce n’est pas le langage, c’est son état d’esprit.





+1 aussi (+10 même)







Citan666 a écrit :



Et soit dit en passant les projets mal documentés (et/ou mal branlés), en PHP et Javascript (les langages que je pratique un minimum au quotidien) c’est pas ce qui manque non plus…





Et là +100



Bon au moins on aura trouvé des points d’entente malgré tout <img data-src=" />



eglyn Abonné
Le 27/08/2019 à 07h 53







alex.d. a écrit :



Au risque de passer moi-même pour un vieux con, ce que je constate chez les “jeunes” actuellement, c’est qu’ils se jettent sur des langages qui ont 2 ans d’existence et bâtissent tout un projet sur un framework trouvé sur github avec 0.25 mainteneur, dont on ne sait pas ce qu’il sera dans 3 mois.

Je ne suis pas sûr d’avoir envie de leur confier une application critique de calcul des impôts. Il faut qu’ils mûrissent un peu d’abord.

&nbsp;





Ahah tellement vrai, je vois ça tous les jours <img data-src=" />

&nbsp;



Le 27/08/2019 à 07h 54

<img data-src=" /><img data-src=" /><img data-src=" />


tazvld Abonné
Le 27/08/2019 à 08h 11







Pseudooo a écrit :



Je lis du COBOL pour la première fois, et franchement je trouve ça assez beau. C’est même bluffant de voir l’état avancé de l’informatique des années 60.





Les “racines” sont même plus ancienne, car il est largement inspiré par les travaux de Grace Hopper sur les langages compilés.



En soit, les “structures” (comme le if-then-else-endif, for-do-done, while-do-done …) était déjà assez connu des algorithmiciens. C’est déjà une traduction plus “automaticienne” des formulations mathématiques (sauf que les mathématiciens aiment plus les fonctions récursives). Par exemple, en math, on va utiliser une accolade pour exprimé une condition (exemple de la suite de Syracuse).



Vu la galère pour “programmer” les ordinateurs, avant même d’avoir du code compiler automatiquement, on écrivait son algo que l’on vérifiait pour être sûr qu’il fonctionne, et ensuite on l’écrivait en langage machine.



Le langage est trop verbeux selon moi, mais cela colle assez bien avec la vision de l’époque de vouloir faire quelque chose se rapprochant d’un langage naturel.

La structures de chaque fichier me fait pensé à ce que j’ai déjà vu en assembleur ASM, où l’on sectorise en plusieurs parties (en particulier la partie DATA et la parti CODE).



Ensuite, il faut voir que le cobol était à l’origine destiné à être écrit sur des cartes perforées, d’où cette mise en forme en colonne (si tu veux savoir d’où vient cette tradition de coupé le code en ligne de 80 colonne, c’est à cause de ces cartes perforées qui comptaient 80 colonnes, en cobol, on utilise 72 colonne, les 8 dernières étant réservé à la numérotation des cartes). Et pour te donner une idée de la quantité de carte, chaque ligne est codé sur une seul carte (qui à le format d’un billet de banque).



Personnellement, je ne suis pas surpris du langage. Il est le travail combiné des contrainte technique, du fonctionnement même des ordinateur des connaissances de la théorie du langage mais aussi de la volonté d’écrire un programme “en anglais”. On a donc un mélange entre de l’assembleur, de l’algo et de l’anglais.



fred42 Abonné
Le 27/08/2019 à 09h 49

Comme je l’avais dit à l’époque du précédent article annonçant cette demande CADA, c’est le calcul de la valeur locative qu’il faut demander. C’est effectivement lui qui est complexe et les données d’entrée sont sûrement discutables.



Demander ce code est assez inutile, le calcul de la taxe foncière est assez simple et déjà bien expliqué dans l’avis d’imposition.



Donc pour vraiment mettre un coup de pied dans la fourmilière, c’est sur ce calcul qu’il faut demander des comptes, pas forcément le code, peu intéressant, mais la documentation technique et les algos servant à ce calcul.


alex.d. Abonné
Le 27/08/2019 à 09h 56







fred42 a écrit :



Comme je l’avais dit à l’époque du précédent article annonçant cette demande CADA, c’est le calcul de la valeur locative qu’il faut demander. C’est effectivement lui qui est complexe et les données d’entrée sont sûrement discutables.



L’algo pour calculer la valeur locative se trouve et n’est pas si compliqué que ça. L’arbitraire de la valeur locative vient essentiellement de la “catégorie du logement” qui, à ma connaissance, est attribuée par un humain et non par un algo.

&nbsp;



Pseudooo Abonné
Le 27/08/2019 à 11h 15

Merci pour cet historique et ces précisions <img data-src=" />


Le 27/08/2019 à 13h 55

Oui et alors, ça nous fait une belle jambe <img data-src=" />


ajangot Abonné
Le 27/08/2019 à 16h 06

Ce n’est qu’un seul taux. Il en faut 6 autre pour le calcul de la valeur locative :‘(


Le 27/08/2019 à 16h 14

Si les taux sont disponibles à quoi sert de rendre le code de l’algo publique?

Ce qui fait le mystère c’est surtout “la base”, la valeur locative que l’Etat estime ou j’ai loupé un truc?

Ce qui aurait fallu c’est plutôt l’ouverture de la base de données des valeurs locatives ?!


ajangot Abonné
Le 27/08/2019 à 16h 19

Le calcul de la valeur locative est très simple:

(nombre de m² du bien coef d’entretien coef de situation coef d’ascensseur) Coef A * Coef d’actualisation = valeur locative

avec

coef d’entretien,coef de situation,coef d’ascensseur = si tu as un vide ordure, baignoire, balcon, ascensseur

Coef A * Coef d’actualisation = coefficient qui sont complétement obscure et déterminé en partie par la mairie et par le centre des impôts qui “nivelle” les taux sur une même zone géographique.



Et c’est bien ces coefficients magiques qui sont à l’origine d’iniquité.


Le 27/08/2019 à 18h 12

Je viens de lire tous les programmes COBOL. Je comprends pas pourquoi vous ralez que ce soit du COBOL C’est parfaitement lisible, compréhensible et ça fait le taff.



Bon d’accord faisant du COBOL tous les jours ça doit aider :)


Le 27/08/2019 à 18h 48

Est-ce que vous avez réussi à le compiler ?

Le fichier principal est FMSTAU2.cob ?



J’ai essayé avec GNU Cobol, et il me renvoie des erreurs:

&nbsp;




FMSTAU2.cob: 60: error: XB30: No such file or directory

FMSTAU2.cob: 64: error: XB35: No such file or directory

FMSTAU2.cob: 72: error: XB40: No such file or directory

FMSTAU2.cob: 76: error: XB45: No such file or directory

FMSTAU2.cob: 79: error: XB46: No such file or directory

FMSTAU2.cob: 83: error: XB36: No such file or directory

FMSTAU2.cob: 87: error: XB37: No such file or directory

FMSTAU2.cob: 91: error: XB38: No such file or directory

FMSTAU2.cob: 95: error: XB47: No such file or directory

FMSTAU2.cob: 99: error: XB41: No such file or directory

FMSTAU2.cob: 106: error: XB50: No such file or directory

FMSTAU2.cob: 110: error: XB51: No such file or directory

FMSTAU2.cob: 113: error: XTAU2: No such file or directory

FMSTAU2.cob: 59: error: PICTURE clause required for 'XB30'

FMSTAU2.cob: 63: error: PICTURE clause required for 'XB35'

FMSTAU2.cob: 71: error: PICTURE clause required for 'XB40'

FMSTAU2.cob: 75: error: PICTURE clause required for 'XB45'

FMSTAU2.cob: 78: error: PICTURE clause required for 'XB46'

FMSTAU2.cob: 82: error: PICTURE clause required for 'XB36'

FMSTAU2.cob: 86: error: PICTURE clause required for 'XB37'

FMSTAU2.cob: 90: error: PICTURE clause required for 'XB38'

FMSTAU2.cob: 94: error: PICTURE clause required for 'XB47'

FMSTAU2.cob: 98: error: PICTURE clause required for 'XB41'

FMSTAU2.cob: 105: error: PICTURE clause required for 'XB50'

FMSTAU2.cob: 109: error: PICTURE clause required for 'XB51'

FMSTAU2.cob: 128: error: 'FIE01-JANIPT' is not defined

FMSTAU2.cob: 128: error: 'FIE01-ACODIR' is not defined

FMSTAU2.cob: 129: error: 'FIE01-CCOCOM' is not defined

FMSTAU2.cob: 129: error: 'FIE01-CCOIFP' is not defined

FMSTAU2.cob: 129: error: 'CR' is not defined

FMSTAU2.cob: 129: error: 'RC' is not defined

FMSTAU2.cob: 130: error: 'ZES' is not defined

FMSTAU2.cob: 134: error: executable program requested but PROCEDURE/ENTRY has USING clause

FMSTAU2.cob: in paragraph 'INIT':

FMSTAU2.cob: 145: error: 'CR' is not defined

FMSTAU2.cob: 145: error: 'RC' is not defined

FMSTAU2.cob: in paragraph 'ACCES-TAUX':

FMSTAU2.cob: 155: error: 'CR' is not defined

FMSTAU2.cob: 156: error: 'RC' is not defined

FMSTAU2.cob: in paragraph 'PELP-DEPT-MULTI-DSF':

FMSTAU2.cob: 166: error: 'FIE01-ACODIR' is not defined

FMSTAU2.cob: 169: error: 'CR' is not defined

FMSTAU2.cob: 169: error: 'FIE01-JANIPT' is not defined

FMSTAU2.cob: 170: error: 'FIE01-CODEP' is not defined

FMSTAU2.cob: 171: error: 'FIE01-CCOCOM' is not defined

FMSTAU2.cob: 169: error: invalid expression

FMSTAU2.cob: 170: error: invalid expression

FMSTAU2.cob: 170: error: invalid expression

FMSTAU2.cob: 170: error: invalid expression

FMSTAU2.cob: 169: error: invalid expression

FMSTAU2.cob: 169: error: invalid expression

FMSTAU2.cob: in paragraph 'RECUP-SEG':

FMSTAU2.cob: 183: error: 'CR' is not defined

FMSTAU2.cob: 183: error: 'FIE01-JANIPT' is not defined

FMSTAU2.cob: 183: error: invalid expression

FMSTAU2.cob: 189: error: 'CR' is not defined

FMSTAU2.cob: 189: error: 'FIE01-JANIPT' is not defined

FMSTAU2.cob: 190: error: 'FIE01-ACODIR' is not defined

FMSTAU2.cob: 189: error: invalid expression

FMSTAU2.cob: 189: error: invalid expression

FMSTAU2.cob: 196: error: 'CR' is not defined

FMSTAU2.cob: 196: error: 'FIE01-JANIPT' is not defined

FMSTAU2.cob: 197: error: 'FIE01-ACODIR' is not defined

FMSTAU2.cob: 197: error: 'FIE01-CCOCOM' is not defined

FMSTAU2.cob: 196: error: invalid expression

FMSTAU2.cob: 196: error: invalid expression

FMSTAU2.cob: 196: error: invalid expression

FMSTAU2.cob: 200: error: 'CR' is not defined

FMSTAU2.cob: 200: error: 'XB40-CTYGC' is not defined

FMSTAU2.cob: 201: error: 'XB40-DNUCOL' is not defined

FMSTAU2.cob: 200: error: invalid expression

FMSTAU2.cob: 200: error: invalid expression

FMSTAU2.cob: 205: error: 'CR' is not defined

FMSTAU2.cob: 205: error: 'XB40-CTYSYN' is not defined

FMSTAU2.cob: 206: error: 'XB40-CCOSYN' is not defined

FMSTAU2.cob: 205: error: invalid expression

FMSTAU2.cob: 205: error: invalid expression

FMSTAU2.cob: 213: error: 'CR' is not defined

FMSTAU2.cob: 213: error: 'FIE01-JANIPT' is not defined

FMSTAU2.cob: 214: error: 'FIE01-ACODIR' is not defined

FMSTAU2.cob: 214: error: 'FIE01-CCOCOM' is not defined

FMSTAU2.cob: 215: error: 'FIE01-CCOIFP' is not defined

FMSTAU2.cob: 213: error: invalid expression

FMSTAU2.cob: 213: error: invalid expression

FMSTAU2.cob: 213: error: invalid expression

FMSTAU2.cob: 213: error: invalid expression

FMSTAU2.cob: 218: error: 'FIE01-JANIPT' is not defined

FMSTAU2.cob: 222: error: 'CR' is not defined

FMSTAU2.cob: 222: error: 'XB40-CTYSYN' is not defined

FMSTAU2.cob: 223: error: 'XB40-CCOSYN' is not defined

FMSTAU2.cob: 218: error: invalid expression

FMSTAU2.cob: 218: error: invalid expression

FMSTAU2.cob: 231: error: 'CR' is not defined

FMSTAU2.cob: 231: error: 'XB45-CCDDIR' is not defined

FMSTAU2.cob: 218: error: invalid expression

FMSTAU2.cob: 238: error: 'CR' is not defined

FMSTAU2.cob: 238: error: 'FIE01-JANIPT' is not defined

FMSTAU2.cob: 239: error: 'FIE01-ACODIR' is not defined

FMSTAU2.cob: 239: error: 'FIE01-CCOCOM' is not defined

FMSTAU2.cob: 218: error: invalid expression

FMSTAU2.cob: 218: error: invalid expression

FMSTAU2.cob: 218: error: invalid expression

FMSTAU2.cob: 245: error: 'CR' is not defined

FMSTAU2.cob: 245: error: 'FIE01-JANIPT' is not defined

FMSTAU2.cob: 246: error: 'FIE01-ACODIR' is not defined

cobc: too many errors

cobc: aborting compile of FMSTAU2.cob at line 246 (PROGRAM-ID: FMSTAU2)



Romain_Ph Abonné
Le 28/08/2019 à 04h 52

Alors fais attention parce que le cobol qu’on utilise est exécuté sur mainframe IBM ( bientôt z/os) et aussi bizarre que cela puisse paraître, il y a pas mal de différences entre les 2 plateformes.



La politique de la DGFIP est de migrer les anciens programmes cobol de IBM chez z/os et pour les migrations X86 les projets sont en Java. Mais a ma connaissance j’ai pas eu vent de conversion cobol IBM =&gt; X86


Le 28/08/2019 à 06h 13

Compile sur un serveur AIX avec les .cpy dans un repertoire copy et les programmes encodés en ANSI. A essayer avec GNU COBOL.


Le 28/08/2019 à 07h 07

D’accord. Merci pour cette info. Apparemment GNU Cobol a une option -std=&lt;dialect&gt; et on peut choisir “ibm” comme dialecte (“IBM Compatible”). Je ne sais pas si c’est suffisamment compatible.

&nbsp;

J’ai l’impression que la directive COPY va chercher un fichier cpy. Par exemple, si je compile le fichier EFITA3B8.cob, je n’ai pas d’erreur à la ligne 38 COPY XBASEB car il y a bien un fichier XBASEB.cpy qui est fourni.

Par contre, les COPY dans FMSTAU2.cob semblent utiliser des noms pour lesquels il n’y a pas de fichier cpy associés.



Question: les différents fichiers sources correspondent-ils chacun à un exécutable, ou bien certains sont-ils des modules ?

Si j’essaie de compiler et de demander un exécutable, j’obtiens ceci:




% cobc -std=ibm -x EFITA3B8.cob

EFITA3B8.cob: 96: error: executable program requested but PROCEDURE/ENTRY has USING clause




mais le même source peut être compilé comme un module (option -m au lieu de -x). Mais que faut-il faire ensuite avec ce module ?


Le 28/08/2019 à 07h 23

Oui du Cobol. Mais ce que laisse entendre l’article c’est que ce vieux langage est encore utilisé uniquement dans les administrations. Il oublie de dire que ce langage est encore massivement utilisé dans les banques (le coeur de leur métier tel que la gestion des contrats ou des comptes est en cobol), dans les assurances, les compagnies aériennes, la grande distribution…..

Bref, les secteurs économiques majeurs reposent encore beaucoup sur le cobol.

Mais c’est mieux de dire que ce vieux langage n’est plus utilisé que par les administrations.


Le 28/08/2019 à 08h 17

Ce sont des programmes COBOL batch qui ont besoin d’une base de données hiérarchique de type DL/I. On les appelle avec un JCL. Mais sans la structure de bases (aka PCB) on ira pas très loin.



Je n’arrive pas à compiler non plus le FMSTAU2, on a pas les COPY.



Il manque clairement des COPY et au moins un programme.


RuMaRoCO Abonné
Le 28/08/2019 à 16h 07

Elle a existé…



&nbsp;Dans des classeurs qui depuis ont été depuis archivés verticalement à l’occasion de déménagement successifs.



CQFD


SebGF Abonné
Le 28/08/2019 à 17h 02

Pour la grande distrib la tendance est quand même à la suppression de l’AS400.



Mais celui-ci a la peau horriblement dure. <img data-src=" />



Souvenir d’arrivée chez un acteur du retail : “l’AS400 c’est en train de disparaître, faut pas trop s’y intéresser”*



* depuis dix ans, il y a dix ans, et de l’écran vert ou bleu j’en vois encore très souvent que ce soit à la Fnac, chez Boulanger, Darty, Auchan, etc. <img data-src=" />



Quand ce ne sont pas des interfaces Web plus fancy qui communiquent en réalité avec l’AS400.


Le 28/08/2019 à 22h 48

Les ecrans verts ou bleus montrent simplement que ce sont des émulations de terminaux TN3270

mais ça ne veut pas dire nécessairement AS400

Ils peuvent être derrière du VM du DOS VSE du z/OS sur platform Z

En principe c’est du CICS

Mais tu as peut-être raison ça peut être de l’AS400 mais pour Darty et la FNAc ça me surprend un peu



tazvld Abonné
Le 29/08/2019 à 07h 53

Ha…. j’ai toujours pensé que ces écran était des émulations du minitel (il faut dire, la mise en page en ASCII, la navigation de champs en champs, c’était aussi du minitel).

Mais, en jetant un oeil aux écran des “conseillé”, j’ai l’impression que beaucoup de programmes ont juste vu leur frontend mise à jour vers une interface plus moderne (web) mais que derrière c’est toujours le même logiciel qui tourne réellement.


Le 29/08/2019 à 08h 13

c’est de l’émulation TN3270 ( et ça existait avant le minitel <img data-src=" /> )


SebGF Abonné
Le 29/08/2019 à 16h 27

Ayant bossé chez leur copain du crédit pour la Fnac, je pense que ce doit être du MVS.



Pour Auchan ou Boulanger (et quelques autres de la famille), c’est de l’AS400.


Le 29/08/2019 à 21h 31

ah ok

Du temps ou j’étais au support IBM ( il y a environ 1000 ans) La FNAC et DARTY était MVS ( enfin os390 ) qui est devenu z/OS .. mais bon ils ont pu migrer…. ou pas <img data-src=" />



Z-os Abonné
Le 01/09/2019 à 18h 36

Désolé, premier commentaire : j’ai pris le troll au bond. :-)



Sinon, je pense que cela pourrait intéresser ici, je suis tombé sur un podcast de Red Hat sur le cobol et le go (oui ça fait bizarre) sur les erreurs qu’il ne faudrait plus faire côté infrastructure (en anglais avec la transcription en dessous) :

https://www.redhat.com/en/command-line-heroes/season-3/the-infrastructure-effect…