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).
- Télécharger le code source des taxes foncières sur « data.gouv.fr »
- Consulter le code source des taxes foncières sur GitHub
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.
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).
Commentaires (75)
#1
Du COBOL… Ils ont pas plus récent et compréhensible à utiliser comme langage ?
" />
#2
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.
#3
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.
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.
#4
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.
#5
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
#6
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 … ).
#7
vu la complexité y’a forcément de la doc quelque part.
#8
Je ne comprends pas bien ?
Pourquoi vous dites que ce n’est pas commenté ?
Toutes les lignes qui commencent par * sont des commentaires
#9
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
#11
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.
#12
ah non j’ai pas regardé, je tiens à mes yeux.
" />
#13
#14
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.
#15
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?
#16
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).
Bref, pas de quoi fouetter un chat, juste de quoi occuper le terrain.
#17
#18
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
#19
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 ?
#20
#21
“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.”
" />
Donc sur la taxe foncière 2020, si c’est pas mentionné, je ne paye pas ?
#22
J’avais pas vu ton post
" />
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
#23
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
#24
Perso, même pour +10K€ par an, j’hésiterais grandement quand même
" />
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 :)
#25
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 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!
#26
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
( 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
#27
#28
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
#29
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).
#30
+1
#31
+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.
#32
Insert thankyou.gif
#33
+1 très bonne idée clairement
#34
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
#35
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
" />
" />
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
#36
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
#37
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.
#38
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
#39
Le papier des impôts est visible ici:
https://www.facebook.com/photo.php?fbid=2952129668194837&set=a.122408151…
#40
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
#41
#42
#43
#44
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.
#45
#46
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
#47
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.
#48
#49
#50
#51
#52
#53
#54
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.
#55
#56
Merci pour cet historique et ces précisions
" />
#57
Oui et alors, ça nous fait une belle jambe
" />
#58
Ce n’est qu’un seul taux. Il en faut 6 autre pour le calcul de la valeur locative :‘(
#59
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 ?!
#60
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é.
#61
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 :)
#62
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:
#63
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 => X86
#64
Compile sur un serveur AIX avec les .cpy dans un repertoire copy et les programmes encodés en ANSI. A essayer avec GNU COBOL.
#65
D’accord. Merci pour cette info. Apparemment GNU Cobol a une option
-std=<dialect>et on peut choisir “ibm” comme dialecte (“IBM Compatible”). Je ne sais pas si c’est suffisamment compatible.
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 XBASEBcar 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:
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 ?
#66
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.
#67
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.
#68
Elle a existé…
Dans des classeurs qui depuis ont été depuis archivés verticalement à l’occasion de déménagement successifs.
CQFD
#69
Pour la grande distrib la tendance est quand même à la suppression de l’AS400.
" />
" />
Mais celui-ci a la peau horriblement dure.
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.
Quand ce ne sont pas des interfaces Web plus fancy qui communiquent en réalité avec l’AS400.
#70
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
#71
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.
#72
c’est de l’émulation TN3270 ( et ça existait avant le minitel
" /> )
#73
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.
#74
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
#75
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…