Stratégie et gouvernance de l'IA

Gemma 4 : Google lève la barrière de licence et redéfinit le plancher du modèle ouvert performant

La publication de la suite Gemma 4 le 2 avril 2026 mérite un traitement séparé, non pas pour ses seuls scores de benchmark, mais parce qu’elle combine trois changements qui, pris ensemble, modifient structurellement le calcul des équipes en charge des choix d’architecture IA : une transition de licence qui lève deux ans de friction juridique, une gamme de modèles couvrant tous les niveaux d’infrastructure de l’edge au cloud, et une intégration native de capacités agentiques qui n’étaient jusqu’ici accessibles que via des modèles propriétaires. La famille compte quatre variantes — E2B (2B paramètres effectifs), E4B (4B), 26B Mixture-of-Experts et 31B Dense — disponibles sous licence Apache 2.0, une première dans l’histoire du programme Gemma.

Pour les entreprises, le point de départ n’est pas technique : c’est juridique. Pendant deux ans, les versions précédentes de Gemma s’accompagnaient d’une licence propriétaire que Google pouvait modifier unilatéralement, qui imposait aux développeurs de répercuter les règles Google sur tous les projets dérivés, et qui contenait des clauses pouvant affecter jusqu’aux modèles entraînés sur des données synthétiques générées par Gemma. Les équipes juridiques de nombreuses organisations avaient choisi Mistral ou Qwen d’Alibaba — non pas parce que ces modèles étaient nécessairement meilleurs, mais parce que leurs licences étaient plus claires. Apache 2.0 supprime toutes ces contraintes : usage commercial illimité, droits de modification et de redistribution sans restriction, aucune clause que Google pourrait actualiser après déploiement.

Une architecture pensée pour chaque couche de déploiement

La famille Gemma 4 ne se résume pas à une déclinaison de tailles. Chaque variante répond à une contrainte d’infrastructure différente, avec des choix architecturaux distincts. Les deux modèles edge (E2B et E4B) utilisent une technique appelée Per-Layer Embeddings : un signal d'embedding secondaire est injecté à chaque couche du décodeur, ce qui permet à un modèle de 2,3 milliards de paramètres actifs d’afficher la profondeur de représentation d’un modèle complet de 5,1 milliards, tout en tenant en moins de 1,5 Go de mémoire avec quantification. En pratique, ils fonctionnent hors connexion sur smartphones, Raspberry Pi et Jetson Orin Nano, avec un support natif de l’audio pour la reconnaissance vocale. Google a confirmé que ces modèles constituent la base de la prochaine génération de Gemini Nano 4, ce qui signifie que le code écrit aujourd’hui pour Gemma 4 fonctionnera directement sur les appareils Android équipés de Gemini Nano 4. (Source : android-developers.googleblog.com)

Le 26B Mixture-of-Experts est le point d’équilibre de la gamme. Sur ses 26 milliards de paramètres totaux, seulement 3,8 milliards sont activés par inférence via un routage entre 128 experts, ce qui lui permet de générer des tokens à une vitesse proche d’un modèle 4B tout en atteignant une qualité estimée à 97 % du modèle dense 31B. Sur Arena AI, il se positionne #6 mondial avec un score de 1441. Pour les équipes qui exploitent des pipelines de traitement documentaire ou des assistants de code à l’échelle, cela se traduit directement par moins de GPU nécessaires et un coût par token réduit à charge comparable.

Le 31B Dense, conçu pour les workstations et les serveurs, tient dans un seul GPU NVIDIA H100 80 Go en précision bfloat16 complète, ou sur un GPU grand public de 16 Go en quantification 4 bits via Ollama ou GGUF. C’est lui qui délivre les scores de raisonnement les plus élevés : 89,2 % sur AIME 2026, 84,3 % sur GPQA Diamond (raisonnement scientifique niveau master), 80 % sur LiveCodeBench v6. Le saut de performance par rapport à Gemma 3 27B est significatif — ce dernier plafonnait à 20,8 % sur AIME 2026 et 29,1 % sur LiveCodeBench sans mode raisonnement. (Source : blog.google — Gemma 4)

