Discussion :

[deusyss]

L'Inforkéologie
l'art de travailler sur des langages obsolètes

L'inforkéologie est un terme que j'ai inventé avec des collègues. Il s'agit donc d'un néologisme. Il permet de désigner l'analyse, l'étude ou le travail sur des technologies obsolètes et/ou bâtardes.

Ce terme a vu le jour après un certain temps passé pour des clients sur des langages « périmés ». En effet, la technologie utilisée la plus récente datait de plus de 15 ans. Ne parlons même pas de la technologie la plus vieille.

Après de nombreuses discussions entre collègues, l'étymologie du terme a germé. Fort de constater que nous travaillions sur des langages, qui aux yeux de l'histoire informatique remontaient à la préhistoire, nous sommes partis sur l'idée que nous faisions de l'archéologie informatique. Le terme initial était alors né: inforchéologie.

Puis par la suite, nos périmètres ayant évolué chez nos clients respectifs, et étant amenés à travailler sur des langages maison dérivés de langages officiels, ne respectant aucune norme voire violant tout ou partie des anti-patterns, le terme a évolué peu à peu en inforkéologie.

Désormais, nous qualifions ainsi le fait de travailler sur des machines vieilles de plusieurs décennies, des langages maison plus ou moins absurdes, ou encore des SI complets maison, ne respectant aucune norme et ne disposant d'aucune documentation quelle qu'elle soit.

Et vous:
Vous sentez-vous l'âme d'un inforkéologue?

[Invité]

Et vous, vous sentez vous l'âme d'un inforkéologue?

Je sais pas mais à lire ton message, je dois être un dinosaure

J'ai installé mon 1er Cisco en 1991, il tournait la version 6.73 et à cette époque, je crois même que le MGS ou AGS+ ne supportait pas encore le routage IP, on faisait tout en bridge

Je crois que, par la force des choses, plus on acquiert de l'expérience, plus on devient inforkéologue

Steph

[deusyss]

Eh oui. Des fois cela ne nous rajeunie pas.

Bien qu'ayant commencé à travaillé en 2006, j'ai passé ces trois dernières années à maintenir et coder un vieux serveur HP de 1979. 5 langage de programmation maison différent sur la machine. Une catastrophe. 2GO de HDD, et je ne parle pas de la RAM.

Mon smartphone avait plus de puissance

[Saverok]

Le hic est que certains systèmes titanesques ont été conçus dans les années 70/80 (je pense aux systèmes bancaires et assurances notamment où une grande partie est écrite en Cobol)
Ces systèmes sont le noyaux d'une activité économique et ils ont besoin d'être maintenus et maj.
Les changer est trop coûteux et très risqué car certaines connaissances se sont perdues et que ces systèmes sont tellement énormes et tentaculaires que plus personne ne s'y retrouve (en dresser la cartographie est un projet de plus d'une centaine de j/h à lui seul).
Je pense que les vielles technos ont encore de beaux jours devant elles.
Et puis, à partir du moment où un système est stable et fonctionne, il n'est pas nécessaire de le changer.
La nouveauté n'est pas synonyme de progrès.

[Invité]

Je pense que les vielles technos ont encore de beaux jours devant elles.

Oui, j'ai 2 ou 3 potes freelance qui bossent sur des "systèmes obsolètes" et ils gagnent effectivement beaucoup d'argent

Steph

[Jonyjack]

J'ai travaillé en COBOL sur AS400.
En C sur un Windows NT (et je ne veux pas parler de la "qualité" du code maintenu sur cette machine...).

Et j'ai commencé à travailler il y a 2 ans seulement

Et puis, à partir du moment où un système est stable et fonctionne, il n'est pas nécessaire de le changer.
La nouveauté n'est pas synonyme de progrès.

Le problème c'est que les personnes qui s'y connaissent vraiment en COBOL de moins de 45 ans ça tend à disparaitre. A terme, si plus personne ne connait le langage ça devient un problème.

[squizer]

Windows XP, quand tu nous tiens...

[tomlev]

Ca me rappelle une blague :

A Cobol programmer made so much money doing Y2K remediation that he was able to have himself cryogenically frozen when he died. One day in the future, he was unexpectedly resurrected.

When he asked why he was unfrozen, he was told:

"It's the year 9999 - and you know Cobol"

[xelab]

