Le benchmark de Gemini 4 Carbon reste derrière Claude, mais présente un meilleur rapport qualité-prix

Le Gemini 4 Carbon de Google reste derrière Claude Opus 5.5 dans un nouveau benchmark, tout en affichant une dépense moyenne par tâche nettement inférieure. Les résultats du benchmark de Gemini 4 Carbon offrent à Google un argument crédible en matière de valeur, même si la comparaison comporte une réserve importante. Changez les domaines testés, et le classement change lui aussi.

Le GDPx de SemiAnalysis, une évaluation de systèmes d’IA réalisant des tâches professionnelles longues, place Anthropic en tête selon son score global. Carbon suit d’assez près pour soulever une question d’achat concrète : quelle dépense supplémentaire le meilleur résultat justifie-t-il ? Cette question compte pour les développeurs finançant des exécutions répétées et les entreprises déterminant quel travail mérite leur modèle le plus coûteux.

Les résultats appuient une conclusion nuancée. Carbon mérite d’être envisagé pour des workflows exigeants, mais sa position dépend du travail évalué et des conditions d’exécution. Des dépenses mesurées plus faibles renforcent l’argument de Google en faveur d’un essai. Elles n’établissent pas des coûts d’exploitation inférieurs pour chaque client, ni ne prouvent que Carbon égale Claude dans l’ensemble du travail professionnel.

Le benchmark de Gemini 4 Carbon place Google parmi les leaders

Le classement publié par GDPx attribue à Claude Opus 5.5 un score de 12,0 %, suivi de Carbon à 10,9 % et de GPT-6 Astra à 9,6 %. L’évaluation comprend 206 tâches réparties dans 11 domaines, développées avec 14 partenaires spécialistes. Les domaines reçoivent le même poids, et les résultats correspondent à la moyenne de trois tentatives avec une notation propre à chaque tâche. Certaines tâches accordent un crédit partiel ; le pourcentage mis en avant ne constitue donc pas un simple taux de réalisation. Ces précisions figurent dans le classement GDPx.

Le résultat de Carbon établit une position concurrentielle dans cette évaluation ; sa signification dépend de la conception de cette évaluation.

Pour les lecteurs qui comparent Google et Anthropic, la distinction immédiate est simple. Claude domine le score agrégé. Google propose un résultat proche avec un profil de dépenses différent. Aucune de ces observations n’impose de considérer le classement comme une mesure universelle de l’intelligence.

Un benchmark est une sélection de problèmes, d’outils et de règles de notation. Son utilité vient de sa capacité à rendre ces choix suffisamment visibles pour permettre leur interprétation. Une organisation évaluant la recherche contractuelle devrait donc poser des questions différentes de celles d’une équipe évaluant la maintenance logicielle.

Le résultat agrégé fournit une comparaison initiale. Il ne peut pas déterminer quelles erreurs un acheteur donné rencontrera, ni combien d’intervention ces erreurs exigeront. C’est dans cet écart entre performance mesurée et performance utile que les décisions d’achat se compliquent.

Prenons l’exemple hypothétique d’une équipe d’ingénierie qui enquête sur des défaillances dans une application existante. Un modèle utile doit identifier les éléments pertinents, proposer une modification défendable et produire un résultat que les réviseurs peuvent tester. Une explication soignée sans correctif fonctionnel crée du travail supplémentaire.

Pour cette équipe, la comparaison pertinente inclut la qualité du correctif et l’effort nécessaire pour le valider. Une position générale dans un classement apporte du contexte, mais c’est le propre dépôt de l’équipe qui détermine si le résultat est transposable.

Une autre organisation pourrait surtout chercher à extraire des réponses cohérentes d’une collection de documents en évolution. Ses critères d’acceptation mettraient l’accent sur la couverture des preuves, les dossiers contradictoires et l’exactitude des citations. Le même classement agrégé pourrait alors justifier une décision d’achat différente.

C’est pourquoi ce nouveau résultat compte sans pour autant régler la compétition. Il place Carbon sur la liste restreinte pour les travaux difficiles. La question suivante consiste à savoir si son économie mesurée résiste au passage des environnements de benchmark au workflow réel d’un acheteur.

Cette distinction évite également une erreur fréquente dans la couverture médiatique. Un faible écart sur un score agrégé ne démontre pas que les systèmes concurrents commettent des erreurs interchangeables. Les acheteurs doivent savoir où ces erreurs surviennent.

Des dépenses mesurées plus faibles mettent sous pression la prime de Claude

