Gemini 4 Argon réussit une tâche métier sur deux : ce que ça change pour une équipe e-commerce

Section 1 · L'annonce

Google sort Argon, un modèle pensé pour le travail en entreprise

Le 30 septembre 2026, Google a présenté Gemini 4 Argon, son nouveau modèle d'IA. Google le destine à trois usages : le développement logiciel, le travail de bureau qualifié (juridique, finance, analyse de documents) et la cybersécurité. Le 13 octobre, le modèle est devenu accessible aux entreprises sur Google Cloud et dans Gemini pour les entreprises, ainsi qu'aux abonnés Google AI Pro et Ultra de l'application Gemini.

Google met en avant deux chiffres. Sur DeepSWE, un test de développement logiciel sur des projets longs, Argon fait 77,9 %. Sur AutomationBench, le test de Zapier sur les tâches métier, il fait 51,3 % et se classe premier. Ces chiffres sont publiés par Google lui-même et n'ont pas été mesurés de façon indépendante.

Un token, c'est quoi ? Les modèles d'IA découpent le texte en petits morceaux appelés tokens, à peu près un mot ou un bout de mot. Le prix se calcule en tokens lus (entrée) et en tokens écrits (sortie). Une limite d'un million de tokens en sortie veut dire que le modèle peut produire en une fois un très long document, par exemple des centaines de fiches produit.

Section 2 · Le test

AutomationBench juge chaque tâche à son résultat final

Un benchmark est un test standard, le même pour tous les modèles, qui permet de les comparer. La plupart des benchmarks posent des questions et notent les réponses. AutomationBench, publié par Zapier en avril 2026, fait autre chose : il donne au modèle une vraie tâche de bureau à mener de bout en bout.

Le modèle travaille dans un environnement qui imite les outils d'une entreprise : un CRM, une boîte mail, un agenda, des messages Slack. Les tâches couvrent six métiers : vente, marketing, opérations, support, finance et ressources humaines. Le modèle doit enchaîner plusieurs actions dans plusieurs outils, et une erreur au début fait souvent échouer toute la suite.

À la fin, Zapier vérifie l'état des outils. Pour reprendre ses mots : soit les bons enregistrements ont été mis à jour et les bons messages envoyés, soit non. Il n'y a ni demi-point ni IA qui juge la copie. Zapier résume le principe ainsi : un test qui mesure des résultats, pas de la production de texte.

Pourquoi 51,3 % est un score élevé Sur un test où chaque tâche est réussie ou ratée en entier, il suffit d'une étape fausse pour perdre tout le point. Réussir plus d'une tâche sur deux sur des enchaînements de plusieurs outils, sans aide, est un niveau que les modèles n'atteignaient pas il y a peu. Ce score reste celui d'un test : il ne dit pas combien de vos propres tâches le modèle réussirait.

Section 3 · Pour l'e-commerce

Une tâche sur deux, c'est déjà beaucoup pour le reporting et les fiches produit

Une équipe e-commerce passe une bonne partie de son temps sur des tâches répétitives qui ressemblent à celles d'AutomationBench : aller chercher des chiffres dans plusieurs outils, les mettre en forme, écrire, mettre à jour une fiche, prévenir quelqu'un. Trois exemples concrets :

• Le reporting hebdomadaire. Récupérer les ventes, le trafic et les campagnes, construire le tableau, rédiger le commentaire et l'envoyer à la direction.
• Les fiches produit. Rédiger ou enrichir des centaines de fiches à partir des données fournisseur, dans le ton de la marque, puis les mettre à jour dans le catalogue.
• Les analyses ponctuelles. Comprendre pourquoi le taux de conversion a baissé sur une catégorie, croiser les sources, proposer des pistes.

Si un modèle mène seul la moitié de ces tâches jusqu'au bout, le gain de temps est réel. Mais il faut lire le chiffre dans les deux sens. Sur cent fiches produit, une moitié peut sortir juste, l'autre contenir une erreur : une taille fausse, une matière inventée, un prix mal recopié. Et rien ne signale à l'avance laquelle est laquelle.

« Une tâche sur deux réussie seule, c'est aussi une tâche sur deux qu'il faut savoir repérer. »

Section 4 · La relecture

La relecture devient une étape du processus, avec un taux d'erreur mesuré

Relire au cas par cas, quand on a le temps, ne suffit pas. La bonne approche consiste à traiter la relecture comme une étape à part entière, avec des règles claires et un chiffre suivi dans le temps : le taux d'erreur, c'est-à-dire la part des productions du modèle qui doivent être corrigées.

1. Un responsable de la relecture par type de tâche, nommé à l'avance.
2. Une grille d'erreurs commune, pour que deux relecteurs notent de la même façon.
3. Un taux d'erreur suivi chaque semaine, par tâche, avec un seuil au-dessus duquel on revient à la relecture complète.
4. Une comparaison avec le travail humain sur les mêmes tâches : les humains font aussi des erreurs, c'est la bonne référence.