Tutoriel Gemini 3 Flash : créer un UI Studio avec function calling

La plupart des démonstrations de générateurs de tableaux de bord IA suivent le même schéma : l’utilisateur envoie un prompt, le modèle génère un énorme bloc de code d’interface, puis l’utilisateur passe le reste de son temps à corriger les mises en page cassées, les états manquants et les composants à moitié câblés.

Ce tutoriel propose une autre voie. Nous allons créer UI Studio, une usine de tableaux de bord pilotée par des appels d’outils, où Gemini 3 Flash orchestre 100 composants d’interface en tant qu’outils appelables. 

Au lieu d’écrire un gros fichier React, Flash enchaîne de petites étapes structurées : créer une barre de navigation, ajouter des filtres, lier des données à un tableau, générer des graphiques d’insights, puis exporter un unique fichier JSON UISpec. Le processus s’exécute pas à pas, tandis que l’UI se met à jour à chaque étape.

À la fin, vous obtiendrez une application de type studio capable de générer plusieurs modèles de tableaux de bord (tri des retours clients, pipeline des ventes, gestion d’incidents SRE, suivi des dépenses Finance, entonnoir d’analytique produit, etc.) et d’itérer rapidement vers un autre mode d’affichage, un autre thème, et plus encore. 

Remarque : cette démo sert de base ; n’hésitez pas à affiner les prompts pour mieux les adapter à vos objectifs et préférences de sortie.

Pour en savoir plus sur la création d’agents IA dans l’écosystème Google, nous vous recommandons le cours Building AI Agents with Google ADK. Nous vous recommandons aussi notre guide de Gemini 3.8 Flash.

Qu’est-ce que Gemini 3 Flash ?

Le modèle Gemini 3 Flash de Google est conçu pour des workflows agentiques centrés sur la vitesse, où l’on ne cherche pas une réponse parfaite unique, mais une boucle d’itération courte : construire, inspecter, ajuster, reconstruire. Flash reproduit le raisonnement de Gemini 3 Pro avec la latence, l’efficacité et le coût de Flash, ce qui en fait un excellent choix pour des applications interactives à haute fréquence. 

Source : Gemini 3 Flash DeepMind 

Deux éléments rendent Flash particulièrement pertinent pour des apps de construction comme UI Studio :

• Il est conçu pour exécuter de nombreuses étapes structurées de manière fiable, plutôt que de livrer une réponse globale unique.
• Il prend aussi en charge des sorties structurées, le function calling, l’exécution de code et la recherche comme outil, ce qui nous permet de garder tout le pipeline déterministe et inspectable.

En théorie, Gemini 3 Flash (aperçu) prend en charge 1 million de jetons en entrée et 64 K en sortie, utile lorsque la trace de build et le UISpec deviennent volumineux. 

Architecture de Gemini 3 Flash 

Gemini 3 Flash est le modèle de workflow agentique de la famille Gemini 3, optimisé pour des applications à faible latence et haut débit, où l’on a besoin d’itérations rapides, d’outillage et de plans multi-étapes. Voici ses caractéristiques clés :

• Niveaux de raisonnement (thinking_level) : Gemini 3 Flash expose un paramètre thinking_level (minimal, low, medium, high), qui permet d’arbitrer profondeur vs latence/coût. Idéal pour les builds UI où la plupart des étapes sont routinières, mais certaines demandent une planification plus poussée.
• Usage d’outils : l’usage d’outils de Gemini 3 est conçu pour des boucles multi-étapes où le modèle émet des appels d’outils, nous les exécutons, renvoyons les résultats, et il poursuit jusqu’à la fin du tour. C’est exactement ce qu’il faut pour un studio UI qui se met à jour en temps réel au fil du build.
• Signatures de pensée : Gemini 3 utilise des signatures de pensée chiffrées pour préserver le contexte de raisonnement entre les tours. La boucle d’outils doit les renvoyer exactement telles qu’elles ont été reçues, sinon le function calling peut échouer (erreur de validation 4xx/400), même avec thinking_level="minimal".
• Multimodalité : Gemini 3 Flash accepte du texte, du code, des images, de l’audio, de la vidéo et des PDF en entrée. Sur Vertex AI, on peut régler media_resolution pour arbitrer coût multimodal vs latence, et même renvoyer des sorties d’outils multimodales quand on a besoin d’un contrôle plus fin.

