DEV Community: Thibault Monteiro

Google mise sur des Gemini moins chers, pas plus forts

Thibault Monteiro — Sat, 25 Jul 2026 06:00:11 +0000

L'essentiel

Google lance trois modèles Gemini Flash (3.6 Flash, 3.5 Flash-Lite et 3.5 Flash Cyber) pensés pour faire tourner des agents IA à grande échelle et à moindre coût.
Le modèle de travail 3.6 Flash consomme 17 % de tokens de sortie en moins que 3.5 Flash, jusqu'à 65 % sur le benchmark DeepSWE, à 7,50 $ le million de tokens produits.
Le flagship attendu, Gemini 3.5 Pro, reste en test chez des partenaires ; le pré-entraînement de Gemini 4 vient tout juste de démarrer.
Le modèle de cybersécurité 3.5 Flash Cyber est réservé aux gouvernements et partenaires triés, via l'agent CodeMender.

Google a dévoilé mardi trois nouveaux Gemini, et son argument tient en deux mots : moins cher. Dix-sept pour cent de tokens de sortie en moins sur son modèle de travail, un prix au million revu à la baisse, des agents qui coûtent moins à chaque tâche. Pendant ce temps, le modèle haut de gamme que tout le secteur attendait, Gemini 3.5 Pro, reste introuvable. Ce contraste raconte mieux la stratégie de Google que n'importe quel classement.

D'où vient le « 17 % de tokens en moins »

Le chiffre vient de l'Artificial Analysis Index, un agrégateur de benchmarks indépendant, et il mesure une chose précise : le volume de tokens de sortie (les unités de texte que le modèle génère) que 3.6 Flash consomme pour accomplir une même tâche, comparé à 3.5 Flash. Moins de tokens produits, ce sont moins d'étapes de raisonnement et moins d'appels d'outils, donc une facture qui fond.

Google pousse le curseur plus loin sur certains cas : jusqu'à 65 % d'économie sur DeepSWE, un banc d'essai de programmation. À 1,50 $ le million de tokens en entrée et 7,50 $ en sortie, 3.6 Flash coûte moins que le 3.5 Flash qu'il remplace, et il dépasse au passage l'ancien 3.1 Pro sur les benchmarks. Autrement dit, le milieu de gamme d'aujourd'hui enterre le haut de gamme d'hier, pour beaucoup moins cher. Voilà le produit d'appel.

Des gains réels, un sommet toujours hors de portée

Réduire la verbosité sans perdre en qualité, c'est l'exploit revendiqué, et les chiffres avancés vont dans ce sens. Sur DeepSWE, la précision passe de 37 à 49 %. Sur MLE Bench, qui évalue le travail de recherche en apprentissage automatique, de 49,7 à 63,9 %. OSWorld-Verified, qui teste la capacité à piloter un ordinateur, grimpe de 78,4 à 83 %. Le score de travail intellectuel GDPval-AA v2 monte de 1 349 à 1 421 points. La fonction Computer Use, qui laisse le modèle manipuler navigateur et bureau, devient un outil intégré côté client dans l'API Gemini.

Reste que ces gains se mesurent contre les Gemini précédents, pas contre la concurrence. Google reconnaît lui-même que ses modèles restent derrière les meilleurs des laboratoires américains et chinois. Logan Kilpatrick, de l'équipe technique, l'a assumé sur X face aux critiques : l'objectif affiché était l'efficacité, la fiabilité et le coût, et la performance a progressé en chemin. Traduction : Google ne cherchait pas à reprendre la première place cette fois-ci.

Flash-Lite pour le volume, Cyber pour les États

La logique du coût se décline sur les deux autres modèles. Gemini 3.5 Flash-Lite vise le débit : 350 tokens par seconde selon l'Artificial Analysis Index, à 0,30 $ le million en entrée et 2,50 $ en sortie. Sa cible, ce sont les tâches répétitives à fort volume, tri de tickets, extraction de données, là où chaque centime par requête compte. Il dépasse même l'ancien 3 Flash, pourtant plus gros, sur plusieurs bancs d'essai agentiques ; son score Terminal-Bench 2.1 bondit de 31 à 54 % face à son prédécesseur direct.

Le troisième, 3.5 Flash Cyber, joue une partition à part. Bâti sur 3.5 Flash et affiné pour la sécurité logicielle, il alimente CodeMender, l'agent de correction de code de Google DeepMind. Son intérêt tient précisément à son coût : CodeMender l'appelle jusqu'à cinq fois pour un seul rapport, multipliant les passages sur une base de code là où un gros modèle unique deviendrait vite prohibitif. Sur le benchmark CyberGym, cette approche a confirmé 55 vulnérabilités uniques dans le moteur JavaScript V8 de Chrome, soit davantage que les 36 relevées par Claude Opus 4.6, et dix d'entre elles avaient échappé à tous les autres modèles. Mais ce modèle ne sera pas ouvert : Google le réserve d'abord aux gouvernements et partenaires de confiance, au titre du double usage de la cybersécurité.

Gemini 3.5 Pro absent, Gemini 4 déjà en chantier

Le plus parlant, c'est ce que Google n'a pas livré. Gemini 3.5 Pro reste « en test chez des partenaires » et sortira « dès qu'il sera prêt », formule qui ne trompe personne. Dans le même souffle, l'entreprise annonce avoir lancé son « run de pré-entraînement le plus ambitieux » pour Gemini 4 et se dit « enthousiasmée par les progrès ». Empiler ces deux messages autour d'un modèle phare absent, cela ressemble moins à une feuille de route qu'à une gestion de l'attente.

