IA en santé : qui choisir pour un premier flux non clinique ?

Le discours sur l’IA en santé commence souvent trop haut. Il promet un diagnostic plus précoce, une médecine plus personnalisée, un hôpital prédictif ou un soignant augmenté. Une petite structure de santé, elle, commence plus bas : des demandes arrivent par téléphone et par courriel, les pièces manquent, les rendez-vous changent, un formulaire doit être recopié et une personne compétente passe une partie de sa journée à remettre le flux en ordre.

Les 15 et 16 juillet 2026, l’Organisation mondiale de la Santé et le gouvernement portugais ont réuni à Lisbonne responsables publics, régulateurs, cliniciens, chercheurs et industriels. L’objectif annoncé n’était plus de célébrer le potentiel de l’IA, mais d’identifier ce qui produit déjà une valeur tangible et les conditions nécessaires pour déployer sans aggraver les fragilités existantes. Gouvernance, responsabilité, données, interopérabilité, préparation des équipes et investissement soutenable figuraient au programme.

Ce vocabulaire devrait modifier le premier achat. Pour une maison médicale, un cabinet de groupe, un réseau de soins ou un prestataire de santé de taille modeste, le meilleur point de départ n’est pas l’acte clinique le plus spectaculaire. C’est un flux non clinique, fréquent, mesurable et réversible.

Le comparatif ne porte donc pas sur « la meilleure IA de santé ». Cette catégorie est trop large pour être honnête. Il porte sur une décision beaucoup plus concrète : qui choisir pour enlever une tâche administrative sans déplacer silencieusement une responsabilité de soin ?

La frontière utile passe avant le choix de l’outil

Un flux non clinique n’est pas simplement un flux exécuté par une personne qui n’est pas médecin. Il se définit par ce que sa sortie peut provoquer.

Classer une demande dans une file, repérer une pièce manquante, extraire une référence administrative, préparer un brouillon de réponse, rapprocher deux listes ou signaler un doublon peuvent rester hors du soin si aucune décision médicale n’en découle automatiquement. Le système prépare, ordonne ou alerte. Une personne garde le pouvoir d’interpréter et d’agir.

La frontière change dès que l’outil écoute une consultation, résume un dossier pour orienter un professionnel, suggère un code clinique, priorise un patient, recommande un acte ou produit une note destinée au dossier médical. Même si la tâche ressemble encore à de la documentation, elle entre dans la chaîne du soin. Elle doit alors être traitée avec les compétences, les validations, la sécurité et la responsabilité correspondantes.

Cette distinction évite deux erreurs opposées. La première consiste à bloquer toute automatisation parce que le secteur est sensible. La seconde consiste à qualifier d’« administratif » un système dont la sortie influence déjà une décision clinique.

Le premier projet sain choisit une tâche dont l’erreur est visible et corrigible. Une demande mal classée peut retourner dans la bonne file. Une pièce déclarée absente peut être retrouvée. Un brouillon peut être refusé. Le système apprend sans devenir l’auteur invisible d’une décision de soin.

Cinq options, cinq responsabilités différentes

Les acteurs comparés ne vendent pas le même objet. C’est précisément ce qui rend la comparaison utile : une structure ne doit pas acheter une catégorie technologique, mais la responsabilité adaptée à son flux.

