Qwen3.8-Max d'Alibaba affirme pouvoir coder seul pendant une quinzaine de jours

Le 2 octobre, l'équipe Qwen d'Alibaba a publié Qwen3.8-Max, un modèle mixture-of-experts de 2 400 milliards de paramètres que l'entreprise présente comme compétent sur des centaines de types de tâches, notamment le droit, la finance et le design. L'affirmation qui a le plus retenu l'attention était plus étroite que le nombre de paramètres. Selon le communiqué, le modèle peut travailler en autonomie sur de la programmation pendant plus d'une douzaine de jours pour livrer un projet complet.

Les décomptes de paramètres ne font plus l'actualité depuis un moment. « Douze jours » est le chiffre qui mérite examen, car il décrit un type de capacité différent de celui des démos qui accompagnent la plupart des modèles.

Une tâche contre un projet

La plupart des benchmarks de modèles de code mesurent une unité de travail unique : écrire une fonction, corriger un bug, répondre à une question sur un dépôt. L'horizon se compte en minutes. Un modèle qui réussit ces tests a démontré qu'il peut produire un résultat correct lorsque le problème est entièrement spécifié et que le résultat est vérifiable en une seule étape.

Un projet qui prend douze jours n'est pas une fonction plus longue. C'est une séquence de décisions où chacune contraint la suivante, et où le modèle doit garder un design en tête à travers des milliers de modifications. Les modes de défaillance changent. Un modèle correct à 95 % à chaque étape est un excellent assistant pour une tâche de cinq minutes et un handicap sur une tâche de deux semaines, parce que les erreurs s'accumulent et que personne ne surveille chaque modification.

C'est pourquoi l'affirmation sur l'horizon compte davantage que le nombre de paramètres. Elle déplace la question de la capacité vers la fiabilité.

Ce qu'exige réellement un long horizon

Trois éléments doivent fonctionner, et aucun n'est une propriété purement liée au modèle.

La gestion de la mémoire et de l'état vient en premier. Douze jours de travail ne tiennent pas dans une fenêtre de contexte, aussi grande soit-elle. Le système doit externaliser l'état de la tâche, écrire les résultats intermédiaires sur disque et reprendre à partir d'un point de contrôle après une interruption. C'est de l'infrastructure autour du modèle, et sa justesse détermine si une longue exécution survit à un redémarrage.

L'auto-correction vient en deuxième. Sur un long horizon, le modèle prendra de mauvaises directions. Sans humain pour examiner chaque étape, il lui faut un moyen de remarquer qu'une approche échoue et de la corriger avant que l'échec ne se propage. Cela signifie que le modèle doit évaluer sa propre production intermédiaire par rapport à l'objectif initial, ce qui est une tâche plus difficile que de générer cette production.

La stabilité des outils vient en troisième. Un projet de plusieurs jours touchera une base de code, un exécuteur de tests, de la documentation et probablement un gestionnaire de paquets. Chaque appel d'outil est une occasion d'inadéquation entre ce que le modèle attend et ce que l'environnement renvoie. Sur des milliers d'appels, c'est la queue de cette distribution qui met fin à l'exécution.

Pris dans son ensemble, l'affirmation des douze jours porte sur un système complet : le modèle, plus le harnais, plus l'environnement. C'est une manière utile de la lire, car elle indique où chercher lorsque cela échoue.

Le débat sur le harnais est le sous-texte

Le calendrier de la publication n'est pas un hasard. Un débat anime les chercheurs travaillant sur les agents : de combien d'échafaudage un modèle puissant a-t-il encore besoin ? La question est de savoir si de meilleurs modèles rendent obsolètes les frameworks d'agents élaborés, ou si c'est le framework qui apporte la fiabilité.

Une affirmation de travail autonome sur douze jours se situe d'un côté de ce débat. Elle implique que le modèle peut porter la charge et que le framework n'est qu'un second rôle. Mais les trois exigences ci-dessus suggèrent l'inverse : c'est le framework qui rend l'horizon possible, et le modèle est un composant à l'intérieur.

Les deux lectures peuvent être vraies en même temps, ce qui est probablement la formulation la plus juste. Des modèles plus puissants réduisent le besoin d'assistance pour une tâche, et ils augmentent aussi le plafond de ce qu'un harnais bien conçu peut accomplir. Un modèle capable de planifier sur un long horizon vaut plus à l'intérieur d'un bon harnais, pas moins.

La moitié « bureautique » de l'affirmation

La publication associe le code au travail de bureau, et cette combinaison n'est pas anodine. Dans les deux cas, le résultat est vérifiable, ce qui rend l'autonomie viable. Un tableur comportant une erreur de formule peut être testé. Un contrat auquel il manque une clause peut être vérifié à l'aide d'une liste de contrôle. Le modèle n'a pas besoin d'avoir raison sur le monde en général, seulement sur une tâche dont la réponse est vérifiable.

C'est aussi pourquoi l'affirmation est plus étroite qu'elle n'en a l'air. Un modèle capable de tourner en autonomie pendant deux semaines sur une base de code n'est pas la même chose qu'un modèle capable de tourner en autonomie pendant deux semaines sur une question de recherche ouverte, où personne ne peut dire si le travail est correct avant bien plus tard. Le cadrage publié maintient la promesse à l'intérieur du domaine où il existe un retour d'information.

Lu ainsi, le chiffre de douze jours devient une affirmation sur la vérification autant que sur la capacité. Plus l'horizon est long, plus le système dépend de sa capacité à vérifier son propre travail.

Le choix de ces deux domaines obéit à une logique commerciale. Le code et le travail de bureau sont les domaines où les entreprises ont déjà des budgets, et où le résultat peut être évalué sans spécialiste. Un modèle qui automatise une tâche de développement de deux semaines offre un retour mesurable. Un modèle qui écrit de la poésie, non.

Comment évaluer l'affirmation

Ignorez le nombre de paramètres et cherchez trois éléments précis.

Demandez ce que « autonome » signifie en pratique. Une exécution de douze jours ponctuée de points de contrôle humains est un produit différent d'une exécution qui se déroule sans surveillance. Les entreprises précisent rarement où se situent ces points de contrôle, et ce détail détermine l'utilité davantage que la durée totale.

Demandez ce que l'exécution a produit. Un projet terminé est un artefact testable. Un dépôt, une suite de tests qui passe et un déploiement fonctionnel peuvent être vérifiés. Des captures d'écran et des démos commentées, non.

Demandez ce qui s'est passé lorsque cela a cassé. Les longues exécutions échouent, et l'information intéressante réside dans la manière. Un modèle qui détecte une impasse et revient en arrière est bien plus utile qu'un modèle qui fonce et produit un résultat d'apparence plausible qui ne tourne pas.

Ce que cela dit du marché

Qu'Alibaba livre un modèle phare orienté vers le code et le travail de bureau plutôt que vers le chat général est une déclaration sur l'endroit où se trouve la valeur. Le marché des chatbots grand public est saturé et difficile à monétiser. Le travail pour lequel les entreprises paieront est celui qui remplace ou augmente des heures, et ce travail a de longs horizons.

Si l'affirmation des douze jours tient, même partiellement, l'effet pratique est qu'une petite équipe peut s'attaquer à des projets qui exigeaient auparavant une équipe plus grande. Si elle ne tient pas, le modèle reste un solide assistant de code doté d'un grand contexte, et la mention des douze jours disparaîtra d'elle-même du marketing. Dans un cas comme dans l'autre, c'est le cadrage qui est utile. La capacité se mesure désormais autant au temps pendant lequel un modèle peut continuer à travailler sans supervision qu'à ce qu'il peut faire en une seule fois.