Exemple Gemini 3 Flash : créer un tableau de bord UI Studio

Dans cette section, nous allons construire UI Studio à partir d’un seul prompt avec Gemini 3 Flash. L’app assemble des interfaces via des appels d’outils et produit un JSON UISpec exportable.

Globalement, l’app finale va :

• afficher un catalogue de modèles comme tri des retours clients, entonnoir d’analytique produit, pipeline des ventes, et plus.
• permettre à l’utilisateur de cliquer sur Démarrer la construction pour déclencher une boucle de build par appels d’outils, où Flash compose le tableau de bord étape par étape.
• rendre le tableau de bord généré en mode prévisualisation, aux côtés d’un inspecteur UISpec et d’une trace d’exécution.
• exporter la spécification finale du tableau de bord en JSON.
• prendre en charge des itérations rapides avec des prompts simples : densité compacte, mode sombre, tri par défaut sur le risque SLA, ou bascule vers un kanban.

Aperçu du prompt

Dans cette section, nous examinons le prompt utilisé pour créer l’UI Studio dans Google AI Studio avec Gemini 3 Flash. Plutôt que de générer un tableau de bord d’un seul tenant, Flash agit comme le cerveau du studio. Il coordonne les appels d’outils, valide et répare les sorties, et produit un artefact unique prêt à être rendu. 

Voici le prompt que j’ai utilisé pour cette démo :

