La fintech britannique Revolut affirme avoir réduit d'environ 90 % sa facture d'IA de codage en moins d'un an, en remplaçant les outils commerciaux comme Claude Code, l'assistant de programmation d'Anthropic, par un modèle chinois hébergé sur ses propres serveurs.

David Abitbol, qui dirige l'infrastructure de la banque en ligne, a raconté la bascule lors d'une conférence à New York. Ses 2 000 ingénieurs sont passés de Gemini début 2025 à Claude Code début 2026, avant d'adopter GLM, un modèle ouvert développé par le chinois Z.ai et utilisé aujourd'hui en version 5.3.

Le calcul est vite fait. Auto-hébergé, GLM revient à 0,30 dollar le million de tokens, ces unités de texte que les fournisseurs d'IA facturent à la consommation, soit à peu près dix fois moins que Claude Code ou que Codex, son équivalent chez OpenAI. Certains développeurs coûtaient jusqu'à 10 000 dollars par mois, pour un retour jugé décevant en interne.

Le tout tourne sur 56 cartes graphiques Nvidia B200 installées chez Revolut. Plutôt que d'empiler les cartes, les équipes ont surtout gratté de la performance avec des réglages fins, comme la compression du modèle ou la séparation des différentes phases de calcul.

Côté performances, la première réponse tombe en moins de 3 secondes et le système sort environ 200 tokens par seconde, et même 800 le soir quand les bureaux se vident. Au-delà de 5 secondes d'attente, les plaintes pleuvent en interne.

La vraie surprise est ailleurs en fait. Les plus gros gains ne viennent pas de l'écriture de code mais du débogage et du traitement des tickets Jira et Confluence, ces outils de suivi de projet que tout le monde adore détester. Le temps de codage se serait quand même amélioré de 60 %.

Et puis il y a l'effet psychologique. Avec des tokens illimités en interne, les ingénieurs ne rationnent plus leurs requêtes pour tenir le budget du trimestre, et la facture ne réserve plus de mauvaise surprise en fin de mois. Les modèles commerciaux restent accessibles pour les cas particuliers, les tâches visuelles partent par exemple chez Gemini.

Un modèle chinois au coeur d'une banque, la question fâche forcément. Abitbol balaie. Hébergés en local ou sur un cloud régional, les poids du modèle ne font selon lui courir aucun risque, le danger serait plutôt de passer par des API hébergées on ne sait où.

Les fenêtres d'un million de tokens que vendent les gros acteurs du secteur sont à ses yeux "une arnaque", 256 000 suffisent largement à coder. Tout le marché vend exactement l'inverse depuis deux ans.

Source : Theregister

Le comite n'a pas contracté

Pour la première fois de son histoire, le langage C++ a échoué à réunir assez de votes au sein de l’ISO pour une nouvelle version. Le C++ 26 n’a pas été ratifié, faute d’un accord sur plusieurs points, dont le principal est le concept de contrat. Explications.

Le 23 octobre avait lieu le vote des organismes nationaux sur le projet de norme internationale (DIS). Le lendemain, Robert Seacord, qui dirige le comité du langage C à l’ISO, annonçait sur LinkedIn que le texte avait été désapprouvé, y évoquant un « jour triste pour la communauté C++ ».

Une première pour le C++

Pour être adopté, un projet doit réunir deux conditions. Il lui faut non seulement les deux tiers des voix des membres participants, mais les votes négatifs ne doivent pas non plus dépasser le quart des votants. Or, C++ 26 n’a obtenu que 12 voix sur 20, soit 60 %, alors que 14 étaient nécessaires. En outre, les votes négatifs ont atteint 9 sur 22, soit 41 %. Le projet C++ 26 a donc échoué sur les deux tableaux.

Selon Mateusz Pusz, membre du comité national polonais qui a consulté le résultat officiel, neuf pays ont voté contre : Danemark, Finlande, Iran, Italie, Japon, Luxembourg, Roumanie, Espagne et Suède. La France et l’Irlande se sont abstenues tout en adressant des commentaires techniques. La Pologne et les États-Unis se sont abstenus sans commentaires.

