Beaucoup de tokens pour rien

Brûler des tokens ne fait pas nécessairement un bon ingénieur. Amazon reconnait les limites de ses indicateurs d’utilisation de l’IA, et demande à ses équipes de privilégier les résultats concrets. Même si les indicateurs restent en place.

Amazon ne veut plus faire partie du club des entreprises où l’on brûle du token pour rien, sinon pour se faire bien voir de la hiérarchie. Au mois de mai, une indiscrétion donnait des détails sur un nouvel outil interne pour mesurer l’utilisation de l’IA. Un usage surveillé de près par des managers poussant sans relâche leurs équipes à intégrer cette technologie dans leur travail de tous les jours. À tel point que certains abusent des tokens.

• Tokenmaxxing : quand les salariés d’Amazon brûlent des tokens pour se faire bien voir

Des indicateurs qui poussent à la consommation

Ce phénomène du tokenmaxxing ne se limite pas à Amazon. De nombreuses autres entreprises, désireuses elles aussi d’embarquer dans le grand train du progrès et des (soit-disant) gains de productivité démentiels forcent leurs salariés à exploiter l’IA, parfois à tort et à travers. À cela s’ajoutent des factures d’usage d’API qui flambent.

Amazon a rapidement appuyé sur la pédale de frein et mis un terme au classement IA interne. Pour enfoncer le clou, un mémo envoyé en septembre par Terk Terkowitz, vice-président de l’ingénierie, et rendu public ce mardi 27 octobre, détaille les nouvelles pratiques en matière de mesure des performances des équipes.

Le message destiné aux ingénieurs logiciels du groupe détaille les mesures utilisées en interne, parmi lesquelles la consommation de tokens pour déterminer le volume d’utilisation des modèles –, ce qui peut en amener certains à en abuser. Amazon mesure aussi l’adoption des outils IA, le nombre de modification dans le code et le nombre de revues de code, ces deux derniers indicateurs servant à suivre le volume de travail réalisé.

« Nous savons tous à quel point ces indicateurs sont imparfaits, principalement parce qu’ils sont déconnectés de ce qui compte vraiment », écrit le dirigeant. « S’ils deviennent des objectifs plutôt que des instruments de mesure, ils peuvent avoir des effets négatifs : une hausse des coûts (…) et une complexité accrue », poursuit-il. Terk Terkowitz espère tout de même que le « sens aigu des responsabilités » des développeurs et leur volonté « d’obtenir des résultats » aidera l’entreprise à éviter les effets négatifs.

Quand l’IA n’aide pas, ce n’est pas forcément un échec

Il faut toujours tenir compte de ces critère donc, mais « avec prudence et discernement ». Le vice-président donne une sorte de feuille de route en recommandant de regarder les deux extrémités : les 10 % des équipes qui adoptent le moins l’IA pour comprendre les freins, et les 10 % qui l’utilisent le plus afin de vérifier que cet usage s’accompagne d’une augmentation des livraisons de nouveautés.

« Si les outils d’IA actuels n’apportent rien à votre travail, c’est un constat, pas un échec. Documentez les raisons, partagez-les avec vos pairs, parlez-en à votre responsable et cherchez des solutions. Un ingénieur capable d’expliquer dans quels cas l’IA ne l’aide pas encore dans son travail fait preuve du discernement que nous attendons. »

Mais le critère final doit être l’impact à long terme sur les clients, l’activité et les équipes. Une métrique basée sur la qualité donc, bien plus que sur la quantité de tokens brûlés.

En juin 2025, le directeur général d’Amazon, Andy Jassy, partageait sa « pensée » autour de l’IA générative. Pour lui, les agents IA vont accélérer et amplifier le développement d’innovations au sein de l’entreprise. Moins réjouissant, il prévoyait aussi une baisse des effectifs grâce aux gains d’efficacité de l’IA, tout en indiquant que certains métiers créeront plus d’emplois.

À l’approche des élections américaines de mi-mandat, OpenAI resserre les conditions d’utilisation de ChatGPT, tout particulièrement de la fonction de génération d’images.

Alors que les élections de mi-mandat se dérouleront le 3 novembre aux États-Unis, ChatGPT n’est plus en mesure de générer des images photoréalistes dépeignant « une ingérence électorale ou susceptibles de décourager le vote ». Le bot peut toujours proposer des images, mais elles apparaissent dès lors sous la forme d’illustrations stylisées, « cartoon », pas réalistes.

L’intimidation électorale passe au dessin

OpenAI veut « réduire le risque qu’une scène imaginaire soit prise pour une preuve documentaire ». Cnet a testé en demandant à ChatGPT de créer une image photoréaliste d’agents de l’ICE (la police de l’immigration) devant un bureau de vote. La crainte est qu’une telle présence décourage les personnes redoutant un contrôle migratoire des urnes, même quand elles ont le droit de voter.

Comme on a pu le tester en dehors des États-Unis, ChatGPT génère bien une telle image mais stylisée. Le bot ne parvient pas à produire une image réaliste. Plus près de nous, c’est le cas aussi pour le prompt « Crée une image photoréaliste d’un cordon de CRS bloquant l’entrée d’un bureau de vote en France ». Même en insistant pour avoir un rendu réaliste, l’image reste stylisée façon dessin de presse ou BD.

La requête « Crée une image photoréaliste d’une urne électorale bourrée de bulletins par un assesseur dans une mairie française » génère d’abord un dessin, mais en réclamant un rendu photoréaliste, ChatGPT s’exécute. Savoir exactement ce qui est autorisé de ce qui ne l’est pas n’est donc pas évident. Ce d’autant que l’approche d’OpenAI « préserve la possibilité de créer des illustrations et des commentaires sur la société ».

Les fausses images alimentent la désinformation

L’entreprise rappelle aussi que ses règles interdisant l’ingérence électorale et la démobilisation des électeurs s’appliquent toujours, « même lorsque ces usages abusifs font appel à des images de type dessin animé. » Les manifestations de ces dernières semaines en France donnent un relief particulier à ces mesures de protection relatives aux élections datées du 27 mai, mises à jour le 20 octobre.

L’image d’un couple d’octogénaires soit-disant « dépouillés » par des casseurs au soir de la manifestation du 17 octobre a été largement partagée sur les réseaux d’extrême-droite. Mais voilà, elle était complètement bidonnée, générée par IA.

• « L’image la plus horrible de ce 17 octobre » émanait d’un site d’info généré par IA

OpenAI ajoute un partenariat avec Associated Press pour le décompte en direct des bulletins de vote pour les élections au Brésil et aux États-Unis. Les fabricants de systèmes de vote électronique qui travaillent avec les autorités américaines pour les élections peuvent participer au programme Daybreak de protection des défenseurs.

L’entreprise interdit également la génération de messages de campagne, y compris des images et des vidéos, en faveur ou à l’encontre d’un candidat, d’un parti politique ou d’une proposition soumise au vote. Pourtant, à l’occasion de la campagne des mid-terms, on a vu fleurir d’innombrables spots générés par IA, notamment du côté des républicains pour dénigrer leurs opposants.

• Présidentielle 2027 : des ingérences aux conséquences difficilement quantifiables
• Présidentielle 2027 : entre « censure » et redirections sauvages, les sites sous pression

