Google Workspace ou Microsoft 365 : ce qui change quand on automatise

La question revient à presque chaque premier rendez-vous : faut-il être sur Google Workspace ou sur Microsoft 365 pour automatiser sérieusement. La réponse tient en une phrase : vous automatiserez dans la suite que vous avez déjà, et changer de suite pour automatiser est la plus mauvaise façon de commencer.

Le choix de la suite ne se rediscute pas

Une suite bureautique, ce sont des années d’habitudes, d’identités, de droits accumulés, d’archives et de partages. Un projet d’automatisation n’a aucune légitimité à rouvrir ce dossier. On se branche sur l’existant : Gmail, Drive, Meet et Agenda d’un côté, Outlook, SharePoint, Teams et Calendrier de l’autre. Le jour où vous nous appelez, la décision est prise depuis longtemps, et elle l’a été pour des raisons qui n’ont rien à voir avec l’IA.

Ce qui ne change pas : la logique métier

Prenez un cas concret. Une réunion commerciale se termine, vous voulez un compte rendu structuré, rattaché au bon contact et à la bonne entreprise, et une proposition de suite qu’un humain valide avant qu’elle parte. Rien dans cette phrase ne dépend de votre suite bureautique. Ce qui décide de la qualité du résultat tient dans quatre choses, identiques dans les deux mondes.

• La règle métier qui décide ce qui mérite une trace, et sous quelle forme.
• Le modèle d’IA qui produit le texte, et les consignes qu’on lui donne.
• La validation humaine avant toute écriture dans un CRM ou tout envoi d’e-mail.
• La reprise sur erreur : source vide, service qui répond mal, même événement reçu deux fois.

Ce qui diffère se situe aux deux extrémités du trajet : là où on capte l’information, et là où on écrit le résultat. C’est réel, cela se compte en jours de travail, mais ce n’est pas le cœur du sujet.

Premier écart : les déclencheurs disponibles

Les deux plateformes savent prévenir un programme extérieur quand quelque chose se passe : notifications sur Drive et Gmail côté Google, notifications de changement Microsoft Graph côté Microsoft. Dans les deux cas l’abonnement expire et doit être renouvelé, dans les deux cas il faut prévoir le moment où la notification se perdra. La différence n’est pas là. Elle est dans l’événement qui existe, ou qui n’existe pas.

Côté Google, la transcription d’une réunion Meet arrive sous forme de document dans Drive : un dossier surveillé suffit alors à savoir qu’une réunion s’est terminée, même quand votre collaborateur n’en était pas l’organisateur. Côté Microsoft, la transcription se récupère via l’API Graph en visant la réunion elle-même, ce qui suppose de savoir de quelle réunion on parle et d’avoir la permission de la lire. Aucune des deux plateformes ne fournit un signal « la réunion est finie » parfaitement fiable. Dans les deux mondes, il faut un filet : un balayage régulier qui rattrape ce que la notification a manqué, et un garde-fou contre les doublons.

Deuxième écart : la transcription des réunions

C’est le point qui bloque le plus souvent, et il ne se règle pas en écrivant du code. Ni Meet ni Teams ne transcrivent par défaut. Il faut l’édition qui le permet, un réglage d’administration qui l’autorise, et souvent une action de l’organisateur au moment de la réunion. Ajoutez le cas fréquent où le rendez-vous est hébergé par votre client, sur son environnement à lui : la transcription lui appartient, vous n’y aurez pas accès.

La bonne question d’audit n’est donc pas « Google ou Microsoft », c’est « qui héberge les réunions que vous voulez exploiter, et la transcription est-elle activée ». On l’a vu arrêter des projets bien plus souvent qu’un choix de plateforme.

Troisième écart : la gestion des droits