C’est la première fois qu’une nouvelle version du langage n’est pas normalisée par l’ISO. Pour Robert Seacord, aucune norme de langage n’avait jamais échoué à ce stade. Selon Daveed Vandevoorde, membre du groupe de direction du comité C++, c’est même encore plus significatif : aucun projet antérieur n’avait reçu un seul vote contre.

Au cœur des débats, les contrats

Le C++ 26 dresse une longue liste de nouveautés, parmi lesquelles les contrats. En développement, un contrat inscrit dans la déclaration d’une fonction ce qu’elle exige de son appelant et ce qu’elle garantit en retour. Il s’agit respectivement de la précondition et de la postcondition. Par exemple, une fonction de racine carrée peut exiger un nombre positif et promettre un résultat tout aussi positif.

Cette idée n’est pas nouvelle, comme l’indique le site Les Joies du Code. Le principe a été popularisé dans les années 1980 par l’informaticien français Bertrand Meyer avec son langage Eiffel. D’autres langages plus modernes, comme Ada et D, l’intègrent également. Le contrat figure dans la déclaration, à la vue de tous (aussi bien les appelants que le compilateur et les outils d’analyse). Pour ses défenseurs, il sert même de documentation qui ne peut pas devenir obsolète en silence.

Pour donner une idée de l’âge du sujet, le comité C++ travaille dessus de manière concertée depuis 2004, et une première version avait été proposée pour C++ 20, avant d’être supprimée en 2019. La version actuelle, présente dans la proposition de C++ 26 récemment refusée, avait pourtant reçu l’aval d’un sous-comité technique en février 2025, par 100 voix contre 14.

Alors que s’est-il passé ? En fait, si l’idée fait globalement consensus, sa conception divise. Dans C++ 26, le code source ne décide pas si un contrat est vérifié. Le texte définit quatre comportements possibles : ignorer la vérification, l’effectuer en signalant l’erreur sans s’arrêter, l’effectuer et arrêter le programme, ou l’arrêter immédiatement sans traitement intermédiaire.

Problème, le choix revient à l’implémentation, autrement dit à une option de compilation. Ainsi, une même règle écrite par le développeur peut donc être appliquée strictement, simplement signalée ou ignorée selon la manière dont le programme est construit. Dans son billet, Mateusz Pusz avait résumé ainsi la problématique : une assertion de contrat est-elle une vérification que la compilation peut supprimer, ou une garantie sur laquelle le programme peut compter ?

Deux camps irréconciliables

Sans surprise, les opposants reprochent la possibilité de désactiver les vérifications. Selon eux, cela revient à la pratique déjà connue de tester du code avec des contrôles puis à les supprimer en production. Ils préfèrent que ces vérifications soient toujours actives, ce qui aurait un coût estimé par Google à 0,3 %.

Ils lui reprochent également son inachèvement, car les contrats sur les fonctions virtuelles ont été repoussés à C++ 29. Dans ce camp, on retrouve notamment Bjarne Stroustrup, le propre créateur du C++. Il exprime son rejet des contrats sous cette forme depuis des années, comme l’indiquait The Register en mars dernier.

Pour les défenseurs en revanche, toutes ces critiques ont déjà reçu des réponses. Ils craignent également que le retrait ne repousse encore les contrats de plusieurs années. L’historique va d’ailleurs dans ce sens : après le retrait de C++ 20, il avait fallu six ans pour les remettre sur la table, dans une version plus modeste. En outre, ils reprochent à certains opposants d’avoir plaidé leur cause directement auprès des pays pendant le vote.

Et maintenant ?

D’abord, précisons qu’il y a peu de conséquences immédiates pour les développeurs. La situation est similaire avec les normes Wi-Fi : les compilateurs n’attendent pas la publication d’une norme pour implémenter un projet en cours de travail. Le vote ne modifie pas non plus ce qu’ils proposent déjà. Par exemple, la version 16 de GCC (sortie en avril) prend en charge les contrats à titre expérimental (avec l’option -std=c++ 26). Clang ne les intègre pas encore en revanche.