Commençons par un rappel. OpenAI propose quatre gammes de modèles, du moins cher au plus « capable ». Luna est ainsi vendu comme le modèle le plus rapide pour les questions courantes, Terra comme le modèle à tout faire, Sol pour les tâches complexes et Astra pour les plus gros besoins. Si Astra a ouvert le bal de la génération de modèles GPT-6 début septembre, Luna et Sol ont suivi peu de temps après. Ne manquait plus qu’une mise à jour de Terra, resté sur GPT-5.6. C’est désormais chose faite.

Pour l’occasion, Terra passe directement sur GPT-6.1, comme Sol fin septembre. OpenAI présente son nouveau modèle comme rapide, capable de combiner raisonnement visuel détaillé et pilotage précis de l’ordinateur, le tout avec une rédaction plus naturelle. L’entreprise cite plusieurs cas d’utilisation, allant de la rédaction de propositions à l’interprétation de dessins techniques, en passant par le remplissage de formulaires et le montage vidéo.

L’accent est largement mis sur la tarification API. Le prix est ainsi de 1 dollar par million de jetons (tokens) en entrée et de 5 dollars en sortie (le double en mode Fast), contre respectivement 2 et 12 dollars pour GPT-5.6 Terra. Le tarif de l’écriture en cache est divisé par deux, à 1,25 dollar le million de jetons, tandis que le prix de la lecture est divisé par quatre, passant de 0,20 à 0,05 dollar. De manière générale, le nouveau Terra est annoncé comme deux fois moins cher que l’ancien.

« Avec un effort maximal, Terra est plus de trois fois plus efficace que Claude Opus 5.5 en matière d’utilisation des tokens, et son prix par token est quatre fois inférieur, ce qui se traduit par un coût par tâche environ neuf fois inférieur », vante ainsi OpenAI.

Sans surprise, GPT-6.1 Terra bat la génération précédente dans tous les tests. Selon OpenAI, il flirte même avec les étoiles d’Astra sur certaines tâches. Sur Terminal-Bench 4.0 en particulier, le score est plus que doublé par rapport à l’ancienne, passant de 21,5 à 50,3 %. Le modèle se veut également rapide, avec une exécution trois fois plus rapide que GPT-6.1 Sol sur Last Exam.

Artificial Analysis confirme les meilleures performances, avec un gain de 6 points dans son Intelligence Index en effort maximal, de 7 à 13 points sur des efforts moins importants, et un coût par tâche (toujours sur son propre benchmark) de 0,40 dollar, contre 1,40 pour la génération précédente.

OpenAI l’affirme également, son modèle se trompe beaucoup moins. Sur son benchmark interne, « le taux d’erreur avec un faible effort de raisonnement est passé de 53,6 % avec GPT-5.6 Terra à 16,7 % avec GPT-6.1 Terra, soit une baisse de près de 37 points de pourcentage. Avec un effort maximal, le taux d’erreur a baissé de 18 points de pourcentage pour atteindre 4,3 %, se rapprochant ainsi des taux de GPT-6 Astra et de GPT-6.1 Sol », indique OpenAI. Difficile d’en savoir plus sur la base d’un benchmark interne, donc non reproductible.

Le nouveau « modèle du quotidien » est disponible pour les personnes abonnées Plus, Pro, Enterprise et Edu, mais uniquement dans ChatGPT Work et Codex pour l’instant. On peut également y accéder via l’API sous le nom gpt-6.1-terra.

« Taxe de vérification »

L’interrogation est croissante : les investissements dans l’IA sont-ils suivis d’effets tangibles sur la productivité ? Si l’on en croit le gestionnaire d’actifs Apollo Global Management, pas encore, la « faute » au facteur humain.

Apollo Global Management est l’un des principaux gestionnaires d’actifs alternatifs au monde. Il est aussi un important financeur des infrastructures de l’IA. En janvier 2026 par exemple, ses fonds ont mené un financement de 3,5 milliards de dollars pour l’acquisition de processeurs GB200 de NVIDIA loués à une filiale de xAI (devenu entre-temps Space XAI puis SpaceXSI).

Aussi, quand l’économiste en chef, Torsten Slok, publie un billet le 24 octobre sur les gains de productivité sous l’influence de l’IA, beaucoup tendent l’oreille. Qu’en dit Slok ? Qu’en dépit des investissements massifs, l’intelligence artificielle n’aurait produit aucun gain financier pour les entreprises américaines en dehors du secteur technologique.

Hors tech, point de salut ?

Le billet a été publié dans le cadre de sa lettre quotidienne The Daily Spark. Il se base essentiellement sur cinq facteurs.

Le premier, et le plus important, est que le chiffre d’affaires par salarié augmente bien pour les sept grandes valeurs technologiques, surnommées « les sept magnifiques », ou « Mag 7 » (Alphabet, Amazon, Apple, Meta, Microsoft, NVIDIA et Tesla). En revanche, il stagne pour les 493 autres sociétés du S&P 500.

Il note d’autres éléments participant à cet avis, notamment une même divergence pour les marges bénéficiaires. En outre, la productivité globale des facteurs (PGF) ne montrerait aucune accélération, Torsten Slok utilisant la série corrigée du taux d’utilisation de la Fed de San Francisco. Enfin, non seulement les dépenses d’IA sont très concentrées, mais elles sont également circulaires, un point abordé plusieurs fois dans nos actualités.

• IA : la valse des contrats entre NVIDIA, OpenAI et consorts ravive les craintes d’une bulle
• Les patrons de l’IA appellent à lever le pied, leurs dépenses disent l’inverse

« Les entreprises soutenues par le capital-risque dépensent de plus en plus pour les tokens, mais l’entreprise américaine grand public n’a pas besoin du dernier modèle et refuse de le payer. Tant que les dépenses en IA agentique et en tokens seront limitées à une petite partie de l’économie, les effets macroéconomiques de l’IA seront très limités », assène l’économiste.

Pourquoi si peu de mouvement dans la productivité ? Selon Torsten Slok, l’IA a beau « être une excellente calculatrice », l’intelligence en entreprise « est surtout un jugement », qui lui-même dépend du contexte : « l’IA ne comprend pas la responsabilité, la confiance, la culture, les règles non écrites, les compromis éthiques ou l’équité, qui façonnent tous le risque réputationnel et favorisent finalement la croissance des revenus et les marges bénéficiaires ».

Pour l’économiste, « l’histoire de l’IA sera décidée dans le S&P 493 » (le S&P500 sans les « sept magnifiques »). Pour l’instant, l’IA serait surtout visible dans l’investissement et les valorisations, mais ne se traduirait pas encore en productivité.

L’humain, ce goulot d’étranglement

On peut relier en partie ces observations à d’autres relevées par le New York Times le 10 octobre. La journaliste Sarah Kessler y posait la question : si l’IA est censée « anéantir des tâches inutiles et rendre des professions entières obsolètes », pourquoi ne le constate-t-on pas sur le terrain ? Elle cite une récente enquête auprès de 6 000 cadres supérieurs, et dont 90 % ont estimé que l’IA « n’avait aucun impact, ni sur l’emploi ni sur la productivité ». Elle citait également un précédent de Torsten Slok, selon qui « le rendement productif de l’IA reste une prévision plutôt qu’une observation ».

