Le modèle d’IA de Google axé sur l’exécution soulève une question d’architecture : une application doit-elle utiliser un seul modèle performant pour tout un workflow, ou répartir le travail entre des modèles aux atouts différents ?
Imaginez que vous demandiez à un assistant de programmation IA d’introduire un contrôle d’accès basé sur les rôles dans une application existante. Il doit repérer le code d’authentification, comprendre quels services appliquent les permissions, planifier la modification, écrire le code et vérifier que les utilisateurs ordinaires ne peuvent pas effectuer d’actions d’administration.
Un seul modèle performant pourrait tenter de tout faire. Mais comprendre une frontière de sécurité n’est pas la même chose qu’appliquer une modification de code bien définie ou exécuter un test existant. Chaque étape exige-t-elle la même capacité de raisonnement, et doit-elle avoir le même prix ?
L’annonce de Gemini 4 Hydrogen par Google, le 12 novembre 2026, met cette question en lumière. Google positionne Hydrogen pour le codage rapide et l’exécution agentique, tandis que ses modèles Gemini 4 Carbon et Argon se concentrent sur le raisonnement exigeant. Son Antigravity Orchestrator peut changer de modèle au cours d’un workflow. L’annonce de Google décrit cette approche, mais une démonstration de produit ne prouve pas qu’il s’agisse de la meilleure architecture pour toutes les applications.
La question pratique est la suivante : quand un modèle supplémentaire apporte-t-il assez pour justifier une frontière de plus, un appel de plus et une façon de plus pour le système de tomber en panne ?
Pourquoi un seul modèle d’IA peut ne pas suffire
Une équipe de développement choisit souvent un modèle d’IA en évaluant le raisonnement, la capacité de codage, le temps de réponse, la taille du contexte et le prix. Elle utilise ensuite ce modèle pour toute l’application. C’est un choix par défaut raisonnable : l’intégration est plus simple, moins d’éléments mobiles sont à surveiller, et le modèle peut conserver un contexte de travail cohérent.
Les workflows réels contiennent pourtant des types de travail différents. Notre assistant de programmation doit interpréter une exigence, repérer les fichiers pertinents, déterminer où placer l’autorisation, modifier des composants et interpréter les échecs de test. La décision d’architecture n’équivaut pas à une recherche de fichier. Un modèle performant sur les raisonnements difficiles peut coûter plus que nécessaire pour une exécution de routine, tandis qu’un modèle moins cher peut être rapide mais négliger une dépendance qui compte.
Cela ouvre la possibilité d’une allocation de modèles au niveau des tâches : confier les décisions difficiles à un modèle plus performant et l’exécution bornée à un autre. Il ne s’agit pas d’exécuter plusieurs modèles en parallèle à tout prix. On peut aussi ne changer de modèle que lorsqu’une tâche franchit un seuil défini de complexité ou d’incertitude.
L’économie apparente s’accompagne d’une obligation : l’application doit toujours fournir un résultat correct, et pas seulement des réponses individuelles moins chères.
Ce que Google a présenté avec Gemini 4 Hydrogen
Google décrit Hydrogen comme un modèle axé sur l’exécution, pour le codage itératif, le débogage, l’utilisation d’outils et le travail de connaissance multimodal. Selon sa fiche de modèle, il est adapté de Gemini 4 Carbon. Il accepte le texte, les images, l’audio et la vidéo, avec une fenêtre de contexte combinée pouvant atteindre un million de jetons. La sortie synchrone par défaut est limitée à 64 000 jetons, tandis que l’option de décodage long en arrière-plan de Google va jusqu’à un million. Ce ne sont pas des affirmations interchangeables sur la sortie ordinaire de l’API.
Hydrogen propose quatre niveaux de réflexion (low, medium, high et xhigh), et Google indique des tarifs d’API standard de 1,50 dollar américain par million de jetons en entrée et 7,50 dollars américains par million de jetons en sortie. Google affirme qu’il est distribué via l’API Gemini, AI Studio, Antigravity et d’autres produits Google. L’accès réel, les quotas et les conditions commerciales applicables doivent être vérifiés pour le produit et le compte utilisés.
Dans Antigravity, Google affirme qu’Orchestrator peut passer d’un modèle à l’autre, par exemple Carbon et Hydrogen, au sein d’une même session de développement. Carbon peut se charger de la planification difficile pendant qu’Hydrogen effectue les étapes d’implémentation ou de vérification. Google rapporte une réussite des tâches proche de celle de Carbon sur Terminal-Bench 4.0, avec 24 % de quota consommé en moins et une exécution 19 % plus rapide en moyenne. Google n’indique pas quel niveau de réflexion ni quelle configuration il a utilisés, ni combien de tâches. Ce sont des résultats de Google, et le chiffre du quota ne correspond pas automatiquement à une baisse de 24 % de la facture d’une organisation. Orchestrator fait partie de Google Antigravity, que Google met à la disposition des abonnés payants de Google AI Pro et Ultra. Annonce de lancement.
Le routage de modèles et les agents spécialisés étaient déjà des modèles de conception établis. Hydrogen est une nouvelle option dans cette architecture, et non l’invention de l’IA multimodèle.
Un modèle ou plusieurs : un exemple pratique
Revenons à la fonctionnalité de contrôle d’accès basé sur les rôles. Il s’agit de permettre aux administrateurs de gérer les rôles sans autoriser les utilisateurs ordinaires à appeler les points d’accès d’administration.
Workflow à un seul modèle. Un assistant de programmation lit le dépôt, identifie les fonctions concernées, propose et applique les modifications, exécute les tests et analyse les échecs. Son avantage est la continuité : un seul modèle et un seul historique d’exécution principal. Son inconvénient peut être le recours à un raisonnement coûteux pour des sous-tâches simples. Ce coût ne compte que si la charge de travail est assez fréquente et assez coûteuse pour justifier une optimisation.
Workflow planificateur-exécutant. Un modèle plus performant identifie les règles d’autorisation, les gestionnaires d’API concernés, les processus d’arrière-plan et les dépendances de données. Il transmet une tâche bornée (avec les fichiers autorisés, les invariants de sécurité et les attentes en matière de tests) à un modèle d’exécution. L’exécutant implémente la modification. Un vérificateur contrôle le résultat, et les questions de conception imprévues remontent au planificateur au lieu d’être tranchées silencieusement par l’exécutant.
Alternative textuelle accessible de cette figure
Un seul modèle : Lire le dépôt, Planifier le changement, Modifier le code, Lancer les tests d’accès, Approuver si tests réussis.
Planificateur, exécutant et vérificateur : Le planificateur fixe les règles, L’exécutant modifie le code, Le vérificateur contrôle, Lancer les tests d’accès, Approuver si tests réussis.
Les deux conceptions se terminent par des tests de contrôle d’accès déterministes. Les trois rôles ne sont pas nécessairement trois modèles différents.
Ce second workflow peut être efficace, mais il introduit un mode de défaillance dangereux. Supposons que le planificateur oublie qu’une tâche d’arrière-plan applique aussi des permissions. Un exécutant pourrait implémenter parfaitement la tâche écrite tout en laissant cette tâche exposée. Un vérificateur qui reçoit le même brief incomplet pourrait l’approuver.
La solution n’est pas simplement un autre relecteur IA. L’application a besoin d’exigences faisant autorité et de tests de contrôle d’accès déterministes, y compris des tests négatifs montrant que les utilisateurs non autorisés sont refusés. L’IA peut aider à proposer et à examiner des modifications, mais l’application des permissions relève du logiciel et de ses contrôles de déploiement.
Comment fonctionne l’orchestration multimodèle
Un orchestrateur attribue les tâches, fournit le contexte pertinent, coordonne les appels d’outils, recueille les résultats et décide quand réessayer, escalader ou s’arrêter. Un schéma courant comporte trois rôles :
- Planificateur : interprète la demande, examine les dépendances et établit les limites de l’implémentation.
- Exécutant : réalise des activités bornées comme modifier du code, rechercher des éléments de preuve ou analyser un échec de test.
- Vérificateur : contrôle le résultat par rapport à la tâche et signale les preuves manquantes ou les défauts.
Ce sont des rôles, pas nécessairement trois modèles différents. Un même modèle peut remplir plusieurs rôles, et des tests ou des moteurs de politiques peuvent assurer une vérification importante sans modèle d’IA.
Il existe des variantes utiles. Dans le routage séquentiel, une étape transmet le travail à la suivante. Dans l’exécution parallèle, des exécutants indépendants travaillent dans des espaces de travail isolés et leurs résultats sont intégrés ensuite. Dans le routage par escalade, un modèle moins coûteux traite les demandes de routine mais oriente les cas incertains vers un modèle plus performant.
Une alternative encore plus simple consiste à conserver un seul modèle et à faire varier son effort de réflexion. Les quatre niveaux d’Hydrogen en font un choix explicite. Avant de construire un orchestrateur, testez si un niveau de réflexion plus bas peut traiter le travail de routine pendant que le niveau high traite les cas difficiles.
Cet article porte sur l’orchestration au niveau des tâches. Pour les questions plus larges sur les identifiants centralisés, l’éligibilité des modèles, les quotas et les politiques des fournisseurs, l’article de TechiesJournal API Gateway vs AI Gateway explique une frontière d’architecture différente. Une passerelle peut contrôler les modèles qu’une application a le droit d’appeler. Elle ne détermine pas, à elle seule, comment les tâches de l’application doivent être planifiées ou vérifiées.
Utiliser plusieurs modèles fait-il vraiment économiser de l’argent ?
Le prix d’une requête isolée n’est pas le coût d’un workflow terminé. Une conception planificateur-exécutant peut envoyer moins de requêtes coûteuses, mais elle transfère aussi du contexte, consomme des jetons supplémentaires pour la coordination, relance les échecs et effectue des vérifications.
Prenons une charge de travail fictive pour laquelle l’approche à un seul modèle coûte 0,40 dollar par tâche menée à bien. Une seconde architecture semble coûter 0,25 dollar en appels de planification et d’exécution, mais les relances et la relecture portent le coût final à 0,38 dollar. L’économie apparente de 37,5 % tombe à 5 %. Ces chiffres sont illustratifs et ne sont pas des mesures d’Hydrogen.
La latence fonctionne de façon similaire. Des tâches indépendantes exécutées en parallèle peuvent se terminer plus tôt. Des transmissions séquentielles peuvent ralentir une tâche. Les mesures utiles sont le coût par tâche correcte menée à bien, le temps écoulé de bout en bout, le taux d’échec et l’intervention humaine. Ne compter que les prix des jetons d’entrée et de sortie peut masquer un retravail coûteux.
L’effort de réflexion modifie lui aussi l’économie. Des mesures indépendantes d’Artificial Analysis indiquent ce qui suit pour Hydrogen, tel que listé le 13 novembre 2026 (les pages ne donnent pas de date de mesure) :
| Réglage de réflexion | Intelligence Index | Coût par tâche évaluée | Temps par tâche évaluée |
|---|---|---|---|
| High | 51 | 1,87 $ | 7,9 minutes |
| Xhigh | 54 | 3,16 $ | 13,7 minutes |
Ces temps et ces coûts se rapportent aux tâches d’Artificial Analysis Intelligence Index, et non à des demandes de codage ordinaires. Xhigh améliore l’indice de trois points tout en augmentant le coût mesuré d’environ 69 % et le temps d’environ 73 %. Le bon choix dépend de la question de savoir si le raisonnement supplémentaire améliore réellement le résultat pour l’application. Mesure High · Mesure Xhigh.
Comment Hydrogen se compare aux modèles d’autres éditeurs
Google n’est pas le seul à proposer différents modèles pour différentes tâches. Le choix comprend d’autres modèles capables de coder et des options plus petites adaptées au routage, à l’extraction et aux opérations répétées à faible risque. Le tableau ci-dessous donne les tarifs d’API standard publiés, en dollars américains par million de jetons en entrée et en sortie, tels que consultés le 13 novembre 2026. Les conditions propres à chaque fournisseur, la mise en cache, les frais d’outils, la tokenisation et les niveaux de service peuvent influer sur les coûts réels.
| Modèle et fournisseur | Entrée / sortie | Usage pertinent ou particularité |
|---|---|---|
| Gemini 4 Hydrogen (Google) | 1,50 $ / 7,50 $ | Codage et agents axés sur l’exécution, réflexion configurable |
| GPT-6.1 Sol (OpenAI) | 2,00 $ / 10,00 $ | Performances proches d’Astra pour le travail complexe, à moindre coût, selon OpenAI |
| Claude Sonnet 5.5 (Anthropic) | 2,00 $ / 10,00 $ | Équilibre entre vitesse et intelligence, selon Anthropic |
| Mistral Small 4 (Mistral) | 0,15 $ / 0,60 $ | Raisonnement hybride et codage, licence Apache 2.0, poids ouverts |
| DeepSeek V4.1 Flash 1017 (hébergé par Mistral) | 0,30 $ / 1,20 $ | Modèle de codage à long contexte hébergé par un tiers, préversion publique |
Tarifs et rôles : Google, OpenAI, Anthropic, Mistral Small 4, DeepSeek hébergé par Mistral. La ligne DeepSeek correspond à un tarif d’hébergement Mistral, et non à un tarif vérifié de l’API DeepSeek directe. Ces lignes n’impliquent ni des performances identiques aux benchmarks ni des conditions de service équivalentes.
OpenAI propose GPT-6 Astra pour le travail exigeant, GPT-6.1 Sol pour un compromis coût/capacité et GPT-6 Luna pour le travail ciblé à fort volume. Ce dernier est listé à 0,10 dollar en entrée et 0,50 dollar en sortie par million de jetons, mais un prix bas ne prouve pas qu’il puisse remplacer un agent de codage plus puissant. Le développeur doit comparer les taux de réussite réels des tâches. Catalogue de modèles OpenAI.
Anthropic distingue de la même façon Sonnet 5.5 de Haiku 5.5, qu’Anthropic positionne pour les tâches à fort volume et sensibles à la latence comme la classification, l’extraction et le routage. Anthropic liste Haiku à partir de 0,10 dollar en entrée et 0,50 dollar en sortie par million de jetons. Les différences de tokeniseurs et de réglages d’effort compliquent les comparaisons fondées sur le seul prix catalogue. Modèles Anthropic.
Mistral Small 4 ajoute une autre dimension : les poids ouverts et la flexibilité de déploiement. Les organisations peuvent envisager l’auto-hébergement, mais les serveurs, le taux d’utilisation, la supervision et la maintenance sont de vrais coûts. Un tarif d’API bas et une licence ouverte ne garantissent pas un coût total faible. Documentation Mistral.
DeepSeek V4.1 Flash 1017 est la version mise à jour du 17 octobre, servie sous le nom deepseek-flash dans l’API de DeepSeek, selon son journal des modifications. Mistral le propose aussi comme modèle tiers en préversion publique, sans modifications de Mistral. Ces offres peuvent avoir des prix et des conditions d’exploitation différents. Nous ne devons pas considérer un résultat Terminal-Bench 4.0 rapporté par DeepSeek comme directement comparable au score Terminal-Bench 4.1 d’un autre éditeur.
La décision ne consiste pas à savoir quel éditeur remporte un classement général. Elle consiste à savoir si un modèle donné remplit de façon fiable le rôle choisi avec les outils prévus et les frontières de sécurité voulues. Parfois, la meilleure conception utilise un seul fournisseur et plusieurs niveaux. Parfois, un éditeur distinct apporte de la valeur. L’exploitation entre plusieurs éditeurs ajoute aussi de la complexité en matière d’API, de confidentialité, de disponibilité et de dépannage.
Où l’orchestration multimodèle peut échouer
Un second modèle introduit une seconde interprétation de la tâche. Des exigences peuvent se perdre quand le planificateur réduit le problème d’origine à un brief. Les exécutants peuvent produire du code d’apparence compatible tout en violant une contrainte omise. Des agents parallèles peuvent modifier des interfaces en conflit, et les relecteurs peuvent partager la même prémisse erronée que l’auteur du code.
L’orchestrateur a donc besoin d’un contrat de tâche explicite, de permissions bornées, de preuves de chaque action d’outil, de règles d’escalade et d’un moyen fiable d’identifier les modifications exactes qui sont testées. Un modèle ne devrait pas pouvoir approuver son propre déploiement en production simplement parce que l’explication qu’il a générée semble convaincante.
La fiche de modèle de Google documente aussi des risques résiduels d’hallucination, de lenteur, de délai d’attente dépassé et de consommation élevée de jetons. Dans ses évaluations de sécurité automatisées internes, par rapport à Gemini 3.8 Flash, Google rapporte une hausse de 5,57 points de pourcentage des refus injustifiés. Google indique qu’un examen manuel ultérieur a conclu que la plupart des régressions signalées étaient des faux positifs ou n’étaient pas graves. Les deux éléments comptent : la régression automatisée est réelle telle que rapportée, mais elle ne prouve pas un préjudice équivalent en conditions réelles.
Pour une discussion plus large sur les raisons pour lesquelles des agents performants ont encore besoin d’une responsabilité indépendante, lisez l’article de TechiesJournal L’IA fait de mieux en mieux le travail. Mais est-elle prête à en assumer le résultat ?. La question plus étroite de cet article est de savoir quel modèle doit accomplir quelle partie de la tâche, et non qui est finalement responsable des résultats en production.
Ce que les benchmarks établissent et n’établissent pas
La fiche de modèle de Google rapporte 57,0 % pour Hydrogen sur Terminal-Bench 4.1 avec correction de la triche, contre 63,9 % pour Claude Sonnet 5.5. Hydrogen fait mieux sur certaines autres évaluations rapportées. Sur Agents’ Last Exam v1.1, la fiche indique 71,6 % pour Hydrogen contre 60,4 % pour Claude Sonnet 5.5, et Hydrogen est aussi en tête sur certaines tâches multimodales. Un modèle peut mener sur une charge de travail et être derrière sur une autre sans contradiction. Fiche de modèle de Google.
Le rapport de méthodologie identifie des harnais et des configurations d’évaluation différents. Par exemple, le résultat de Google sur Terminal-Bench 4.1 repose sur cinq tentatives par tâche, moyennées sous un harnais précisé, alors que plusieurs résultats de concurrents proviennent de classements publics ou de rapports d’éditeurs. Cela compte quand un chiffre phare est présenté sans les conditions du test.
Artificial Analysis mesure de façon indépendante certaines caractéristiques d’Hydrogen en matière d’intelligence, de vitesse et de coût, mais ces mesures représentent elles aussi un benchmark défini, et non une garantie pour le dépôt privé d’une application.
Les éléments disponibles étayent une conclusion plus étroite : Hydrogen est une option crédible pour les workflows axés sur l’exécution, et l’expérience d’orchestration de Google suggère un possible gain d’efficacité. Ils ne prouvent pas que le routage de modèles est toujours moins cher, plus fiable ou plus sûr. Les applications doivent toujours faire leur propre évaluation sur des tâches représentatives.
Comment les développeurs devraient choisir une architecture
Commencez par un seul modèle et un petit ensemble de tâches représentatives. Pour notre scénario de contrôle d’accès basé sur les rôles, incluez un cas d’implémentation normal, un cas avec une dépendance cachée et un cas qui doit être rejeté parce que l’opération demandée dépasse les permissions. Utilisez la même base de code, les mêmes outils, les mêmes exigences et les mêmes critères de réussite dans chaque comparaison.
Notez si l’assistant a trouvé les frontières concernées, si les tests d’autorisation ont réussi, le temps écoulé total, les frais réels facturés par le fournisseur, les relances et toute correction humaine. Essayez ensuite un réglage de raisonnement plus bas ou un modèle moins cher sur une étape bornée. N’ajoutez une transmission planificateur-exécutant que si les résultats le justifient.
| Situation | Approche de départ raisonnable |
|---|---|
| Tâche petite ou peu fréquente | Un seul modèle performant |
| Extraction ou classification à fort volume | Modèle moins coûteux dont la précision est testée |
| Planification complexe avec implémentation prévisible | Évaluer la séparation planificateur-exécutant |
| Tâches indépendantes avec interfaces contrôlées | Envisager des exécutants parallèles |
| Actions sensibles pour la sécurité ou modifiant la production | Contrôles déterministes et autorisation requise, quel que soit le nombre de modèles |
| Exigences incertaines ou capacité d’ingénierie limitée | Garder l’architecture la plus simple jusqu’à ce que les preuves justifient un changement |
Si vous introduisez du routage, consignez quel modèle a traité chaque tâche, pourquoi il a été choisi et quelles preuves ont justifié l’acceptation. Sinon, les problèmes de coût et de fiabilité deviennent difficiles à diagnostiquer.
Ce que les développeurs devraient faire ensuite
Hydrogen reflète une vraie direction des systèmes d’IA : les développeurs peuvent choisir des modèles et des réglages de raisonnement pour différents types de travail au lieu de traiter toutes les requêtes de la même façon. Google a rendu cette répartition plus explicite avec un modèle axé sur l’exécution et Antigravity Orchestrator.
Mais davantage d’options ne dispensent pas l’ingénieur de choisir avec soin. Une conception multimodèle qui économise des jetons mais perd des exigences critiques n’est pas une amélioration. Un modèle unique qui mène la charge de travail à bien de façon fiable à un coût acceptable peut être la meilleure architecture.
Partez de la tâche métier ou d’ingénierie. Établissez une base de référence mesurable, examinez où l’effort de raisonnement est utile et testez le plus petit changement susceptible d’améliorer le résultat. N’ajoutez l’orchestration que si les preuves montrent que les frontières supplémentaires en valent la peine.
Le but n’est pas d’utiliser plus de modèles d’IA. C’est d’appliquer la bonne capacité au bon travail, et de faire en sorte que chaque couche ajoutée justifie sa place.
Références et lectures complémentaires
- Google: Introducing Gemini 4 Hydrogen (12 November 2026): positionnement, tarifs et affirmations sur Orchestrator.
- Google DeepMind: Gemini 4 Hydrogen model card (12 November 2026): architecture, contexte, résultats de benchmarks, limites et données de sécurité.
- Google DeepMind: Hydrogen evaluation methodology (November 2026): harnais, méthodes de notation et limites de comparaison.
- Artificial Analysis: Hydrogen high et Hydrogen xhigh: mesures indépendantes d’intelligence, de coût et de durée.
- OpenAI: API model catalog: positionnement officiel des modèles et prix des jetons listés.
- Anthropic: Model overview: niveaux de Claude, charges de travail et tarifs.
- Mistral: Small 4 specifications: capacités du modèle, licence et prix.
- DeepSeek: API change log et Mistral: hosted DeepSeek V4.1 Flash: détails propres à la version et à l’hébergement.
Les sources ont été consultées le 13 novembre 2026. Les prix des éditeurs, les conditions des modèles et leur disponibilité peuvent changer.