Votre première application Gemini Enterprise : de la création dans la console aux agents qui répondent avec vos documents

« Des agents avec les documents de votre entreprise » sonne comme un projet de six mois avec une équipe derrière. Le cycle réel de la première application Gemini Enterprise (la suite d'agents de Google Cloud, configurée sur les données d'une organisation) prend nettement moins, et le parcours que je vais dérouler ici le couvre de bout en bout : création dans la console, identité, trois sources de données connectées, agents préconstruits et un notebook qui transforme le matériel en audio et en vidéo. La source est « Create Your First Gemini Enterprise Application », de Google Skills.

La création : chercher, créer, nommer

Le premier tronçon vit dans la Google Cloud Console. On cherche « Gemini Enterprise », on sélectionne le produit, et sur la page d'accueil on choisit Create your first app. Ensuite : un nom (dans la démonstration, « Symbol Foods Marketing Team ») et Create. Quatre étapes, et aucune n'exige d'écrire du code.

L'identité avant les données

Voici l'étape que les gens sautent et qui explique ensuite la plupart des problèmes de partage : Setup identity. On choisit Google Identity comme fournisseur d'identité de l'organisation et on confirme l'identité de la main-d'œuvre avec Confirm Workforce Identity.

L'ordre n'est pas anodin. Configurer l'identité apparaît comme préalable à toute connexion de données ou au partage du lien. L'application est créée d'abord, elle reçoit ensuite son propre nom au sein de votre organisation, et ce n'est qu'alors qu'on connecte les sources et qu'on partage. Inverser cet ordre revient à avoir une app dont les documents sont accessibles via un lien qui a circulé trop tôt.