Quelle suite à présent ? Le comité WG21, le groupe de travail de l’ISO chargé du langage C++, doit se réunir à Búzios, au Brésil, du 16 au 21 novembre 2026. Il devra répondre à chacun des commentaires nationaux (que l’on ne peut pas consulter) et recommander une marche à suivre.

De là, il peut y avoir quatre possibilités : un projet révisé soumis à un nouveau vote de huit semaines, un nouveau projet de comité soumis à commentaires, une publication comme spécification technique, ou l’abandon pur et simple. Le président du SC22, sous-comité de l’ISO chargé des langages de programmation, devra choisir parmi les trois premières. Pour un abandon, il faut en revanche que tout le SC22 vote.

Pour l’instant, les camps sont divisés. Certains militent pour un nouveau vote sur le texte inchangé, d’autres pour retirer la seule fonction contestée afin que le reste passe. D’ici à ce que le problème soit tranché, il est probable que la date du vote glisse en 2027. La future norme pourrait alors changer de nom pour C++ 27.

Chapeau la distrib'

Fedora 45 est maintenant téléchargeable en version finale. Les nouveautés sont assez nombreuses, notamment sur la sécurité et les paquets reproductibles.

Mise à jour du 4 novembre

La version finale est désormais disponible au téléchargement. On peut récupérer les images ISO depuis le site officiel.

---

Article original du 16 septembre

Fedora est le laboratoire à ciel ouvert de Red Hat. La distribution est connue pour être pionnière dans ses choix technologiques, comme le choix du serveur d’affichage Wayland par défaut dès la version 25, longtemps avant les autres distributions (et les bugs de jeunesse qui allaient avec).

• X11, Wayland : pourquoi la transition est-elle aussi longue ?

Comme Ubuntu, Fedora dispose d’un rythme biannuel, au printemps et à l’automne. La nouvelle mouture 45 est ainsi prévue pour le 20 octobre, ou le 27 en cas de problème. Maintenant que la bêta est disponible, on peut observer ses nouveautés, parmi lesquelles une hausse manifeste du niveau de sécurité.

Toutes les variantes du système peuvent être téléchargées (images ISO) depuis le site officiel. Sur la page de téléchargement, il faut penser à activer le sélecteur d’affichage pour la bêta. Depuis l’annonce officielle, les différents liens pointent tous directement vers les versions 45.

Composants de base

La bêta de Fedora 45 est livrée avec le noyau Linux 7.2, la dernière révision stable (sortie le 16 aout). Parmi les nouveautés de ce dernier, le Cache Aware Scheduling permet à l’équilibrage de charge de tenir compte du cache de dernier niveau au sein des processeurs. Phoronix, connu pour ses tests de performances, indiquait en outre que le noyau 7.2 introduisait des gains mesurables de performances pour les processeurs AMD et Intel. Entre autres nouveautés, on trouve une première prise en charge du HDMI 2.1 FRL dans le pilote AMDGPU, le support du protocole USB4STREAM d’Intel ou diverses prises en charge dans KVM de fonctions de sécurité propres à AMD et Intel.

Comme toujours avec Fedora, la version proposée par défaut pour les PC, Workstation, est fournie avec GNOME, qui passe pour l’occasion en version 51. Cette mouture n’est pas finalisée, même si les composants en bêta sont remplacés par leurs équivalents RC (Release Candidate) après l’installation de Fedora 45. GNOME 51 inaugure des curseurs au format SVG (déjà présents dans KDE), une nouvelle interface de gestion des empreintes digitales, le support de la connexion distante multi-utilisateurs via Kerberos, de nouveaux réglages pour le pavé tactile, de meilleures performances pour Agenda ou encore le nettoyage du code auparavant lié aux anciens pilotes NVIDIA. Pour les personnes n’appréciant pas GNOME, KDE Plasma 6.7 est disponible dans une version dédiée.