La couverture du 2 novembre par 9to5Google souligne les dépenses moyennes de benchmark nettement plus faibles de Carbon par rapport à Claude Opus 5.5. Elle rapporte également que GPT-6 Astra a enregistré un score global inférieur tout en coûtant davantage dans l’évaluation. La comparaison des coûts du benchmark constitue le fondement de l’argument de valeur, plutôt qu’une évaluation générale des formules d’abonnement.

Le défi d’Anthropic consiste à démontrer où la performance mesurée supplémentaire de Claude compense sa dépense supplémentaire.

Il s’agit d’une interprétation économique des résultats, et non d’une preuve que les clients ont déjà changé de fournisseur. La pression devient pertinente lorsque les acheteurs peuvent reproduire un résultat acceptable avec l’un ou l’autre système. Dès lors, les écarts de dépenses méritent une attention accrue.

Pour une entreprise exécutant régulièrement des tâches de recherche ou d’ingénierie, les dépenses d’inférence correspondent au coût nécessaire pour qu’un modèle traite les demandes et génère des réponses. Cette dépense devient plus importante à mesure que l’usage s’étend. Un workflow expérimental apparemment gérable peut devenir difficile à financer lorsqu’il est répété dans toute une organisation.

Cependant, la dépense moyenne par tâche tentée ne représente qu’une partie du calcul. Les acheteurs paient en définitive pour des résultats utiles. Une tentative peu coûteuse nécessitant des corrections importantes peut perdre son avantage avant que le travail n’atteigne un client.

La révision humaine doit donc faire partie de la même comparaison. Les réviseurs doivent vérifier qu’une réponse traite la demande, respecte les contraintes et étaye les affirmations importantes. Leur temps peut modifier l’équation économique, même lorsque la facture du modèle paraît avantageuse.

Les nouvelles tentatives comptent pour des raisons similaires. Un système qui nécessite plusieurs essais consomme des ressources supplémentaires et retarde l’achèvement. Les acheteurs devraient distinguer une faible dépense par tentative d’une faible dépense par résultat accepté.

Il existe également une différence entre les erreurs récupérables et les erreurs coûteuses. Un problème de mise en forme est généralement facile à réparer. Une hypothèse erronée enfouie dans une recommandation technique peut exiger bien davantage d’investigation.

Claude peut donc justifier une prime dans un workflow où ses résultats nécessitent moins de corrections ou détectent davantage de problèmes importants. Carbon peut justifier son choix lorsqu’il atteint le même niveau d’acceptation avec un effort total moindre. Le benchmark ne décide pas laquelle de ces conditions s’applique.

L’effet concurrentiel reste néanmoins significatif. Google a une raison fondée sur des preuves d’inviter les acheteurs à évaluer Carbon aux côtés du leader. Anthropic doit expliquer la valeur pratique de l’écart, plutôt que de s’appuyer entièrement sur sa position en tête.

Pour les équipes achats, cela oriente la discussion vers des résultats mesurables. La question utile devient celle de la performance de chaque système face à une norme d’acceptation commune. La préférence de marque et la position agrégée restent des éléments de contexte, tandis que le travail achevé détermine l’achat.

Les filtres de sécurité modifient le paysage concurrentiel

SemiAnalysis attribue certains résultats affaiblis de Claude et des modèles GPT à des classificateurs de sécurité, des systèmes qui examinent les demandes ou les comportements au regard de règles de sécurité. Sa méthodologie GDPx évoque l’exclusion de la cybersécurité, de la biologie et de la recherche sur l’alignement, qui vise à maintenir le comportement de l’IA cohérent avec ses objectifs prévus. Cela produit une comparaison différente. L’évaluateur exécute également les modèles dans leurs outils d’exécution natifs lorsqu’ils sont disponibles, ce qui fait des résultats des comparaisons de systèmes opérationnels.

Un classement influencé par le comportement en matière de sécurité ne peut pas être lu uniquement comme un classement de la capacité sous-jacente à résoudre des problèmes.

Un système peut ne pas parvenir à réaliser une demande parce qu’il ne peut pas résoudre le problème. Il peut aussi refuser de poursuivre parce que ses garde-fous détectent une préoccupation. Ces résultats paraissent similaires dans une évaluation orientée vers la réalisation, tout en ayant des implications différentes pour un acheteur.

Pour une équipe de recherche autorisée, un refus inutile peut interrompre un travail légitime. De ce point de vue, le comportement de refus fait partie de l’évaluation de l’utilité. Un système techniquement compétent doit tout de même prendre en charge les tâches que son client est autorisé à effectuer.

