Projet final : un vrai workflow Gemini de bout en bout

Construisons une chose réaliste de bout en bout : un assistant de veille concurrentielle qui lit votre secteur chaque matin, surveille vos concurrents et dépose un briefing sourcé dans un Google Doc avant que vous ayez fini votre café. Nous expliciterons les décisions d'architecture pour que vous puissiez changer de domaine (juridique, commercial, recherche, recrutement) et réutiliser le squelette.

L'intérêt d'un projet final n'est pas la démo. C'est l'ensemble des choix : quel palier de modèle, où le travail s'exécute, comment les faits restent à jour, et ce qui déclenche l'ensemble. Réussissez ces choix et le workflow survit au contact du réel.

Le scénario et les contraintes

L'assistant a quatre missions chaque jour ouvré à 7h00 :

1. Récupérer les dernières actualités et annonces concernant trois concurrents nommés.
2. Lire les PDF ou présentations déposés hier dans un dossier Drive (grilles tarifaires, rapports d'analystes).
3. Synthétiser un briefing d'une page avec ses sources.
4. L'ajouter à un Doc « Competitive Intel » en cours et vous envoyer les points saillants par email.

Les contraintes qui pilotent la conception :

• Les faits doivent être à jour et citables, pas hallucinés. Cela impose le grounding.
• Les entrées sont mixtes : texte web, PDF, images de graphiques. Cela impose la multimodalité native.
• Le tout doit tourner sans surveillance, selon un planning. Cela écarte l'app de chat comme moteur.
• Une personne non technique de votre équipe doit pouvoir ajuster le prompt. Cela pousse une partie de la logique vers Workspace.

Décision 1 : où cela s'exécute-t-il ?

Vous avez trois hébergements réels pour le travail avec Gemini, et ils ne sont pas interchangeables.

• L'app Gemini et les Gems sont faits pour un usage interactif. Un Gem est une version enregistrée et instruite de Gemini (voyez-le comme un personapersonaUne représentation semi-fictive, fondée sur des données, de votre client idéal : ses objectifs, ses frustrations, ses comportements et ses critères de décision.Voir la définition complète → réutilisable avec des instructions permanentes et des fichiers). Parfait pour « poser une question à mon assistant de recherche », inutile comme cron job de 7h du matin parce que personne n'est là pour appuyer sur entrée.
• Gemini dans Google Workspace s'exécute *à l'intérieur* de Docs, Sheets, Gmail et Drive. C'est là que vit la sortie et là où Apps Script peut l'automatiser gratuitement sous votre compte Workspace.
• L'API Gemini (via Google AI Studio pour le prototypage, ou Vertex AI pour la production) est le moteur programmable : appels de modèle, grounding, sortie structurée, planification.

Le découpage propre pour ce projet final : Apps Script est l'orchestrateur et la couche d'intégration Workspace ; l'API Gemini fait le raisonnement lourd et le grounding. Apps Script vous donne un planificateur intégré (déclencheurs temporels), un accès natif à Drive/Docs/Gmail, et un endroit où vos collègues peuvent lire le prompt. L'APIAPIApplication Programming Interface : une interface standardisée qui permet aux applications de communiquer et d'échanger des données sans connaître leur fonctionnement interne respectif.Voir la définition complète → vous donne un contrôle du modèle que l'interface Workspace n'expose pas, comme la configuration du grounding et les schémas JSON.

S'il s'agissait d'un agent plus large, multi-étapes, avec usage d'outils et mémoire, vous iriez plutôt vers l'[Agent Development Kit (ADK)](https://google.github.io/adk-docs/) sur Vertex AI. Nous reviendrons sur cette ligne de démarcation.

Décision 2 : quel palier de modèle ?

Vous avez les paliers Pro et Flash. L'instinct d'utiliser le plus gros modèle partout est coûteux et lent. Découpez par tâche.

• Flash pour le travail à fort volume, sensible à la latence, de type « lire et extraire » : parcourir chaque actualité, extraire les faits clés d'un PDF. Rapide et pas cher, et la tâche n'est pas du raisonnement difficile.
• Pro pour l'étape finale de synthèse : pondérer les sources, repérer les contradictions, écrire le briefing. C'est un appel par jour, donc payer le modèle le plus puissant ne coûte presque rien et le saut de qualité compte.

Ce pattern à deux paliers (Flash pour le fan-out, Pro pour le jugement final) est le levier de coût le plus utile en production avec Gemini. **Décidez du palier par *tâche*, pas par *projet***.

Décision 3 : comment les faits restent-ils à jour ?

La connaissance issue des données d'entraînement est périmée par définition, donc l'étape d'actualité concurrentielle utilise le grounding avec Google Search. Le grounding indique au modèle de lancer de vraies recherches et de renvoyer des réponses liées à des résultats en direct, avec des métadonnées de citation que vous pouvez afficher sous forme de liens.

Vous l'activez comme un outil sur la requête. Voici l'appel de synthèse principal en Python avec le SDK `google-genai`, grounding search activé :

from google import genai
from google.genai import types

client = genai.Client()  # lit GEMINI_API_KEY depuis l'environnement

grounding = types.Tool(google_search=types.GoogleSearch())

resp = client.models.generate_content(
    model="gemini-2.5-pro",
    contents=(
        "Summarize this week's announcements, pricing changes, and "
        "product launches for Acme, Globex, and Initech. Flag anything "
        "that affects our positioning. Cite every claim."
    ),
    config=types.GenerateContentConfig(
        tools=[grounding],
        temperature=0.3,
    ),
)

print(resp.text)
# resp.candidates[0].grounding_metadata contient les URL sources

Température basse parce qu'il s'agit d'analyse, pas de brainstorming. Le grounding_metadata de la réponse porte les liens justificatifs, votre briefing peut donc mettre chaque affirmation en note de bas de page. C'est cette traçabilité des citations qui rend la sortie suffisamment fiable pour être transmise à un dirigeant. Consultez la documentation grounding pour la forme actuelle des métadonnées.

Décision 4 : traiter les entrées multimodales

Le dossier Drive peut contenir la grille tarifaire PDF d'un concurrent et une capture d'écran d'un tableau de prix issu d'un webinar. Vous ne faites pas d'OCR séparément. Gemini est nativement multimodal : passez-lui les octets du PDF et l'image directement dans la même requête, et sa longue fenêtre de contexte vous permet d'inclure plusieurs documents entiers d'un coup au lieu de les découper.

C'est la partie du workflow où vous n'avez véritablement *pas* besoin de RAGRAGMéthode qui permet à un modèle d'IA de répondre à partir de vos propres documents, en récupérant les passages pertinents avant de générer une réponse.Voir la définition complète →. Le RAG se justifie quand votre corpus est bien plus gros que la fenêtre de contexte. Pour « les trois fichiers que quelqu'un a déposés hier », les mettre directement dans un prompt à long contexte est plus simple, moins cher à construire, et ne perd aucune fidélité. Savoir quand se passer de la couche de retrieval est une compétence d'architecture.

from pathlib import Path

pdf = client.files.upload(file="reports/globex_pricing.pdf")
chart = client.files.upload(file="reports/webinar_chart.png")

extract = client.models.generate_content(
    model="gemini-2.5-flash",
    contents=[
        pdf, chart,
        "Extract every price, tier name, and feature change. "
        "Return JSON: {items: [{vendor, tier, price, note}]}.",
    ],
    config=types.GenerateContentConfig(
        response_mime_type="application/json",
    ),
)

Notez response_mime_type="application/json". Demander une sortie structurée plutôt que de la prose est ce qui permet à l'étape suivante (le rédacteur Apps Script) de consommer le résultat de façon fiable. Deux autres raisons d'utiliser Flash et non Pro ici : cela tourne une fois par fichier, et l'extraction est mécanique.

Décision 5 : orchestration et planification

Maintenant, on câble le tout. Le planificateur est un déclencheur temporel Apps Script, le cron fiable le moins cher que vous possédez déjà dans Workspace. Le script appelle votre endpoint d'API (ou appelle Gemini directement via UrlFetchApp), puis écrit les résultats dans Docs et Gmail avec les services natifs.

Ici l'orchestrateur vit dans Apps Script. Il tourne à 7h, appelle votre service de synthèse et ajoute le briefing :

function dailyBriefing() {
  const payload = { date: new Date().toISOString().slice(0, 10) };
  const res = UrlFetchApp.fetch("https://your-service/brief", {
    method: "post",
    contentType: "application/json",
    payload: JSON.stringify(payload),
  });
  const brief = JSON.parse(res.getContentText());

  const doc = DocumentApp.openById("YOUR_DOC_ID").getBody();
  doc.appendParagraph(brief.title).setHeading(DocumentApp.ParagraphHeading.HEADING2);
  doc.appendParagraph(brief.summary);
  brief.sources.forEach(s => doc.appendListItem(s.url));

  GmailApp.sendEmail("you@company.com", "Daily Intel: " + brief.title, brief.summary);
}

Vous réglez le déclencheur de 7h une fois dans l'interface Apps Script sous Déclencheurs, ou par programmation avec ScriptApp.newTrigger. Aucun serveur à surveiller, aucune facture de planificateur séparée. Si vous voulez du 100 % côté serveur, exécutez le Python sur Cloud Run avec Cloud Scheduler ; le compromis est plus de contrôle sur l'infra contre plus de configuration.

L'architecture complète, assemblée

Lisez le flux de données une fois, de haut en bas :

1. Déclencheur de 7h00 (déclencheur temporel Apps Script) lance dailyBriefing.
2. Ingestion (Flash, multimodalmultimodalIA qui traite plusieurs types de contenu à la fois: texte, image, audio, vidéo et données, au lieu d'un seul format.Voir la définition complète →) : chaque nouveau fichier Drive est uploadé et extrait en JSON.
3. Recherche (Pro, grounded) : un appel avec grounding search rassemble les actualités concurrentes fraîches avec citations.
4. Synthèse (Pro) : un appel combine les faits extraits des fichiers et les actualités groundées en un briefing d'une page, sortie JSON ({title, summary, sources}).
5. Livraison (Workspace) : Apps Script ajoute au Doc en cours et envoie le résumé par email.

Remarquez que les paliers de modèle se calent proprement sur les étapes : Flash se déploie sur de nombreuses petites entrées, Pro fait les deux appels qui exigent du jugement. Remarquez aussi que le grounding est cantonné à exactement une étape. Vous ne groundez pas l'étape d'extraction, parce que ces faits viennent des documents devant vous, pas du web. Grounder la mauvaise étape ajoute de la latence et peut faire remonter des résultats de recherche hors sujet.

Où chaque outil mérite sa place

• API + AI Studio : les prompts et le grounding ont été prototypés dans AI Studio, puis exportés en code SDK. Le bouton « Get code » d'AI Studio est le chemin le plus rapide d'un prompt qui fonctionne à un script.
• Apps Script : le planificateur, la colle Workspace, et le seul fichier qu'un collègue non technique peut éditer sans risque (le prompt du briefing et la liste des destinataires).
• Vertex AI / ADK : pas utilisés ici, volontairement. Le jour où vous ajoutez des outils entre lesquels le modèle choisit (search *et* une recherche CRMCRMCustomer Relationship Management : logiciel et stratégie pour gérer et analyser les interactions clients tout au long de leur cycle de vie.Voir la définition complète → interne *et* une action sur l'agenda), faites passer l'orchestrateur à ADK et déployez sur Vertex AI. C'est le seuil : les décisions multi-outils, multi-étapes appartiennent à un framework d'agents, pas à des if bricolés à la main.

L'ordre de construction qui fonctionne vraiment

Ne construisez pas de haut en bas. Construisez d'abord le milieu risqué.

1. Dans AI Studio, mettez au point à la main le prompt de synthèse groundée. C'est là que la qualité se gagne ou se perd.
2. Rendez l'extraction JSON fiable sur vos vrais PDF. Les fichiers réels cassent les prompts naïfs.
3. Seulement ensuite, enveloppez les deux dans Apps Script et ajoutez le déclencheur.

La planification et l'écriture dans le Doc sont ennuyeuses et fiables. Les prompts du modèle sont ce sur quoi vous allez itérer dix fois, donc prouvez-les d'abord.

Ce qu'il faut surveiller en production

• Des citations qui ne résolvent pas. Affichez toujours les URL de grounding et cliquez-en quelques-unes chaque semaine. Un briefing avec des sources mortes est pire que pas de briefing.
• Des échecs silencieux liés aux types de fichiers. Vérifiez que l'étape d'ingestion gère un dossier Drive vide et un fichier illisible sans tuer toute l'exécution. Entourez chaque fichier de son propre try/catch.
• La dérive des prompts. Quand un collègue modifie le prompt dans Apps Script, le format de sortie peut casser le rédacteur du Doc. Gardez l'exigence de schémamaUtiliser un logiciel pour automatiser les tâches et campagnes marketing répétitives, afin de personnaliser à grande échelle sur des canaux comme l'email, le web et le social.Voir la définition complète → JSON dans le prompt et validez avant d'écrire.

Points clés à retenir

• Découpez par tâche, pas par projet. Utilisez Flash pour l'extraction à fort volume et Pro pour le ou les deux appels qui demandent un vrai jugement. C'est votre plus gros levier de coût et de latence.
• Cantonnez le grounding à l'étape qui a besoin de faits frais. Groundez l'appel de recherche web ; ne groundez jamais les étapes dont les faits viennent de documents que vous avez déjà fournis.
• Passez le RAG quand le long contexte suffit. Pour une poignée de documents par exécution, mettez-les dans un prompt multimodal à long contexte plutôt que de construire une couche de retrieval.
• Laissez Apps Script orchestrer Workspace, laissez l'API faire le raisonnement. Vous obtenez un planificateur gratuit, un accès natif à Docs/Gmail et un prompt éditable pour les non-techniciens, avec un contrôle complet du modèle là où ça compte.
• Ne passez à ADK sur Vertex AI que lorsque vous avez besoin d'une vraie agentivité multi-outils. Des étapes bricolées à la main suffisent jusqu'à ce que le modèle doive choisir entre plusieurs outils et se souvenir d'une exécution à l'autre.