L’essentiel
- Meta a présenté Muse Spark 1.3 le 2 septembre, avec des performances annoncées en hausse sur les tâches agentiques et de programmation.
- La capacité mise en tête par l’équipe AI at Meta : maintenir un travail à plus long horizon à travers plusieurs workflows.
- L’annonce insiste sur l’utilisabilité en conditions réelles et n’ouvre sur aucun tableau de scores.
Une démonstration de trente secondes sur un problème difficile fait toujours son effet dans une salle. Deux heures et quatre appels d’outils plus tard, le même modèle doit reprendre le travail exactement là où il l’a laissé, avec les contraintes posées au départ encore en mémoire. Meta a choisi ce second terrain pour se présenter, le 2 septembre.
L’ordre des arguments a changé
Ce jour-là, le compte AI at Meta a lancé Muse Spark 1.3 en mettant en avant des performances améliorées sur les tâches agentiques (des tâches où le modèle enchaîne lui-même actions et appels d’outils, sans qu’on le relance à chaque étape) et sur la programmation. En tête de la liste : tenir un travail sur un horizon plus long, d’un workflow à l’autre. Aucun classement n’ouvre l’annonce.
Cet ordre est un choix éditorial autant que technique. Depuis trois ans, un lancement de modèle s’ouvre sur des barres et des pourcentages. Ici, l’usage réel passe devant, et quiconque a déjà confié une tâche longue à un agent sait pourquoi : personne n’a jamais perdu une journée de travail à cause de deux points d’écart sur une évaluation publique.
La persistance a remplacé le raisonnement comme point de rupture
Un agent qui échoue à la troisième heure échoue rarement sur une déduction. Il échoue parce qu’il a perdu l’état : la fenêtre de contexte s’est remplie, un résumé intermédiaire a effacé une contrainte posée au démarrage, un appel d’outil a renvoyé une erreur que plus rien ne rattache à la tâche d’origine. La qualité du raisonnement, elle, était intacte à la minute où tout a déraillé.
Les évaluations publiques mesurent mal cette dimension. Elles portent sur des tâches courtes, isolées, rejouables à l’identique, quand la durée ne se lit que sur des sessions longues où l’erreur s’accumule au lieu de se corriger. Un modèle peut donc gagner sur les tableaux et perdre sur une migration de trois heures. Beaucoup d’équipes vivent déjà cet écart. Anthropic a publié ses propres relevés d’usage : en conditions réelles, la moitié des tours durent environ 45 secondes, quand le 99,9e percentile a franchi les 45 minutes entre octobre 2025 et janvier 2026. L’entreprise ajoute que l’horizon d’autonomie mesuré par METR chiffre la difficulté d’une tâche pour un humain, pas la durée pendant laquelle la machine tient.
Mémoire auditable, reprise propre, coût à l’heure
Annoncer l’horizon long engage sur des propriétés vérifiables, pas sur une impression de fluidité.
- Une mémoire auditable : pouvoir lire ce que l’agent a retenu, et surtout ce qu’il a jeté, à chaque étape du travail.
- Une reprise propre : couper volontairement un travail de trois heures à la moitié, le relancer, et vérifier qu’il ne repart pas de zéro.
- Un coût rapporté à l’heure de travail utile, pas au million de tokens : la durée se paie en relectures de contexte et en appels répétés, deux postes qui gonflent sans prévenir.
Quand la durée deviendra un argument de vente
Avant la fin 2026, la durée d’autonomie sera affichée comme un argument commercial, exprimée en heures de travail tenu plutôt qu’en points d’évaluation. Les concurrents suivront vite, parce que l’argument se vérifie chez le client et qu’il flatte exactement la frustration du moment.
Au premier semestre 2027, la conséquence tombe sur la facture. Les offres destinées aux développeurs se rapprochent d’un forfait par tâche menée à son terme, avec un engagement sur le taux d’achèvement. Condition stricte : que ce taux devienne assez stable sur des travaux de plusieurs heures pour être garanti contractuellement. Sans cette stabilité, aucun éditeur ne signera.
Le scénario contraire reste ouvert. Si l’écart entre la démonstration et l’usage réel se maintient au niveau actuel, les équipes rebasculeront sur des tâches courtes pilotées par un orchestrateur maison, qui découpe, vérifie et relance. La promesse d’horizon long deviendrait alors un argument de lancement de plus, oublié à la version suivante.
Une demi-journée suffit pour vérifier
Prenez un travail réel qui dure : une migration de dépendances, une refonte de suite de tests, un traitement de données en plusieurs passes. Rejouez-le trois fois et mesurez trois choses seulement : le nombre d’interventions humaines nécessaires, le moment précis où une contrainte posée au départ est oubliée pour la première fois, et le comportement après une coupure volontaire à mi-parcours.
Ces trois mesures se relèvent en un après-midi et valent plus que n’importe quel classement. Elles disent si l’agent tient réellement l’état, ou s’il simule la continuité en refaisant discrètement le chemin déjà parcouru, à vos frais.
Meta a fixé publiquement le critère sur lequel son modèle sera jugé, et ce critère se vérifie sans laboratoire. La prochaine version, quel que soit son numéro, sera lue à cette aune : combien d’heures avant que l’agent ne perde le fil.
Mon avis
La durée sera vendue bien avant d’être mesurée, et cet écart va durer au moins un an. Je vois déjà la métrique arriver dans les argumentaires sans définition partagée : chacun comptera ses heures avec son protocole, ses reprises et ses relances silencieuses. Mon pronostic pour 2027 : le premier éditeur qui publiera un protocole reproductible de travail long, échecs compris, prendra une avance d’image que dix points d’évaluation ne rattraperont pas. D’ici là, je n’accorde aucun crédit à une promesse d’autonomie que je n’ai pas cassée moi-même avec une coupure à mi-parcours.
