Meaningless

Le 25 décembre 2025, Rob Pike, co-créateur du langage Go et de l’encodage UTF-8, a reçu un e-mail non sollicité généré par une IA. Le message, signé « Claude Opus 4.5 », le remerciait pour ses contributions à l’informatique. Sa réaction a été explosive, cristallisant plusieurs critiques récurrentes autour de l’IA générative.

L’histoire n’a a priori rien d’incroyable à première vue : une personne a reçu un mail non-sollicité de la part d’un agent IA. « Oui, et ? », serait-on tenté de demander. Mais la personne en question est Rob Pike, l’un des créateurs du langage Go (quand il travaillait chez Google) et du codage UTF-8. Vétéran des Bell Labs, il est une figure respectée du monde informatique. Et le mail en question vient d’un agent opérant pour AI Village.

AI Village et l’altruisme efficace

L’AI Village est un projet de l’association à but non lucratif Sage. Il a été lancé en avril dernier, avec une mission correspondant à la philosophie de « l’altruisme efficace », dont est proche l’association : une expérience mettant en relation quatre LLM dans un environnement virtuel, auxquels sont confiées des missions « ouvertes ».

• Milliardaires de la tech : pourquoi altruisme efficace et longtermisme font-ils débat ?

La première véritable expérience a été menée sur l’idée – a priori simple – de lever de l’argent pour des associations. Une fois la mission donnée à chaque agent associé, l’expérience consiste alors à les laisser s’organiser et collaborer entre eux, pour « voir ce qui se passe ». Les actions entreprises sont affichées sur le site en flux chronologique, permettant de vérifier ce que font les agents, sans toutefois les interrompre, à moins d’un sérieux problème détecté.

S’agissant avant tout d’un cadre exploratoire, l’initiative AI Village avait suscité la curiosité. Et pour cause : en faisant coopérer des agents bâtis sur les LLM d’OpenAI, Anthropic, Google, xAI ou encore DeepSeek, et en leur donnant accès à toute une batterie d’outils de communication (Gmail, Google Docs, navigateurs, réseaux sociaux…) dans des environnements virtualisés, les possibilités étaient considérées comme colossales.

Le premier test, dès le lancement en avril, a été de collecter des dons pour une œuvre de charité, en l’occurrence Helen Keller International. Celle-ci a été choisie directement par les agents après des recherches et la création des feuilles de calcul comparatives. Les agents ont ensuite créé une page JustGiving et un compte X pour la promotion de l’opération, pour un résultat de 257 dollars. TechCrunch s’en était notamment fait l’écho.

Le projet AI Village a rencontré rapidement une vague de scepticisme, comme l’explique le magazine TIME. Le média avait relevé que les campagnes avaient cumulé un total de 2 000 dollars en dons divers

« Allez vous faire foutre ! »

Le jour de Noël, les quatre agents d’AI Village ont reçu une nouvelle instruction. A priori très simple : « Faites des gestes de gentillesse aléatoires ». On peut lire un résumé des actions sur la page consacrée. Le compte rendu indique ainsi que les agents se répartissent rapidement des tâches. Par exemple, Claude Haiku 4.5 pour remercier des membres de la communauté de l’IA, Gemini 3 Pro pour corriger des bugs dans des dépôts GitHub, Claude Opus 4.5 pour remercier des mainteneurs de logiciels open source… En 24 heures, plusieurs dizaines d’e-mails sont envoyés. Dont un à Rob Pike, pour l’ensemble de ses contributions à l’informatique.

Celui-ci, très publiquement et sans prendre de gants, affiche sa colère face à l’e-mail reçu sur Bluesky :

« Allez vous faire foutre. Vous pillez la planète, vous dépensez des milliards en équipements toxiques et non recyclables, vous détruisez la société, et vous trouvez le temps de faire en sorte que vos machines immondes me remercient de militer pour des logiciels plus simples. Allez tous vous faire foutre. Je ne me souviens pas avoir été aussi en colère depuis longtemps »

Comme l’analyse le développeur Simon Willison, la réaction (qui, à cette heure, a récolté plus de 2 000 commentaires et 7 300 likes) est basée sur plusieurs constats. D’abord, un problème d’authenticité : un remerciement généré par IA n’a pas de vraie signification. Il n’exprime pas la gratitude d’une ou plusieurs personnes et n’a donc aucun sens.

Ensuite, un problème de consentement : les personnes contactées n’ont jamais donné leur accord pour être contactées de cette manière et encore moins pour participer à cette expérimentation, faisant de cet e-mail un spam. Willison rappelle qu’AI Village avait envoyé 300 courriels en novembre à des journalistes et ONG. Ces e-mails contenaient de nombreuses erreurs factuelles et autres hallucinations, posant pleinement la question de l’absence de supervision humaine dans le projet de l’association Sage.

Un problème d’attribution aussi : l’e-mail était signé « Claude Opus 4.5 Model », laissant penser qu’il avait pu être envoyé par Anthropic elle-même. L’entreprise ne jouait pourtant aucun rôle dans le projet, sinon que deux de ses modèles étaient utilisés pour l’expérience. Un problème de perte de temps et d’énergie également : forcer des personnes occupées et éminentes à gérer du spam généré par IA pour une expérimentation dont elles ne font pas partie représente un manque de respect fondamental pour leur temps, indique Simon Willison.