Sur le pourquoi, le New York Times propose deux facteurs. Le premier est le plus simple : les entreprises ont besoin de temps pour s’adapter et faire évoluer leurs processus. Le second est plus complexe : une « taxe de vérification ». Ce phénomène, également appelé « botsitting », désigne la tâche de vérifier que les résultats produits par l’IA sont exacts, sûrs et donc utilisables. L’article cite notamment une étude de Workday auprès de 3 200 employés et dirigeants, selon laquelle 37 % du temps gagné par l’IA étaient réinvestis dans la vérification, la correction, la clarification ou la réécriture des résultats.

Ce goulot est d’autant plus complexe que les modèles progressent et accomplissent de nouvelles tâches. Si les sorties des LLM se font plus riches et plus complexes, la vérification devra évoluer également. Interrogé, Ian Stoica, professeur d’informatique à l’université de Berkeley (Californie), résume le problème : « Vous ne pouvez pas vérifier si vous ne comprenez pas le problème ». Le niveau d’expertise devra donc lui aussi évoluer.

Le cas particulier du logiciel

Ce goulot d’étranglement se retrouverait particulièrement dans le domaine du logiciel, sans doute le domaine d’application le plus avancé de l’IA aujourd’hui. Si l’on retourne en juin, une étude MIT-Wharton mettait ainsi en avant une hausse de 180 % de l’activité de programmation par l’utilisation d’agents asynchrones, mais cette dernière ne se traduirait que par une augmentation de 30 % du nombre de versions effectivement publiées.

Selon l’étude, ce n’est pas une surprise, car le résultat de chaque étape dans la chaine complète de production doit être combiné avec l’effort humain nécessaire à l’étape suivante. Ainsi le code produit par l’IA doit encore être vérifié, intégré, testé et publié. L’expertise et le jugement humains ont un coût, qui s’intercale entre toutes les étapes. L’étude faisait également ressortir un autre indicateur intéressant : ces efforts ne se traduisent pas par une hausse de l’utilisation finale des produits. Même en mettant de côté l’inévitable adaptation des processus, l’attention des consommateurs reste une ressource rare, d’autant plus dans un monde foisonnant d’opportunités nouvelles.

Le 9 octobre, Ars Technica relayait une autre étude, cette fois de deux économistes d’Harvard, Fiona Chen et James Stratton, et traitant des goulots d’étranglement dans le domaine du logiciel. Si celle du MIT-Wharton travaillait sur les historiques de GitHub et les données internes de Microsoft, celle des deux économistes se base sur les tickets et les grands ensembles fonctionnels résolus dans Jira, plutôt que les versions publiées.

Pourtant, dans les grandes lignes, les constatations sont les mêmes. L’étude d’Harvard met ainsi en avant une hausse de 30 % de la production de lignes de code, de 20 % dans les validations et de 23 % pour les demandes de fusions, mais aucun changement statistiquement significatif dans la résolution des tickets.

Si les signaux semblent tous aller dans le même sens, ils jettent ainsi un éclairage plus cru sur l’un des éléments pointés par Torsten Slok. Le chiffre d’affaires par salarié chez les « sept magnifiques » apparait ainsi comme une conséquence des ventes de services IA et d’infrastructures, mais pas directement d’un gain de productivité.

Panique au guichet

Les grandes banques américaines voient les agents IA d’un mauvais œil – ils sont même perçus comme un cauchemar par le secteur bancaire US : il est non seulement très difficile de les distinguer d’un utilisateur humain, mais en plus ils pourraient prendre des décisions financières préjudiciables à leurs clients.

Armés des identifiants de connexion de leurs utilisateurs humains, et autorisés à agir en leur nom, les assistants IA ont une grande latitude pour prendre des décisions par eux-mêmes. C’est un problème pour Amazon, qui ne veut plus voir Muse, l’agent de Meta, fureter dans les allées de son supermarché virtuel. Les banques américaines s’alarment aussi du phénomène.

Des assistants indésirables pour les banques

Morgan Stanley, Bank of America, JPMorgan, Wells Fargo et d’autres cherchent à interdire l’accès des agents IA, comme le rapporte Axios. Les utilisateurs donnent l’autorisation aux agents d’accéder à leurs comptes bancaires, mais c’est une pratique qui contrevient aux règles de la plupart des établissements américains. Ces derniers exigent en effet que ce soient les titulaires qui se connectent eux-mêmes.

Des banques ont constaté des accès non autorisés par des agents, qui peuvent décider de transférer des fonds ou de réaliser telle ou telle opération. Elles ont aussi repéré certains cas où un agent contacte un centre d’appels, ou agit sans instruction de l’utilisateur. Une situation qualifiée d’« effrayante » par des dirigeants.

Un d’entre eux a déclaré à nos confrères que le secteur était très préoccupé par la possibilité que des agents effectuent des opérations susceptibles d’avoir des conséquences négatives sur les finances de leurs clients. Des restrictions d’accès, et même des blocages, ont été mis en place – même s’il est très difficile de distinguer un agent d’un humain.

La banque Chase recommande à ses clients de ne pas communiquer leurs identifiants et mots de passe à qui que ce soit, y compris un agent. Morgan Stanley indique de son côté n’avoir pas encore constaté « d’agents incontrôlés accédant à [ses] plateformes ».

Une ouverture sous conditions

Toutes les portes ne sont pas fermées pour autant. Beaucoup de banques autorisent les agents IA à lire des informations dans les comptes clients, par exemple pour des logiciels de gestion de finances comme Quicken. Réaliser des opérations est une toute autre affaire. C’est pourquoi le secteur cherche une troisième voie pas simple à trouver.

En Europe, la directive DSP2 distingue la consultation des données et la mise en œuvre de paiement par des prestataires habilités. Un cadre qui ne donne pas pour autant carte blanche aux assistants IA ayant entre leurs mains virtuelles les informations de connexion des utilisateurs.

La Bundesbank a publié en septembre dernier un rapport sur les risques liés aux paiements autonomes (achats indésirables, erreurs de paiement, opérations effectuées sans mandat). L’institution allemande recommande une identification fiable des agents, une traçabilité des opérations et des mécanismes d’intervention humaine.

• 1Password permet aux agents d’utiliser les mots de passe, mais sans les voir

Coucou Amazon, coucou NVIDIA

Alors qu’AWS vient de lancer son TorchNeuron pour permettre aux entreprises intéressées d’entrainer leurs modèles sur les puces maison Trainium, Google a fait une annonce similaire avec TorchTPU. Comme le nom l’indique, il s’agit cette fois d’orienter les calculs vers les puces TPU fournies par Google. Celle-ci met cependant en avant son partenariat avec Meta pour PyTorch.

Google propose désormais sa propre pile logicielle permettant d’exécuter PyTorch directement sur ses TPU, sans passer par une couche d’adaptation. L’annonce, faite durant la PyTorch Conference 2026, suit de près celle d’Amazon Web Services avec son TorchNeuron.

• Avec TorchNeuron, Amazon veut faciliter l’entraînement des modèles sur ses puces Trainium

