>Moi j'aurais dit que ça témoigne de la résistance au changement des administrations et des entreprises.
Tu aurais bossé dans ce genre de boite, tu n'aurais pas dit ça ;-)
j'ai bossé il y a une douzaine d'année dans une grosse boite d'assurances. Ce genre de boite ont des dizaines de milliers de programmes en COBOL qui tournent en permanence (il y en avait 150 000 et des poussières à l'époque dans la boite où je bossais, donc en gros des millions de lignes de codes), sur des gros systèmes qui bouffent du calcul à l'heure comme jamais le serveur de linuxfr n'en fera dans sa courte vie. Beaucoup de ces programmes sont critiques, où la moindre erreur de calcul peut être catastrophique.
Bref, migrer ce genre de système d'information, c'est très compliqué car c'est un énorme chantier. On ne peut pas se dire qu'on va migrer les programmes les uns après les autres, parce qu'en fait il y a beaucoup d'interdépendance. Donc quand il faut migrer, il faut migrer par paquet de centaines ou de milliers. Et réécrire ces programmes pour un autre environnement, ça ne se fait pas à coup de baguette magique. ça demande litteralement des années (quoi que, depuis quelques temps, on a des outils de transcodage très intéressant, voir https://linuxfr.org//2008/09/10/24462.html , qui peuvent raccourcir un peu ces délais). De plus il faut être sûr que les nouveaux programmes feront les mêmes calculs, donc écrire des milliers de tests, faire de longues procédures de recettes...
Il y a aussi le fait que ce n'est pas seulement un changement de langage de développement ou autre, mais aussi un changement de système complet : migrer d'une architecture gros systèmes vers une autre, ou vers un truc mixte (parce que quand même, se priver de la puissance de calcul d'un gros système, c'est dommage).
Si en plus on compte les heures de formation à assurer aux "informaticiens", qui pour certains, n'ont jamais vu autre chose que du COBOL (genre les employés qui sont là depuis 20 ans, qui ont été formé en interne au développement informatique etc..), et le cout de migration du materiel (si il y a encore des vieux terminaux) ou logiciel sur les postes clients.
Alors voilà, je te laisse imaginer les budgets à débloquer sur de nombreuses années pour passer à des technologies plus modernes.
Les systèmes d'information des moyennes et grosses boites ont une inertie énorme. ça ne se change pas en quelques mois. Surtout qu'il faut avoir l'assurance que le nouveau système aura une certaine perenité (histoire qu'à la fin de la migration, ça ne soit pas déjà complètement obsolète), donc demande de belles études pour le futur cahier des charges.
[^] # Re: Trolls velus
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal bon anniversaire. Évalué à 7.
Tu aurais bossé dans ce genre de boite, tu n'aurais pas dit ça ;-)
j'ai bossé il y a une douzaine d'année dans une grosse boite d'assurances. Ce genre de boite ont des dizaines de milliers de programmes en COBOL qui tournent en permanence (il y en avait 150 000 et des poussières à l'époque dans la boite où je bossais, donc en gros des millions de lignes de codes), sur des gros systèmes qui bouffent du calcul à l'heure comme jamais le serveur de linuxfr n'en fera dans sa courte vie. Beaucoup de ces programmes sont critiques, où la moindre erreur de calcul peut être catastrophique.
Bref, migrer ce genre de système d'information, c'est très compliqué car c'est un énorme chantier. On ne peut pas se dire qu'on va migrer les programmes les uns après les autres, parce qu'en fait il y a beaucoup d'interdépendance. Donc quand il faut migrer, il faut migrer par paquet de centaines ou de milliers. Et réécrire ces programmes pour un autre environnement, ça ne se fait pas à coup de baguette magique. ça demande litteralement des années (quoi que, depuis quelques temps, on a des outils de transcodage très intéressant, voir https://linuxfr.org//2008/09/10/24462.html , qui peuvent raccourcir un peu ces délais). De plus il faut être sûr que les nouveaux programmes feront les mêmes calculs, donc écrire des milliers de tests, faire de longues procédures de recettes...
Il y a aussi le fait que ce n'est pas seulement un changement de langage de développement ou autre, mais aussi un changement de système complet : migrer d'une architecture gros systèmes vers une autre, ou vers un truc mixte (parce que quand même, se priver de la puissance de calcul d'un gros système, c'est dommage).
Si en plus on compte les heures de formation à assurer aux "informaticiens", qui pour certains, n'ont jamais vu autre chose que du COBOL (genre les employés qui sont là depuis 20 ans, qui ont été formé en interne au développement informatique etc..), et le cout de migration du materiel (si il y a encore des vieux terminaux) ou logiciel sur les postes clients.
Alors voilà, je te laisse imaginer les budgets à débloquer sur de nombreuses années pour passer à des technologies plus modernes.
Les systèmes d'information des moyennes et grosses boites ont une inertie énorme. ça ne se change pas en quelques mois. Surtout qu'il faut avoir l'assurance que le nouveau système aura une certaine perenité (histoire qu'à la fin de la migration, ça ne soit pas déjà complètement obsolète), donc demande de belles études pour le futur cahier des charges.