Côté développement, la chaîne GNU passe à GCC 16.2, binutils 2.47, glibc 2.44 et gdb 17.2. S’y ajoutent LLVM 23 pour l’ensemble des sous-projets, Go 1.27, Python 3.15, Perl 5.44 et Lua 5.5. Dans les notes de version de la distribution, on peut lire que plusieurs changements cassent la compatibilité. Par exemple, Setuptools 82 supprime le module pkg_resources. Pandas passe de la 2.3 à la 3.0, avec une gestion des chaînes revue, un comportement copie-sur-écriture cohérent et la suppression de fonctionnalités dépréciées depuis longtemps. Même chose avec libxml2, dont le passage de la 2.13.9 à la 2.15.3 s’est accompagné d’un changement d’ABI, imposant une recompilation de masse avec dépréciation des liaisons Python.

Parmi les autres changements, Podman 6 est une des mises à jour les plus lourdes de conséquences. Elle « inclut des changements importants de rupture de l’API et de la ligne de commande, de nouvelles fonctionnalités, ainsi que la suppression finale de composants obsolètes tels que slirp4netns, cgroups v1 et le backend BoltDB », prévient Fedora. Citons également le passage de MySQL de la version 8.4 à 9.7, et celui de MariaDB de la version 11.8 à la 12.3. NetworkManager prend en charge par défaut les réseaux « IPv6-mostly ».

Sécurité : plusieurs serrages de vis

Plusieurs changements importants sont présents dans Fedora 45. D’abord, l’équipe indique avoir franchi la barre des 90 % de paquets reproductibles.

Pour comprendre l’intérêt, rappelons qu’un paquet est dit « reproductible » si, à partir du même code source, du même environnement de compilation et des mêmes instructions, n’importe qui peut régénérer une copie identique bit à bit du paquet publié. En clair, il s’agit d’un gage de sécurité de la chaine d’approvisionnement : c’est la garantie que le binaire téléchargé correspond bien au code source publié. Dans le cas de Fedora, toute non-reproductibilité détectée est considérée comme un bug et est traitée comme telle, via un rapport. La distribution n’est pas la seule à progresser dans ce domaine, d’autres comme Arch Linux ou NixOS font de même.

On reste dans le sujet avec la vérification désormais obligatoire des signatures par le gestionnaire de paquets RPM. Un mode de vérification stricte, conformément au comportement en amont introduit par la version 6.0, comme nous l’indiquions il y a un an. Ainsi, seuls les paquets dont la signature est vérifiée peuvent être installés, sauf dérogation explicite avec --nosignature ou l’API correspondante. Les RPM compilés localement et non signés sont directement concernés. Côté Fedora, ce changement se fait dans la foulée du passage à RPM 6.1.

Fedora 45 restreint également ptrace par réglage global dans le noyau qui retire par défaut certaines permissions de débogage aux utilisateurs non privilégiés. L’objectif est d’empêcher un logiciel malveillant d’inspecter les autres processus du même utilisateur. En revanche, si des outils de débogage sont installés, un fichier sysctl rétablit le comportement classique de Fedora 44 et des versions précédentes.

Autre changement significatif, le changement de fournisseur par défaut du service Secret. On passe ainsi de KWallet et GNOME Keyring à oo7. Écrit en Rust, il implémente la même interface D-Bus org.freedesktop.secrets, et se veut une alternative légère utilisable sur tous les environnements. Il est développé dans le cadre du projet linux-credentials et sert déjà de service de secrets natif pour COSMIC Desktop. D’après la fiche Fedora, oo7 doit permettre un modèle d’autorisation limitée par application ou par service, ouvrir la voie à l’authentification FIDO2 et mieux encadrer l’accès des applications isolées aux secrets.

On trouve d’autres modifications liées à la sécurité, comme l’interdiction par DNF5 de changer de fournisseur par défaut. Un changement important, car à moins d’une manipulation spécifique, un paquet installé ne peut donc plus être remplacé automatiquement par celui d’un autre fournisseur. Signalons aussi que chpasswd et newusers passent désormais par PAM et appliquent donc les politiques de mots de passe du système.