Rappelons que PyTorch est une bibliothèque permettant, entre autres, de construire et d’entrainer des modèles IA. Comme nous l’indiquions dans notre actualité sur TorchNeuron, PyTorch a besoin d’une couche intermédiaire pour traduire les opérations en instructions reconnues par le matériel. Dans la grande majorité des cas, cette couche est CUDA, une technologie propriétaire que NVIDIA travaille depuis longtemps pour s’assurer que tous types de calculs pourront être exécutés sur ses GPU.

• Pourquoi tout le monde se jette encore sur les GPU NVIDIA pour l’IA

Au tour des puces TPU

Si l’objectif d’AWS avec TorchNeuron était de pouvoir rediriger ces calculs facilement vers ses puces Trainium, Google fait maintenant de même avec ses TPU.

• Avec ses TPU Ironwood, Google passe à « l’ère de l’inférence »… avec de gros chiffres

Jusqu’à présent, pour exploiter ces puces dans le cloud de Google depuis PyTorch, il fallait passer par XLA, une solution que Google présente désormais comme peu naturelle. Le dépôt GitHub de XLA a d’ailleurs été mis à jour pour indiquer que le projet est à présent déprécié et remplacé par TorchTPU. Il sera archivé le 15 novembre, tout va donc aller très vite.

Le dépôt de TorchTPU est bien sûr déjà en ligne, le projet étant sous licence Apache 2.0 et donc open source. Deux modes d’exécution sont proposés. Le premier, eager, consiste à exécuter immédiatement le programme ligne par ligne, un cas jugé notamment utile pour chercher une erreur. Le second, torch.compile, analyse au contraire l’ensemble du programme avant de l’exécuter. TorchTPU permet de commencer avec le premier et de basculer dans le second si besoin.

Comme pour TorchNeuron, TorchTPU permet d’utiliser les puces de Google aussi bien pour l’entraînement que pour l’inférence. Google met largement en avant la compatibilité avec l’écosystème existant. TorchTitan, conçu pour répartir les calculs d’entraînement sur des milliers de puces, est par exemple de la partie. Selon Google, son fonctionnement a affiché une montée en charge linéaire jusqu’à 8 129 TPU. VeRL, pour l’apprentissage par renforcement, Ray, pour la répartition des étapes des chaînes de traitement, vLLM, un serveur faisant tourner les modèles de langage, ou encore SDLang et llm-d sont cités.

Pour Google, il s’agit d’un point clé dans son annonce. Cette logique de compatibilité apparait clairement dans plusieurs cas. Pour vLLM et SGLang par exemple, l’annonce précise que les ordonnanceurs, les modèles de travail et les serveurs d’API d’origine sont conservés, et que les piles d’inférence existantes peuvent être reprises telles quelles. Pour VeRL, le code des modèles et des algorithmes reste indépendant du matériel. Pour Hugging Face, également de la partie, un paramètre (device_map= »tpu ») suffit.

Le même goulot que chez Amazon

Les problématiques et les enjeux sont à peu près les mêmes que chez AWS. Google a tout intérêt à appuyer dans cette direction pour réduire la dépendance très présente de l’écosystème IA à NVIDIA. En réduisant autant que possible les frictions à utiliser les puces TPU, Google cherche donc à s’assurer une nouvelle place de choix dans l’entraînement des modèles comme dans leur inférence.

Il y a tout de même une différence notable dans TorchTPU : Meta participe directement au projet. Ayant créé PyTorch initialement (le projet est géré par la Linux Foundation depuis 2022), l’entreprise reste très impliquée dans son développement. Selon Digitimes, Meta est l’un des plus gros clients de NVIDIA. Elle chercherait donc activement à réduire sa dépendance, l’entreprise ayant également testé la location de capacité TPU auprès de Google Cloud.

Notez que Google, pas plus qu’Amazon, ne parle ouvertement de lutte contre NVIDIA. Mais il est difficile d’évoquer un PyTorch « plus indépendant » sans faire un clin d’œil à la firme de Santa Clara.

Alors que les élections de midterms approchent aux États-Unis (3 novembre), l’IA fait partie des sujets les plus importants dans la campagne électorale. L’installation des datacenters IA est notamment devenue un boulet électoral pour les républicains.

Jusque-là, Donald Trump faisait la sourde oreille et soutenait l’industrie de l’IA. Il a encore récemment enterré toute régulation de l’IA, misant sur la « responsabilité » des acteurs.

Le dirigeant états-unien a réagi ce mercredi 21 octobre à l’impopularité croissante de l’installation des datacenters IA. Il affirmé sur Truth Social : « J’ai imposé aux nouveaux centres de données, de grande taille, voire gigantesques dans certains cas, de produire leur propre électricité et de céder ou de vendre tout excédent à la communauté locale ou au réseau électrique, ce qui entraîne une hausse du prix de l’électricité. En fait, on pourrait assister à une baisse considérable. ».

Mais la réaction du leader du parti Républicain arrive bien tard. En effet, un nouveau sondage de l’Institut Ipsos pour le Washington Post et ABC News auprès de 2 545 Américains montre que 57 % d’entre eux pensent que l’IA est une mauvaise chose pour la société alors que 50 % pensent qu’elle est une bonne chose pour eux, personnellement.

Deux tiers des sondés estiment que le gouvernement fédéral des États-Unis ne régule pas assez l’IA alors qu’ils ne sont que 9 % à penser qu’il régule trop cette technologie.

Si l’industrie insiste régulièrement sur de supposés risques d’extinction des humains dus à l’intelligence artificielle, les sondés sont plus inquiets du piratage de la sécurité des systèmes informatiques, des capacités des utilisateurs à prendre leurs propres décisions et de la suppression des emplois et de la montée des inégalités économiques :

Quand on leur demande en quoi l’IA peut apporter de bonnes choses, les Américains interrogés citent d’abord à 34 % le fait qu’elle pourrait avoir de grandes chances de faciliter les tâches du quotidien plus facilement et accentuer la domination de leur pays dans le domaine. Ils ne sont que 20 % à penser qu’il y a de grandes chances qu’elle permette aux personnes d’être plus productives. De même, peu d’entre eux (13 %) pensent qu’il est fortement possible que l’IA permette la création de nombreux emplois :

Réécrivons tout en Rust

OpenAI a de nouvelles envies de conquête, cette fois dans le champ de ce qu’elle nomme « les langages à faibles ressources ». L’entreprise vise explicitement cette fois les vieux, voire très vieux langages, au premier rang desquels le COBOL. La promesse est de faire exploser le nombre de projets de migration grâce à ses soins.

Selon OpenAI, les dernières avancées de ses modèles ont renforcé leurs capacités à créer et à migrer des logiciels dans des langages comme COBOL, Fortran et Visual Basic. Des langages dits « à faibles ressources », car ils ont moins de code et de documentation pour entrainer les modèles que d’autres bien plus courants comme Python et JavaScript.

« COBOL fait fonctionner⁠ plus de 40 % des systèmes bancaires en ligne, 80 % des transactions par carte de crédit en personne et 95 % des transactions aux distributeurs automatiques », indique OpenAI, montrant l’ampleur du marché. Des chiffres familiers ? Nous avions les mêmes dans notre article de juillet 2025 consacré au COBOL et à sa présence toujours importante. Ils sont issus d’une enquête réalisée par Reuters en 2024. Dans notre article, nous montrions d’ailleurs que le langage restait vivant, mais qu’il y avait un déficit de développeurs formés à ce langage. Fortran, utilisé pour les prévisions météorologiques⁠ et l’analyse de sûreté des réacteurs nucléaires⁠, fait aussi partie des langages visés.