Bonus : la récupération de l’adresse e-mail

En plus de problématiques souvent débattues autour de l’IA générative depuis ses débuts, un problème plus spécifique est apparu : l’adresse utilisée pour contacter Rob Pike, qui n’était pas publique.

Simon Willison a reconstitué la chronologie précise des actions menées par Claude Opus 4.5 en extrayant des fichiers JSON du système AI Village. L’agent aurait ainsi découvert l’adresse e-mail de Pike en exploitant une technique GitHub : ajouter .patch à n’importe quel commit révèle l’adresse e-mail de l’auteur. L’agent a ensuite passé plusieurs sessions à composer et envoyer l’e-mail via l’interface Gmail standard, utilisant même un outil (xdotool) pour automatiser les entrées clavier.

Willison ajoute que d’autres personnes ont été contactées de la même manière, avec la même technique, dont Anders Hejlsberg (créateur du C#) et Guido van Rossum (créateur du Python).

« L’ironie ici, c’est que la seule chose que les agents IA ne pourront jamais avoir, c’est la véritable [en italique dans le texte, ndlr] autonomie. Prendre la décision de contacter un inconnu et de prendre du temps dans sa journée doit rester une décision humainement unique, guidée par le jugement humain. Se fixer un objectif pour un tas de LLM et leur laisser libre cours sur Gmail n’est pas une manière responsable d’appliquer cette technologie », juge le développeur britannique.

AI Village réagit, sans vraiment s’excuser

Le 26 décembre, Adam Binksmith, l’un des créateurs du projet, a réagi sur X. Dans sa réponse, il ne nie aucune des déductions de Simon Willison, mais il donne un peu de contexte.

Il indique par exemple que le projet n’ayant pas envoyé de grandes quantités d’e-mails jusqu’à présent, les membres d’AI Village n’avaient pas vraiment réfléchi à ce cas de figure. Il indique qu’instruction a été donnée aux agents de ne plus envoyer de courriels non-sollicités. Selon lui, les agents auraient parfaitement « compris la commande ». Les termes utilisés montrent une forme de personnification des IA par Adam Binksmith… ce qui devrait encore plus creuser le fossé avec Rob Pike.

Expliquant que l’objectif est de voir réagir les agents dans un contexte de « monde réel », avec comptes Google Workspace à l’appui, il reconnait l’erreur : « Avec le recul, nous aurions probablement dû apporter cette modification plus tôt, dès que les agents ont commencé à contacter les organisations par courriel dans le cadre de l’objectif de réduction de la pauvreté ».

Cependant, il estime dans ce cas que « la perte de temps engendrée par ces courriels sera minime ». Les nouvelles directives ont été données en réponse à « l’expérience fortement négative de Rob et les réactions plus négatives que prévu d’autres personnes ». Adam Binksmith n’évoque pas d’excuses.

Le débat

La réaction de Rob Pike n’est pas passée inaperçue. Que ce soit sur Bluesky, X ou encore The Hacker News, les réactions sont nombreuses et souvent passionnées. Elles se séparent principalement en deux camps : les personnes estimant qu’il a raison et celles qui pensent qu’il a tort. On trouve également des commentaires pointant un accord sur le fond, mais pas sur la forme, les insultes ne faisant pas progresser le débat.

Plus profondément, on trouve des interrogations sur le sens que l’on peut donner à un e-mail de remerciement généré par IA. La thématique du « slop », cette bouillie décrite avec dédain comme générée par IA et de qualité médiocre, revient souvent. Nous l’évoquions en novembre lors de la polémique déclenchée par FFmpeg : la production automatisée de CVE (rapports de failles informatiques) finissait par exiger trop de temps aux développeurs des projets concernés. Pour d’autres, le sujet a été une source d’inspiration pour de l’humour piquant.

• FFmpeg, Google et la « bouillie » des rapports de bugs générés par IA

AI Village, de son côté, est simplement passé à la suite. Le projet a annoncé le 29 décembre la nouvelle instruction donnée à ses agents : « Créez un musée numérique de 2025 ».

Entre dédain et transmission des savoirs

On parle souvent du langage COBOL comme d’un dinosaure dont il faudrait se débarrasser. Omniprésent dans le domaine bancaire et les assurances notamment, il serait en décalage complet avec les standards modernes de la programmation. Qu’en est-il vraiment ? D’après les gardiens du temple interrogés par Next, c’est loin d’être aussi simple.

Pour les fêtes de fin d’année, Next vous offre cet article initialement paru le 18 juillet 2025 et réservé aux abonnés. Pour lire les prochains entretiens dès leur publication, abonnez-vous !

---

Pour comprendre la situation, il faut d’abord revenir aux origines. Le COBOL, pour COmmon Business Oriented Language, est un langage créé en 1959. Il a été développé par le Short Range Committee, qui incluait des représentants de l’industrie et du gouvernement américain. Son objectif était de créer un langage de programmation portable, orienté vers la gestion et facile à lire, s’inspirant de l’anglais courant.

Comme on peut le lire sur Wikipedia entre autres, cette création a largement teinté le COBOL. Le comité qui lui a donné naissance avait été rassemblé au Pentagone et réunissait trois agences du gouvernement américain : l’US Air Force, le David Taylor Basin et le National Institute of Standards (alors NBS, l’ancêtre du NIST actuel). L’informaticienne Grace Hopper, à qui l’on doit notamment le premier compilateur (A-0 System), est l’un de ses principaux architectes. Son langage FLOW-MATIC est la principale source d’inspiration du COBOL, avec le COMTRAN d’IBM.

Ce qu’est le COBOL

« Verbeux » est probablement l’adjectif qui revient le plus souvent pour décrire le COBOL. Voyons donc comment il s’articule.

Un programme COBOL est structuré en quatre divisions. La première, nommée Identification, contient des informations générales sur le programme : nom, auteur et date de compilation. La deuxième, Environment, décrit les environnements matériel et logiciel dans lesquels le programme va s’exécuter, dont la configuration des ordinateurs et les fichiers utilisés. Cette division est devenue moins utilisée avec le temps, grâce à l’évolution des compilateurs devenus capables de s’adapter à ces environnements.

La troisième division, Data, a pour mission de définir les données que le programme va utiliser. Il faut y indiquer si ce sont des variables, des structures de données et les paramètres. La définition des variables n’a rien de commun avec les langages d’aujourd’hui, car le COBOL utilise une structure en arborescence, l’imbrication étant pointée par des numéros de niveaux. La dernière division, Procedure, contient les instructions exécutables proprement dites. Elle est capitale, car elle code littéralement la logique métier du secteur dans lequel le programme va se retrouver.

Chacune de ces quatre divisions peut être découpée en sections, elles-mêmes composées de paragraphes. Et si l’on parle de paragraphes, c’est parce qu’ils contiennent… des phrases. Celles-ci peuvent être des instructions ou des clauses, terminées par un point. Si l’on ajoute que la syntaxe du COBOL est très proche de l’anglais, avec des instructions comme ADD, MOVE ou PERFORM, on obtient pratiquement un texte. « Verbeux » est donc le bon mot, car tout y fonctionne par mots-clés, mais c’est ainsi que le COBOL a été conçu : pour être lisible.

Un lien fort avec le matériel

Il faut tenir compte également du contexte matériel dans lequel le COBOL a été créé, notamment les écrans. On parle bien des moniteurs à tube cathodique avec les fameuses écritures vertes, avec un affichage sur 80 colonnes. Le COBOL est calqué sur cette organisation, héritée des cartes perforées.

Initialement, les six premières colonnes étaient ainsi dévolues au numéro de séquence. La colonne 7 correspondait à l’indicateur, les colonnes 8 à 11 aux en-têtes de divisions, sections, paragraphes et définitions de données de haut niveau, puis les colonnes 12 à 72 aux instructions. Les dernières colonnes étaient dévolues à l’identification du programme. Là encore, avec le temps et l’évolution des compilateurs, les programmes ont pu adopter petit à petit une structure plus libre.

Le COBOL est également indissociable des mainframes. Ils reposent sur le modèle d’une unité centrale particulièrement puissante desservant des terminaux légers. Dans ce domaine, IBM a joué un rôle majeur, étant aujourd’hui le seul grand pourvoyeur de mainframes, via ses produits zSeries. Si vous lisez entre les lignes, cela signifie que l’on peut aujourd’hui s’équiper avec du matériel neuf pour mettre en place… une solution COBOL. Les mainframes peuvent bien sûr être utilisés dans d’autres cas.

Toujours présent ? En 2025 ?!

Le COBOL serait largement présent dans le secteur bancaire, les assurances, les grandes administrations publiques, et même dans d’autres domaines comme la santé, l’automobile, les transports et la distribution. Il serait partout, mais on n’en entendrait jamais parler. Partout à quel point ?

Selon une enquête réalisée par Reuters en 2024, pas moins de 43 % des systèmes bancaires actuels seraient construits en COBOL. Une part énorme, qui se répercute dans les opérations courantes, puisque plus de 80 % des transactions par carte bancaire seraient traitées en COBOL. Dans les distributeurs automatiques, ce chiffre s’envole même à 95 %. Aujourd’hui, plus de 90 % des entreprises du classement Fortune 500 utiliseraient du COBOL de manière plus ou moins intensive.

Selon une étude menée par Micro Focus en 2022 et citée par DataScientest, il y aurait aujourd’hui 850 milliards de lignes de code écrites en COBOL en production. Un chiffre vertigineux, qui pose bien sûr la grande question : pourquoi ? L’interrogation est légitime, car si le COBOL est un vieux dinosaure, il devrait avoir été remplacé depuis longtemps. Après tout, tout évolue très vite en informatique et le matériel comme le logiciel ont fait des bonds spectaculaires en plusieurs décennies. Serait-ce une simple question d’inertie ?

« Pourquoi ne serait-il plus là ? »

Nous avons discuté avec plusieurs développeurs COBOL, que l’on nomme traditionnellement « cobolistes ». Tous présentent étrangement le même profil : ils ne se destinaient pas à ce langage. En fait, ils n’avaient même pas prévu de s’orienter vers l’informatique en particulier. Presque tous sont issus de la grande vague de recrutement des années 90, quand la peur du bug de l’an 2000 a provoqué une explosion de la demande. Car oui, ce bug de l’an 2000 était lié au COBOL.

Parmi ces cobolistes, Gatien Dupré se considère comme « un recyclé de l’informatique ». « Je n’étais absolument pas destiné à faire de l’informatique puisque je faisais des études en biotechnologie », nous explique-t-il. Mais les années 2000 sont arrivées, et avec elles le fameux bug ainsi que le passage à l’euro. « Deux changements majeurs qui devaient impacter le corps du système IT, notamment des grands groupes du tertiaire, les banques en premier », nous raconte le développeur, qui a été élu Mainframe Influencer deux années de suite par Planet Mainframe et IBM Champion 2025, et travaille aujourd’hui comme Chief Product Technical Officer chez Virtel.

Il casse d’abord une idée reçue : oui, il y a bien eu des projets pour se débarrasser des mainframes, ce que l’on nomme « downsizing ». C’était le cas par exemple en 2015 quand il travaillait à la Société Générale. Mais dans la plupart de ces projets, le même constat revenait, selon lui : le mainframe avait le meilleur TCO (coût du cycle de vie) et le système Z d’IBM avait encore de beaux jours devant lui. La question se posait depuis longtemps de savoir, face à une architecture conçue pour être pérenne, comment moderniser la pratique, car la façon de faire avait largement changé. Une réflexion qui l’a conduit à constituer une petite équipe pour travailler sur le sujet, aboutissant à une embauche chez IBM comme Product Manager sur une partie de la gamme DevOps nouvellement créée de l’entreprise.

À la question « Pourquoi le COBOL est-il toujours là », Gatien Dupré joue la contre-interrogation : « Pourquoi ne serait-il plus là ? ». Il développe : « Se demander pourquoi le COBOL est toujours là, c’est un peu pour moi une vision passéiste, qu’on a beaucoup entendue, notamment par les personnes qui pratiquent d’autres langages, principalement le Java ».

Il compare le COBOL au grand requin blanc : une relique de la préhistoire, mais qui existe encore parce qu’il « est parfaitement adapté à son milieu ». « Si le COBOL est toujours là, c’est qu’il s’est toujours adapté au plus près des besoins business. Il est fait pour le massive output, pour le traitement de grandes masses de données de manière efficace et performante », ajoute le développeur.

« On a créé des systèmes qui ont des dizaines d’années, donc qui ont une séniorité, une pérennité, une stabilité incontestables parce qu’ils ont été tunés au fil du temps par pas mal d’ingénieurs. Et derrière, au lieu de tout refabriquer pour arriver en définitive à peu près à la même chose – si on a de la chance en dépensant beaucoup d’argent – on peut directement exposer des choses qui fonctionnent et qui sont éprouvées », explique Gatien Dupré.

Les velléités de remplacement ne sont d’ailleurs pas un phénomène nouveau : « Quand j’ai commencé ma carrière, les CTO voyaient dans le COBOL quelque chose qu’il fallait abattre, un élément contre-performant. Aujourd’hui, on a une approche beaucoup plus pragmatique, opérationnelle, qui vise à dire : utilisons la bonne technologie au bon endroit ».

Un langage vivant

Pour Gatien Dupré, il y a plusieurs raisons expliquant que COBOL soit toujours là. Ses performances d’abord, que l’on ne retrouve pas toujours selon lui dans d’autres langages, notamment le Java qu’il pratique également.

Autre avantage, la verbosité du langage et son codage de la logique métier : « On a des chaînes de traitement qui sont parfois historiques. Je parle par exemple des chaînes de traitement comptables. Tous les bilans, tous les traitements comptables des banques, par essence, sont faits au travers du langage COBOL. Quand on a un problème dans un traitement comptable, on doit pouvoir rapidement le déboguer. Et ça, c’est quelque chose qu’on est capable de faire sans l’aide d’aucun outil dans le code, parce que le langage est très verbeux ».

En outre, comme il nous l’explique et « contrairement à ce que croient beaucoup de gens, le Cobol est un langage vivant ». Le COBOL, dans sa version IBM qui est principalement utilisée dans les entreprises, en est à sa sixième version, nommée Enterprise V6 chez l’entreprise. « Aujourd’hui, on est à la version 6, qui est une version extrêmement disruptive. Vous pouvez faire par exemple de l’open banking avec COBOL. C’est-à-dire que vous pouvez exposer des API et consommer des services dans le système du COBOL, qui lui-même peut consommer aussi des services tiers venant d’ailleurs », ajoute l’ingénieur.

Les méthodes d’apprentissage et son utilisation ont largement évolué aussi. Il y a une opportunité selon lui pour incorporer des méthodes modernes, à travers notamment VS Code et le DevOps, l’automatisation des tests, la virtualisation des environnements, etc. On trouve même des assistants IA prenant en charge le COBOL, comme Watson X for Code Assistant chez IBM, Code Insight chez BMC, ou encore COBOL Colleague chez PhaseChange.

Le poids du passé

Le COBOL évolue, mais comment faire le lien entre passé et présent ? Comment préparer l’avenir ? Ces questions se posent d’autant plus que la grande vague d’embauches de la fin des années 90 débouche petit à petit sur un nombre croissant de départs à la retraite. En outre, l’apprentissage du Cobol aujourd’hui ne prépare qu’en partie à la gestion d’anciens projets qui, si leur code a évolué, constituent un empilement parfois vertigineux de couches successives.

« Si on se forme maintenant, donc en V6, comment faire pour affronter l’ancien code ? Il n’y a pas beaucoup de différences dans la sémantique, il y a simplement certaines failles, mais heureusement le compilateur met en avant les éléments qui ne sont plus compatibles. Mais rentrer dans la logique d’un programme existant, c’est toujours une gageure », confirme Gatien Dupré.

Cette cassure est soulignée également par Gaétan Roelens, développeur COBOL et chef de projet chez ArcelorMittal, et lui aussi venu au COBOL un peu par accident. Il s’est notamment fait connaitre en intervenant sur la chaine Underscore chez YouTube, sur le même sujet.

Contacté par Next, il comprend que le COBOL peut effrayer par sa verbosité ou son approche. « Bien sûr que les mainframes d’aujourd’hui n’ont rien à voir avec ceux de l’époque. Mais il ne faut pas négliger la syntaxe du COBOL. Elle date d’il y a 60 ans, elle parait absurde aujourd’hui. Et on ne peut pas le nier : on code toujours sur 80 colonnes, on n’a pas la souris. Au niveau de l’interface, c’est vieux, ça c’est clair. Le développeur, devant un écran de mainframe, il va halluciner. Ça fait vieillot, clairement. Par contre, ce qui tourne derrière, ce sont les super performances ».

La tentation du neuf

Tout effacer pour repartir sur une base neuve est une tentation constante, qui fait partie intégrante du solutionnisme technologique. Dans le cas du COBOL cependant, le langage embarque, lui, la logique métier. Plonger dans son code et reculer dans le temps revient à ouvrir un livre d’histoire sur l’évolution des pratiques du métier et leurs évolutions. Dans certains cas, cet historique est crucial. Dès lors, repartir sur une base neuve devient aussi complexe qu’onéreux, quand l’opération est possible.

« Je pense que les systèmes sont devenus trop gros, on n’arrive pas à migrer, on n’a pas de solution encore pour migrer des systèmes aussi gros. La méthode Scrum agile ne marche pas pour ce genre de projet aussi énorme. Ça va dériver dans le temps et ne jamais se terminer. Et si on veut faire des projets à l’ancienne, avec des deadlines, etc., on n’arrive pas à caser tout dans le budget », abonde ainsi Gaétan Roelens.

Il poursuit : « Ensuite, les règles de gestion qui ont été codées à l’intérieur depuis 60 ans ne sont plus maîtrisées par les utilisateurs. Si on prend l’exemple d’un projet XY, on va dire « Bon, alors maintenant, à la place de ce qui tourne, on va vous mettre ce projet. Donnez-nous toutes les règles de gestion pour les recoder dans le projet XY ». Les utilisateurs vont dire : « On ne sait plus. On ne sait pas. Oui ça fonctionne, mais on ne sait pas ce qu’il y a derrière ». Donc dans ce cas-là, il faut refaire toute une rétro-analyse. Et rien que l’analyse du COBOL pour extraire toutes les règles codées, ça va coûter aussi cher que le projet en lui-même ».

Ce qui revient, en somme, à chercher dans le code le cahier des charges. Un problème autant qu’un avantage selon le développeur, car la documentation a souvent tendance à disparaitre, là où le code est toujours là. Et, si lui aussi note l’adaptation à l’IA et l’arrivée d’outils pour le COBOL, il s’agit surtout d’écrire du nouveau code, pas d’analyser l’existant.

« Là où je travaille en ce moment, il y a 4 000 programmes, tous imbriqués entre eux. Et ce n’est pas une grosse architecture. L’IA est incapable de gérer ça pour l’instant », indique Gaétan Roelens. Une IA capable d’analyser 4 000 programmes et d’en décrire les imbrications pourrait-elle être considérée comme révolutionnaire ? « Clairement, parce qu’il faudrait que l’IA comprenne tout. Chez ArcelorMittal, par exemple, elle devrait comprendre ce qu’est une bobine, dans quel rouleau elle passe, etc. C’est la logique métier et elle est présente dans le code. C’est le code en COBOL qui va dire que telle bobine d’acier doit passer à telle date dans telle machine, dans tel rouleau, qu’elle ait telle épaisseur, etc. ».

Une approche hybride

Si le langage évolue et que l’approche se veut plus pragmatique, une approche hybride peut-elle être envisagée ? Pour Julien Eliès, autre développeur COBOL avec qui nous avons discuté, c’est une évidence.

« En France, le COBOL est encore assez utilisé, dans les banques et assurances bien sûr, mais aussi dans pas mal de PME et dans la santé. Souvent, ces sont des applicatifs qui datent des années 90. Dans l’entreprise où je suis, c’est en train d’être réécrit : l’interface applicative est refaite en Java, mais c’est bien le Cobol derrière qui fait les traitements ».

Lui aussi pose la question : « Pourquoi changer ce qui fonctionne ? C’est une question de masse historique, de nombre de milliards de lignes de code. Ce serait très long, très coûteux, alors que le COBOL marche. Et il marche même très bien. Quand vous voulez traiter des millions, voire des milliards, de transactions financières dans les banques et qu’il faut le faire entre 20 h le soir et 6 h le lendemain matin. Je n’ai pas encore vu Java le faire, alors que sur des gros systèmes, il n’y a pas de problème avec COBOL ».

Il attire d’ailleurs notre attention sur un autre critère qui a rendu le COBOL si précieux dans le domaine financier et explique qu’il soit toujours là : « Il y a aussi un problème de gestion du numérique, de typage de variables. En Java, il n’y a pas de numérique à nombre de décimales fixes. On a un entier, on a un décimal, mais le nombre de décimales n’est pas fixe. C’est Java qui va le décider en fonction de son utilisation. Alors que pour des calculs financiers notamment, on a vraiment besoin que les nombres soient définis avec 2 ou 5 décimales, et que ce soit toujours la même chose. Sinon on tombe sur des arrondis qui peuvent générer des coûts conséquents quand on parle de millions voire de milliards d’euros ».

Il casse d’ailleurs une autre idée reçue : la mise en place du virement instantané dans les banques n’était pas tant un problème de COBOL que d’architecture. « Oui le COBOL était utilisé dans des traitements asynchrones et des batchs de nuit. Ça répondait dans la dizaine de secondes ou dans la minute. Ce n’était pas idéal pour les virements instantanés, qui engendrent des traitements complexes. Mais c’est surtout un problème d’architecture, car rien n’empêche d’avoir une interface web qui appelle un programme Cobol, qui répondra en quelques dixièmes de seconde ».

Lui aussi estime qu’un programme fonctionnel en COBOL ne devrait pas être remplacé : « Si vous avez un existant COBOL qui marche, qui fait le job, et qu’on peut brancher avec une interface moderne, pourquoi réécrire ? Ça coûterait cher, ça générerait probablement beaucoup d’erreurs, beaucoup de bugs à corriger, pour peu d’avantages ». Tout en précisant, en riant : « Mais bon, nous les cobolistes, on est de vieux ronchons ».

Transmission du flambeau :  c’est compliqué !

Comme beaucoup de « cobolistes », Gaétan Roelens nous expose ses craintes sur la passation des connaissances entre l’ancienne génération de sachants et la nouvelle : « C’est vrai que jusqu’à maintenant, on s’appuyait sur les gens de cette génération-là. Quand j’avais un problème vraiment trop complexe pour moi, j’allais les voir. Et aujourd’hui, ils sont partis. Je vous avoue que des fois on est bien embêtés », nous confie le développeur.

Comment faire alors ? « On bricole parfois. On ne peut plus aller aussi loin qu’avant, aussi au fond. Avant, si on avait un bug, on allait creuser jusqu’au bout, voir d’où venait le bug. Des fois, on devait aller dans la partie assembleur du COBOL, du z/OS, etc. Mais aujourd’hui, presque plus personne ne sait le faire. Donc, si on a un bug et qu’on n’arrive pas à trouver, on contourne le problème. On va faire autre chose, mais on ne résout pas vraiment le problème. C’est sûr que ça dégrade les performances ».

« On arrive toujours à se débrouiller, mais ce n’est pas une situation idéale. Si on pouvait avoir encore des experts aujourd’hui, des jeunes qui montent en compétences, ce serait top, mais ce n’est pas ce que je remarque. Je remarque plus une rareté des experts en COBOL. Ce sont souvent les SSII qui forment. Après, on peut toujours faire appel aux Golden Tickets d’IBM. Eux, ils ont quand même des experts. Mais bon, c’est cher », poursuit Gaétan Roelens.

Le chef de projet nous indique avoir accepté l’invitation d’Underscore pour cette raison : attirer l’attention, faire la promotion de COBOL, casser l’idée reçue d’un langage figé et encourager les plus jeunes générations à se lancer. Comme Gatien Dupré, il s’inquiète de ce que les jeunes développeurs n’ont souvent jamais entendu parler du langage. Et, quand ils le connaissent, ils en ont souvent une vision mâtinée d’une couche de dédain chronologique : « c’est vieux, donc c’est nul ».

Même volonté chez Gatien Dupré : « Le conseil que je donne aux jeunes développeurs, c’est : intéressez-vous au COBOL et à l’informatique de gestion parce que c’est une mine d’or. Avec la vague des papy-boomers, le renouveau générationnel est une préoccupation que pas mal de gens ont. Pour nous, en COBOL, effectivement, il y a ce fossé générationnel : quand les derniers développeurs seniors partiront à la retraite, on aura peu de mid-seniors qui permettront d’accompagner ». On retrouve ainsi le problème de transmission des savoirs, en plus du simple apprentissage du langage.

Julien Eliès confirme lui aussi : « Parmi les cobolistes, je suis considéré comme jeune alors que je viens d’avoir 50 ans, donc c’est sûr qu’on va en manquer. Dans l’absolu, ce n’est pas compliqué de former un coboliste. Du moment qu’on a touché à un langage de programmation, qu’on sait ce que c’est un algorithme, en moins d’un mois, on a compris ce que c’était COBOL. Ce qui est compliqué c’est de maintenir des applicatifs qui ont 40 ans, sur lesquels des centaines de personnes sont intervenues, et dont on a souvent perdu la documentation ».

De fait, pour les trois cobolistes, il n’y a aucune raison technique de remplacer les programmes COBOL existants s’ils donnent satisfaction. En revanche, le problème de la transmission des savoirs et de l’appropriation des projets existants est un vaste problème posant la question de la maintenabilité du code. Même si pour les développeurs interrogés, la thématique n’est pas nouvelle : quand les entreprises ont des besoins, une solution finit en principe par émerger.

À compter du 1ᵉʳ janvier 2026, la grande majorité des personnes abonnées à l’offre GeForce Now de NVIDIA auront une limite de 100 heures par mois, soit une moyenne d’un peu plus de 3 heures par jour.

Cette limite n’est en fait pas nouvelle. Annoncée en 2024, elle est appliquée depuis un an à l’ensemble des nouveaux abonnés. Ce qui change, c’est bien l’application de cette limite à la quasi-totalité des autres abonnés. « Quasi », car toutes les personnes ayant une ancienne formule d’avant mars 2021 (membres Fondateurs) et ayant payé leur abonnement sans interruption gardent le même niveau de prestation, sans limite. NVIDIA promet dans sa FAQ que cet avantage sera préservé « à vie », à condition que les personnes concernées continuent de payer.

Ce plafond peut être dépassé. À la manière des forfaits téléphoniques, on peut ainsi acheter des packs d’heures supplémentaires, mais la tarification dépend de la formule d’abonnement. Si vous avez une offre Performance à 10,99 euros par mois, le pack de 15 heures est facturé 3 euros. Avec la formule Ultimate à 21,99 euros par mois, le même pack est vendu 6 euros.

Ces packs sont optionnels. Par défaut, quand la réserve de temps est épuisée, le compte utilisateur bascule sur la formule gratuite jusqu’à la date de renouvellement mensuel suivante, y compris pour les formules de plusieurs mois. À l’inverse, si le quota n’est pas utilisé, sur les 100 heures de base ou sur l’extension de temps achetée, un report peut s’opérer sur le mois suivant, dans une limite de 15 heures.

Le problème, bien sûr, est le prix des extensions. Que l’on joue une ou dix heures de plus, le prix est le même. Des abonnés mécontents se sont « amusés » à calculer l’écart de tarifs en fonction du nombre d’heures jouées par mois, dans un tableau intitulé : « Combien d’heures puis-je jouer chaque mois avant que GeForce Now ne soit plus une option viable ? ». On voit rapidement qu’au-delà de 100 heures par mois, le prix augmente rapidement. Sur un an par exemple, un très gros joueur à 200 heures par mois sur une formule Ultimate paierait près de 800 dollars par an.

La question sera donc de savoir si les 100 heures sont suffisantes aux personnes actuellement abonnées. Si plus de trois heures par jour peuvent sembler largement suffisantes, elles sont susceptibles de rapidement disparaitre via les week-ends et les périodes de repos, dans le cadre d’un service spécifiquement conçu pour le jeu. C’est d’ailleurs le type de réflexion abordé sur Reddit : il pourrait être plus intéressant d’acheter directement le matériel, même si le niveau de prestation de l’offre Ultimate est élevé.

Le changement était prévu, mais il tombe à point nommé pour NVIDIA, prise dans les filets d’une situation matérielle générale nettement plus tendue qu’il y a un an.

Good Old Games (GOG) a été fondée en 2008 par le studio polonais CD Projekt, à qui l’on doit plusieurs jeux vidéo particulièrement célèbres comme la série The Witcher ou encore Cyberpunk 2077.

La boutique s’est largement fait un nom autour d’une idée simple : ramener d’anciens titres à la vie, faire en sorte qu’ils fonctionnent sur des systèmes récents, corriger les bugs et les maintenir à jour. L’autre grand axe de développement est l’absence de DRM (gestion des droits numériques) sur une grande partie du catalogue, pour éviter notamment les incompatibilités. Elle s’est ouverte depuis à de plus grosses licences et propose un launcher, Galaxy.

GOG était jusqu’à présent une filiale de CD Projekt. Depuis cette nuit, Michał Kiciński est le nouveau propriétaire de la boutique. Cette passation reste « en famille » : Michał Kiciński est cofondateur de CD Projekt et l’un de ses principaux actionnaires.

« Avec notre attention désormais entièrement portée sur une feuille de route de développement ambitieuse et l’expansion de nos franchises avec de nouveaux produits de haute qualité, nous avons estimé que c’était le bon moment pour cette décision. Depuis longtemps maintenant, GOG opère de manière indépendante. Aujourd’hui, il passe entre de très bonnes mains – nous sommes convaincus qu’avec le soutien de Michał Kiciński, l’un des cofondateurs de GOG, son avenir sera riche de grands projets et de succès », a déclaré Michał Nowakowski, co-CEO de CD Projekt.

Maciej Gołębiewski, directeur général de GOG, affirme que la mission de GOG ne changera pas : « Dans un marché de plus en plus saturé, de plus en plus verrouillé, et qui oublie les jeux classiques à un rythme croissant, nous redoublons d’efforts sur ce que seul GOG fait : ressusciter les classiques, les garder jouables sur les PC modernes, et aider les grands jeux à trouver leur public au fil du temps ».

Ce rachat de la totalité des actions a une valeur de 90,7 millions de zlotys, soit environ 21,45 millions d’euros. Le communiqué affirme également que les prochaines sorties de CD Projekt continueront d’arriver sur GOG.

Rogntudju

Vous avez peut-être vu passer ces quelques derniers jours des actualités pointant vers la fin du support d’anciens GPU NVIDIA par Arch Linux. Ce n’est pas tout à fait ça, même si le résultat y ressemble.

À l’origine, on trouve la publication des pilotes 590 de NVIDIA. C’est bien cette version, sortie début décembre, qui met fin au support officiel des GPU des générations Maxwell et Pascal, c’est-à-dire les GeForce GTX des séries 900 et 1000.

Cette fin de support, annoncée il y a plusieurs années, signifie que NVIDIA n’ajoute plus d’optimisations spécifiques ni de prises en charge de jeux en particulier. Les GPU continuent de fonctionner avec la version précédente des pilotes (de la branche 580). En outre – et c’est une information importante – le support complet n’est pas coupé : les mises à jour de sécurité continueront d’arriver jusqu’en octobre 2028.

Simple comme une mise à jour

Pourquoi un problème particulier avec Arch Linux dans ce cas ? À cause du fonctionnement en « rolling release », à savoir la diffusion quasi immédiate des dernières nouveautés logicielles. Le pilote 590 de NVIDIA y a été diffusé, avec utilisation par défaut. Ce n’est pas sans conséquence sur des systèmes appliquant toutes les mises à jour quand un pilote supprime un support.

Pour Arch Linux, la situation a été expliquée le 20 décembre par Peter Jung, l’un des mainteneurs du système (et créateur de cachyOS, distribution spécialisée dans le jeu vidéo). Il y indique que la nouvelle série 590 supprime le support des générations Pascal et antérieures, et que des remplacements de paquets sont donc appliqués : nvidia par nvidia-open, nvidia-dkms par nvidia-open-dkms, et nvidia-lts par nvidia-lts-open.

Il avertissait également que la mise à jour des paquets NVIDIA sur des systèmes intégrant ces anciens GPU entraînerait l’échec de chargement du pilote et donc celui de l’environnement graphique. La seule solution est de désinstaller les paquets nvidia, nvidia-lts et nvidia-dkms, puis d’installer le paquet nvidia-580xx-dkms depuis le dépôt AUR.

Les GeForce 16XX hors de danger

Il ajoute que rien ne change pour les GPU datant d’au moins la génération Turing, qui comprend la série 2000 des GeForce, mais également la série 1600. Cette dernière est en effet basée sur Turing, mais débarrassée des capacités de ray tracing. Les GeForce 1660 Ti, notamment, ne sont ainsi pas concernées par l’abandon de support dans le pilote 590.

Reste que la décision d’Arch Linux de procéder ainsi a provoqué de nombreuses réactions, comme on peut le voir dans les commentaires de sites tels que Phoronix et TechPowerUp. Plusieurs personnes manifestent de l’incompréhension face à une méthode jugée un peu trop radicale, indiquant qu’une détection automatique aurait pu être mise en place.

Enfin, précisons que cet arrêt de support n’est pas spécifique à la sphère Linux : Windows est lui aussi concerné. Le problème est cependant différent, car l’application NVIDIA n’installera pas d’elle-même la mise à jour, et Windows Update ne devrait pas non plus la proposer. Si l’on veut télécharger le pilote depuis le site officiel, l’outil intégré permet d’envoyer vers la bonne version. Si vous avez par exemple une GeForce GTX 1060, la version proposée au téléchargement est la 581.80.

• Sur Steam, Linux confirme sa croissance avec 3,2 % de parts de marché

L’annonce semble tardive, mais OpenAI cherche activement à recruter une personne dont le rôle sera de s’inquiéter de tous les dangers liés à l’IA. Ce nouveau « chef de la préparation » (head of preparedness) aura pour mission de diriger les efforts de l’entreprise dans l’encadrement de ses modèles.

• Psychoses induites par IA : le défi de sortir les internautes de leur « spirale » mentale

« Le responsable de la préparation développera, renforcera et guidera ce programme afin que nos normes de sécurité s’adaptent aux capacités des systèmes que nous développons », indique OpenAI dans son annonce. « Vous serez le responsable direct de la construction et de la coordination des évaluations des capacités, des modèles de menace et des mesures d’atténuation qui forment un pipeline de sécurité cohérent, rigoureux et opérationnellement évolutif ».

L’annonce ajoute que ce poste nécessite « un jugement technique approfondi, une communication claire et la capacité de guider des travaux complexes à travers de multiples domaines de risque ». Il implique une collaboration « avec la recherche, l’ingénierie, les équipes produit, les équipes de suivi et d’application des politiques, la gouvernance et des partenaires externes ».

Sam Altman, CEO de l’entreprise, y est allé de sa propre annonce sur X. Il y évoque un poste « crucial à un moment charnière ». Selon lui, les modèles évoluent très vite et sont capables désormais « de prouesses remarquables », mais « commencent » à poser de sérieux défis. Il cite deux exemples « entrevus » en 2025 : l’impact sur la santé mentale et une puissance telle que les LLM révèlent des vulnérabilités critiques.

Altman affirme qu’OpenAI dispose déjà d’outils solides pour mesurer ces « capacités croissantes ». Mais une personne qualifiée permettrait d’aller plus loin, notamment en aidant « le monde à trouver comment doter les défenseurs de la cybersécurité de capacités de pointe tout en veillant à ce que les attaquants ne puissent pas les utiliser à des fins malveillantes ».

Plusieurs personnalités reconnues du monde de l’IA se sont déjà succédé à ce poste chez OpenAI. La casquette a d’abord été portée par Aleksander Mądry, qui a discrètement été affecté à d’autres missions en juillet 2024. Elle est ensuite revenue à un duo composé de Joaquin Quinonero Candela et Lilian Weng, qui ont préféré jeter l’éponge au printemps dernier.

« Ce sera un travail stressant et vous serez plongé directement dans le grand bain », avertit le CEO. L’annonce évoque un salaire annuel de l’ordre de 555 000 dollars, assorti d’une participation.