Pour une autre organisation, la même restriction pourrait être souhaitable. Une entreprise déployant largement l’IA peut privilégier des limites prévisibles concernant les demandes sensibles. Son système préféré pourrait différer de celui qui poursuit le plus souvent dans un benchmark de recherche.

Le classement filtré introduit un autre enjeu d’interprétation. Retirer les domaines sensibles modifie la charge de travail évaluée. Cela ne révèle pas comment les mêmes modèles se comporteraient sur ces tâches avec des garde-fous différents.

Cette distinction limite ce que les lecteurs peuvent déduire de la position de Carbon. Le résultat non filtré décrit les performances sur le mélange publié. Le résultat filtré décrit un mélange plus restreint. Aucun des deux ne devrait être présenté comme une réponse universelle tandis que l’autre disparaît.

Le benchmark de Gemini 4 Carbon soulève donc une question plus précise que celle de savoir si Google a rattrapé Anthropic. Il demande quelle combinaison de capacités, de comportement de refus et d’outils d’exécution correspond aux exigences du client.

Les outils d’exécution comptent parce qu’un agent d’IA, un système qui agit par l’intermédiaire de logiciels, dépend de plus que de ses réponses. Son environnement détermine quels fichiers il peut examiner, quelles commandes il peut exécuter et comment il reçoit les retours.

Un assistant de programmation hypothétique pourrait raisonner correctement sur un défaut, mais avoir des difficultés à lancer les tests du projet. Un autre pourrait se remettre efficacement d’une erreur d’environnement. Un acheteur perçoit ces différences comme des différences entre produits.

Cela donne aux évaluations pratiques un avantage : elles peuvent refléter le système qu’un client utilise réellement. Cela limite également les affirmations concernant le modèle pris isolément. Un bon résultat ne permet pas d’identifier quel composant mérite le crédit.

Les acheteurs devraient donc examiner les catégories d’échec avant de choisir un gagnant. Les refus inutiles, les raisonnements incorrects, le contexte manquant et les défaillances d’outils appellent des réponses différentes. Les réunir dans un seul jugement peut masquer la raison pour laquelle un système a déçu.

D’autres évaluations renforcent la nécessité d’un jugement adapté aux tâches

Des évaluations distinctes apportent des contrôles utiles sans résoudre la confrontation GDPx. Le Vals Index, qui pondère certaines tâches professionnelles selon les parts sectorielles de la production économique américaine, place Claude Sonnet 5.5 à 70,85 %. Carbon suit à 70,45 %, devant Claude Opus 5.5 à 70,18 %, dans sa mise à jour du 30 octobre. Ces résultats de tâches professionnelles utilisent une méthodologie différente et doivent rester distincts de GDPx.

Des leaders différents selon les benchmarks sont une raison d’examiner la charge de travail avant de généraliser à partir d’un classement.

Le contraste est pertinent pour Gemini 4 Carbon face à Claude, car « Claude » recouvre des modèles distincts. Un résultat impliquant Opus ne décrit pas automatiquement Sonnet. Les comparaisons exigent l’identité exacte du modèle, ainsi que les conditions de test.

Elles exigent également la date de l’évaluation. Un classement publié est un instantané de systèmes précis dans des conditions particulières. Des mises à jour ultérieures peuvent modifier la comparaison sans rendre l’instantané antérieur malhonnête ou inutile.

Pour les acheteurs, les différences entre évaluations permettent d’identifier ce qui reste non résolu. Une affirmation générale sur l’utilité professionnelle nécessite des preuves couvrant les types de travail que le client réalise effectivement. Répéter la même affirmation agrégée dans différentes présentations ajoute peu de confiance.

L’évaluation distincte de Zapier illustre comment la configuration peut modifier le résultat. AutomationBench teste l’exécution de flux de travail métier simulés. Carbon a obtenu 31,5 % avec un faible effort de raisonnement, 53,0 % avec un effort moyen et 53,9 % avec un effort élevé. Son évaluation des flux de travail métier montre donc une amélioration bien plus importante entre les niveaux faible et moyen qu’entre les niveaux moyen et élevé.

Ces chiffres n’expliquent pas le score GDPx de Carbon. Ils établissent un point plus précis : les paramètres du modèle peuvent affecter sensiblement les performances mesurées. Une comparaison qui omet ces paramètres ne fournit pas aux acheteurs les informations nécessaires pour la reproduire.

L’implication opérationnelle est qu’un nom de modèle ne définit pas à lui seul le comportement d’un produit. Un acheteur doit également comprendre la configuration utilisée dans le déploiement proposé. Les performances observées avec des paramètres exigeants pourraient ne pas se transposer à une configuration moins coûteuse ou plus rapide.

