Au cœur de chaque produit d’IA clinique se trouve un choix discret mais lourd de conséquences : le logiciel est-il un décideur, ou l’assistant d’un décideur ? Il est tentant de traiter cette question comme une affaire de degré — un curseur que l’on pourrait pousser vers davantage d’automatisation à mesure que la confiance grandit. Ce n’est pas ainsi que nous voyons les choses. Pour nous, il s’agit d’une posture de conception fixe, établie avant que la première fonctionnalité ne soit esquissée, et elle régit la manière dont les observations sont présentées, dont les résultats sont consignés, et dont un clinicien les examine, les modifie ou les écarte.

Assistif par conception signifie que c’est le clinicien qui décide et que l’outil soutient cette décision. La phrase est courte, mais s’y tenir ne l’est pas. Elle a des implications pour l’interface utilisateur, le compte rendu, la piste d’audit et la responsabilité qui accompagne un dossier longtemps après sa clôture.

L’assistance est une posture, pas un avertissement

Il est facile d’inscrire « à titre d’assistance uniquement » en bas de page et de continuer à construire quelque chose qui, en réalité, se comporte comme un oracle. Une case pré-cochée, une observation présentée comme un fait établi, un réglage par défaut fastidieux à défaire — chacun de ces éléments pousse le clinicien à accepter le point de vue de la machine sans vraiment l’examiner. L’avertissement dit une chose ; la conception en dit une autre, et c’est à la conception que les gens réagissent.

Nous traitons donc l’assistance comme une contrainte d’ingénierie plutôt que comme une posture juridique. Une suggestion doit ressembler à une suggestion. Le jugement du clinicien doit être la voie de moindre résistance, et non une exception qu’il faut un effort pour faire valoir. Lorsque le logiciel est incertain, cette incertitude doit être visible plutôt que lissée en un résultat unique d’apparence assurée. L’objectif n’est pas de faire paraître l’IA plus autoritaire ; c’est de rendre l’examen humain plus rapide et mieux éclairé.

L’humain dans la boucle est un vérificateur et un approbateur

« L’humain dans la boucle » peut ne pas signifier grand-chose si l’humain est réduit à cliquer sur accepter quoi que produise le modèle. Nous traçons ce rôle plus nettement : le clinicien est un vérificateur et un approbateur, et rien ne sort du système comme définitif sans cette approbation.

Concrètement, cela signifie qu’un résultat assisté par l’IA reste un brouillon jusqu’à ce qu’une personne qualifiée le signe. Dans notre couche de radiologie, TomoPod produit des comptes rendus semi-automatisés, mais le radiologue demeure le vérificateur et l’approbateur — le compte rendu est le sien, façonné par ce qu’il confirme, corrige ou écarte. En pathologie, PathoPod apporte les images de lames entières et l’assistance computationnelle au laboratoire d’anatomopathologie, et le visualiseur web est conçu pour la relecture collaborative en réunion de concertation pluridisciplinaire, et non pour remplacer discrètement la validation du pathologiste. En endoscopie, EndoPod offre une assistance en temps réel pendant l’intervention, mais c’est l’endoscopiste qui agit sur ce qu’il observe ; le système éclaire l’instant plutôt que de s’y substituer.

Le fil conducteur est que la contribution du modèle est toujours proposée au sein d’un flux de travail humain, jamais substituée à lui. Le clinicien peut accepter une suggestion, la modifier ou l’écarter entièrement, et le système doit faire de ces trois actions des options de premier rang à parts égales.

Comment cela façonne l’interface