SYSTEM / DEVELOPER PROMPT — Gemini 3 Flash (UI STUDIO ORCHESTRATOR)
You are UI_STUDIO_ORCHESTRATOR inside an app called “UI Studio”.
Goal: Build a reusable “dashboard builder studio” that can generate many different dashboards (Sales, Support, Ops, Finance, Product Analytics, etc.) by orchestrating 80–150 callable UI component tools (agents). 
Each UI component (navbar, cards, table, filters, auth, charts, drawers, modals, etc.) is represented as a tool/function that returns structured JSON. 
You must reliably sequence many tool calls and output a valid UISpec JSON that renders the Studio UI and the generated dashboards.
HIGH-LEVEL BEHAVIOR
UI Studio itself is a dashboard-like app (the “builder”), not just a single dashboard.
Users can select a dashboard type/template to build (e.g., “Customer Feedback Triage”, “Sales Pipeline”, “SRE Incident”, “Finance Spend”, “Product Analytics”).
The Studio exposes a catalog of components (count ~100) and a tool registry (count 80–150), plus specialized agents for different template families.
Gemini 3 Flash must:
Render the UI Studio builder UI
Provide template selection and “Start Build” for a chosen dashboard
Use different specialist agents for different dashboard templates
Assemble the requested dashboard via many component tool calls
Iterate rapidly based on feedback (A/B knobs)
ABSOLUTE RULES
TOOL-FIRST: Build everything via tools. Do not “describe” UIs in prose.
MANY CALLS: On first build, make 30–80 tool calls. This is expected.
STRUCTURED OUTPUT ONLY: Final response must be ONE valid JSON object (UISpec). No markdown or commentary.
VALIDATE + REPAIR: Always run validate_uispec and repair until ok=true.
CONSTRAINTS: Only call enabled tools and only instantiate allowed components (if lists are provided).
ITERATION: Patch minimal deltas using update tools; preserve stable IDs.
INPUTS YOU RECEIVE (RunContext)
The user (or the app) provides a JSON RunContext each run:
{
"studioGoal": string,
"selectedTemplate": string | null,
"requestPrompt": string,
"knobs": { ... },
"allowedComponents": string[],
"enabledTools": string[],
"availableTemplates": string[] | null,
"agents": [{ "name": string, "role": string, "specialty": string }]
}
Use this as the constraints. If missing, assume reasonable defaults and proceed.
TOOLS AVAILABLE (CONCEPTUAL)
You can call tools returning JSON. Only call tool names included in enabledTools.
set_agent_status(agentName, status, note) -> ok
emit_trace(eventName, payload) -> ok
list_templates() -> { templates: TemplateMeta[] }
choose_template(userIntent) -> { templateId, rationale }
define_data_model(domain, templateId, constraints) -> DataModel
compose_layout(layout_type, regions, responsive_rules) -> LayoutSpec
create_component(type, variant, region, intent, theme_tokens, data_contract, constraints) -> ComponentSpec
update_component(component_id, patch) -> ComponentSpec
bind_data(component_id, bindings) -> BindingSpec
define_workflow(name, steps, triggers) -> WorkflowSpec
validate_uispec(uispec) -> { ok: boolean, issues: Issue[] }
repair_uispec(uispec, issues) -> UISpec
create_ab_variant(base_uispec, knob_changes) -> { variants: [{name, uispec}], metricPlan }
save_template(templateId, uispec) -> ok
export_dashboard(uispec, format) -> { artifactRef }
UISPEC OUTPUT CONTRACT (STRICT)
Return ONE JSON object:
{
"app": { "name": "UI Studio", "description": string, "routes": [...] },
"theme": { "mode": "light"|"dark", "density": "compact"|"comfortable", "tokens": {...} },
"studio": {
"templateCatalog": TemplateMeta[],
"selectedTemplate": string|null,
"componentCatalog": { "count": number, "items": string[] },
"toolRegistry": { "count": number, "items": string[] },
"agents": [{ "name": string, "role": string, "specialty": string }]
},
"dataModel": DataModel,
"layout": LayoutSpec,
"components": ComponentSpec[],
"workflows": WorkflowSpec[],
"states": { "loading": {...}, "empty": {...}, "error": {...} },
"generatedDashboards": [
{ "templateId": string, "name": string, "uispecRef": string }
],
"abTests": [ ... ] // optional
}
UI STUDIO BUILDER UI (MUST INCLUDE)
The Studio UI must include:
A) Header + Hero Banner
Title “UI Studio”
Subtitle: “Build dashboards via function-calling components”
Buttons: “Start Build”, “Iterate”, “Export”
B) REQUESTS (cards like “Orders”)
Preset request cards (Easy/Intermediate/Difficult) for different dashboard types
“Add New Request” card
Each request card has Start + status
C) COMPONENTS panel (count ~100)
Searchable list of UI components (navbar, cards, table, filter, auth, charts, drawer, modal, etc.)
Allow/prefer/disable toggles (optional)
Shows count
D) TOOLS panel (count 80–150)
Searchable list of callable tools/functions
Shows call counters for the current run and “recently called”
Shows count
E) AGENTS panel
3–8 specialist agent cards (all powered by Flash, but role-separated):
Template Selector Agent (chooses dashboard template from user intent)
IA/UX Planner Agent (information architecture)
Data Modeler Agent (schemas + bindings)
Component Composer Agent (creates component specs)
Chart Builder Agent (insights widgets)
QA/A11y Gatekeeper Agent (validation + fixes)
Experimentation Agent (A/B variants + knobs)
Agent cards show status: Idle / Working / Waiting / Done
F) Preview Drawer
Tabs: Preview | UISpec JSON | Trace
Preview renders either the Studio or the generated dashboard spec
TEMPLATE SYSTEM (MUST INCLUDE)
Provide at least 8 templates in templateCatalog with metadata:
id, name, category, difficulty, primaryComponents, dataEntities, defaultKnobs
Examples:
customer_feedback_triage
sales_pipeline
support_ticket_ops
sre_incident_command
finance_spend_tracker
product_analytics_funnel
marketing_campaign_performance
inventory_warehouse_ops
Selecting a template should:
set selectedTemplate
populate default knobs
drive which specialist agents become active
drive which components/tools are preferred during build
A/B KNOBS (FIRST-CLASS)
Studio must support knob-driven iterations:
density: compact|comfortable
navigation: topbarOnly|leftRail
defaultSort: template-specific enum
viewMode: table|inboxList|kanban|gridCards
insightFocus: overviewFirst|triageFirst|trendsFirst
themeMode: light|dark
BUILD ALGORITHM
When user requests “create UI studio …” (this message), you must:
emit_trace("start_studio_build", {...})
set_agent_status(...) as you plan/build/validate
Create the UI Studio builder UI (sections A–F above) via MANY create_component calls
Define templateCatalog and agent roster
Implement template selection workflow:
choose_template from user intent
build_dashboard workflow that triggers component creation for the chosen template
Implement “Start Build” workflow:
picks template
defines dataModel
composes layout
creates components for the generated dashboard
validates + repairs
stores in generatedDashboards with uispecRef
validate_uispec and repair until ok
Output ONLY the UISpec JSON
ITERATION BEHAVIOR
If user later asks: “build a Sales dashboard” or “change to dark mode, compact density”:
update Studio state (selectedTemplate/knobs)
call update_component and rebuild only the generated dashboard region
re-validate and output updated UISpec JSON only
NOW EXECUTE
User intent: Create a UI Studio that can build numerous dashboards, with 100 UI components as callable tools/agents, dashboard selection, and specialist agents for different templates.
Start building immediately via tools, then output a single valid UISpec JSON.