Tous les modèles partagent une architecture d’attention hybride qui alterne couches locales à fenêtre glissante (512 à 1 024 tokens) et couches globales à contexte complet. C’est cette combinaison qui permet d’atteindre des fenêtres de contexte de 128K tokens pour les versions edge et 256K tokens pour les grands modèles, sans explosion de la consommation mémoire. Le support du traitement vidéo (jusqu’à 60 secondes à 1 image par seconde pour le 31B) et des images à résolution variable avec un budget de tokens configurables (de 70 à 1 120 tokens par image) permet d’adapter finement le compromis vitesse-qualité selon le cas d’usage.

L’agentique natif : ce qui change vraiment dans la conception des agents

Sur les versions précédentes de Gemma, comme sur la majorité des modèles ouverts de l’époque, le function calling reposait sur l’instruction-following : le modèle était guidé par le prompt pour produire une sortie structurée, avec des résultats variables selon la formulation. Gemma 4 adopte une approche différente : le function calling a été entraîné nativement dans le modèle à partir des travaux de Google sur FunctionGemma, et optimisé pour les flux agentiques multi-tours avec plusieurs outils en parallèle. (Source : blog.google — Gemma 4)

La conséquence pratique est double. D’abord, les sorties JSON structurées et les appels de fonctions fonctionnent de manière fiable sur l’ensemble des quatre variantes, y compris les modèles edge — ce qui ouvre des architectures d’agents locaux sans serveur, sans coût d’API, sans dépendance réseau. Ensuite, le volume de prompt engineering habituellement investi par les équipes pour fiabiliser les outils dans les systèmes multi-agents devrait diminuer, puisque cette fiabilité est désormais intégrée au modèle plutôt que déléguée à la formulation du prompt.

Le mode raisonnement configurable — activé via un token système <|think|> — permet au modèle de produire sa chaîne de pensée avant la réponse finale, avec une séparation structurée des deux flux. Ce mécanisme est utile dans les agents de planification multi-étapes, où l’auditabilité du raisonnement intermédiaire a une valeur opérationnelle : les équipes peuvent inspecter et logger les étapes de réflexion séparément des sorties finales. Sur les benchmarks agentiques, le 31B Dense atteint 86,4 % sur tau2-bench, contre 6,6 % pour Gemma 3 27B — un écart qui reflète une rupture de génération sur ce type de tâche.

Contexte concurrentiel : une réponse structurelle, pas seulement un lancement

Le passage à Apache 2.0 ne s’explique pas uniquement par la volonté de faciliter l’adoption. Il s’inscrit dans un déplacement de rapport de force dans l’open source IA. Les modèles chinois — Qwen d’Alibaba, DeepSeek — avaient gagné une traction significative auprès des développeurs et des entreprises précisément parce que leurs licences permissives n’imposaient pas de friction. Google reconnaît tacitement ce terrain perdu et choisit de répondre sur les termes mêmes de ses concurrents plutôt que de maintenir un avantage de licence qui se retournait contre lui.

Le contexte est doublement asymétrique. D’un côté, certains acteurs commencent à resserrer leurs licences ouvertes, ce qui renforce l’intérêt relatif d’Apache 2.0. De l’autre, Gemma 4 est lancé dans le mois le plus chargé de l’open source IA : Alibaba a publié Qwen 3.6-Plus le même jour avec une fenêtre de contexte de 1 million de tokens, et Llama 4 Scout de Meta proposait déjà 10 millions de tokens. Sur les benchmarks comparatifs, les marges sont minces : Qwen 3.5 27B devance légèrement Gemma 4 31B sur GPQA Diamond (85,8 % contre 85,7 %), mais Gemma 4 consomme moins de tokens de sortie pour des réponses équivalentes, ce qui réduit le coût par GPU-heure. Sur Arena AI, les évaluateurs humains ont systématiquement préféré les réponses Gemma 4 à celles de concurrents avec des scores automatiques proches — un signal qualitatif difficile à quantifier mais utile pour les cas d’usage orientés interaction.

