Le 28 octobre 2026, Google a présenté Gemini 4 Carbon. C’est un nouveau modèle de la famille Gemini 4. Il arrive deux semaines à peine après Gemini 4 Argon. Google le destine aux tâches de programmation complexes et à la cybersécurité.

Le modèle fait parler de lui depuis plusieurs semaines. Des employés de Google le testaient en interne avant l’annonce. Voici ce que l’on sait aujourd’hui, et ce que cela peut changer pour les personnes qui font du test.

Ce que Google annonce

Carbon vise surtout le code. Selon Google, il sait repérer des vulnérabilités, les valider et proposer un correctif. Il peut aussi suivre un projet logiciel en plusieurs étapes sur une longue durée.

Google avance un chiffre fort. D’après ses évaluations internes, Carbon produit du code sans faille deux fois plus souvent que Gemini 4 Argon. Ce résultat vient de Google seul. Il n’a pas encore été vérifié par une source indépendante.

Côté performances générales, les premiers classements le placent tout en haut. L’index de Vals AI le met au deuxième rang de son classement général. Sur les tests d’agents en terminal, il se place quatrième. Les écarts avec les autres modèles de pointe restent faibles. Quelques points seulement les séparent.

Un modèle qu’on ne peut pas encore utiliser

C’est le point le plus étonnant. Carbon n’est pas ouvert au grand public. Google explique que ses capacités en cybersécurité sont trop sensibles pour une sortie large. Un modèle capable de trouver une faille peut aussi aider à l’exploiter.

Le déploiement se fait donc par étapes. Les premiers accès vont à des spécialistes de la défense informatique. Google veut d’abord évaluer ses garde-fous. On n’a, à date, aucune date d’ouverture générale confirmée.

Pourquoi la QA devrait suivre ce sujet

Un modèle qui écrit du code plus sûr ne supprime pas le besoin de tester.

Le test de sécurité devient plus accessible. Repérer une vulnérabilité demandait jusqu’ici une expertise pointue. Un assistant comme Carbon peut aider une personne en charge du test à cibler les zones à risque. Il faut garder en tête qu’il peut se tromper.

Les correctifs générés doivent être vérifiés. Un patch proposé par une IA reste du code à tester. Il peut corriger la faille et casser autre chose, on garde donc les tests de régression.

Les résultats annoncés restent à confirmer. Un taux de réussite mesuré par l’éditeur n’est pas une preuve, il faut mesurer sur son propre contexte avant de faire confiance.

Ce qu’il faut retenir

Gemini 4 Carbon montre une tendance claire. Les modèles d’IA se spécialisent dans le code et la sécurité. Pour l’équipe de test, c’est un outil de plus à apprivoiser !

Les risques restent les mêmes qu’avec les autres modèles. Hallucinations, biais et excès de confiance sont toujours là. Ils sont détaillés dans la page Risques et limites de l’IA. Pour voir comment intégrer ces outils au quotidien, la page Adopter l’IA en équipe QA donne des repères concrets.

Affaire à suivre…