L’objectif du prompt est d’imposer une boucle de construction prévisible pour que Gemini 3 Flash se comporte comme un constructeur, pas comme un chatbot. Pour cela, le prompt doit inclure :

• Une cible explicite d’usage d’outils lors du premier build, généralement 30 à 80 appels, afin que Flash découpe l’UI en nombreuses petites étapes plutôt que de générer un gros bloc.
• Une boucle obligatoire valider puis réparer jusqu’au passage, pour garantir que le UISpec final est rendable et éviter les états cassés.
• Des mises à jour « patch » pendant l’itération pour préserver les identifiants de composants et éviter les reconstructions complètes. Cela stabilise l’UI entre les éditions et accélère les itérations.
• Un contrat UISpec haut niveau couvrant thème, mise en page, composants, liaisons, workflows, états, catalogue de modèles, agents et trace. Cela donne à Flash un format cible strict pour produire un artefact structuré cohérent à chaque build.
• Un catalogue de modèles et des rôles d’agents spécialistes, afin que chaque type de tableau de bord parte avec des valeurs par défaut (layout, réglages, composants préférés) et que Flash répartisse le travail entre planification, construction et validation.

Cela fonctionne parce que le modèle génère un unique UISpec structuré que vous pouvez valider, corriger par petits patchs et mettre à jour rapidement, sans reconstruire toute l’interface.

Aperçu du projet

Même si Gemini 3 Flash génère l’intégralité du code pour cette démo, comprendre le rôle de chaque fichier reste utile. La séparation est nette entre l’UI du studio, l’aperçu du tableau de bord et la couche d’API Gemini. Une fois que vous savez où résident les deux boucles IA, le reste du dépôt devient facile à suivre.

Voici le déroulé haut niveau de la façon dont l’app UI Studio déclenche Gemini 3 Flash et rend le tableau de bord généré :

• Au chargement, App.tsx ouvre la vue Studio et récupère le catalogue initial de modèles, le registre d’outils, le catalogue de composants et la liste des agents depuis mockData.ts.
• La sélection de modèle est gérée entièrement côté client à ce stade, sans requête Gemini.
• Quand vous cliquez sur Démarrer la construction, l’app efface la trace de l’exécution précédente, passe en état « construction » et met à jour les cartes agents et les événements de trace pour rendre l’avancement visible.
• Après ces mises à jour progressives de l’UI, l’app envoie la requête principale de build via services/geminiService.ts.
• La réponse JSON du modèle est analysée en UISpec, stockée en état, puis l’UI bascule en mode Prévisualisation.
• En Prévisualisation, le tableau de bord généré est rendu avec des composants React standards : tableaux, filtres, insights.
• PreviewDrawer.tsx sert de panneau d’inspection pour consulter le JSON UISpec et des statistiques de build.
• Une seconde boucle Gemini vit dans DetailDrawer.tsx et s’exécute au niveau de la ligne sélectionnée.
• Quand un utilisateur ouvre un retour et demande l’aide de l’IA, analyzeFeedback() et suggestResolution() dans geminiService.ts rappellent Gemini pour produire une classification structurée et des actions recommandées.
• Globalement, l’app fait tourner deux pipelines : un pour construire la spec du tableau de bord et un pour assister les utilisateurs dans le tableau de bord.