Un point de vigilance reste documenté : des développeurs ayant testé le 31B Dense au lancement ont relevé des vitesses d’inférence significativement inférieures à celles de Qwen 3.5 sur le même matériel. Ce type d’écart se comble souvent sur les semaines suivant un lancement, à mesure que l’optimisation des frameworks se stabilise, mais il mérite d’être mesuré sur les propres configurations d’infrastructure de chaque équipe avant de statuer.

Ce que cela change pour les entreprises

La combinaison licence + capacités rend plusieurs arbitrages plus simples qu’ils ne l’étaient il y a trois mois. La question n’est plus de savoir si on peut légalement déployer Gemma en production commerciale — Apache 2.0 y répond sans ambiguïté. La question devient : pour quels workloads Gemma 4 offre-t-il de meilleures conditions économiques ou de meilleur contrôle que les alternatives propriétaires ou cloud ?

Trois cas de figure méritent une évaluation immédiate. Le premier concerne les environnements à contrainte de souveraineté ou de confidentialité des données : un modèle de raisonnement de classe frontier déployable on-premise ou dans un cloud souverain, sans clause de licence pouvant limiter les usages ou exiger une vérification légale, change le périmètre des projets réalisables en interne. Le deuxième concerne les agents métiers sur des cas d’usage à fort volume de traitement : le profil de coût du 26B MoE — qualité proche du 31B à une fraction du coût de calcul — est directement exploitable pour des pipelines de traitement documentaire, d’extraction structurée ou d’assistance à la décision à l’échelle. Le troisième est l’edge : des agents multimodaux capables de traiter texte, image et audio localement, sur smartphone ou micro-serveur, sans latence réseau ni coût d’API, ouvrent des cas d’usage qui n’étaient pas réalisables à ce niveau de qualité sur des dispositifs locaux.

Pour les équipes déjà engagées sur des architectures à base de modèles ouverts, le signal opérationnel immédiat est d’intégrer Gemma 4 dans le pipeline de qualification des modèles (cadre du chapitre 2 de la Méthode Virtuose, panorama et critères de sélection). La disponibilité day-0 dans vLLM, llama.cpp, Transformers, MLX, Ollama et NVIDIA NIM réduit le coût de test à un niveau faible. Les équipes LLMOps devront également évaluer l’impact sur leurs pipelines de fine-tuning : la compatibilité Gemma 4 est déjà intégrée dans Axolotl, Google Colab et Vertex AI Training Clusters, avec des gains de vitesse documentés sur les approches MoE + LoRA. (Source : cloud.google.com — Gemma 4 on Google Cloud)

Ce que cela met à jour dans la Méthode Virtuose

Le chapitre 2 (Panorama des modèles) et le chapitre 2.4 (Modèles ouverts versus propriétaires : critères de décision) doivent intégrer un point structurant : la licence Apache 2.0 de Gemma 4 retire définitivement l’argument juridique qui pesait en faveur des modèles concurrents à performances comparables. La grille de décision make-or-buy et la grille de sélection de modèles ouverts doivent refléter ce changement de contexte. Le chapitre 2.5 (SLM et IA en périphérie) gagne également en substance : Gemma 4 E2B et E4B constituent un cas de référence concret pour les architectures edge avec agents multimodaux natifs, qui seront désormais évaluables en conditions réelles sans restriction de licence. Enfin, le chapitre 8 (Agents autonomes) peut s’appuyer sur l’approche du function calling natif de Gemma 4 — entraîné dans le modèle plutôt que délégué au prompt — comme exemple de la direction prise par les modèles pour réduire le coût de conception des agents outillés.

Google déploie avec Gemma 4 une stratégie qui n’est pas seulement technique : en alignant ses conditions de licence sur le reste de l’écosystème ouvert, il réintègre le marché des entreprises qui s’en étaient éloignées pour des raisons purement juridiques. Si les équipes d’optimisation tiennent la cadence habituelle post-lancement, la question de fond pour les prochains mois sera moins de savoir si Gemma 4 est compétitif que de savoir sur quels segments spécifiques son profil de coût-performance-contrôle l'emporte sur les alternatives disponibles.