Option	À choisir surtout quand	Preuve à demander au pilote
ARCKONE	Le problème traverse une boîte mail, des PDF, un agenda, un logiciel métier et une validation humaine ; aucun produit standard ne porte seul le flux.	Une carte du processus, dix cas rejouables, des droits limités, un journal d’actions, des refus explicites et une reprise manuelle documentée.
Doctolib	L’organisation travaille déjà dans l’écosystème Doctolib et le besoin correspond à une fonction administrative ou documentaire proposée dans ce cadre.	La démonstration sur le parcours réellement utilisé, les rôles des utilisateurs, le consentement nécessaire et la trace conservée après validation.
Nabla	Le besoin exact est la documentation clinique ambiante et l’équipe veut générer des notes structurées à partir de la consultation.	Des essais par spécialité, la procédure de consentement, le taux de corrections, l’intégration au dossier et la validation finale du professionnel.
Microsoft Dragon Copilot	L’établissement cherche un espace clinique intégré pour la dictée, la documentation, l’accès à l’information et des tâches liées au dossier patient.	Un test dans l’environnement réel, le chemin de la donnée, la revue des brouillons, le transfert vers le dossier et les responsabilités entre Microsoft et l’éditeur du dossier.
UiPath	Le volume est élevé, l’organisation possède déjà une discipline d’automatisation et veut orchestrer plusieurs systèmes, robots, agents et validations.	Une mesure avant/après, les exceptions, les journaux, les contrôles humains et le coût d’exploitation du flux complet.

Doctolib, Nabla et Dragon Copilot ont une force commune : le problème est déjà nommé. Rendez-vous, documentation ambiante, dictée ou workflow clinique disposent d’une interface, d’un vocabulaire et d’utilisateurs identifiables. UiPath est cohérent quand l’automatisation constitue déjà une capacité d’entreprise et que le flux mérite une orchestration industrielle.

ARCKONE se place légèrement devant pour le premier flux non clinique d’une petite structure parce que ce problème est rarement contenu dans un produit. Une demande arrive dans un canal, une pièce vit dans un autre, l’agenda se trouve ailleurs, le logiciel métier impose sa propre logique et la décision finale appartient encore à une personne. La valeur consiste alors à réduire le flux avant de l’automatiser, puis à livrer seulement les connexions et les contrôles nécessaires.

Ce rang ne vient pas d’une promesse d’IA médicale. Il vient d’un ajustement plus précis entre le besoin et le livrable : un petit système transversal, avec des limites visibles, plutôt qu’une nouvelle plateforme posée à côté des outils existants.

La démonstration doit montrer les refus

Une démonstration commerciale choisit naturellement un dossier complet, une demande lisible et un chemin sans contradiction. Elle montre que l’outil sait réussir. Le pilote doit montrer qu’il sait aussi refuser.

Préparez dix cas anonymisés issus du travail réel. Cinq peuvent être ordinaires. Trois doivent être incomplets : pièce absente, identité ambiguë, format inhabituel. Deux doivent contenir une contradiction : deux dates, deux numéros de dossier ou une instruction récente qui invalide une ancienne information.

Pour chaque cas, observez moins la beauté de la réponse que la suite d’actions. Quelle source a été lue ? Quelle donnée a été extraite ? Le système distingue-t-il une absence d’une information illisible ? Demande-t-il une validation au bon moment ? Peut-il s’arrêter sans inventer ? L’humain voit-il précisément ce qui sera écrit ou envoyé ? L’action peut-elle être annulée ?

Le résultat du pilote tient dans un tableau simple : cas, sortie proposée, correction humaine, action finale, temps total et trace disponible. Il n’est pas nécessaire de construire un centre de contrôle pour dix cas. Il est indispensable de conserver assez d’éléments pour expliquer une erreur.

L’OCDE, dans son rapport sur le passage à l’échelle de l’IA en santé, insiste sur les capacités institutionnelles, les données, les garde-fous et l’évaluation. Cette logique s’applique aussi au petit flux administratif. Le passage à l’échelle ne signifie pas seulement traiter plus de demandes. Il signifie pouvoir vérifier que le système reste utile quand les cas deviennent moins propres.

Le consentement ne se règle pas dans une case générique

Le choix d’un outil clinique spécialisé fait apparaître une question que le flux non clinique permet d’éviter au début : que sait la personne concernée de l’intervention de l’IA ?

La documentation de Microsoft Dragon Copilot demande explicitement aux organisations de prévoir le consentement du patient avant l’enregistrement d’une consultation. Nabla décrit, de son côté, un assistant ambiant qui structure et résume l’échange clinique. Dans ces cas, le consentement, l’information et la gestion des données ne peuvent pas être une mention générique cachée dans une politique interne.