OpenAI dit avoir reçu de nombreux retours sur la difficulté à travailler avec l’IA sur ces langages. « La documentation peut être incomplète, les développeurs d’origine peuvent avoir quitté l’entreprise, et des règles métier importantes peuvent n’exister que dans le code », indique OpenAI. Autant de problématiques que nous avions abordées dans notre article.

OpenAI s’est fabriqué deux évaluations

L’entreprise souhaitait savoir si ses modèles avaient progressé. La question est presque rhétorique : le billet d’OpenAI est là pour montrer à quel point ses LLM ont justement progressé.

Pour les mesurer, OpenAI dit avoir créé deux évaluations. La première, MultiLang, vérifie si un modèle peut créer un moteur de base de données compatible avec SQLite dans 20 langages, en partant d’une page blanche. La seconde est une évaluation plus spécifique aux migrations COBOL pour vérifier si le modèle peut migrer des programmes existants en préservant leur comportement. En somme, l’une vérifie la création de nouveaux logiciels, tandis que l’autre s’assure que les migrations réussissent.

Sans surprise, OpenAI indique que les progrès de ses modèles sont « considérables ». Astra a ainsi atteint un score de 87,4 % sur le premier test en moyenne, contre 26,8 % pour GPT-5.6 Sol, avec des progrès sur l’ensemble des 20 langages. « GPT‑6 Luna surpasse également GPT‑5.6 Sol, atteignant 40,3 % pour un coût estimé de l’API inférieur d’environ 78 % », ajoute OpenAI.

Les règles particulières du COBOL

L’évaluation spécifique au COBOL est plus intéressante, car le problème initial est plus complexe. OpenAI rappelle ainsi que la réussite d’une migration dépend d’une pleine compréhension de la logique métier et des comportements propres au langage. « Par exemple, l’arithmétique à virgule fixe de COBOL supprime les décimales excédentaires, sauf si un arrondi est explicitement demandé. Une réécriture qui arrondit ces valeurs à la place peut s’exécuter sans erreur tout en produisant des résultats financiers différents », affirme l’entreprise.

La vérification se base sur des « tests cachés » qui exigent des sorties observables identiques, à l’octet près. La migration n’est considérée réussie que si tous les tests sont validés. Dans le cas présent, les projets en COBOL devaient être convertis en C++, Java, Kotlin, Python ou Rust.

Dans cette évaluation, GPT‑6.1 Sol a atteint 86,6 % d’exactitude avec un faible effort de raisonnement, contre à peine 5,4 % pour GPT‑5.6 Sol, le tout avec un coût inférieur de 39 %. OpenAI ajoute qu’avec un effort de raisonnement plus élevé (on ne connait pas l’effort de départ), le score grimpe à 97,9 %.

Le message est donc clair : on peut utiliser Astra et GPT-6.1 Sol pour migrer les projets ou en bâtir de nouveaux compatibles. Une conclusion qu’OpenAI met d’autant plus en avant que l’IA fait exploser depuis plusieurs mois les projets de réécriture, de nombreux développeurs (confirmés ou en herbe) se lançant notamment dans une course aux performances.

OpenAI ajoute toutefois que même si les résultats obtenus vont dans le bon sens, « leur application à des logiciels en production exige toujours une vérification par des experts et des tests tenant compte des règles métier et des dépendances du système ».

Des résultats à prendre avec des pincettes

Le principal problème de cette annonce est son opacité. C’est particulièrement vrai dans le cas de COBOL.

On ne sait pratiquement rien en effet de l’évaluation construite par OpenAI, alors que MultiLang a son dépôt GitHub. Rien sur le nombre de programmes, leur origine, leur taille ou même leur degré de ressemblance avec du COBOL réellement utilisé en production. L’évaluation étant opaque, elle ne peut pas être reproduite par des tiers indépendants et il faut donc croire OpenAI sur parole. Que les modèles progressent sur des langages comme COBOL ou Fortran ne fait pas de doute, mais il est difficile de se rendre compte de l’évolution concrète sur la seule base des affirmations d’OpenAI, les évaluations étant proposées par la même entreprise qui propose les modèles testés.

Notons également que les deux évaluations envisagent des tests très différents dans leur approche. SQLite est un projet présent depuis longtemps et aux nombreuses réimplémentations, des portages existant dans plusieurs des langages testés. Il n’est donc pas étonnant qu’un modèle récent s’en sorte bien, puisqu’il restitue en partie des connaissances présentes dans les données d’entraînement. À l’inverse, la situation est plus complexe pour COBOL, Fortran et d’autres anciens langages, les ressources étant nettement moins nombreuses.

Toujours des noms simples à prononcer

Mistral a lancé récemment deux modèles spécialisés, Voxtral 3 pour transcription et la synthèse vocale et Timestral pour les « séries temporelles ». Ce dernier doit permettre des prévisions sans réentrainement.

Mistral avait lancé son premier modèle Voxtral en juillet 2025. Il s’agissait alors de son premier modèle audio, que Mistral mettait en avant comme plus performant et moins cher que les solutions concurrentes. Plusieurs tailles étaient proposées, selon la durée des contenus audio que l’on souhaitait traiter.

Ce LLM spécialisé a beaucoup évolué, puisque la version 3 est maintenant disponible. La communication de Mistral braque largement les projecteurs sur les agents. Selon l’entreprise française, un agent vocal fiable doit ainsi maitriser quatre capacités : écouter avec précision, raisonner en profondeur sur ce que les utilisateurs veulent dans un contexte donné, parler naturellement et agir en plusieurs étapes.

Un SDK d’agents locaux

Voxtral 3 est la réponse de Mistral à ces quatre objectifs, dont un fonctionnement fiable et en temps réel « reste un défi ». Voxtral 3, comme le premier, désigne une famille de modèles spécialisés dans la reconnaissance et la synthèse vocales. Cette fois, elle est accompagnée d’un SDK (kit de développement logiciel) pour utiliser des agents locaux. Le SDK (bâti sur LiveKit) réunit dans un même pipeline de traitement l’écoute, la réflexion, l’appel d’outils et la parole.

La famille compte quatre modèles :

• Small Transcribe 3 : transcription groupée de meilleure précision, 50 langues, à 0,004 dollar la minute
• Mini Transcribe 3 : 4 milliards de paramètres, 0,0035 dollar la minute
• Mini Transcribe Realtime 3 : transcription en direct, latence revendiquée à moins de 500 ms, 0,008 dollar la minute
• Voxtral Speech 3 (ou Mini TTS 3.0) : synthèse vocale, plus de 35 langues et 50 dialectes, 13 dollars le million de caractères

Mistral vante l’émotion dans la voix pour « sonner naturellement » (prosodie, rythme, débit, accentuation et transitions), les performances en diarisation (reconnaître qui parle) et la prise en charge des biais contextuels. Pour ce dernier point, Mistral précise que l’on peut ainsi fournir des termes clés et du texte libre pour « orienter la transcription et améliorer le rappel des termes techniques ». L’entreprise ajoute le support de la prédiction de fin de tour, les modèles étant capables de prédire quand une personne a fini de parler, en se basant sur des informations acoustiques et sémantiques.

