IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)

Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

Un employé du DOGE d'Elon Musk a enfreint la politique du Trésor en envoyant par courriel des données personnelles non chiffrées à l'administration Trump
D'après un dépôt auprès du tribunal

Le , par Anthony

12PARTAGES

6  1 
Un employé du DOGE d'Elon Musk a enfreint la politique du Trésor en envoyant par courriel des données personnelles non chiffrées à l'administration Trump, selon un dépôt auprès du tribunal

Un employé du groupe de travail d'Elon Musk chargé de réduire les coûts a enfreint la politique du département du Trésor en faisant circuler une feuille de calcul contenant des informations personnelles à d'autres personnes de l'administration Trump, selon le dépôt d'un dossier au tribunal par un fonctionnaire fédéral.

Ce développement est la dernière controverse en date concernant le département de l'efficacité gouvernementale (DOGE) d'Elon Musk. En février dernier, il a été révélé qu'un employé du DOGE, licencié pour des fuites de données, a eu accès à des systèmes sensibles du gouvernement américain. L'embauche d'Edward Coristine, un employé de 19 ans qui aurait des liens avec le groupe de cybercriminels « The Com », avait en effet suscité des inquiétudes concernant les protocoles de sécurité du DOGE.

Le membre du personnel impliqué dans ce nouveau rebondissement est Marko Elez, qui a démissionné du soi-disant Département de l'efficacité gouvernementale d'Elon Musk le mois dernier après avoir été lié à un compte de médias sociaux promouvant l'eugénisme et le racisme. Il a cependant été réembauché peu de temps après.

Le dépôt, effectué par le responsable de la sécurité du Bureau du service fiscal (Bureau of the Fiscal Service ou le Bureau), David Ambrose, indique que les fonctionnaires du Trésor ont effectué une analyse scientifique de l'ordinateur portable et du courrier électronique de Marko Elez, concluant qu'il « n'a pas fait d'altérations ou de changements dans les systèmes de paiement du Bureau ».

Toutefois, l'examen a révélé que Marko Elez avait envoyé par courrier électronique une feuille de calcul contenant « un nom (une personne ou une entité), un type de transaction et une somme d'argent » à deux fonctionnaires de l'Administration des services généraux des États-Unis, en violation des politiques du Bureau du service fiscal.


Selon David Ambrose, Marko Elez n'a pas envoyé la feuille de calcul par des moyens chiffrés et n'a pas « obtenu l'approbation préalable de la transmission », ce qui l'aurait obligé à décrire « ce qui sera envoyé et les mesures de protection que l'expéditeur mettra en œuvre pour protéger les informations ».

Comme les noms figurant dans la feuille de calcul envoyée par Marko Elez ne contenaient pas « d'identifiants spécifiques, tels que des numéros de sécurité sociale ou des dates de naissance », David Ambrose a déclaré que les noms figurant dans le document étaient soumis à un « risque faible ».

L'analyse judiciaire a été encouragée par une action en justice intentée par 19 procureurs généraux d'État qui cherchent à empêcher le DOGE d'accéder à des informations de paiement sensibles sur les contribuables américains, les employés du gouvernement et les entrepreneurs.

Dans un précédent dossier, le Trésor a affirmé que Marko Elez s'était vu accorder par erreur un accès en lecture et en écriture aux systèmes du ministère dans le cadre de ses fonctions antérieures au sein du DOGE, avant d'être réembauché. L'accès du groupe de travail aux systèmes du ministère est actuellement limité par une ordonnance restrictive temporaire, que l'administration Trump a demandé au tribunal de modifier pour permettre au DOGE d'accéder à davantage de données.

Dans un document séparé déposé le 14 mars, les États qui poursuivent le Trésor au sujet de l'accès du DOGE ont écrit que l'analyse scientifique de l'ordinateur et du compte de messagerie de Marko Elez « n'apaise en rien les inquiétudes exprimées par le tribunal dans son avis sur la nature précipitée et chaotique du processus d'intégration de l'équipe du DOGE du Trésor. [...] Au contraire, ces nouvelles déclarations confirment que les inquiétudes de la Cour étaient fondées. »