Mon environnement de dev était sous Windows 2000 il y a encore 2 ans... (j'ai changé de boîte depuis, mais je ne serais pas surpris que ça tourne encore là bas). J'ai fait de nouveaux modules d'application en VB6/Asp en 2009... D'ailleurs j'ai un pote qui était sous VB5 à la même période. Je sortais de formation, on avait vu tous les langages "modernes" de type .NET ou Java, ça m'a fait bizarre, mais c'est formateur.
Par contre autant j'estime que COBOL n'est pas vraiment obsolète puisque toujours maintenu, autant des OS comme Windows 2000 et des langages comme VB6 sont pour moi , comme vous dites, de l'inforkéologie.
De manière générale, toutes les entreprises que j'ai pu fréquenter avaient un manque criant de documentation technique (et fonctionnelle aussi, ne pas comprendre le métier pour lequel on bosse, c'est embêtant).

[ggbbii]

Pour le coup, je suis un inforkéologue Suite à un rachat de ma boite et une harmonisation des SI, je me suis retrouvé à bosser sur un langage vieux de 20 ans que à mon avis personne ne connait : Progress. C'est une horreur, quasiment aucune doc sur internet. On a une IHM en "mode caractère" de 80 x 30 caractères ou un truc comme ça.

[gangsoleil]

inforkeologue... Rien que l'utilisation de la lettre k me laisse reveur...

Apres, un langage qui a plus de 15 ans et qui est encore utilise, pour moi, c'est surtout un gage de qualite.

Apres, je pense que tu t'es fourvoye en prenant 15 ans, car s'il est evident que C, Cobol, Smalltalk ou Fortran sont des langages vieux, je suis persuade que tu ne classe pas Java dedans, qui est pourtant ne en 1995, c'est a dire qu'il va feter ses 19 ans, tout comme JavaScript (truc hyper a la mode en ce moment).

D'ailleurs, si je regarde un peu plus loin :

• C++, 1983
• Perl, 1987
• Python, 1991
• Objective-C, 1983
• R, 1993
• ...

Dans les langages de moins de 15 ans, je ne trouve guere que les langages Microsoft (C# en 2000) ou les langages somme toute tres peu utilises, genre Go (2009) ou Scala (2003).

Est-ce que pour autant tous les gens qui developpent ou maintiennent du code dans ces langages sont des inforcheologues ? Je ne crois pas.

[DotCertis]

J'ai été recruté en 2011 dans une SSII avec 11 autres personnes ( des ingénieurs généralistes) et nous avons tous eu une formation de 5 semaines sur du cobol ^^
N'ayant jamais vraiment étudié de langage de programmation je dois avouer avec le recul que c'est une très bonne porte d'entrée.

Et même en croyant ce langage mort dans une précédente mission qui porte sur le module FI de SAP dans un très grand nom du monde du transport, j'ai participé à un projet de refonte global du système financier. Et au cours de la phase d'études nous avons vu que 90 % des flux en entrée du module FI venait d'une appli monstrueuse (sorte d'ETL, broker, moulinette géante...) qui contenait plus de 30 ans de dév majoritairement en cobol mais faisant appel à des programmes qui étaient véritablement indispensable au bon fonctionnement écrit ... en assembleur et utilisant des bases DL1...

Finalement et bien que le projet était présenté comme "budget illimité" devant cette "monsturosité" (mais qui fonctionnait très bien) la décision a été de la conserver (avec quelques évolutions).

Et dernière anecdotes dans cette même boite sur un autre projet un appli cobol a été refaite en java et bim ! des perfs plombées de plus de 30 % et un retour arrière.

Bref ces technologies qui ont largement faits leur preuve ne sont peut être pas "sexys" du tout, mais elles restent bien souvent des références en robustesse et en performances

[martopioche]

J'ai un peu la même opinion que Saverok, gangsoleil ou DotCertis. Le problème n'est pas une techno "vieille" mais si la techno a évoluée ou non. Et par "a évoluée", j'entends avant tout qui s'adapte aux méthodes de travail, aux outils; etc, pas qui évolue pour évoluer.

[sevyc64]

Prenons un langage "vieux" et éprouvé dont on connais tous les avantages, mais surtout aussi tous les défauts que l'on sait gérer, maitriser, contourner.
Prenons à l'inverse un langage plus moderne, tout jeune, tout génial et qui sent encore la peinture fraiche. C'est le super langage à la mode, mais peut-être encore bourré de failles et bugs, qui peut-être subira 4 ou 6 mises à jour dans les 6 mois à venir dont certaines en rupture de compatibilité parce qu'il n'est pas possible de faire autrement.