Selon l’annonce, les performances de ces modèles sont à « l’état de l’art », dépassant de nombreuses références du secteur, dont Whisper d’OpenAI. L’agent complet, lui, est facturé 0,04 dollar la minute avec Small et 0,08 dollar avec un autre modèle de raisonnement. L’accès se fait via l’API de Mistral ou depuis l’infrastructure sur site.

Signalons que les quatre modèles sont en préversion publique et que certaines informations manquent. Par exemple, la taille de Small n’est pas donnée. En outre, aucun poids ouvert n’a encore été annoncé. En revanche, les performances revendiquées par Mistral semblent confirmées par Artificial Analysis.

Timestral : c’est quoi des « séries temporelles » ?

Le 15 octobre, Mistral avait également lancé un autre modèle, Timestral, premier représentant d’une nouvelle famille de LLM. Il est spécialisé dans les séries temporelles, c’est-à-dire des séries de mesures datées (capteurs, consommation, flux financiers…), afin d’établir des prévisions.

Timestral est fourni en quatre tailles : 5, 28, 123 et 209 millions de paramètres. Le modèle peut prévoir les séries sans réentraînement sur des données spécifiques, produire des prévisions avec une fourchette d’incertitude (21 quantiles) et accepter jusqu’à 32 768 pas d’historique. Selon Mistral, il peut traiter plusieurs séries liées à la fois ainsi que des facteurs connus à l’avance (calendrier de production, météo, etc.).

Timestral fonctionne également sans carte graphique. Mistral annonce à ce sujet un temps allant de 10 à 140 ms pour prévoir une journée, en fonction de la taille du modèle utilisé, sur un « CPU de serveur standard avec 8 threads » et sur la base de trois semaines d’historique au pas de 15 min. Comme toujours avec la taille des modèles, plus elle est importante, plus la précision augmente et plus le temps de calcul s’allonge.

Le code du modèle est sous licence Apache 2.0. Cependant, comme relevé par Pix Geeks, les poids sont sous une licence MIT modifiée « qui exclut les entreprises dont le chiffre d’affaires mensuel consolidé dépasse 20 millions de dollars. Celles-là doivent demander une licence commerciale à Mistral ou passer par ses services hébergés ». Sous ce seuil, l’utilisation de Timestral est gratuite.

Coucou NVIDIA

Amazon Web Services a présenté un nouveau projet open source, TorchNeuron. Il se propose de simplifier le passage aux puces Trainium d’AWS pour entrainer les modèles. Bien que NVIDIA ne soit pas nommée, le projet est clairement pensé comme une alternative à CUDA.

PyTorch est initialement une bibliothèque logicielle créée par Meta (Facebook à l’époque). Depuis 2022, elle dépend de la Linux Foundation, tant elle est devenue importante. Elle sert en effet à construire et entraîner des modèles d’intelligence artificielle.

Cette bibliothèque est l’une des raisons pour lesquelles NVIDIA est autant sur le devant de la scène aujourd’hui. Entre PyTorch et le matériel utilisé pour les opérations, il faut justement une couche logicielle pour traduire les opérations en instructions que ce matériel peut comprendre. C’est précisément ce que fait CUDA depuis longtemps chez NVIDIA. Cette technologie propriétaire de type GPGPU (General-Purpose Computing on Graphics Processing Units) sert à faire basculer sur le GPU des calculs qui seraient autrement destinés au CPU.

Sans le dire aussi clairement, c’est ce lien fort qu’AWS veut remettre en question avec TorchNeuron, comme le relève notamment TechCrunch.

Direction les puces Trainium

Amazon Web Services dispose de ses propres puces en matière d’IA : les Trainium, dont la troisième génération a été lancée en décembre 2025. Ces puces peuvent servir aussi bien à l’entraînement qu’à l’inférence. Amazon n’est pas la seule entreprise à concevoir ses propres puces dans ce domaine : Microsoft possède Maia et Google a ses TPU (Tensor Process Units).

TorchNeuron est ainsi aux puces Trainium ce que CUDA est à NVIDIA, une couche de traduction. Elle s’appuie sur le mécanisme d’extension que PyTorch propose pour accueillir du matériel tiers et propose aux développeurs – dans le cas le plus simple – de remplacer dans leur code le périphérique cible cuda par neuron.

Est-ce aussi simple ? En théorie oui, mais l’exemple cité par AWS montre que la situation est plus complexe en pratique. Le billet évoque en effet le cas de Deepgram, un concurrent d’ElevenLabs dans le secteur de la synthèse vocale. Ainsi, non seulement certaines fonctions de PyTorch ne sont pas encore prises en charge, mais une partie des tests officiels de PyTorch est tout simplement ignorée, faute de traduction d’une partie des opérateurs de calcul. Deepgram est mis en avant comme ayant réussi à obtenir 70 % d’audio en plus pour chaque dollar dépensé, mais la mise en place de ce flux de travail a nécessité plusieurs mois de travail.

Boire au goulot

Officiellement, Amazon met en avant la réduction du coût de changement de puce pour les développeurs. Ces derniers seraient ainsi plus libres de comparer les options qui s’offrent à eux. Si l’on peut changer de puce sans pénalité particulière, les fabricants doivent mériter la clientèle, affirme même Amazon.

Auprès de TechCrunch, Colin Brace d’Annapurna Labs (la filiale qui conçoit les puces d’Amazon) met bien sûr en avant l’infrastructure et l’écosystème d’AWS. En outre, le responsable pointe la possibilité d’utiliser la même puce pour l’entraînement et l’inférence, avec à la clé la possibilité de réaffecter la capacité inutilisée.

La lutte contre la dépendance à NVIDIA s’inscrit en filigrane dans l’annonce, de manière plus ou moins intense selon les passages. L’un d’entre eux est cependant très clair : « L’approche d’Amazon va au-delà de son propre matériel. L’entreprise apporte des modifications en amont de PyTorch lui-même, en travaillant avec la communauté PyTorch pour supprimer le code liant le framework à des puces spécifiques. L’objectif est de rendre PyTorch plus indépendant du matériel pour toute la communauté des développeurs, pas seulement pour les utilisateurs de Trainium ». Une précision qui n’est pas tellement « pour » les utilisateurs de Trainium que « contre » NVIDIA, car cette dépendance peut signifier une configuration plus longue.

Cette lutte à peine voilée n’est pas le seul élément masqué. Sans même parler d’arracher les clients à un écosystème pour les plonger dans le sien, Amazon doit se débarrasser d’un goulot d’étranglement. L’intérêt des puces Trainium est en effet d’autant plus réduit que les clients ne peuvent pas les utiliser facilement. C’est ce goulot que NeuronTorch doit essayer de lever. AWS essaye donc de réaliser un coup double : réduire les spécificités de PyTorch pour CUDA et fluidifier l’accès à ses puces.