Quelques principes découlent directement de cette posture, et ils se manifestent dans les parties du produit que les gens manipulent réellement.

  • Les observations sont présentées, pas affirmées. Le visualiseur expose ce que le modèle a signalé comme méritant attention, l’image ou la donnée sous-jacente étant toujours à portée d’un coup d’œil. Le clinicien confirme par rapport à la source plutôt qu’à un résumé.
  • Les réglages par défaut privilégient l’examen. Rien n’est pré-accepté. Une suggestion assistée par l’IA n’entre dans le compte rendu que lorsque le clinicien l’y place, et la modifier ou la rejeter est aussi simple que de l’accepter.
  • Les passer outre est normal, pas conflictuel. Être en désaccord avec le modèle est une action ordinaire et sans friction — pas un réglage caché ni une exception truffée d’avertissements. Un outil qui vous pénalise lorsque vous le contredisez n’est pas vraiment assistif.
  • L’incertitude reste lisible. Là où le système n’est pas sûr, l’interface le dit, au lieu de réduire un cas difficile à un résultat net et faussement assuré.

Rien de tout cela n’est décoratif. Chaque choix est là pour maintenir l’attention du clinicien là où elle doit être — sur le patient et les éléments probants — tout en réduisant le travail mécanique qui mène des images à un compte rendu achevé et imputable.

Le compte rendu et le dossier

L’assistance ne s’arrête pas lorsque le clinicien tranche ; elle doit se refléter dans ce qui est consigné. Un compte rendu assisté par l’IA doit indiquer clairement qu’il l’a été, et doit consigner les décisions humaines qui ont produit la version finale. C’est en partie une question d’honnêteté et en partie une question de sécurité : quiconque lit le dossier plus tard — un collègue, un auditeur, le clinicien lui-même dans le futur — doit pouvoir voir ce que l’outil a proposé et ce que la personne a décidé.

Parce que le compte rendu transite par les normes que le reste de la médecine parle déjà — DICOM et HL7 à travers le RIS, le PACS, le LIS et l’EIS — le résultat assisté vit à l’intérieur du dossier existant plutôt qu’à part, dans un silo propriétaire. L’assistance fait partie du flux de travail clinique, et non un gadget distinct greffé à côté. Et parce que les outils en périphérie et les pods échangent des informations de manière asynchrone entre le point de soins et le système plus large, le moment de cet échange n’oblige jamais un clinicien à attendre une réponse distante avant de pouvoir agir.

La responsabilité doit reposer sur une personne

C’est au fond pour cela que cette posture importe. La responsabilité d’une décision clinique ne peut être déléguée à un logiciel. Un modèle n’est pas tenu à une obligation de soins ; un clinicien l’est. Si un système est conçu de telle sorte que l’humain ne fait qu’apposer un tampon sur le résultat de la machine, alors la responsabilité s’est discrètement évaporée, même si, sur le papier, quelqu’un a signé.

Concevoir pour l’assistance maintient la responsabilité là où la loi et les bonnes pratiques la placent déjà. Le clinicien qui approuve un compte rendu en est vraiment l’auteur, parce que le système lui a donné les moyens de vérifier, la liberté de passer outre, et un dossier qui reflète ses décisions. La piste d’audit n’est pas là pour reporter la faute sur l’outil ; elle est là pour montrer, fidèlement, qu’une personne qualifiée a tranché avec un bon appui.

Une meilleure assistance, pas plus d’autonomie

Nos systèmes sont prêts pour l’assistance par l’IA dès la conception : les modèles s’y intègrent et se déploient au fil du temps, et l’assistance disponible en endoscopie, en pathologie et en radiologie ne cessera de s’améliorer à mesure que cela se produit. Mais « meilleure » a ici un sens précis. Cela ne signifie pas confier peu à peu davantage de la décision à la machine. Cela signifie rendre le clinicien plus rapide, mieux éclairé et plus à même de se concentrer sur les cas et les détails qui comptent le plus.

Voilà la promesse de l’assistif par conception. L’outil gagne sa place en améliorant le travail, non en s’en emparant. Le clinicien décide ; le système soutient — et nous construisons chaque partie du produit, du premier pixel du visualiseur à la dernière ligne de la piste d’audit, pour qu’il en reste ainsi.