Google Cloud met en preview un produit qui ne cherche pas à diagnostiquer, mais à remplir les dossiers. Quatre briques, une couche d'agents, et une promesse de conformité qui mérite d'être lue mot à mot.
Gemini for healthcare s'attaque à la paperasse, pas au diagnostic
Le premier réflexe, en lisant l'annonce, est de chercher la partie médicale. Elle n'est pas là.
Google Cloud a présenté cette semaine Gemini for healthcare, en preview. Thomas Kurian, patron de Google Cloud, parle d'une solution sectorielle construite pour l'occasion, qui prolonge l'agent Gemini universel dévoilé en octobre lors de l'événement Gemini at Work.
Les cas d'usage cités sont administratifs et financiers : reconstituer un dossier, préparer une consultation, monter une demande d'autorisation, rédiger un recours. Pas de lecture d'imagerie, pas de suggestion thérapeutique.
Les quatre briques de Gemini for healthcare
Le produit s'articule autour de quatre éléments. Des compétences métier rédigées par des spécialistes du secteur. Des connecteurs vers les systèmes cliniques, financiers et opérationnels. Un écosystème de partenaires. Et une plateforme gouvernée qui peut router entre plusieurs modèles.
Cette dernière brique est la plus stratégique. Google indique qu'une organisation peut associer ses modèles maison à des modèles partenaires sous la même couche de gouvernance. En clair, un hôpital n'est pas enfermé dans un seul fournisseur pour chaque tâche.
Les connecteurs méritent une phrase de plus. Un hôpital n'a pas un système, il en a une dizaine : dossier patient, laboratoire, facturation, imagerie. Chaque raccordement est un projet informatique, avec ses délais et ses tests. Google promet des connecteurs, pas une intégration automatique.
L'agentic layer, ou comment Google limite les accès
Le produit porte un nom, mais il désigne un assemblage. Google Cloud healthcare AI, c'est cette combinaison de compétences, de connecteurs et de gouvernance, pas une application unique. Le mot agent, lui, est partout. La partie intéressante est ce qui l'entoure.
Google décrit une agentic layer, une couche où chaque agent possède sa propre identité, hérite des permissions du rôle de l'utilisateur et applique des frontières de besoin d'en connaître entre utilisateurs, sous-agents et workflows. Un agent ne peut donc pas voir plus qu'un soignant du même service.
S'ajoutent une journalisation complète des accès et des citations vérifiables, pour qu'un relecteur puisse remonter à la source d'une réponse. Sans ces deux éléments, un agent dans un hôpital n'est pas auditable, et un service juridique le refusera, quel que soit le score du modèle sur un benchmark.
Prior authorization : le dossier monté avant l'envoi
C'est le workflow le plus concret, et le plus coûteux aujourd'hui.
Côté soignant, le produit reconstruit une chronologie du patient, en séparant les problèmes actifs des problèmes résolus et en signalant les incohérences de traitement. Il prépare la consultation, puis assemble un dossier de prior authorization conforme à la politique du payeur, avant l'envoi.
L'intérêt tient à l'ordre des opérations. Une demande refusée coûte un appel, une reprise de dossier et parfois une semaine de délai de soin. Vérifier la politique de l'assureur avant l'envoi évite une partie de ces allers-retours.
Ce que l'agent fait quand une demande est refusée
Le refus arrive, et c'est là que le produit devient intéressant.
Gemini for healthcare peut rédiger un recours appuyé sur le dossier clinique et sur la politique du contrat d'assurance. Le texte n'est pas envoyé seul : il sert de base à un humain qui relit, corrige et signe.
Côté payeur, c'est-à-dire côté assureur, la même mécanique s'inverse. L'outil vérifie les demandes entrantes au regard de la politique médicale, organise les constats pour les médecins-conseils, et explique les garanties et les coûts à partir des documents du contrat du membre.
HIPAA : ce que Google promet, et ce qu'il ne promet pas
La formulation compte ici, et elle est souvent déformée.
Google écrit que la plateforme est conçue pour soutenir la conformité HIPAA, avec des contrôles d'accès de niveau entreprise, une journalisation de bout en bout et des citations vérifiables. « Conçue pour soutenir » n'est pas « certifiée ». Aucun certificat HIPAA n'existe à proprement parler, et Google ne revendique pas davantage.
Pour un établissement français, la question se déplace. Un outil qui traite des données de santé doit s'appuyer sur un hébergement certifié HDS, et la conformité au RGPD se joue au niveau du contrat et des flux, pas dans une case cochée sur un site.
Les 28 heures par semaine, un chiffre signé Google
L'argument de vente repose sur un chiffre : près de 28 heures par semaine passées par les cliniciens à réconcilier des informations dispersées.
Ce chiffre est celui de Google. Il n'est pas tiré d'une étude indépendante publiée avec l'annonce, et il faut le citer comme un argument d'éditeur. Il reste plausible pour qui a déjà vu un service reconstituer un dossier à la main, mais plausible n'est pas mesuré.
Ce qu'un hôpital doit demander avant la preview
Cinq questions, dans l'ordre.
Quels dossiers patients sont connectés le premier jour, et via quels connecteurs ? Combien de temps faut-il pour en brancher un ? Combien coûte une preview, parce qu'aucun tarif n'a été publié. Qui porte la responsabilité quand un agent applique mal une politique de remboursement. Et si les équipes soignantes, syndicats compris, ont leur mot à dire sur le déploiement.
La dernière question n'est pas rhétorique. Un outil qui réécrit des dossiers de demande de prise en charge modifie le travail réel d'un service, et pas seulement sa documentation.
Google annonce une disponibilité en preview, sans date de généralisation ni liste de clients. Pour un établissement, la bonne posture est celle de l'essai encadré : un service, un workflow, une mesure avant et après. Le reste attendra les premiers retours.
