Étiquette : programmation

  • Meta Muse Spark Open installe un modèle géant directement sur Mac

    Meta Muse Spark Open installe un modèle géant directement sur Mac

    La plupart des grandes annonces en intelligence artificielle se terminent de la même façon. Une entreprise présente un modèle puissant, puis le public le loue, une question à la fois, en passant par les serveurs de quelqu’un d’autre. Meta a pris la direction opposée le 15 octobre. L’entreprise a publié Muse Spark Open en téléchargement libre, avec l’ensemble de ses paramètres, et l’a présenté comme le modèle ouvert américain le plus performant publié à ce jour. Cette dernière formule vient de Meta elle-même et doit être lue comme telle. Même en laissant l’affirmation de côté, la forme de cette publication reste assez inhabituelle pour compter.

    Commençons par les chiffres, car ils sont grands d’une manière qui demande une seconde pour être mesurée. Muse Spark Open compte 816 milliards de paramètres au total. Seuls environ 42 milliards d’entre eux sont actifs pour chaque unité de texte traitée, ce qui rend un modèle de cette taille utilisable. Sa fenêtre de contexte atteint 1 million d’unités, de quoi contenir un long document, une vaste base de code ou des heures d’échanges dans une seule session. Le modèle est aussi nativement multimodal, conçu dès le départ pour recevoir davantage que du texte simple au lieu de recevoir d’autres sens ajoutés après coup.

    Conçu pour travailler, pas seulement pour répondre

    Meta a orienté ce modèle directement vers la programmation et le travail en agents. Le mot agent désigne une idée simple : au lieu de répondre à une question puis de s’arrêter, le modèle planifie une tâche, enchaîne les étapes, vérifie son propre résultat et continue. C’est la direction que prend déjà une grande partie du travail logiciel. Un outil capable de lire un rapport d’erreur, de trouver le code fautif, d’écrire une correction et de la tester n’a plus grand-chose d’un simple robot conversationnel poli.

    Meta a accompagné la publication de Muse Code, son outil de programmation, et a montré l’ensemble à l’oeuvre sur des tâches réelles. Dans une démonstration, le système travaillait sur Ice Cubes, un client bien connu du réseau Mastodon, en ajoutant des fonctions et en corrigeant des problèmes dans l’application. Dans une autre, il examinait des images dans DaVinci Resolve et s’occupait de travaux de recadrage au montage. Aucune de ces démonstrations ne relève de la magie. Les deux correspondent au genre de tâches minutieuses et en plusieurs étapes qui absorbent un après-midi entier, et c’est exactement le sujet. Si un modèle peut prendre en charge ces tâches avec fiabilité, les gens récupèrent leurs après-midis.

    Les lecteurs qui suivent l’arrivée des machines intelligentes dans la vie quotidienne reconnaîtront le même mouvement que celui raconté dans notre article sur un robot de stationnement présenté en Corée : des systèmes capables quittent les centres de données lointains pour se rapprocher des lieux de vie et de travail. Muse Spark Open représente le bout le plus musclé de ce déplacement.

    La surprise venue d’Apple

    Voici le passage qui a fait lever les sourcils dans tout le secteur. Meta a optimisé Muse Spark Open pour une exécution locale sur Mac grâce à MLX, le cadre d’apprentissage automatique d’Apple, et l’entreprise l’a fait avec l’aide d’Apple. La configuration de référence de Meta frappe les esprits : deux Mac Studio, chacun équipé d’une puce M5 Ultra de 512 gigaoctets. Cette configuration arrive plus tard en octobre, et faire tourner le modèle en local de cette manière demande au moins 1 téraoctet de mémoire au total sur les deux machines.

    Soyons honnêtes sur ce que cela signifie. Il ne s’agit pas encore d’une astuce pour tous les ordinateurs portables. Une paire de Mac Studio haut de gamme représente un achat sérieux. Mais la direction compte davantage que le point de départ. Un modèle de niveau avancé, qui tourne sur du matériel posé sous un bureau, sans qu’aucune question ne quitte le bâtiment, change la liste des personnes qui peuvent expérimenter, construire en privé et travailler dans des lieux où l’envoi de données vers un service en nuage n’est pas une option. Les petits studios, les laboratoires de recherche et les développeurs indépendants attendaient exactement cela depuis des années.

    Mark Zuckerberg a rendu le partenariat explicite en remerciant publiquement John Ternus, le dirigeant d’Apple. Deux entreprises qui se livrent une concurrence intense sur les casques, les téléphones et les plateformes ont travaillé ensemble pour faire bien tourner un modèle d’intelligence artificielle sur les puces d’Apple. Surprenant ? Un peu. Bienvenu ? Entièrement. Les plus belles histoires de technologie naissent souvent de concurrents qui décident qu’un problème partagé, ici faire tourner de très grands modèles sur des machines locales, mérite d’être résolu ensemble.

    Libre à télécharger, avec des conditions à lire

    Les paramètres sont disponibles dès maintenant sur Hugging Face, Amazon SageMaker, Google Cloud Model Garden et Microsoft Foundry. Pour celles et ceux qui préfèrent ne rien héberger eux-mêmes, le modèle est aussi accessible par des interfaces proposées par Baseten, Fireworks AI, Groq, Modal, Nebius, OpenRouter et Together AI. Cette diversité compte. Un étudiant peut y accéder d’une manière, une jeune entreprise d’une autre, et une équipe plus grande peut le brancher sur une infrastructure qu’elle paie déjà.

    Une prudence doit être énoncée clairement : la publication s’accompagne d’une licence d’usage commercial limité. Libre à télécharger ne signifie pas libre de conditions, et toute personne qui envisage de bâtir un produit payant sur Muse Spark Open devrait lire la licence avant d’écrire la moindre ligne de code métier. Ce n’est pas un reproche adressé à cette publication. C’est une pratique normale pour les modèles à paramètres ouverts, et Meta a présenté ses conditions ouvertement.

    Pourquoi cette publication peut bien vieillir

    Les modèles ouverts ont l’habitude de grandir après leur lancement. Les utilisateurs les adaptent, les réduisent, les transforment en nouveaux outils et leur trouvent des usages que l’équipe d’origine n’avait pas imaginés. Un modèle doté d’une fenêtre d’un million d’unités et d’une vraie capacité de programmation donne beaucoup de matière à cette communauté. L’angle Mac pourrait aussi attirer un public qui regardait la scène des modèles ouverts depuis la touche, en attendant un produit qui tourne correctement sur les machines déjà présentes dans ses bureaux.

    Muse Spark Open conservera-t-il le titre que Meta revendique pour lui ? Ses concurrents donneront leur avis dans quelques semaines, sans doute dans quelques jours. Mais la combinaison proposée, une capacité immense, un téléchargement libre, un soutien sérieux au matériel local et un coup de main d’Apple, est réellement nouvelle. Pour une fois, le modèle le plus intéressant de la semaine n’est pas enfermé derrière une liste d’attente. Il se trouve sur Hugging Face, en attente de quelqu’un qui le mette au travail.

  • Claude écrit désormais la plus grande partie de son propre code

    Claude écrit désormais la plus grande partie de son propre code

    Voici une phrase qui aurait ressemblé à un coup de publicité il y a quelques années. Selon Anthropic, Claude écrit désormais environ 90 pour cent du code de Claude Code, l’outil de programmation de l’entreprise. Ce chiffre vient d’un récit publié le 16 octobre 2026 par des membres de l’équipe Claude Code – Osmani, Lunt et Wang – qui décrivent leur manière de construire le produit au quotidien. Simon Willison a signalé ce texte le même jour. L’outil, en grande partie, se construit lui-même.

    Le chiffre de tête attire l’attention. Le changement plus discret en dessous compte davantage. La relecture du code, explique l’équipe, ne se situe plus à la fin du processus, comme un professeur qui corrige des copies après le cours. Elle se déroule en continu, pendant que le code s’écrit, plus proche d’un correcteur orthographique que d’une inspection formelle. La plupart des modifications, rapporte l’équipe, sont relues et corrigées par Claude avant qu’un humain les voie. Relisez cela. L’humain n’est plus le premier lecteur. Il est le deuxième.

    Les chiffres derrière l’affirmation

    Le récit de l’équipe d’Anthropic donne deux chiffres qui donnent forme à l’histoire. Les demandes de fusion acceptées – les morceaux de code qui arrivent réellement dans le produit – ont plus que doublé entre juin et septembre 2026. Dans le même temps, la part des modifications qui ont dû être annulées, c’est-à-dire du travail défait après sa livraison, a chuté de plus de 40 pour cent.

    Ces deux chiffres vont ensemble. Faire arriver plus de code n’a rien d’impressionnant en soi ; n’importe qui peut livrer plus vite en abaissant l’exigence. Ce que l’équipe affirme, c’est la vitesse et un taux d’erreur plus faible en même temps, ce qui est le tour le plus difficile. Si deux fois plus de modifications arrivent et qu’une part plus petite revient en arrière, quelque chose dans le processus lui-même a changé, pas seulement le rythme.

    La relecture entrée dans l’écriture

    La relecture classique a un rythme que la plupart des programmeurs connaissent par coeur. On écrit pendant des heures, parfois des jours. On ouvre une demande de fusion. Un collègue la lit plus tard, fatigué, occupé, en passant d’une tâche à l’autre, et laisse des commentaires. On corrige, on attend, on corrige encore. La boucle peut s’étirer sur une semaine, et quand un vrai problème apparaît, l’auteur a à moitié oublié pourquoi il avait fait le choix que l’on questionne.

    La relecture continue brise ce rythme. Si Claude lit chaque modification au moment où elle apparaît, signale sur-le-champ une hypothèse fragile et propose une correction pendant que le raisonnement est encore frais, la relecture cesse d’être une porte pour devenir une partie de l’acte d’écrire. La comparaison avec le correcteur orthographique, dans le récit de l’équipe, est juste. Personne n’envoie une lettre pour demander ensuite à un ami d’en vérifier l’orthographe. Le soulignement rouge apparaît pendant que les mains sont encore sur le clavier. C’est ce modèle qui s’applique désormais au logiciel, sauf que le soulignement peut aussi s’expliquer et proposer la correction. Cette recherche de fiabilité dès la conception rappelle, dans un autre registre, les vingt ans de travail méthodique pour la planète célébrés à Monte-Carlo, où la constance du contrôle fait la crédibilité du résultat.

    Ce que l’humain fait toujours

    Rien de tout cela ne retire les personnes de la boucle, et le récit de l’équipe ne le prétend pas. Un humain décide toujours de ce que le produit doit faire, regarde toujours après le passage de Claude et porte toujours la responsabilité de ce qui part en production. Le goût, le jugement, le sens du produit : appelez cela comme vous voulez, cela n’a pas été automatisé. Ce qui a changé, c’est l’ordre des opérations. Le premier passage, infatigable, ligne par ligne, appartient à la machine. Le passage humain devient une question d’intention. Est-ce que cela fait la bonne chose, et pas seulement une chose correcte ?

    Cette distinction compte. Vérifier la syntaxe et repérer un cas limite oublié est un travail qu’un relecteur patient fait bien un bon jour et mal un mauvais jour. Décider si une fonction doit exister demande un contexte qu’aucun modèle ne détient seul : la feuille de route, la plainte d’un client au printemps dernier, la promesse faite à un partenaire.

    Pourquoi cela compte au-delà d’Anthropic

    Anthropic dispose ici d’un avantage évident. L’entreprise construit le modèle et l’outil de programmation sous le même toit, donc Claude est testé chaque jour sur un code réel et exigeant. La plupart des équipes n’ont pas ce luxe.

    Le schéma, pourtant, voyage. Toute équipe peut se poser la question soulevée par ce récit : où se fait la vérification dans notre processus, et à quel moment devient-elle trop tardive ? Le même déplacement s’observe dans les logiciels grand public, où les assistants se rapprochent du moment de l’action. L’aide qui arrive pendant la tâche vaut mieux que l’aide qui arrive après. La programmation est l’endroit où la preuve est la plus claire, parce que le code fonctionne ou ne fonctionne pas, et que les chiffres – demandes acceptées en hausse, annulations en baisse – peuvent se compter.

    Quelques réserves honnêtes

    Ces chiffres viennent de la propre équipe d’Anthropic, qui écrit sur son propre produit. Cela ne les rend pas faux, mais ils doivent être lus comme un rapport venu de l’intérieur, pas comme un audit indépendant. D’autres équipes, sur des systèmes plus anciens et plus désordonnés, doivent s’attendre à des résultats plus désordonnés.

    Il y a aussi une vraie question de compétence. Si les jeunes ingénieurs ne font jamais eux-mêmes le lent travail de première relecture, comment développent-ils l’oeil sur lequel les ingénieurs expérimentés s’appuient ? Les équipes auront ce débat, et elles ont raison de l’avoir.

    La leçon pour les équipes qui travaillent

    Retirez le chiffre de tête et une leçon pratique demeure. Déplacez la vérification plus tôt. Rendez le premier passage de relecture rapide, automatique et continu, afin que les relecteurs humains consacrent leur attention à la conception, à l’intention et au risque. Mesurez deux choses à la fois : ce qui part en production, et ce qui revient. La vitesse seule n’est qu’une manière plus rapide de faire du désordre.

    Quatre-vingt-dix pour cent est un chiffre frappant, et il sera cité toute la semaine. Mais le doublement des demandes de fusion acceptées, accompagné d’une baisse de plus de 40 pour cent des annulations, est la partie sur laquelle il faut s’attarder. L’histoire n’est pas qu’une machine a appris à taper du code. L’histoire est que la relecture, la plus ancienne habitude de qualité du logiciel, est entrée dans l’écriture elle-même, et que le travail est devenu meilleur en devenant plus rapide.

    À lire aussi sur Le Miroir Français : la princesse héritière Victoria sur la Haute Côte suédoise, un littoral en pleine transformation, un autre récit récent qui prolonge, à sa manière, le plaisir de cette lecture.