Ce que Google a annoncé le 8 octobre 2026

L’annonce a été faite lors de Gemini at Work 2026. Google présente Gemini agent comme un point d’entrée unique capable de répondre à des questions, produire des contenus, analyser des données et écrire ou exécuter du code. L’agent peut recevoir un objectif, planifier les étapes, sélectionner des compétences et des outils, puis restituer un livrable dans l’environnement de travail concerné.

La proposition repose sur trois briques. Les outils connectent l’agent aux applications et aux systèmes de l’entreprise. Les compétences regroupent des instructions, des connaissances et des workflows réutilisables. Le contexte conserve les éléments nécessaires pour éviter de rebriefer l’agent à chaque étape, avec des mécanismes de mémoire décrits par Google.

Gemini peut aussi fonctionner comme un agent personnel, un agent d’équipe ou un agent de rôle. Google donne l’exemple d’un agent doté d’une identité et d’un espace de travail propres, auquel les collaborateurs peuvent faire appel dans un espace de discussion ou dans un document. Cette approche est importante pour la traçabilité : l’action n’est plus nécessairement réalisée sous l’identité d’un salarié.

L’annonce inclut enfin des fonctions de choix de modèle et de maîtrise des dépenses. Le smart routing doit orienter chaque charge vers le modèle adapté, tandis que les plafonds de dépense peuvent interrompre un projet lorsque le budget défini est atteint. Google présente également des capacités de données et d’analytique permettant de transformer une question en langage courant en requête, rapport ou tableau de bord, en s’appuyant sur un catalogue de connaissances.

Pourquoi cette annonce compte pour les DSI et les métiers

Jusqu’ici, de nombreux projets d’IA d’entreprise ajoutaient un assistant à une application précise. Le Gemini agent propose une logique différente : une même couche pourrait passer de la recherche documentaire à la production d’un rapport, puis à la création d’un support ou à l’exécution d’une action. Cette promesse peut réduire les ruptures entre outils, mais elle augmente aussi le périmètre à gouverner.

Une couche d’exécution plutôt qu’un simple chatbot

Pour une DSI, le sujet n’est pas seulement la qualité des réponses. Il faut comprendre quelles données l’agent peut lire, quelles actions il peut lancer, dans quels outils il peut écrire et comment ses décisions sont enregistrées. La combinaison des connecteurs, des compétences et de la mémoire ressemble davantage à une couche d’orchestration du SI qu’à une interface conversationnelle classique.

Le modèle de Google peut intéresser les organisations qui disposent déjà de plusieurs assistants isolés. Une compétence validée pour préparer un reporting financier, trier des demandes IT ou analyser un portefeuille de contrats pourrait être réutilisée par plusieurs équipes, à condition que les droits, les sources et les critères de validation soient documentés.

Il faut toutefois distinguer l’architecture annoncée de la disponibilité opérationnelle de chaque fonction. Le billet de Google Cloud mélange capacités présentées, aperçus sectoriels et résultats de clients. Les responsables produit et sécurité doivent donc vérifier, cas par cas, les conditions d’accès, les régions disponibles, les connecteurs pris en charge et les niveaux de service.

Gouvernance, audit et maîtrise des coûts

Le point le plus intéressant pour les entreprises est peut-être la tentative de rendre l’agent identifiable et contrôlable. Google décrit une identité propre à chaque agent, des autorisations fondées sur les rôles, une attribution des actions dans les journaux et une exécution dans un environnement isolé. Une passerelle réseau doit également appliquer les politiques entre les utilisateurs, les agents, les systèmes et les modèles.

Cette approche répond à un problème concret : un agent qui agit dans plusieurs applications peut contourner les contrôles conçus pour un seul outil si l’organisation ne centralise pas les règles. En pratique, l’équipe sécurité devra tester les scénarios de privilège excessif, d’accès à une donnée classifiée, de réutilisation d’un contexte entre projets et de propagation d’une erreur dans un workflow automatisé.

Le coût doit être suivi avec la même précision. Le smart routing et les plafonds de dépense sont utiles, mais ils ne remplacent pas une comptabilité par cas d’usage. Un agent qui relance plusieurs sous-agents, exécute du code ou consulte de gros volumes de données peut être peu coûteux à l’unité et devenir significatif à l’échelle d’un département.

Cas d’usage et plan d’évaluation

Les exemples publiés par Google couvrent la finance, le juridique, la data, les télécoms, le support et les opérations. Ils donnent des pistes, mais les chiffres annoncés par un fournisseur ou un client ne constituent pas automatiquement un résultat reproductible. Le bon point de départ reste un workflow interne, avec un périmètre et une métrique clairement définis.

Deux cas d’usage à tester en priorité

Analyse et reporting opérationnel. Une équipe data ou finance peut demander à l’agent de retrouver les jeux de données pertinents, générer une requête, produire un rapport et expliquer les écarts par rapport à la période précédente. Le test doit mesurer la précision des indicateurs, la traçabilité des sources, le coût par rapport et le temps nécessaire à la validation humaine.

Orchestration du support et des opérations. Un agent peut qualifier une demande, consulter la base de connaissances, vérifier le statut dans un outil métier et préparer une réponse ou une action soumise à approbation. Les indicateurs utiles sont le taux de résolution, le taux d’escalade, le nombre d’actions annulées et l’impact sur le temps de traitement.

Travail juridique et conformité. Dans un environnement contrôlé, l’agent peut repérer des clauses, préparer une synthèse ou signaler des informations personnelles avant une publication. Il faut alors tester les permissions documentaires, les murs éthiques, la conservation des traces et la capacité à citer chaque source utilisée.

Les points à vérifier avant un déploiement

• Cartographier les données accessibles, les connecteurs et les actions possibles.

• Attribuer une identité distincte à chaque agent et appliquer le principe du moindre privilège.

• Définir les actions qui nécessitent une validation humaine et celles qui peuvent être automatiques.

• Mettre en place des jeux de tests avec cas nominaux, erreurs, données sensibles et demandes ambiguës.

• Mesurer la qualité, le coût, le temps gagné, le taux d’escalade et les incidents par workflow.

• Vérifier la localisation des données, les engagements contractuels, la réversibilité et la possibilité de changer de modèle.

• Commencer par un pilote limité, puis élargir seulement lorsque les journaux et les procédures d’incident sont opérationnels.

Google cite plusieurs déploiements clients pour illustrer cette trajectoire. Bradesco affirme notamment avoir réduit le temps de revue de documents d’une heure à cinq minutes sur certains workflows, tandis qu’Orange Spain indique avoir déployé plus de 1 000 agents personnalisés. Ces chiffres doivent être lus comme des résultats déclarés dans le cadre de cas particuliers, et non comme une garantie de ROI pour toute entreprise.