La récente controverse sur le traitement d'informations sensibles par le DOGE fait suite à des contestations juridiques antérieures. Le mois dernier, un juge fédéral a statué que le gouvernement américain avait violé la loi sur la protection de la vie privée en partageant des données personnelles avec le DOGE d'Elon Musk. Le juge a donc bloqué l'accès du DOGE aux informations sensibles du ministère de l'Éducation et du Bureau de gestion du personnel, estimant que la violation constituait un préjudice irréparable.

Source : Dépôt auprès du tribunal

Et vous ?

Quel est votre avis sur le sujet ?
Trouvez-vous que la démarche initiée par le Bureau du service fiscal justifiée et pertinente ?

Voir aussi :

Le DOGE d'Elon Musk supprime l'unité de conseil de l'équipe technologique fédérale, connue sous le nom de 18F, qui faisait le même travail que le DOGE avant que celle-ci ne soit créée

Le DOGE d'Elon Musk remplace les employés fédéraux licenciés par un chatbot d'IA et automatise les tâches, une approche controversée qui suscite des préoccupations en matière de sécurité
Vous avez lu gratuitement 508 articles depuis plus d'un an.
Soutenez le club developpez.com en souscrivant un abonnement pour que nous puissions continuer à vous proposer des publications.

Une erreur dans cette actualité ? Signalez-nous-la !

Avatar de TJ1985
Membre chevronné https://www.developpez.com
Le 05/04/2025 à 11:45
En fait, lorsqu'on parle d'application "COBOL", nous n'avons pas forcément la même image. Lorsque je travaillais dans cet environnement, sous VMS, une application COBOL c'était :

- Un compilateur et un langage normé.
- Un gestionnaire de fenêtres (mode caractères). Il y en avait trois chez DEC, mon favori étant DEC Forms, qui fut choisi.
- Un moniteur transactionnel, ACMS.
- Une base de données relationnelle, RdB.
- Un langage de scripts systèmes, DCL.

Ajoutons un dictionnaire centralisé qui marchait plus ou moins, un éditeur puissant (TPU puis LSE), la gestion des sources (MMS / CMS).

Les applications s'exécutaient sur un cluster VAX, puis AXP, etc, suivant l'évolution des technologies. Le cluster assurait la tolérance aux pannes et la répartition de charge.

Aujourd'hui, je ne sais pas si la notion de moniteur transactionnel existe toujours. Dans le cas contraire, ça veut dire qu'il faut développer une couche de colle entre les modules provenant de COBOL, simplement pour implanter la logique métier qui se cachait dans le moniteur.

Bien sûr, je n'ai l'expérience que d'un "gros" environnement. COBOL est un langage suffisamment complet pour avoir permis des développements complexes monolithiques, sans outils externes. Il emporte en fait tout ce qui était nécessaire à une application de gestion de l'époque (File Section, Screen Section, Report Section) et pouvait très bien travailler tout seul, j'en ai eu plusieurs preuves, constatées et commises.

Lorsque mon client a décidé de quitter C2IHB pour DEC, une guerre des chefs a eu lieu : L'ancien tenait pour une conversion des applications, le nouveau affirmait pouvoir tout réécrire en deux ans... Donc, après trente ans les derniers modules convertis ont finalement pu être débranchés !

Un point : 60 millions de lignes de code, pour du COBOL, ce n'est pas énorme. Un programme fait très facilement 1000 lignes pour dire bonjour. Un programme "utile" fait facilement 10'000 lignes. On arrive donc à 6'000 modules, ce qui n'est pas rien mais pas effrayant non plus.

Ceci pour dire que les évaluations données par Musk me semblent aussi fiables que ses prévisions de disponibilité de l'AutoPilot Tesla...

Quant à moi, j'ai lu Bill Gates, je lis Paul Allen, déçu par Lazarus je me mets à l'Assembleur, Na ! ;-D
5  0 
Avatar de Artemus24
Expert éminent sénior https://www.developpez.com
Le 02/04/2025 à 22:11
salut à tous.

Citation Envoyé par Der§en
Sans avoir recours à l’IA, on peux parfaitement réécrire du code cobol vers d’autres langages !
Ca, c'est la théorie, mais dans la pratique, tu vas rencontrer des problèmes pour convertir des nombres.

Je ne sais pas si tu connais la représentation des nombres décimales dits condensés (COMP-3) en COBOL. C'est spécifique à COBOL et ça n'existe pas dans le langage 'C/C++'. J'ai eu jadis un problème avec la lire italienne où les montants étaient proches du maximum des 18 digits de sa représentation interne et étaient intraduisibles en langage 'C/C++' car ce langage ne le permettait pas.