Inversement, le paramètre disponible le plus élevé ne produit pas automatiquement le meilleur résultat commercial. Le calcul supplémentaire doit générer une amélioration suffisante pour justifier son incidence sur le coût et le temps d’attente. Ce jugement dépend de la tâche.

Par exemple, un processus hypothétique de recherche en arrière-plan pourrait tolérer une exécution plus longue si le résultat exige moins de vérifications. Un assistant interactif pourrait privilégier la réactivité, car l’utilisateur doit attendre avant de poursuivre. Aucune de ces préférences ne découle directement d’un classement agrégé.

C’est là qu’intervient la conception des flux de travail de connaissance. Les équipes qui évaluent la gestion des connaissances par IA doivent aussi examiner comment les informations pertinentes parviennent au modèle. Des éléments de preuve manquants peuvent compromettre un système performant avant même que la qualité du raisonnement ne devienne le facteur déterminant.

La réponse utile à des résultats de benchmark concurrents est donc une plus grande précision. Définissez le travail, les informations disponibles, la configuration et les critères d’acceptation. Évaluez ensuite le flux de travail complet au regard de ces exigences.

L’accès et la vérification déterminent si la valeur atteint les clients

Google a annoncé Carbon le 28 octobre et décrit un déploiement progressif commençant auprès de certains défenseurs de la cybersécurité et partenaires de confiance. Son plan déclaré consistait à élargir l’accès après de nouveaux retours et travaux sur les mesures de protection. La publication de lancement de Google présente également ses propres affirmations sur les capacités. Les détails du déploiement de Carbon établissent que l’annonce et la disponibilité générale pour les clients constituent des étapes distinctes.

Un résultat favorable à un benchmark devient commercialement utile lorsque les clients peuvent tester le système concerné dans des conditions exploitables.

Cela importe directement pour l’argument de valeur. Un acheteur ne peut pas valider les économies prévues sans accéder au modèle et aux paramètres qui sous-tendent la comparaison. La disponibilité détermine si Carbon représente une option immédiate ou un candidat futur.

L’accès progressif peut aussi limiter l’ampleur des retours publics. Les premiers résultats d’organisations sélectionnées peuvent éclairer des applications exigeantes tout en laissant sans réponse les questions de déploiement quotidien. Les acheteurs doivent distinguer une évaluation prometteuse de performances établies auprès d’une clientèle diversifiée.

Pour Google, le prochain défi commercial consiste à transformer l’attrait du benchmark en une offre utilisable. Cela exige plus que de produire de bonnes réponses. Les clients ont besoin d’un accès constant, d’un comportement clair et de suffisamment d’informations opérationnelles pour évaluer le flux de travail complet.

Pour Anthropic, la disponibilité et l’intégration existante peuvent procurer des avantages pratiques même lorsqu’un rival publie des résultats attrayants. Une équipe utilisant déjà Claude doit considérer l’effort requis pour changer de système. Cet effort mérite d’être mesuré plutôt que supposé.

Le changement implique de vérifier les prompts, les outils, les autorisations et les attentes en aval. Un résultat qui semble équivalent pour une personne peut néanmoins perturber un logiciel qui attend une structure particulière. De telles différences influencent l’adoption, même lorsque la qualité du modèle est compétitive.

Le benchmark Gemini 4 Carbon ne mesure pas ces coûts de transition. Il donne une raison de les examiner. Les acheteurs devraient éviter de traiter implicitement une dépense de benchmark favorable comme un dossier économique complet de migration.

La vérification introduit une autre limite. Les éléments examinés ici établissent ce que l’évaluateur a publié ; ils ne constituent pas une réplication indépendante de GDPx. Une reproduction renforcerait la confiance dans la relation rapportée entre performance et dépenses.

D’ici là, les affirmations doivent rester associées à leur source et à leurs conditions. Carbon a enregistré un résultat solide dans l’évaluation publiée. Cela justifie des tests supplémentaires sans établir que chaque client connaîtra le même avantage.

La même discipline s’applique aux exemples de déploiement. Un assistant de recherche hypothétique traitant des documents techniques internes a besoin d’une sélection précise des éléments probants et d’une attribution fiable. Un agent logiciel hypothétique a besoin de modifications qui résistent à la revue et aux tests. Aucun de ces résultats ne découle automatiquement d’une position dans un benchmark.

