Une campagne de marketing entière en une seule conversation avec des agents Gemini Enterprise

Un gérant de magasin de vêtements de plein air veut comprendre l'historique des ventes de sa boutique et en sortir des opportunités exploitables. Il ne demande pas un chatbot : il demande que la recherche, les assets de la campagne et l'action métier finissent connectés. Ce parcours, fait dans la console de Gemini Enterprise (la console Google Cloud pour construire, déployer et exploiter des agents), est ce que je vais dérouler ici. La source est « Orchestrate Multi-agent Workflows with Gemini Enterprise », de Google Skills, et ce qu'elle enseigne vaut pour tout processus métier qui démarre par une question et se termine par un ticket dans un système.

Un flux, trois tâches

La promesse du flux multiagent est de trois tâches résolues dans la même conversation : recherche approfondie avec des données first- et third-party (internes et externes à l'entreprise), génération d'assets image et vidéo haute fidélité, et automatisation d'actions métier sur des plateformes externes. L'argument de clôture est direct : la fonctionnalité multiagent permet de gérer un flux de travail entier, tout en un seul endroit.

Le point de départ suppose un travail préalable : des agents Gemini Enterprise déjà construits et déployés. Ce qui reste en suspens, c'est une autre question, celle du quotidien : quel rôle joue un flux agentic dans les opérations quotidiennes de l'entreprise, du côté de qui coordonne ou sert ? Le cas du gérant est la réponse qui se parcourt, et après la démonstration vient la pratique dans une simulation guidée.

Avec first- et third-party se nomment les deux classes de données que l'analyse combine : celles que produit l'entreprise elle-même (ventes, rapports de campagnes précédentes) et celles qui viennent de l'extérieur (tendances mode actuelles). La recommandation qui sort de l'autre côté dépend de mélanger les deux ; avec une seule, le résultat est une photo partielle.

Ce qu'il faut croire avant de continuer : que les agents différents partagent le contexte. Si chaque agent démarre de zéro, le « un seul endroit » n'est qu'une jolie interface. La démonstration qui suit soutient cette croyance avec un détail mécanique qui apparaît plus bas.

Deep Research : bien demander et approuver le plan

Depuis le menu des agents de la console, on choisit Deep Research, décrit comme utile pour l'analyse approfondie sur tout type de données publiques et privées. Le prompt de départ a deux parties. L'une est la persona : je suis gérant d'un magasin, je veux comprendre l'historique des ventes de ma boutique et identifier des opportunités exploitables. L'autre est les questions concrètes : analyser les sources internes comme les ventes et rapports de campagnes marketing précédentes, et externes comme les tendances mode actuelles ; de plus, quelles marques ont les meilleurs résultats et pourquoi, où investir davantage dans les campagnes, et quels produits montrent la meilleure opportunité de croissance.

Avant que la recherche démarre, Gemini génère un plan de recherche. C'est là le point qu'on saute le plus : le plan se déplie, se relit, et peut être modifié en envoyant d'autres prompts. Ce n'est que quand la personne est satisfaite qu'on appuie sur Start research. La recherche ne démarre pas du fait d'avoir écrit un prompt ; elle démarre par l'approbation du plan.

flowchart TD
    R[Demande du gérant] --> DR[Deep Research avec persona et questions]
    DR --> P[Plan de recherche relu et élargi]
    P --> S[Start research]
    S --> Cat[Liste de produits et images du catalogue]
    Cat --> M[Marketing Agent : image avec coucher de soleil]
    M --> A[AdGen Agent : brief, storyline et clips]
    A --> T[The Analyst : ticket dans ServiceNow]

Quand cela se termine, les résultats se déplient avec les ressources en vue : on survole chacune et on voit d'où elle vient, avec les sources first- et third-party de l'entreprise mélangées. Dans le cas parcouru, la recommandation concrète est une campagne pour la veste « Khaki Explorer Rugged Outerwear Ski Jacket » de la marque Verana, portée par le succès d'un lancement récent de vêtements extérieurs. La recommandation apporte sa suite : travailler sur cette pièce.

La peine vaut d'être prise pour la différence entre le prompt et le plan. Le prompt délègue la recherche ; le plan met en ce qui va être cherché et permet de corriger la route avant de dépenser du temps. Élargir le plan avec d'autres prompts, en pratique, c'est ajouter des questions qui manquaient ou cadrer le périmètre pour que la réponse arrive à temps.

Le catalogue comme pont

Entre la recherche et la création d'assets, il y a une petite étape pratique : « List the product names and links to their images ». Le chat renvoie la liste des produits du catalogue avec leurs images ; en sélectionnant le lien de l'image de la veste Verana, s'ouvre la photo qui servira de base, un personnage marketing stock sur une montagne enneigée.

Sans ce pont, la phase d'assets s'appuie sur la mémoire du modèle sur le produit. Avec le lien en main, la phase suivante travaille sur un vrai fichier, et renvoyer le lien en plus du nom évite que la publicité soit conçue contre une description textuelle du produit.

Changer d'agent sans changer d'outil

La mécanique d'orchestration est simple et c'est l'axe de tout le flux : écrire « @ » dans la chat box invoque un nouvel agent dans la même conversation. Trois apparaissent dans le parcours (Marketing Agent, AdGen Agent et The Analyst) et, pour revenir à l'assistant par défaut, on utilise le bouton de sortie de l'agent.

Le parcours utilise ce interrupteur de façon explicite : il sort de l'AdGen Agent avec le bouton de sortie avant d'invoquer The Analyst. Sortir et ré-invoquer est ce qui sépare les tronçons dans une conversation unique, avec le contexte de campagne accumulé jusque-là et sans changer d'outil.

Marketing Agent : régénérer l'image

La demande au Marketing Agent est du genre « retouche la publicité » : générer une image avec la même personne et la même veste, mais avec un coucher de soleil en arrière-plan, et passer le lien de la nouvelle publicité. La réponse apporte trois pièces : la description de la publicité, la justification du pourquoi c'est sorti ainsi, et le lien. Et elle accepte des prompts de suivi pour itérer jusqu'à ce que l'équipe soit satisfaite.

AdGen Agent : brief, storyline et clips

Le tronçon vidéo démarre avec un brief structuré, qui est ce qui sépare un clip généré d'un clip qui sert. Les champs du brief du parcours : marque (Verana), produit (Khaki Explorer Ski Jacket), localisation cible (Tahoe, Californie, USA), âge cible (25-45), genre (Male) et intérêts (ski, activités de plein air, qualité, longévité, durabilité, production éthique et mindful living).

La sortie a deux temps. D'abord un storyline avec des notes de visuels et de thème, qui s'itère avec des prompts de suivi. Ce n'est que lorsque le storyline est confirmé que l'agent produit les clips vidéo, que l'équipe de production utilise comme point de départ. L'ordre compte : réécrire un storyline coûte des minutes ; régénérer des clips à contretemps coûte plus.

Un brief comme cela fonctionne comme liste de décisions déjà prises. Chaque champ ferme une question qui ensuite ne se discute plus avec l'équipe de production : à qui parle le spot, où on le voit, quels valeurs il promet et à quoi ressemble le produit.

flowchart LR
    subgraph Confirmations[Points de confirmation]
        C1[Plan de recherche] --> C2[Storyline de la vidéo]
        C2 --> C3[Revue du ticket]
    end

The Analyst : l'action se termine dehors

Le dernier tronçon est celui qui transforme la campagne en quelque chose que d'autres personnes vont voir. On sort de l'AdGen Agent avec le bouton de sortie, on invoque The Analyst avec @, et on lui demande : créer un nouveau ticket pour cette campagne de marketing, avec un résumé bref de la campagne proposée dans la description. The Analyst crée le ticket dans ServiceNow (la plateforme tiers que l'entreprise utilise) et renvoie un lien pour le relire.

Le détail à ne pas perdre : l'action métier se termine hors de Gemini, dans le système où le reste de l'entreprise travaille. La console a gardé le contexte ; le ticket est ce que l'équipe d'opérations ouvrira demain.

Ce que ce motif laisse et ce qui reste à tester

Vu de bout en bout, le motif a une porte de confirmation à chaque tronçon qui produit quelque chose de coûteux à refaire : le plan de recherche avant de chercher, le storyline avant de générer les clips, la revue du ticket avant qu'il circule dans ServiceNow. Les trois points remplissent la même fonction et tout flux multiagent sérieux les nécessite.

Ce qui reste à tester vient de la source : la simulation guidée qui accompagne la leçon n'a pas été exécutée, et de surcroît elle n'admet pas la navigation au clavier seul selon sa propre note d'accessibilité ; le quiz de la source non plus n'a été ouvert ; et les vidéos de cas d'usage de la partie introductive n'ont pas de transcription dans le matériel disponible, de sorte que leurs exemples restent hors de ce texte. La source se termine aussi par une évaluation ultérieure dont la réussite octroie la skill badge « Orchestrate Multi-Agent Workflows with Gemini Enterprise », qui figure comme gagnée sur le profil public, mais dont les questions n'ont pas été revues pendant cette documentation. Ce qui a bien été tracé, c'est le squelette du flux : persona et questions, plan approuvé, catalogue comme base, agents enchaînés avec @, et une action qui se termine dans le système du client.

---

*Source : « Orchestrate Multi-agent Workflows with Gemini Enterprise », de Google Skills (cours google.orchestrate-multimagent-gemini).*