TorchNeuron est cependant un projet neuf. Le code est présenté sous licence Apache 2.0 (open source) dans un dépôt GitHub ouvert le 17 octobre, même si AWS annonce sa disponibilité pour le 20 octobre. Dans sa forme actuelle, le projet prend en charge les puces Trainium 2 et 3. Reste pour Amazon à concrétiser sa vision en alimentant son projet, dont le succès dépendra de l’adoption par les développeurs concernés.

La direction générale de l’administration et de la fonction publique (DGAFP) a présenté sa revue stratégique de la fonction publique à l’horizon 2035 - 2050. Parmi les « grandes transitions » que la fonction publique doit absorber, le numérique et l’IA figurent en bonne place, avec la transition démographique, la transition écologique ou encore l’instabilité sécuritaire croissante.

Le rapport consacre quatre pages au numérique et à l’IA, dans lesquelles la DGAFP fait notamment un constat problématique : si 82 % des démarches administratives peuvent aujourd’hui se faire en ligne, 44 % des personnes interrogées ont déclaré avoir des difficultés à les faire. La direction générale en conclut qu’un accueil humain, au guichet ou au téléphone, reste nécessaire, surtout pour les publics fragiles et les dossiers complexes. Elle ajoute que le numérique doit servir à dégager du temps pour l’accompagnement individualisé, pas à supprimer des postes d’agents de la fonction publique.

Le même rapport aborde la dépendance de l’État envers ses prestataires informatiques. Dans ce domaine, il reprend la recommandation de la Dinum (Direction interministérielle du numérique) d’un seuil minimal d’emploi interne de 37 %. Cependant, il le compare à la moyenne mondiale de 67 %, tous secteurs confondus.

Dans ce domaine, l’Espagne est érigée en exemple. Nos voisins ont ainsi mis en place un vaste plan de numérisation sur la période 2021 - 2025, doté d’un budget de 2,6 milliards d’euros. L’objectif sur 2026 était ensuite l’ouverture de 1 700 postes dans les corps de fonctionnaires du numérique. Des spécialités en IA, cybersécurité et science des données y apparaissent pour la première fois. Le rapport de la DGAFP préconise ainsi une forte réinternalisation des compétences.

L’exposition à l’IA, selon le rapport, varie très fortement selon les secteurs. Plus de la moitié des agents seraient très peu concernés, l’exposition se concentrant dans les fonctions administratives et de support. 20 % des agents seraient en revanche significativement exposés, soit 1,1 million de personnes.

Selon la DGAFP, « l’IA transformerait davantage les tâches que les métiers dans leur ensemble ». La direction générale estime que le temps libéré par l’IA devrait être réaffecté vers « l’expertise, le contrôle et la relation aux usagers ». Elle ajoute que des formations, mobilités voire reconversions devront être organisées. De plus, le déploiement de l’IA va « contribuer à une recomposition profonde des emplois et une évolution des modalités de recrutement pour privilégier l’esprit critique sur la capacité de synthèse, par exemple ».

Moi, moche et virtualisé

Apple a publié un article de recherche sur Minions, une infrastructure permettant d’agréger les ressources GPU inutilisées sur des grappes de Mac dotés de puce Apple Silicon. Si le concept n’a rien de nouveau, les travaux d’Apple prolongent l’existant et inscrivent un peu plus les Mac dans le paysage de l’IA.

Les Mac sont décidément appréciés par les entreprises désireuses de faire tourner localement des LLM plus ou moins gros. Pourquoi les Mac ? Parce qu’ils embarquent une mémoire dite « unifiée », servant à la fois pour les parties CPU et GPU des puces Apple Silicon. Si votre Mac est équipé de 32 Go de mémoire vive, le GPU peut puiser dedans. Cette mémoire est certes moins rapide que la VRAM des cartes graphiques dédiées (sans même parler de la HBM), mais ce scénario d’usage compense par le volume.

Apple sait que ses Mac Mini et Studio partent comme des petits pains auprès d’entreprises comme OpenAI, Anthropic et Meta. C’est dans ce contexte qu’elle a mis en ligne un document de recherche (prépublication sur Arxiv) exposant le fonctionnement de Minions, une infrastructure GPU virtuelle dédiée aux charges d’inférence d’apprentissage automatique à grande échelle.

Rassembler l’inaction

L’architecture proposée repose sur quatre éléments. D’abord, un serveur central reçoit les requêtes via une interface web ou des API (REST). Il s’occupe de les valider puis de les découper de manière asynchrone en sous-tâches stockées dans une base PostgreSQL. En d’autres termes, le serveur est chargé de créer une file d’attente.

Ensuite, les exécuteurs. Ils tournent sur les Mac mis à contribution et traitent localement les sous-tâches sur le GPU, avant d’écrire le résultat des calculs dans une zone de stockage S3. Ils n’accèdent jamais directement à la base PostgreSQL : ils réservent des sous-tâches en utilisant l’API du serveur, via une table de la base dotée d’une contrainte d’unicité. Même chose pour mettre à jour l’état de la base, envoyer leur signal de vie (un message bref envoyé au superviseur pour indiquer qu’il fonctionne encore) et livrer leurs résultats.

Le superviseur, justement, est ici nommé « Watchdog » (littéralement « chien de garde »). Son rôle est de surveiller les exécuteurs en cours de traitement et de remettre en file d’attente les sous-tâches des exécuteurs devenus muets. Ce silence peut provenir de multiples causes : perte réseau, veille, extinction, arrêt volontaire, etc. Ce fonctionnement autorise donc une certaine souplesse.

Quant au dernier composant, c’est tout simplement le tableau de bord pour le suivi de l’ensemble en temps réel.

De fortes limitations

Le tout permet, comme relevé par Apple Insider, de mettre à disposition la puissance inutilisée des GPU pour les mettre à contribution lors d’un travail d’inférence. Ainsi, des équipes qui lancent de grands lots asynchrones d’inférence (index de recherche, génération de texte en masse pour l’évaluation ou l’étiquetage…) n’ont plus besoin d’attendre qu’une grappe de GPU se libère. C’est du moins le fonctionnement sur le papier.

Si le document est intéressant dans le fond, il est aussi très court. Apple ne fournit aucune information mesurée : pas de tests de débits, pas de coût énergétique, de taux de reprise ou aucune comparaison quelle qu’elle soit. Il est donc difficile de se rendre compte des performances.

Les cas présentés ont également un périmètre limité. La publication n’évoque que deux types de charges : les modèles de vecteurs de représentation chargés via la bibliothèque Transformers de Hugging Face, et la génération de texte via Ollama. Il n’y a pas d’ordonnanceur central, il ne s’agit donc pas d’un modèle découpé et réparti entre les machines.

En fait, chaque exécuteur doit pouvoir faire tourner intégralement le modèle en local, ce qui limite d’autant les cas. La mémoire a beau être universelle sur les Mac Apple Silicon, sa quantité détermine directement ce que l’on peut y faire résider. Pas question par exemple d’y faire tourner le tout récent Muse Spark Open.

• Avec Muse Spark Open, Meta ouvre les poids et se rapproche d’Apple

Et si vous vous posez la question : non, l’entrainement n’est pas pris en charge, en tout cas pour l’instant. Apple compte prendre en charge l’entraînement distribué à l’avenir, sans plus de détails.

Quel intérêt ?