flowchart TD
    C[Google Cloud Console : chercher Gemini Enterprise] --> A[Create your first app + nom]
    A --> I[Setup identity : Google Identity + Confirm Workforce Identity]
    I --> D[Connected data stores : Drive, Calendar, Cloud Storage]
    D --> U[URL unique d'Overview partagée avec la main-d'œuvre]
    U --> H[Page d'accueil : prompt box, agents et épinglette NotebookLM]

Connecter les data stores

La connexion se fait depuis Connected data stores, avec New data store par connecteur. La démonstration en connecte trois.

Google Drive synchronise tous les espaces partagés de l'organisation : on choisit la carte Drive, on confirme la synchronisation complète, on nomme le data store et on le crée. Google Calendar suit le même schéma : carte, nom, Create.

Il vaut la peine de relire cette première ligne : le connecteur Drive ne demande pas un dossier choisi à la main, il demande de synchroniser les espaces partagés complets. Le corpus démarre plus large que ce que beaucoup attendent, et cela se voit ensuite dans les réponses de l'assistant.

Google Cloud Storage demande deux paramètres que les deux autres connecteurs n'ont pas. Le premier est le type de données : Documents, conçu pour du contenu non structuré comme PDF, HTML et TXT. Le second est la fréquence de synchronisation : One time, c'est-à-dire que les fichiers sont ingérés une seule fois. S'y ajoute la sélection du bucket source avec Browse et Select. La configuration se termine avec trois data stores connectés.

Le réglage One time mérite un second regard. Subir le bucket une seule fois convient quand le corpus est stable et que vous voulez contrôler quand il se met à jour ; si le bucket change au quotidien, ce data store garde la photo du jour de la configuration jusqu'à ce que quelqu'un relance la synchronisation. La décision est de conception, pas de configuration.

Partager et entrer

La toute nouvelle application se partage avec la main-d'œuvre via l'URL unique de la section Overview. Et la page d'accueil est conçue pour donner à la main-d'œuvre un accès facile aux agents et outils préconstruits les plus utiles : la prompt box comme entrée principale, les agents en ligne et l'épinglette NotebookLM.

Aucun partage par rôle n'apparaît dans cette démonstration ; le lien est le véhicule présenté. La démonstration utilise cette URL pour ouvrir l'application créée et explorer ses fonctions, et la page d'accueil agit alors comme la porte d'entrée de la main-d'œuvre vers les agents préconstruits. Dans une organisation aux données mêlées, c'est un rappel que le contrôle fin vient ensuite, et qu'ici l'identité et les permissions des data stores sont ce qui tient l'exposition.

L'assistant général et ses paramètres

Le premier usage est un prompt simple : « Give me an update on our latest marketing data ». L'assistant cherche dans les sources internes et externes et renvoie une réponse contextualisée, c'est-à-dire que les sources connectées à l'étape précédente travaillent déjà.

Ce qui suit est le détail utile pour l'administrateur : le bouton « enhance your conversation » permet d'ajuster les paramètres de recherche du chat. Dans la démonstration, il est réglé sur les sources internes seulement, et sur ce réglage s'exécute un prompt multimodal : « Summarize the customer sentiment pie chart », passé avec l'image d'un graphique circulaire. Le modèle accepte texte et image dans la même entrée. Le même écran propose la génération de vidéos avec Veo (le modèle vidéo de Google) et d'images avec Nano Banana.

Limiter le périmètre aux sources internes avant de demander le sentiment des clients est exactement le genre d'ajustement qui sépare une réponse générique d'une réponse exploitable. La démonstration utilise aussi l'assistant avec recherche interne et externe par défaut, de sorte que l'ajustement ne bloque rien : il change seulement l'endroit où l'on cherche.

Les agents préconstruits partagent un schéma

Les deux agents qui accompagnent la page d'accueil ont le même squelette, et ce squelette est la leçon à retenir.

Idea Generation travaille comme une équipe d'agents qui planifie, génère et évalue des idées sur un sujet. La démonstration lui demande un brainstorming pour une campagne destinée aux clients Gen-Z avec les derniers produits. L'agent répond avec un plan ; la personne le relit, et seulement alors elle appuie sur Start session. L'équipe génère alors plusieurs idées à réviser.

Deep Research vise l'analyse approfondie sur des sujets complexes. Le prompt de la démonstration, dans sa forme complète, demande d'étudier les derniers conseils et astuces de marketing utilisés par les entreprises alimentaires et de produire une liste de mesures concrètes que l'entreprise peut prendre pour améliorer sa stratégie actuelle. La seconde moitié du prompt est ce qui transforme un rapport en quelque chose d'exécutable : elle ne demande pas seulement l'analyse, elle demande les mesures. Encore le même ordre : l'agent rédige un plan de recherche, la personne le relit ou le modifie, et seulement ensuite on appuie sur Start research. Le résultat est un rapport complet avec un résumé audio.

flowchart LR
    P[Plan proposé par l'agent] --> R[Personne relit ou élargit]
    R --> S[Start session ou Start research]
    S --> O[Résultat : idées, rapport et résumé audio]

Les trois modes de la page d'accueil (assistant général, Idea Generation et Deep Research) partagent le squelette de confirmation, avec des sorties différentes : une réponse conversationnelle, un ensemble d'idées à réviser et un rapport avec son résumé audio. Les sorties diffèrent ; le schéma plan → confirmation → résultat est identique au flux multiagent que j'ai déroulé dans un autre texte : rien de coûteux ne se produit sans qu'une personne approuve le plan préalable.

NotebookLM : du corpus à la vidéo

NotebookLM s'ouvre depuis la section épinglée de la page d'accueil et fonctionne comme un outil couplé au notebook de l'application. Ses sources se combinent : Google Docs, URL de sites web, vidéos YouTube et texte collé ; dans la démonstration, des fichiers montés depuis le disque.

La valeur du couplage est dans cette combinaison : un même notebook peut recevoir un document Google, l'URL d'un article, la vidéo YouTube d'une conférence et un texte collé, et répondre aux questions sur l'ensemble chargé. Aucune de ces sources ne sert à elle seule pour la question d'exemple ci-dessous.

Les réponses sont contextuelles au corpus chargé. La question d'exemple, « What audience did the spring cookie promotion target? », a reçu une réponse concrète : des femmes de 25 à 55 ans intéressées par la pâtisserie et les desserts, à Oakland, en Californie. Chaque réponse peut être enregistrée comme note pour réutilisation ultérieure.

L'onglet Studio est l'endroit où le matériel cesse d'être un corpus pour devenir des pièces : des formats dynamiques comme l'audio, les vidéos, les cartes mentales et plusieurs types de rapports. Dans la démonstration, une présentation vidéo de cinq minutes intitulée « Marketing by the Numbers », générée à partir du matériel source du notebook. L'utilité pratique saute aux yeux quand l'équipe doit consommer la même chose dans des formats différents et que le corpus a déjà été chargé une seule fois.

Ce que le cycle laisse et ce qui est resté non exécuté

Vue dans son ensemble, le cycle a deux idées qui survivent à tout changement d'interface. La première est l'ordre de la configuration : application, identité, données, partage ; chaque étape dépend de la précédente et n'autorise aucun raccourci. La seconde est le schéma plan avant exécution, qui apparaît dans Idea Generation et dans Deep Research sous le même format et empêche un agent coûteux de prendre la mauvaise direction.

Ce qui est resté non exécuté dans cette documentation : l'évaluation n'a ni été ouverte ni soumise, la simulation guidée n'a pas été lancée et déclare explicitement qu'elle n'admet pas la navigation au clavier seul (avec la démonstration vidéo et sa transcription comme alternative), et le champ de transcription de cette simulation porte le marqueur « XYZ » au lieu d'une transcription réelle. La credential n'a pas non plus été réclamée. Et l'état completed a été lu dans l'inventaire server-side du profil, pas dans une exécution des activités elles-mêmes.

---

*Source : « Create Your First Gemini Enterprise Application », de Google Skills (cours google.gemini-enterprise-first-app).*