Pour avoir fait beaucoup de maintenance en COBOL, il existe des sous-programmes écrits en assembleur pour résoudre des problèmes de calculs comme les taux. Je peux t'assurer qu'il y a beaucoup de spécificités propre au cobol que l'on ne peut pas convertir aussi facilement qu'on veut le croire, sans créer des problèmes qui vont engendrer des effets de bords ou encore des bugs alors que l'existent a déjà été épprouvé depuis fort longtemps.

Et je ne parle même pas des bases de données (DB2 sous IBM) ou encore du transactionnel (CICS) couplé à l'internet pour rendre plus conviviaux les terminaux sous internet. Une vrai usine à gaz ! J'ai, par le passé, fait beaucoup de migration et ce n'est pas aussi simple qu'on veut le croire.

Citation Envoyé par Fagus
Au pire, est ce si problématique de maintenir le code ?
Oui, car la maintenance coute très très chers aux entreprises et je ne parle même pas du manque de développeurs formés au COBOL, ni du métier du client. Remettre en cause un système informatique qui fonctionne parfaitement ne peut pas se faire en six mois alors qu'il a fallu plusieurs décénies pour en arriver là.

Citation Envoyé par Fagus
Les dév ça se forme,
Oui, en théorie, mais qui veut encore faire du COBOL aujourd'hui ? Peut-être des retraités car ils savent encore faire, et que la paye est intéressante. Mais un petit jeune ne sera pas intéressé à developper dans une technique de programmation qu'il ne connnait pas et ne veut pas apprendre. De loin, il préfère le WEB car il a été biberonné dès sa plus tendre enfance. Je rappelle qu'il n'existe pas de framework en COBOL où vous appelez la fonction qui va bien. Si vous avez besoin de quelque chose, vous devez la développer par vous-même. Et ces techniques ne sont plus du tout enseignés à l'école, ni d'ailleurs le COBOL.

Citation Envoyé par Fagus
et c'est sans doute préférable de manipuler des grandes quantités de calculs en cobol que dans la plupart des langages non ? surtout si on a besoin d'avoir des arrondis obéissant à des règles comptables plutôt que sur une accumulation d'imprécision du calcul flottant binaire.
Le flottant est destiné à des calculs scientifiques et non comptables où l'on a besoin d'avoir une réprésentation exacte et non approximative. Il y a des règles comptables, fiscales, financières sur les arrondis que l'on peut faire que si l'on maitrise la représentation des nombres en mémoire, ce que la plupart des langages modernes ne font plus. J'entends par là que si l'on a réellement besoin de 18 digits, on ne peut pas se permettre d'en perdre pour des problèmes d'arrondis.

Citation Envoyé par Prox_13
Et être capable de transcoder des monuments d'avant guerre en COBOL vers un langage actuel en préservant les règles de gestion et la performance du code, c'est une tâche aussi fastidieuse que complexe, qui requiert autant d'expérience que de rigueur.
Pourquoi d'avant guerre ? Le COBOL a été créé en 1959 et le premier COBOL que j'ai connu date de la version "68". Depuis, il y a eu beaucoup de progrès fait dans ce langage.

Les mainframes comme IBM fonctionnent pour des langages comme COBOL et ASSEMBLEUR IBM 370 et non sur du 'C/C++' dont les compilateurs ne doivent même pas exister sur ces machines. Il y a aussi la performance en terme de temps d'exécution que l'on ne retrouve sur des mini-ordinateurs qui sont trop lents, ni des problèmes de sécurités comme "RACF" sous IBM.

Citation Envoyé par Def44
Si l'être humain peut y arriver, aucun doute que l'IA le fera plus efficacement, et très rapidement.
Certainement pas car c'est essentiellement un problème non pas de conversion mais de faisabilité.
Il y a des astuces utilisés en COBOL qui nécessitent de repenser le code pour l'utiliser dans un nouveau langage. Il faudrait aussi comprendre ces astuces, ainsi que la façon de programmer dans les années 60. Bon courage à ceux qui vont mettre leur nez dans ce type de code.

Citation Envoyé par Jepamo
Nous ne sommes plus nombreux à connaitre le Cobol.
Il n'y a rien de complique à programmer dans ce langage mais faudrait aussi connaitre les astuces utilisées qui sont légions dans le domaine bancaire et de la finance. Je connais ce langage car je l'ai pratiqué pour des grands comptes en banque et en assurance et je peux assurer que le maitriser est autre chose que du 'C/C++'.

