Gemini “agent” en entreprise : ce qui change (et pourquoi ça te concerne)
Jusqu’ici, Gemini dans Google Workspace, c’était surtout un assistant. Tu demandes, il répond. Tu colles un email, il résume. Tu lui donnes un doc, il t’en sort un plan.
Maintenant, Google pousse clairement Gemini vers un rôle d’agent en environnement business : capable de planifier, enchaîner des tâches et réagir à des événements. En parallèle, des capacités “agentiques” arrivent dans Workspace et alimentent les automatisations que tu peux construire dans Workspace Studio.
Traduction dirigeant : tu ne “discutes” plus avec une IA. Tu commences à déléguer un bout de process. Et là, les gains peuvent être très réels. Mais les risques aussi : accès aux emails, aux fichiers Drive, actions irréversibles, conformité, audit, et une nouvelle ligne de coût souvent oubliée… l’orchestration.
Donc le sujet n’est pas “est-ce que Gemini est bon”. Le sujet c’est : qu’est-ce que tu autorises, qu’est-ce que tu interdis, et à quel niveau d’autonomie.
Avant de commencer : 3 réalités qui évitent les décisions stupides
1) “Agent” ne veut pas dire autonomie totale
Dans Workspace, beaucoup de choses restent “assistées” ou “orchestrées” via des flows. Et côté intégrations Workspace Marketplace (outils tiers), c’est souvent lecture seule. Donc si ton scénario suppose “Gemini modifie aussi l’outil X”, vérifie. Très souvent, ça ne passera pas.
2) Les erreurs dangereuses sont silencieuses
Le risque numéro 1 d’un agent, ce n’est pas qu’il se trompe. C’est qu’il se trompe sans que personne ne s’en rende compte, puis qu’il enchaîne : mauvais résumé, mauvais email, mauvaise pièce jointe, mauvais destinataire. Et tu te retrouves à gérer une fuite, un client perdu, ou un litige.
Si tu veux un protocole simple pour tester ça, garde sous la main : https://jimmymanin.com/blog/ia-qui-cache-ses-erreurs-le-protocole-dirigeant-5-tests-avant-dautomatiser.
3) Le vrai coût, c’est la gouvernance et le contrôle
Un agent utile n’est pas “un prompt”. C’est :
- des accès (comptes, Drive, Gmail, Chat, éventuellement tiers),
- des règles (ce qui est autorisé, interdit, escaladé),
- des logs,
- des validations humaines,
- un pilote, des critères d’arrêt, des revues.
Si tu n’as pas le temps pour ça, tu n’as pas le temps pour un agent. Point.
Ce que Google te donne côté contrôle (utile pour la gouvernance agents IA)
Quelques faits concrets qui comptent dans une décision de direction :
- Données Workspace : Google indique que les données Google Workspace (prompts et sorties inclus) ne sont pas utilisées pour entraîner ses modèles GenAI en dehors de Workspace sans autorisation. C’est la base pour éviter de financer du shadow AI.
- Contrôles admin : tu peux activer/désactiver Gemini et gérer des contrôles dédiés via l’Admin console (selon licences et options).
- Régionalisation : l’app Gemini supporte des data regions (UE, US, ou les deux) avec une granularité possible au niveau unité organisationnelle.
- Audit Drive : l’activité Gemini peut générer des événements d’audit Drive, par exemple “item content accessed” quand Gemini accède au contenu d’un fichier en réponse à une requête.
- Intégrations tiers : les intégrations Gemini via Workspace Marketplace ne supportent que des actions de lecture (pas de modifications) dans les apps tierces. Limite majeure si tu veux un agent “de bout en bout”.
Tu n’as pas besoin de tout retenir. Retient ceci : tu peux gouverner, mais tu dois choisir ton niveau de délégation. Et documenter.
La méthode en 60 minutes : décider quoi automatiser, quoi interdire (protocole en 6 étapes)
Objectif : en 1 heure, tu sors avec une shortlist de tâches à tester, une blacklist claire, et un cadre d’autonomie. Pas une usine à gaz.
Étape 1 (10 min) : cartographie rapide des tâches éligibles
Tu fais un inventaire brut. Pas “les processus de l’entreprise”. Les tâches qui reviennent chaque semaine.
Prends 3 colonnes : volume, risque, accès nécessaires.
- Volume : combien de fois par semaine, combien de minutes.
- Risque : impact si c’est faux (faible, moyen, critique).
- Accès : lecture Drive, lecture Gmail, envoi Gmail, écriture Drive, publication, etc.
Exemples typiques “bon terrain agentique” dans Google Workspace :
- Pré-tri d’emails entrants : classifier, extraire, préparer une réponse (mais pas envoyer).
- Préparation de compte rendu : récupérer notes, structurer, proposer un CR, créer un doc.
- Contrôle de conformité documentaire : vérifier présence de clauses, repérer trous, lister actions.
- Veille interne : surveiller un Drive/fil, synthétiser, pousser un digest dans Chat.
Exemples “mauvais terrain” :
- Tout ce qui déclenche un engagement juridique (contrats, réponses sensibles) sans validation.
- Tout ce qui peut envoyer à la mauvaise personne (email sortant autonome).
- Tout ce qui peut supprimer, écraser, ou publier sans rollback.
Étape 2 (10 min) : score simple “éligible / interdit / à discuter”
Tu poses une règle de tri. Simple. Sinon tu ne finiras jamais.
- Éligible si : répétitif + données déjà dans Workspace + impact d’erreur faible à moyen + possibilité de validation.
- Interdit si : impact critique + action irréversible + exposition externe + données ultra sensibles.
- À discuter si : gain énorme mais risque moyen/élevé. Tu ne dis pas oui/non, tu cadres un pilote très contrôlé.
À ce moment-là, tu obtiens déjà une gouvernance agents IA minimale : une liste “OK”, une liste “NON”. Et ça calme tout le monde.
Étape 3 (10 min) : fixe un niveau d’autonomie (sans fantasmer)
Décide noir sur blanc : l’agent fait quoi, seul, et à quel moment il s’arrête.
Je te conseille un modèle à 3 niveaux :
- Niveau 1, assisté : Gemini propose, l’humain exécute. Zéro action automatique.
- Niveau 2, semi-autonome : Gemini prépare et déclenche des actions réversibles, avec validation humaine avant sortie externe.
- Niveau 3, autonome : Gemini exécute sans validation sur un périmètre strict, avec garde-fous + logs + mécanisme d’arrêt.
Si tu veux creuser ce modèle (utile pour aligner direction, IT, métiers) : https://jimmymanin.com/blog/agents-ia-le-modele-3-niveaux-dautonomie-pour-automatiser-sans-provoquer-lincident.
Règle terrain : démarre au niveau 1 ou 2. Le niveau 3 se mérite. Il ne se “teste” pas sur des clients.
Étape 4 (10 min) : cadre les accès (comptes, emails, Drive) comme un sujet sécurité
Un agent, c’est un sujet d’identités et d’autorisations. Pas un sujet “IA”.
Décisions à prendre :
- Quel compte exécute l’automatisation : compte utilisateur, compte de service, compte générique ? (évite le compte perso du stagiaire).
- Quels Drive : quels dossiers précisément. Pas “tout mon Drive”. Périmètre minimal.
- Quels emails : lecture seule au début. L’envoi automatique est l’un des plus gros multiplicateurs de risque.
- Quels connecteurs tiers : rappelle-toi la limite fréquente “lecture seule” côté Marketplace. Donc ne promets pas un agent qui met à jour ton CRM via une intégration qui ne sait que lire.
- Régionalisation : si tu as des contraintes UE, applique les data regions au bon niveau organisationnel.
Deux règles cash :
- Least privilege : l’agent n’a accès qu’à ce qu’il doit toucher. Rien de plus.
- Sépare lecture et écriture : si possible, un agent lit, un humain valide, un autre mécanisme écrit. Ça évite la catastrophe “il a tout fait tout seul”.
Pour compléter avec une checklist sécurité plus large (anti-fuite) : https://jimmymanin.com/blog/agents-ia-en-entreprise-checklist-securite-en-12-points-anti-fuite-avant-deploiement.
Étape 5 (10 min) : impose logs + validation humaine (et définis “irréversible”)
Si tu ne peux pas retracer ce que l’agent a consulté et produit, tu ne pilotes rien. Et quand ça dérape, tu ne sais même pas quoi corriger.
Ta base minimale :
- Journalisation : qui a déclenché, quand, sur quels fichiers/emails, quelle sortie générée, quelle action proposée.
- Preuves : conserve les prompts, les sources utilisées, et la version envoyée. Tes prompts peuvent devenir des preuves, au sens très littéral. À cadrer : https://jimmymanin.com/blog/vos-prompts-peuvent-devenir-des-preuves-ce-que-tout-dirigeant-doit-cadrer.
- Validation humaine : obligatoire avant toute action externe (envoi client, publication, engagement). Le “human-in-the-loop” n’est pas un concept, c’est une case à cocher avant incident.
Définis aussi ta liste d’actions irréversibles. Exemples : envoyer un email externe, partager un doc à l’extérieur, supprimer un fichier, publier un contenu, modifier une donnée de référence.
Règle simple : irréversible = validation humaine. Toujours.
Étape 6 (10 min) : pilote 2 semaines avec critères d’arrêt (sinon tu subis)
Deux semaines. Pas deux mois. Un pilote long devient politique, personne ne coupe, tu accumules des demi-problèmes.
Tu choisis :
- 1 tâche maximum (pas 5).
- 1 équipe ou 5 à 10 utilisateurs.
- 1 canal (ex : Gmail entrant OU Drive, pas tout Workspace).
Tu définis des métriques avant de lancer :
- Temps net gagné (pas “temps théorique”).
- Taux d’erreur (erreurs détectées + erreurs passées au travers).
- Taxe de vérification : combien de temps tu passes à vérifier/corriger. Si elle explose, tu n’automatises rien, tu te rajoutes du boulot. Référence utile : https://jimmymanin.com/blog/taxe-de-verification-eviter-que-lia-te-fasse-perdre-du-temps-pas-en-gagner.
- Incidents : tout envoi incorrect, mauvaise permission Drive, confusion de destinataire, doc partagé trop large.
Et surtout : tes critères d’arrêt. Sans ça, tu continues même quand c’est mauvais.
Exemples de critères d’arrêt réalistes :
- 1 incident externe (mauvais destinataire, doc partagé à tort) = stop immédiat.
- Plus de X% de sorties nécessitant réécriture totale = stop (l’agent n’aide pas).
- Temps de vérification supérieur au temps initial = stop (tu perds de l’argent).
- Accès nécessaires trop larges (impossible de limiter) = stop (risque structurel).
La blacklist “dirigeant” : ce que tu interdis par défaut
Si tu dois prendre une position claire pour éviter la foire, voici une base d’interdictions par défaut. Tu n’ouvriras ces portes qu’avec un cadre plus strict.
- Envoi d’emails externes en autonomie (surtout réponses client, litiges, juridique).
- Partage Drive externe automatique (liens publics, domaines non contrôlés).
- Suppression / écrasement de fichiers ou données (sans versioning + validation).
- Décisions financières (paiements, remboursements, commandes) sans double validation.
- Traitement de données sensibles hors périmètre et sans cadrage RGPD/AI Act (données santé, mineurs, etc.).
Si tu veux une checklist accès/identités (sujet critique pour des agents) : https://jimmymanin.com/blog/agents-ia-et-cybersecurite-controle-des-acces-nhi-avant-ton-premier-agent.
Le piège classique : automatiser “parce que c’est possible”
Gemini agent entreprise, IA agentique Google Workspace, automatisation agent IA… tout ça donne envie de connecter et de laisser faire.
Mais un agent, c’est comme embaucher un junior ultra rapide qui :
- travaille vite,
- fait parfois n’importe quoi,
- et ne te prévient pas toujours quand il doute.
Ton job n’est pas de lui donner plus de responsabilités. Ton job est de designer le poste : périmètre, limites, validation, audit.
Plan d’action immédiat (30 minutes ce soir, 30 minutes demain)
Ce soir (30 min)
- Liste 10 tâches hebdo et score volume/risque/accès.
- Classe : éligible, interdit, à discuter.
- Choisis 1 tâche éligible pour un pilote 2 semaines.
Demain (30 min)
- Fixe le niveau d’autonomie (1 ou 2) et écris la règle “irréversible = validation”.
- Cadre les accès minimaux (Drive et Gmail en lecture d’abord).
- Pose les critères d’arrêt et la métrique “temps net gagné”.
Si tu veux compléter ta gouvernance agents IA avec une liste de décisions à trancher avant de “laisser agir” : https://jimmymanin.com/blog/agents-ia-prets-a-lemploi-10-decisions-avant-de-les-laisser-agir-dans-tes-outils.
Tu n’as pas besoin d’un grand programme IA. Tu as besoin d’un cadre simple, testé, et défendable. Gemini devient agent. Toi, tu deviens responsable du périmètre.