Côté Google, on passe par un compte de service et la délégation à l’échelle du domaine. Un administrateur autorise une fois pour toutes une liste de périmètres d’accès, et le programme peut ensuite agir au nom de n’importe quel utilisateur du domaine. C’est rapide à mettre en place et très large : la granularité porte sur le type d’accès, pas sur les personnes. Restreindre à une équipe relève de la discipline, pas d’un réglage. S’ajoute la vérification de l’application par Google dès qu’on touche à Gmail ou à Drive, une procédure qu’il faut anticiper dans le calendrier.

Côté Microsoft, on déclare une application dans Entra ID, puis des permissions Graph, une par une, avec un consentement administrateur. Les permissions déléguées agissent au nom d’un utilisateur connecté, les permissions applicatives agissent sans personne devant l’écran. Ces dernières sont larges elles aussi, mais sur les boîtes mail elles se restreignent à un groupe précis par une règle d’accès applicatif. Plus long à cadrer au départ, plus fin à l’arrivée.

• Google : l’accès se règle en une fois pour tout le domaine, donc vite, donc à surveiller de près.
• Microsoft : l’accès se déclare permission par permission, donc lentement, donc plus facile à restreindre à un périmètre.
• Dans les deux cas, l’administrateur de la suite doit être dans la boucle dès le premier jour. Ce n’est pas un réglage qu’un utilisateur peut faire lui-même.

Ce qui compte moins qu’on ne le dit : le modèle d’IA

Un environnement Google mène naturellement vers Vertex AI, un environnement Microsoft vers Azure. Les deux offrent des régions européennes et un cadre contractuel qui tient. Rien n’oblige techniquement à prendre le modèle du même éditeur que la suite, et il nous arrive de ne pas le faire. Mais chaque fournisseur supplémentaire, c’est un contrat, un traitement de données à documenter et un interlocuteur de plus le jour où quelque chose casse.

Le piège du « on migre d’abord, on automatisera ensuite »

C’est la phrase qui repousse un projet d’un an. Une migration de suite consomme exactement la ressource dont l’automatisation a besoin : le temps des administrateurs, l’attention de la direction et la patience des utilisateurs. Le BCG relevait en 2025 que les entreprises les plus performantes en IA consacrent 10 % de leurs efforts aux algorithmes, 20 % aux données et à la technologie, et 70 % aux personnes, aux processus et à la conduite du changement. Une migration prélève sur ces 70 % sans rien ajouter au résultat métier.

Le facteur limitant n’est pas la marque de l’outil. Le Microsoft Work Trend Index 2026 attribue aux facteurs d’organisation 67 % de ce qui explique l’impact réellement obtenu avec l’IA, contre 32 % aux facteurs individuels. Et l’Insee indiquait en 2026 que, parmi les entreprises françaises qui n’utilisent pas l’IA, 54 % invoquent un manque d’expertise. Changer de suite ajoute une couche de réapprentissage à une compétence déjà rare.

L’erreur symétrique existe : automatiser en surface pour pouvoir dire qu’on l’a fait. Le Deloitte AI Institute relevait en 2026 que 37 % des organisations utilisent encore l’IA en surface, sans changer leurs processus existants. Poser un assistant sur une suite, quelle qu’elle soit, sans toucher à la façon dont le travail circule, produit une démonstration, pas un gain.

Comment on tranche, en pratique

Quatre questions, dans cet ordre, et le choix se fait tout seul.

• Où sont les identités et la messagerie aujourd’hui ? C’est là qu’on travaille.
• Les réunions que vous voulez exploiter se tiennent-elles chez vous, avec la transcription activée ?
• Qui est l’administrateur capable d’accorder les accès, et quand est-il réellement disponible ?
• Où vos données ont-elles le droit de résider, et votre contrat cloud le couvre-t-il ?

Si vous êtes à cheval sur les deux mondes, ce qui arrive après un rachat ou dans un groupe à filiales, ne cherchez pas à unifier avant d’automatiser. Prenez un seul cas d’usage, dans un seul des deux mondes, et faites-le tourner en vrai. Vous saurez alors ce que coûte la deuxième version, ce qui vaut mieux qu’un comparatif de fiches techniques.