Si vous souhaitez approfondir d’autres fichiers clés pour comprendre le câblage de la démo, voici plus de détails :

Répertoire racine

Ces fichiers définissent la configuration du projet, les contrats de types et les données d’initialisation qui rendent la démo cohérente et exécutable.

• package.json : Définit les dépendances et scripts (React, Recharts, SDK @google/genai), ainsi que les scripts de dev vite, build et preview.
• tsconfig.json : Contient les réglages du compilateur TypeScript pour React et la résolution du bundler. Il garantit la sûreté des types sans émettre de TS compilé en développement.
• vite.config.ts : Config de dev/build Vite, incluant port et variables d’environnement. Ce fichier mappe GEMINI_API_KEY vers process.env.API_KEY pour que le SDK GenAI puisse la lire côté navigateur.
• metadata.json : Métadonnées de l’app utilisées par AI Studio pour l’hébergement : nom, description et permissions requises.
• types.ts : Agit comme couche de contrat pour toute l’app : définit les types pour modèles, agents, outils, lignes de feedback et la forme UISpec pour maintenir la cohérence entre UI et sorties du modèle.
• mockData.ts : Contient des données d’amorçage pour l’expérience Studio et Preview : catalogue de modèles, liste initiale d’agents, registre d’outils et exemples de retours pour que l’UI fonctionne avant tout appel au modèle.

Services (services/)

Cette couche contient l’intégration Gemini et gère tous les appels au modèle et les réponses structurées.

• geminiService.ts : Trois appels principaux : la fonction orchestrateBuild() pour générer un UISpec, et analyzeFeedback(), suggestResolution() pour l’assistance IA.
• Remarque : orchestrateBuild() cible actuellement gemini-3-pro-preview, tandis que les deux autres utilisent gemini-3-flash-preview ; vous pouvez tout basculer en Flash-only si souhaité.

Composants de l’UI du studio (components/)

Ces composants React rendent l’UI du builder Studio et l’aperçu du tableau de bord généré, y compris l’inspecteur JSON et les flux de détail.

• StudioHeader.tsx : Affiche l’en-tête du Studio et le CTA de lancement. Il reflète l’état du build pour rendre la pipeline visible.
• TemplateCatalog.tsx : Affiche les cartes de modèles et permet de choisir le tableau de bord à construire. La sélection met à jour l’état local dans App.tsx.
• AgentPanel.tsx : Affiche les « agents spécialistes » sous forme de cartes d’état. Dans cette démo, la progression d’état est pilotée par des mises à jour scénarisées dans App.tsx pour rendre le workflow lisible.
• ToolPanel.tsx : Aide à rendre la liste du registre d’outils depuis mockData.ts. Sert d’emplacement UI pour afficher disponibilité et compteurs d’appels.
• ComponentPanel.tsx : Représente l’idée « composants = outils » et sera l’endroit naturel pour ajouter plus tard des bascules autoriser/interdire.
• PreviewDrawer.tsx : Permet de consulter le JSON UISpec et des stats basiques, ce qui facilite le débogage de la trace de build.

• Topbar.tsx : Contient la navigation supérieure du tableau de bord et la barre de recherche. Montre comment des contrôles au niveau du tableau de bord cohabitent avec les réglages du studio.
• Sidebar.tsx : Gère la navigation latérale gauche du tableau de bord rendu.
• FilterBar.tsx : Bandeau de filtres pour segmenter les données de retour. 
• FeedbackTable.tsx : Vue tableau principale des retours ; cliquer une ligne la sélectionne et ouvre le tiroir de détail.
• DetailDrawer.tsx : Appelle analyzeFeedback() et suggestResolution() et affiche la sortie du modèle sous l’onglet IA.
• InsightsSection.tsx : Aide au rendu des graphiques et de la vue synthèse avec Recharts.

Voici une courte vidéo qui illustre le workflow complet d’UI Studio : sélection d’un modèle, flux « Démarrer la construction », et prévisualisation du tableau de bord généré.