Citation Envoyé par Jepamo
S'ils partent dans cette optique, ils vont subir une grosse désillusion.
Il suffit de ce rendre compte des problèmes rencontrés avec "Louvois", le système informatique de l'armée française pour la paye des militaires. Ou encore celui utilisé pour le RSA où il y a fréquemment des erreurs ou des retards dans les paiements.

J'ai l'impression que ce DOGE va détruire les Etats-Unis sous le prétexte de faire des économies.

@+
5  1 
Avatar de Guesset
Expert confirmé https://www.developpez.com
Le 11/04/2025 à 23:04
Bonjour,

La migration du COBOL vers un autre langage sera aussi difficile pour des questions d'âge.
Les vieilles applications accumulent du code mort. Par exemple, une nouvelle règle s'impose, alors on développe un module pour la prendre en charge, mais on garde l'ancienne règle active pour traiter les dossiers en cours. Normalement, au bout d'un certain temps l'ancienne règle devrait être retirée, mais c'est rarement (jamais ?) fait. Et des scories s'accumulent.
Alors, faire une migration permettrait d'avoir, non pas une nouvelle application, mais une vieille application avec des habits neufs.

En outre, je suis toujours fasciné par notre aptitude à croire à la magie. Aujourd'hui cela s'appelle IA. Tous les outils ont leur intérêt et leur limitations.
L'IA a besoin de modèles construits sur la base de (très) nombreux exemples.
Mais des exemples de migrations COBOL vers C++ ou n'importe quoi, il n'y en pratiquement pas (même le simple accès aux sources COBOL des grosses applications est très protégé).
Donc pas de baguette magique. Et cela malgré la simplification outrancière que je fais en réduisant le problème à un portage entres langages alors que ce serait une migration de tout un écosystème.

Je pense que la solution passera par une duplication croisées des données dans une base actuelle. Puis de commencer des développements par modules autour de cette base. D'abord des fonctionnalités existantes pour vérifier la stabilité comportementale puis, peu à peu, sur de nouveaux modules. Avec un peu de chance, quand la réécriture sera complète, le langage cible sera lui aussi obsolète

Salutations
4  0 
Avatar de TJ1985
Membre chevronné https://www.developpez.com
Le 02/04/2025 à 22:12
Mon premier gros mandat a été l'écriture de programmes de traduction COBOL-COBOL pour passer d'un environnent Honeywell Bull à VAX VMS. Il s'agissait aussi de passer d'une base de données réseau à une base relationnelle et donc d'adapter les requêtes en conséquence.
Nous bénéficiions de deux chefs de projets hyper-compétents, connaissant en détail les aspects métiers des applications à porter.
Malgré tout, la migration complète a pris deux ans à une équipe de sept personnes qui n'ont pas chômé.
En parallèle, une vaste équipe de jeunes ingénieurs sans connaissance métier était sensée réécrire l'ensemble des applications, en C++, Delphi, VB, Java en deux ou trois ans.
Total : après quasi-trente ans il a été possible de débrancher les systems VMS, longtemps donc après que DEC eut disparu.
Le choix le pire était encore Java, qui trimbale avec lui un énorme sac de contraintes d'organisation et une terrible dette de performances.
Le système originel tournait avec une puissance de l'ordre d'un Raspberry Pi, aujourd'hui la salle serveurs compte plus de 2000 machines...
Les prestations ont un peu augmenté, dans un domaine assez statique, la banque. Jamais pour justifier une telle inflation.
Donc, bon courage aux bénéficiaires des prestations du système actuel. Et en plus, il y a des bouts d'assembleur...
4  1 
Avatar de calvaire
Expert éminent https://www.developpez.com
Le 20/03/2025 à 10:51
Citation Envoyé par _toma_ Voir le message
Jusqu'à maintenant j'ai réussi à ne pas me suicider mais, putain, qu'est-ce que notre époque est déprimante !
Pourtant le champs des possibles que nous offre ce monde est fantastique.
On a jamais eu autant d'opportunités dans sa vie que dans ce monde moderne.
Voyager n'importe ou, étudier et exercer n'importe quels métiers, se reconvertir, travailler n'importe ou dans le monde...