Le signal tient dans l'ordre des priorités. Un géant qui aligne trois modèles économiques avant de dévoiler son sommet vise d'abord les déploiements massifs : ces milliers d'agents en production dont chaque appel pèse sur la note finale. C'est là, dans les budgets des entreprises qui passent l'IA à l'échelle, que se jouera la prochaine manche, bien plus que sur un point de pourcentage en tête de tableau.

Mon avis

La manœuvre ressemble à une nouvelle norme, et je ne la lis pas comme un aveu de faiblesse. Sortir trois modèles bon marché en gardant son flagship au chaud, c'est déplacer le terrain : la valeur d'un modèle d'agent ne se mesure plus à la ligne du haut d'un classement, mais en dollars par tâche accomplie. Google l'assume à demi-mot, et ses rivaux suivront avant la fin de l'année. Parce qu'on ne facture pas un benchmark, on facture des tokens.

Le développeur bâtit l'usine qui écrit le code à sa place

Thibault Monteiro — Sat, 25 Jul 2026 06:00:10 +0000

Deux billets publiés le même jour, le 20 juillet 2026, racontent la même mutation par deux bouts opposés. D'un côté, des bricoleurs qui laissent un agent démonter le firmware de leur aspirateur connecté pour l'automatiser en un après-midi. De l'autre, des équipes qui n'écrivent plus une ligne : elles construisent l'usine qui écrit le code à leur place. Le geste de programmer vient de changer de nature.

L'unité de travail n'est plus la ligne de code

Addy Osmani, ingénieur chez Google, décrit dans « Software Factories, Light and Dark » une pile à trois étages. À la base, la boucle : un agent qui répète un cycle unique, rassembler le contexte, agir, vérifier le résultat, recommencer jusqu'à une condition d'arrêt. Autour, le harnais (harness) : le bac à sable où tourne l'agent, les outils qu'il peut atteindre, la mémoire qui survit d'une exécution à l'autre, et les portes qui définissent ce que « terminé » signifie. Au sommet, l'usine : des dizaines de boucles harnachées en parallèle, alimentées par une file de tâches et drainées vers la production à travers une porte de revue.

L'idée n'a rien de neuf. Osmani la fait remonter à un papier de Bob Bemer de 1968, « The economics of program production », qui rêvait déjà d'un logiciel produit comme on emboutit des pièces automobiles. Le rêve a échoué pendant un demi-siècle, faute de pouvoir industrialiser les idées elles-mêmes. Ce qui a basculé en deux ans, c'est que les agents savent enfin tenir une boucle sans supervision permanente. Le développeur ne rédige plus le diff : il conçoit et pilote la chaîne qui le produit. Dex Horthy, cofondateur de HumanLayer, le formule crûment dans une conférence donnée à l'AI Engineer World's Fair : l'ingénierie du harnais ne suffit pas, c'est l'usine entière qu'il faut penser.

Quand démonter son aspirateur ne coûte plus rien

Simon Willison observe le même glissement par le bas. Il collectionne les récits de gens qui se servent d'agents de programmation pour rétro-concevoir (reverse-engineering) et automatiser leurs appareils domestiques. Rien de techniquement inédit : disséquer l'API non documentée d'un objet connecté était déjà possible hier. Ce qui manquait, c'était le retour sur investissement.

Le calcul vient de s'inverser. Ce code coûtait cher en heures et en frustration, surtout pour des API instables vouées à casser à la prochaine mise à jour du fabricant. Willison pointe le déclic : quand produire du code devient quasi gratuit, le poids psychologique de devoir le maintenir, ou de le jeter pour tout recommencer, s'effondre. On tente, on échoue, on relance sans y penser. La même logique de boucle bon marché qui alimente l'usine d'Osmani se rejoue dans un garage, un dimanche après-midi.

Usine claire ou usine sombre : qui reste dans la boucle

Osmani trace une frontière nette. L'usine claire (light factory) garde des humains dans la boucle : on échange du jugement et de la concentration contre de la vitesse, en assumant un peu de casse. L'usine sombre (dark factory) évacue l'humain : les agents cadrent, construisent et livrent le code sans que personne n'en lise vraiment le détail.

Le risque n'est pas la vitesse, c'est l'aveuglement. Si les gens cessent de lire le code, ils cessent de le comprendre. Une base logicielle que plus personne ne saisit devient impossible à réparer le jour où elle dérape, et nul ne saura même expliquer pourquoi. La compétence critique se déplace donc : elle ne consiste plus à écrire les lignes, mais à savoir quels garde-fous construire et quelle dose d'autonomie confier à chaque boucle.

Concepteurs d'usine d'un côté, artisans du code de l'autre

À terme, le poste de développeur devrait éclater en deux fonctions nettes. D'un côté, des concepteurs d'usine qui passent leurs journées à écrire des tests, des portes de revue et des règles d'autonomie : leur livrable n'est plus le code, mais le système qui le contrôle. De l'autre, des artisans qui refusent la boucle là où l'erreur coûte trop cher, sécurité, paiement, santé, et continuent de relire chaque ligne à la main.

La bascule ne tiendra qu'à une condition : la fiabilité des garde-fous automatisés. Tant que les portes de revue resteront plus lentes ou moins sûres que les boucles qu'elles filtrent, l'usine sombre ne sera qu'une dette différée déguisée en gain de productivité. Le basculement ne se lira pas dans un modèle plus puissant. Il se lira le jour où une équipe assumera de livrer en production du code qu'aucun humain n'a relu, sans que ce choix ne choque plus personne. Ce jour-là, le savoir-faire du développeur tiendra dans une décision : ce qu'il garde sous ses yeux, ce qu'il abandonne à l'usine.