Pour les travailleurs de la connaissance, un flux de travail IA efficace dépend aussi de l’organisation et de la recherche d’informations. Une meilleure économie du modèle ne peut pas compenser un processus qui fournit de manière répétée des documents obsolètes ou omet un contexte essentiel.

La décision d’achat qui en résulte est plus large qu’un choix entre des logos. Elle concerne l’ensemble du parcours, de la demande au travail accepté. La valeur mesurée de Carbon constitue une raison d’examiner attentivement ce parcours, en y incluant les propres contraintes du client.

Les prochains signaux seront un accès élargi, des classements stables et un travail accepté

Le premier signal à surveiller est un accès utilisable au-delà du déploiement initial. Les acheteurs ont besoin d’occasions d’évaluer Carbon avec leurs propres outils et éléments probants. Un accès élargi renforcerait l’importance commerciale du benchmark ; des restrictions persistantes laisseraient davantage l’argument de valeur au stade prospectif.

L’étape pertinente est un accès permettant des tests reproductibles. Une brève démonstration peut montrer un potentiel, mais elle ne peut pas établir une cohérence opérationnelle. Les clients ont besoin d’une exposition suffisante pour observer à la fois les exécutions réussies et les schémas d’échec.

Le deuxième signal est de savoir si la relation concurrentielle se maintient dans des évaluations supplémentaires et avec des sélections de domaines clairement documentées. Des résultats qui restent favorables pour des combinaisons de tâches pertinentes renforceraient le dossier de Google. Des classements dépendant fortement d’une sélection étroite rendraient la conclusion plus spécifique.

Les comparaisons dans des domaines sensibles méritent une attention particulière. Les futurs rapports devraient distinguer les changements dans la sélection des tâches des changements dans le comportement du modèle. Sinon, un classement réorganisé peut sembler établir une avancée technique que l’évaluation n’a jamais mesurée.

Des reproductions indépendantes apporteraient une autre vérification utile. Elles aideraient à déterminer si la relation rapportée se maintient avec différents opérateurs et environnements. Un accord renforcerait la confiance, tandis qu’un désaccord identifierait des conditions nécessitant une explication.

Le troisième signal est constitué d’éléments sur le travail accepté, notamment la revue humaine et la récupération après des erreurs. C’est le résultat que les entreprises achètent en définitive. Un déploiement peut sembler économique au niveau du modèle tout en devenant coûteux après correction et supervision.

L’argument de valeur de Carbon se renforce lorsque des dépenses mesurées plus faibles s’accompagnent de résultats que les clients peuvent accepter avec un effort comparable.

Des éléments allant dans le sens inverse affaibliraient l’affirmation plus large. Si les réviseurs ont besoin de beaucoup plus de temps, ou si les nouvelles tentatives effacent l’avantage initial, des dépenses de benchmark plus faibles deviennent moins convaincantes. Cela n’invaliderait pas le résultat publié ; cela en définirait les limites pratiques.

La réponse d’Anthropic compte dans le même cadre. Des améliorations du résultat accepté, de la fiabilité d’exécution ou de l’économie opérationnelle pourraient modifier la comparaison. Les acheteurs devraient surveiller ces résultats plutôt que de supposer que la relation actuelle persistera.

L’interprétation la plus utile de Gemini 4 Carbon vs Claude est donc conditionnelle et exploitable. Google a mérité une évaluation plus approfondie. Claude conserve le meilleur score GDPx. La charge de travail du client détermine dans quelle mesure l’une ou l’autre observation doit influencer les dépenses.

Cela remet le titre à sa juste proportion. Le résultat de Carbon remet en cause l’hypothèse selon laquelle le score de benchmark le plus élevé doit aussi représenter le meilleur achat. Il n’établit pas que la tâche tentée la moins coûteuse produit toujours un travail achevé moins coûteux.

Avant de considérer le benchmark Gemini 4 Carbon comme un verdict d’achat, identifiez le travail que votre équipe doit réellement accomplir. Choisissez des tâches représentatives, définissez des résultats acceptables et incluez le temps de revue dans la comparaison. Notez les cas où un système refuse, reste bloqué ou produit une réponse plausible qui échoue à l’inspection. Gardez les configurations testées visibles afin que les résultats restent interprétables. Comparez ensuite l’effort nécessaire pour parvenir à un résultat accepté. Ces éléments montreront si l’avantage mesuré par Google se transpose à votre flux de travail, et où le score plus élevé de Claude justifie son supplément. Qu’est-ce qui compte le plus pour votre prochain déploiement : davantage de capacités pour la tâche la plus difficile, ou davantage de travail acceptable dans le budget disponible ?