Ce monde est au contraire très excitant. Tu devrais juste sortir de chez toi et aller voir ailleurs, jusqu’à trouver un lieu et mode de vie fait pour toi.
Je connais des collègues déprimé a paris, monter leur propre boite et/ou partis au canada, en finlande, en suisse, certains retourner à la campagne devenir fermier... d'autres monter un business en ligne et partir vivre sur les plages de thailande a se taper des putes et fumer du cannabis tous les jours.

Prends l'avion, va en vacances quelques semaine en ouzbekistan vivre avec une tribut nomade, ca te changera les idées.
3  1 
Avatar de der§en
Membre expérimenté https://www.developpez.com
Le 30/03/2025 à 0:27
Sans avoir recours à l’IA, on peux parfaitement réécrire du code cobol vers d’autres langages !

Dans les années 90, à la bourse de paris, on avait développé un convertisseur qui prenait le code cobol issus des mainframes IBM, pour le convertir en langage C pour les VAX/VMS, cela a permis de migrer des millions de lignes de code !
7  5 
Avatar de calvaire
Expert éminent https://www.developpez.com
Le 31/03/2025 à 8:18
Citation Envoyé par Fagus Voir le message
Mais est-ce que c'est si intéressant que ça de convertir les bases de code de cobol, alors que ça marche et c'est performant, sachant que la conversion a un coût et des risques de régressions (il y a eu plusieurs histoires ici de migration ratée vers java avec des pertes de performance).
Alors qu'il existe des compilateurs comme gnuCOBOL qui permettent d'exécuter le code sur PC ?

Au pire, est ce si problématique de maintenir le code ? En regardant sur wikipedia, en cobol 2014 le langage est modernisé avec des types modernes et l'orientation objet. (il y a même un cobol 2023).

Les dév ça se forme, et c'est sans doute préférable de manipuler des grandes quantités de calculs en cobol que dans la plupart des langages non ? surtout si on a besoin d'avoir des arrondis obéissant à des règles comptables plutôt que sur une accumulation d'imprécision du calcul flottant binaire.

Quoique, en python, il y a le module decimal pour ça, et je viens de voir qu'il peut être utilisé en c et c++.
c'est tous le probleme justement.
Il faut trouver des dev pour faire du cobol, il y'en a peu et coutent cher.

Pour les dev c'est loin d’être une bonne affaire aussi, ok avec cobol ils peuvent trouver un taff mieux pays, mais cobol c'est rare et donc ils seront prisonnier de leurs boite. Un dev cobol va difficilement pouvoir retrouver un taff ailleurs, surtout en cas de layoff il sera dans la merde.
Pour un dev il vaut mieux se former dans des technos d'avenir, sa lui donnera un taff mieux payé et être attractif sur le marché du travail.

Ou alors négocier avec sa boite d’être dev cobol à mi temps ET aussi de faire autre chose de plus vendeur sur le cv, mais pour la boite ca coute encore plus cher ce deal.
Au final la migration apparait comme une bonne solution pour l'avenir de la boite. Car un salarié sa reste pas longtemps dans une boite, 2-5ans. Trouver des devs cobols tous les 2-3 ans, c'est chaud.

Perso j'ai toujours travaillé sur des technos d'avenir, j'ai toujours choisis mes postes en fonction de ca (en plus du salaire). Ca m'a toujours garantie des portes ouvertes auprès des entreprises et des salaires attractifs.
J'ai toujours poussé en interne a utiliser et travailler sur les technos les plus vendeurs sur le cv. Il faut toujours préparer son prochain job, même si il arrivera jamais ou dans 10ans, ou... dans 1 semaine par surprise car la boite a décidé de te virer.

en 2025, Cobol reste une bonne compétence pour le salaire si on habite dans un gros bassin d'emploi comme paris, mais ne surtout pas s'enfermer que la dedans et développer d'autres expertises.
7  5 
Avatar de christiandocker
Futur Membre du Club https://www.developpez.com
Le 03/04/2025 à 11:58
Musk se croit une fois encore au dessus du lot ... mais il ne sait pas que des migrations existent déjà qu'il serait bon d'utiliser.

C'est ancien, ça date d'environ 30 années ! Mais cela a déjà été réalisé à grande échelle.