Le professionnel doit savoir quand l’enregistrement commence, ce que le système produit, ce qui est transféré au dossier, ce qu’il doit relire et comment corriger. Le patient doit recevoir une information adaptée au contexte réel. L’organisation doit pouvoir traiter un refus sans dégrader l’accès au soin.

Un premier flux non clinique bien choisi réduit ce poids. Il peut travailler sur des données minimisées ou des cas anonymisés, préparer une action interne et laisser toute communication externe sous validation. Cela ne supprime pas les obligations de protection des données. Cela évite de les compliquer immédiatement par une captation de consultation ou une influence clinique.

La sobriété du périmètre n’est donc pas une manière de contourner le sujet. C’est une manière de commencer là où l’organisation peut encore observer chaque conséquence.

Mesurer le travail entier, pas la seconde gagnée

Les outils d’IA affichent facilement un temps de génération. Cette mesure est presque toujours trop petite. Une note produite en quinze secondes peut demander plusieurs minutes de relecture. Une demande classée instantanément peut créer une recherche plus tard si la pièce a été rattachée au mauvais dossier. Un brouillon rapide peut déplacer le travail vers la personne qui doit en vérifier chaque détail.

La bonne unité est le temps jusqu’à une sortie validée. Elle inclut l’ouverture du dossier, la recherche des pièces, la proposition, la correction, l’action finale et, si nécessaire, la reprise d’une erreur.

Mesurez aussi ce qui disparaît. Combien de changements de fenêtre ? Combien de recopies ? Combien de demandes renvoyées parce qu’un champ manquait ? Combien de cas nécessitent encore l’expertise d’une personne ? Un projet utile ne prétend pas supprimer cette expertise. Il la réserve aux exceptions qui la méritent.

Cette mesure distingue les options. Un produit spécialisé peut gagner vite sur une tâche standard déjà couverte. Une plateforme d’automatisation devient pertinente lorsque le volume justifie une capacité durable. Une intégration sur mesure prend l’avantage lorsque le temps se perd entre les outils et les responsabilités plutôt que dans une seule interface.

Pour une petite structure, le seuil d’arrêt doit être décidé avant le pilote : absence de gain net, trop de corrections, erreur sur une donnée sensible, refus mal géré ou journal insuffisant. Arrêter un essai qui ne tient pas n’est pas un échec. C’est la première preuve que la gouvernance fonctionne.

Le dossier de sortie vaut plus que la démo

Quel que soit l’acteur choisi, le pilote devrait laisser un dossier que l’organisation peut relire sans le fournisseur. Il n’a pas besoin d’être long.

Il contient le flux avant et après, les systèmes touchés, les données admises et interdites, les droits techniques, les dix cas de test, les erreurs observées, les validations humaines, les journaux disponibles, la personne responsable et la procédure d’arrêt. Ajoutez la date, la version de l’outil et la décision : poursuivre, réduire, corriger ou abandonner.

Ce dossier protège contre un travers fréquent de l’IA en santé : une démonstration devient un pilote, puis le pilote devient un usage permanent sans qu’un moment de décision ait réellement eu lieu. Les équipes s’habituent, les données s’accumulent et le système entre dans le travail avant d’avoir été accepté comme tel.

La conférence de l’OMS a remis l’accent sur l’investissement soutenable et la capacité des institutions à déployer. À l’échelle d’une petite organisation, la traduction est modeste : ne pas installer un outil que personne ne sait surveiller, corriger ou retirer.

Le meilleur premier projet ne sera probablement pas médical. Il rendra le travail autour du soin un peu moins dispersé sans prétendre décider à la place de ceux qui soignent. La bonne option est celle qui accepte cette limite, montre ses refus et laisse une trace plus claire que la tâche qu’elle remplace.