Maintenant vous êtes développeur/chef de projet/architecte/ce que vous voulez, sur un projet hautement sensible. Imaginons un projet dont la maintenance sera difficile voire impossible, un projet dont les arrêts de productions se chiffrerons en plusieurs millions d'euros et plus voire un abandon pur et simple du projet et pertes sèches ou pire des pertes humaines, un projet dont le taux de fiabilité doit être exagérément au delà du raisonnable. Je pourrais continuer longtemps !

Quel langage allez-vous choisir ?


Un projet comme ça, ça n'existe pas ?

Il s'en code tous les jours. On parlera d'une application bancaire, d'applications médicales, d'application industrielles que ce soit chimique, nucléaire ou autres. On peut citer aussi tout ce qui part dans l'espace, etc, etc...

[deusyss]

Je vois que le sujet fait discuté, et cela me plait.

Personnellement, les applis que je maintenait était en mode caractère en 80 * 24. Le serveur faisait tourner les usines de 3 pays en pointe. Et comme il tombait souvent en panne, les usines s'arrêtait.

Aucune doc en interne, les "chef" ou du moins ceux qui se prennent pour tel, ne voulant laisser aucune doc et ne donner aucune info, afin de se rendre indispensable. Les langages étant des langages buggés plus maintenus depuis un bon moment, et de toute façon modifié maison; rien n'est stable et crash regulierement. De multiples coredump par jour.

Une modernisation, j'entend par là une bonne étude et des langage vraiment adapté, en temps homme et cout de debuggage, couterait la moitié de ce que leur coute les panne a repetition par an. Seulement avec une mentalité de "touche pas à ça petit c..., ça fonctionne a peu pres", rien n'avance.

Le cas de Cobol est à mon sens un peu l'exception qui confirme la règle, car il s'agit certes d'un vieux langage, mais qui a été conçu spécifiquement pour le bancaire. Il a donc effectivement,je le pense aussi de beaux jours devant lui.

[Gurdil le nain]

@gangsoleil : il faut voir les évolutions des langages en question aussi, autant Java et JS ont beaucoup évolués (enfin je suppose je connais pas les toutes premières versions), alors que COBOl...

Et vous, vous sentez vous l'âme d'un inforkéologue?

Delphi 7 ça compte ?

[KEKE93]

A mon humble avis, ce n'est pas vraiment COBOL qui est obsolète mais plutôt tous les Ateliers de Génie Logiciels et autres L4G clients/Serveur du début des années 90 comme par exemple:
MAGIC, PROGRESS, NSDK de Nat Système, NATSTAR de Nat Système, VB6, voire Powerbuilder...

[Invité]

Et au cours de la phase d'études nous avons vu que 90 % des flux en entrée du module FI venait d'une appli monstrueuse (sorte d'ETL, broker, moulinette géante...) qui contenait plus de 30 ans de dév majoritairement en cobol mais faisant appel à des programmes qui étaient véritablement indispensable au bon fonctionnement écrit ... en assembleur et utilisant des bases DL1...

Et dernière anecdotes dans cette même boite sur un autre projet un appli cobol a été refaite en java et bim ! des perfs plombées de plus de 30 % et un retour arrière.

Il aurait fallu faire une appli java/C (via jni) tout comme les anciens développeurs faisaient du Cobol/Assembleur.

[Gugelhupf]

Pour moi il n'y a pas de "vieux langage fossile". Juste des cas particuliers, et les langages fait maison (ou pas "standard"/reconnu).

Cas particuliers :

• Si je prends un exemple extrême comme l'assembleur, oui c'est un langage très bas niveau, mais c'est un peu la base de tout. D'ailleurs sans ce langage, pourrait-t-on avoir les autres ? Pour moi ce langage sert à faire les autres langages, sans plus, il n'est pas nécessaire d'être en quête de puissance en se lançant dans de l'assembleur.
• Pour ce qui est de COBOL, ce n'est pas un langage fait par n'importe qui, certes c'est un langage qui n'a pas la même communauté que les autres sur internet et qui rebute les jeunes, mais c'est un langage qui a du support en entreprise et qui n'est pas très difficile quand on a les bons outils de développement.

Le vrai problème (selon moi) et sans entrer dans les détails :

• Les langages ET frameworks faits maisons. Ces choses que vous ne trouverez nul part ailleurs.
• Les vieux frameworks pourris (ex: Struts), alors qu'il y a mieux depuis.

[dragonjoker59]

Je me souviens qu'en primaire on faisait du dessin en BASIC