Se rapprocher des SSII française pour éviter d'inventer le fil à couper le beurre !
2  0 
Avatar de Prox_13
Membre éprouvé https://www.developpez.com
Le 11/04/2025 à 17:03
Citation Envoyé par Artemus24 Voir le message
Pourquoi d'avant guerre ? Le COBOL a été créé en 1959 et le premier COBOL que j'ai connu date de la version "68". Depuis, il y a eu beaucoup de progrès fait dans ce langage.
Je ne code pas des monuments d'avant-guerre au marteau-burin, il s'agissait là d'un abus de langage, à l'évidence puisque le langage a été créé en 1959.
Après c'est vrai qu'en un demi-siècle d'existence, le langage a pu évoluer, c'est important de le souligner.

Citation Envoyé par Artemus24 Voir le message
Les mainframes comme IBM fonctionnent pour des langages comme COBOL et ASSEMBLEUR IBM 370 et non sur du 'C/C++' dont les compilateurs ne doivent même pas exister sur ces machines. Il y a aussi la performance en terme de temps d'exécution que l'on ne retrouve sur des mini-ordinateurs qui sont trop lents, ni des problèmes de sécurités comme "RACF" sous IBM.
En effet, les quelques programmes C++ dont nous disposons sont exécutés sur des machines Windows et non sous nos VMS, même si j'ai du mal a comprendre où tu voulais en venir.
Et oui, globalement nous avons fait le même constat:
- Les développeurs juniors ne sont pas intéressés par le langage, mis à part pour toucher une paie commode.
- Les règles métiers accumulées depuis 40 ans sont difficilement traduisibles, surtout quand a l'époque la Qualité n'imposait pas une documentation rigoureuse.
- Les performances du code COBOL sont impressionnantes comparées aux alternatives proposées.

Mais je suis curieux de savoir quelle pertinence tu as vu sur ce point d'avoir été créé avant ou après les guerres ? Tu as l'air d'avoir quelque chose a dire sur les langages d'avant guerre et ça m'intéresserait de savoir.
2  0 
Avatar de Artemus24
Expert éminent sénior https://www.developpez.com
Le 11/04/2025 à 18:29
Citation Envoyé par Prox_13
En effet, les quelques programmes C++ dont nous disposons sont exécutés sur des machines Windows et non sous nos VMS, même si j'ai du mal a comprendre où tu voulais en venir.
Remplacer les gros ordinateur IBM VM/CMS JCL TSO ISP qui sont très performants, par des mini ordinateurs en migrant le COBOL vers du 'C/C++', risque d'être problématique du point de vue sécurité mais aussi en performance. C'est selon moi, peu réaliste.

Citation Envoyé par Prox_13
- Les règles métiers accumulées depuis 40 ans sont difficilement traduisibles, surtout quand a l'époque la Qualité n'imposait pas une documentation rigoureuse.
Ce problème existe aussi dans les banques où l'on ne sait plus trop comment fonctionner des pans entiers de codes COBOL car il n'y a pas ou plus de documentations pour expliquer ce que ça fait réellement. Sans compter, le nombre considérable d'intervenant qui ont modifié le code, pas toujours d'une bonne manière. Bonjour pour faire une retroingérierie qui sera extrêment complexe, sans rien apporter de bénéfique au final.

[quote="Prox_13"]-Les performances du code COBOL sont impressionnantes comparées aux alternatives proposées.
Entièrement d'accord. Donc pourquoi changer quelque chose qui fonctionne parfaitement ?

Citation Envoyé par Prox_13
Mais je suis curieux de savoir quelle pertinence tu as vu sur ce point d'avoir été créé avant ou après les guerres ?
J'ai réagit sur le fait que le COBOL n'est pas apparu avant guerre mais en 1959.

Citation Envoyé par Prox_13
Tu as l'air d'avoir quelque chose a dire sur les langages d'avant guerre et ça m'intéresserait de savoir.
J'ai connu la fin des perforatrice et des cartes perforées pour écrire un programme. Le seul point positif est qu'à l'époque, on savait programmer car la place manquait et il fallait jongler dans des techniques qui ont totalement disparu aujourd'hui pour gérer la mémoire. C'est comparable entre la règle à calcule et les approximations que l'on faisaient à l'époque et l'avènement aujourd'hui des calculatrices et des ordinateurs qui nous ont simplifié grandement la tâche. Mais croire que la tâche sera plus simple de remplacer le COBOL est selon moi une erreur.
2  0