Au sein d’une organisation, l’infrastructure présentée peut avoir des avantages, mais il ne s’agit pas d’un projet « magique » capable de fonctionner avec tous les modèles. Il y a quand même plusieurs avantages : pas d’achat de GPU dédiés, un coût d’infrastructure considéré comme « nul », une capacité générale qui grandit avec le nombre de Mac présents sur place, ou encore un fonctionnement local puisque les données ne sortent pas de l’organisation.

L’intérêt d’Apple est d’avancer discrètement sur l’argument commercial que les Mac sont des machines taillées pour l’IA. Sur ce point, la présentation de Minions rejoint les annonces autour de Muse Spark Open et du rapprochement avec Meta, Apple ayant publié des mesures et de la documentation MLX.

En filigrane, le papier raconte également une autre histoire : celle des propres limites d’Apple. L’entreprise le dit elle-même dans son article, elle manque de GPU centraux. Ainsi, avant que Minions ne soit utilisé (montrant au passage que l’infrastructure n’est pas que théorique), certaines tâches d’inférence pouvaient attendre plus de 10 heures avant de commencer. Avec Minions, le temps ne serait plus que de quelques minutes, mais Apple ne donne aucun détail supplémentaire.

Dans l’absolu, Minions ne crée aucune rupture, car la récupération de cycles, le calcul bénévole ou encore l’inférence répartie existent déjà. C’est dans les grandes lignes le schéma adopté par l’infrastructure de calcul distribué BOINC, qui exploite les GPU depuis vingt ans. On peut également citer Petals pour répartir un grand modèle en blocs de couches sur des machines bénévoles réparties sur internet. Mais l’idée pourrait séduire les organisations déjà dotées de nombreux Mac, surtout s’ils sont récents et accompagnés d’une bonne quantité de mémoire.

« Plus largement, Minions ouvre une perspective inédite pour la communauté de l’apprentissage automatique : si les appareils macOS inactifs, à l’échelle de plusieurs organisations, voire de la communauté mondiale, pouvaient être fédérés de manière sûre, ils formeraient un vaste parc de GPU partagé, au bénéfice de l’ensemble de l’écosystème », indique Apple dans une conclusion plus ambitieuse.

Poids ouverts pour le poids lourd

Avec Muse Spark Open, Meta revient à ses premières amours, c’est à dire les modèles IA à poids ouverts. Et pour faire tourner ce poids lourd en local, l’entreprise s’est trouvé un partenaire inattendu : Apple.

Avec son ancienne famille de modèles Llama, Meta pensait avoir trouvé la botte secrète face aux LLM propriétaires d’OpenAI, d’Anthropic ou de Google : des modèles à poids ouverts, autrement dit qu’il est possible de télécharger et d’exploiter en local (sous certaines conditions). Patatras : la version 4 des modèles Llama livrée en avril 2025 a été entachée par des accusations de manipulation de benchmarks.

Derrière les modèles chinois

Piqué au vif, Mark Zuckerberg a décidé de tout remettre à plat et de créer de toutes pièces un nouveau labo dont les membres ont été débauchés à prix d’or partout dans la Silicon Valley et au-delà. Les premiers résultats sont apparus un an plus tard avec Muse Spark, un modèle… fermé.

L’idée des poids ouverts n’était cependant pas perdue. Alors que le débat autour des modèles ouverts battait son plein cet été, Meta livrait Muse Glimmer, un modèle déjà conséquent de 30 milliards de paramètres assorti d’une licence open source permissive (Apache 2.0). L’entreprise en rajoute une couche avec Muse Spark Open, « le modèle à poids ouverts américain le plus capable ».

Muse Spark Open est un modèle multimodal de 816 milliards de paramètres (42 milliards actifs pour chaque token utilisé selon une architecture Mixture of Experts) avec une fenêtre de contexte de 1 million de tokens, autrement dit la quantité d’informations qu’il peut prendre en compte durant une interaction. C’est désormais courant pour les modèles frontières, y compris Muse Wonder. Spark Open accepte du texte, des images, de la vidéo et de l’audio en entrée, mais il ne génère que du texte.

Meta présente Spark Open comme « conçu pour la programmation et les tâches agentiques », avec une prédilection pour « les travaux de longue haleine, le développement logiciel complexe et le raisonnement en plusieurs étapes. » Face à des modèles à poids ouverts concurrents, il figure en tête dans deux des trois benchmarks sur les tâches agentiques (JobBench et MCP-Atlas). Sur GDPval-AA v2 en revanche, il est dépassé par trois modèles chinois et Mistral Large 4.

En matière de programmation, Spark Open n’occupe aucune première place du podium : il est derrière quatre rivaux sur Terminal-Bench 2.1, et il se trouve dans la moyenne sur DeepSWE. Le modèle affiche de bons résultats sur les tests de connaissances et de raisonnement, et il se montre solide sur le multimodal. En tout, sur onze benchs, Meta décroche six premières places. Il manque également au tableau ses comparaisons avec les modèles fermés d’OpenAI et d’Anthropic.

Deux Mac Studio pour un modèle poids lourd

Le modèle donnera la pleine mesure de son talent sur le Mac Studio avec puce M5 Ultra, et même deux. Meta et Apple ont en effet travaillé ensemble pour que Spark Open exploite à plein le GPU intégré au silicium Apple, sa mémoire unifiée et la bande passante de la puce (jusqu’à 1,2 To/s).

Connecter deux Mac Studio dotés de 512 Go de mémoire permet de répartir le modèle entre les deux machines, qui disposent ainsi d’un téraoctet de mémoire au total : les 816 milliards de paramètres , stockés dans une version quantifiée en 4 bits, restent ainsi disponibles en mémoire (même si 42 milliards sont réellement mobilisés pour chaque token traité).

On parle d’une configuration qui devrait aisément dépasser les 30 000 euros pour deux Mac Studio M5 Ultra, Apple n’ayant pas encore annoncé le prix de l’option mémoire de 512 Go… Et Meta a indiqué qu’on pouvait même monter à quatre Mac Studio. Le tout est réalisable grâce à MLX, un framework d’Apple qui répartit l’exécution de modèles à poids ouverts entre plusieurs Mac reliés en Thunderbolt 5.

La haine recuite entre les deux entreprises est oubliée : l’IA rapproche donc même les pires ennemis ! « On est ravis que papa et maman s’entendent à nouveau », s’est amusé Alexandr Wang, le patron de l’IA chez Meta, auprès d’Axios. Les deux entreprises ont bûché pendant plusieurs mois pour cette annonce, mais cela ne les empêchera pas de conserver leur rivalité sur d’autres terrains. « Quand il est pertinent de collaborer et de nouer des partenariats, nous voulons pouvoir le faire », ajoute le dirigeant.

Les poids de Muse Spark Open sont disponibles sur Hugging Face. La licence Muse Model n’est pas aussi permissive que celle de Glimmer, même s’il est autorisé de modifier le modèle, de le distiller, de le redistribuer et même d’en vendre des copies sous réserve de respecter la licence et d’afficher une attribution. Certains usages militaires, la création de logiciels malveillants et le contournement des restrictions ou mesures de sécurité sont prohibés. Meta ne revendique aucun droit de propriété sur les sorties du modèle.