Notermed est un scribe médical IA pour les cliniques. Le médecin enregistre la consultation, l’application transforme la conversation en note clinique, puis le médecin la relit et la signe.
Au départ, l’IA fonctionnait avec OpenAI. Puis une exigence simple a tout changé : chaque donnée patient devait rester chez des fournisseurs couverts par un accord HIPAA. La façon la plus nette d’y répondre était de déplacer toute l’IA vers Amazon Bedrock, couvert par notre accord avec AWS.
Sur papier, changer de fournisseur d’IA est un simple changement de configuration. En pratique, c’était un court projet, avec de vraies décisions. Si vous dirigez une équipe qui utilise l’IA, ou qui prévoit de le faire, voici les leçons à connaître avant de commencer.
1. Décidez où vos données peuvent aller, puis rendez tout le reste impossible
La tentation était de garder l’ancien fournisseur en secours, au cas où. Nous ne l’avons pas fait. Un secours qui peut recevoir des données patients est aussi une porte de sortie pour ces données, dès que quelqu’un modifie le mauvais paramètre.
Nous avons donc retiré complètement l’ancien fournisseur. L’application refuse même de démarrer si quelqu’un tente de la rebrancher dessus. En conformité, « nous promettons de ne pas l’utiliser » pèse moins que « ce n’est plus possible ».
Pour les gestionnaires: Quand vous rédigez une politique sur l’IA, demandez à votre équipe comment le système l’applique, pas seulement s’il l’applique.
2. « Pris en charge » et « fonctionne avec notre configuration » sont deux réponses différentes
Le premier modèle choisi était disponible sur la plateforme et indiqué comme pris en charge. Il a pourtant échoué, à cause d’une petite incompatibilité avec la version de la bibliothèque logicielle que nous utilisons. Nous avons retenu un modèle équivalent qui fonctionnait, sur la même plateforme conforme.
Pour les gestionnaires: Prévoyez quelques jours de tests pour tout changement de fournisseur, même quand le vendeur promet un remplacement direct. Les surprises sont petites, mais elles bloquent les mises en production.
3. La « mémoire » de votre IA dépend du modèle qui l’a créée
Notermed peut répondre à des questions à partir des documents de la clinique : lignes directrices, formulaires, procédures internes. Pour cela, les documents sont convertis dans un format que l’IA peut interroger. Ce format dépend du modèle exact qui l’a produit.
Changez de modèle, et chaque document doit être retraité. Nous l’avons fait dans un nouvel espace de stockage en laissant l’ancien intact, pour pouvoir revenir en arrière en quelques minutes. Un écran d’administration a continué d’afficher l’ancien espace après la bascule et a semé la confusion pendant un moment. Ce genre de détail justifie un plan de retour arrière.
Pour les gestionnaires: Traitez un changement de modèle d’IA comme une migration de données, avec un plan de retour arrière, et non comme un simple réglage.
4. Les vrais documents cassent les hypothèses
Le nouveau modèle limite la quantité de texte qu’il accepte d’un coup. Nos réglages par défaut envoyaient des morceaux plus gros, et certains PDF ou fichiers Word échouaient tout simplement. La solution : découper les documents en morceaux plus petits et appliquer la limite strictement, au lieu de se fier à une estimation.
Pour les gestionnaires: Testez avec les vrais fichiers de vos clients, imparfaits, et non avec des exemples propres. C’est là que se cachent les problèmes de production.
5. En médecine, l’IA ne doit pas être « serviable »
Les modèles de langage sont entraînés à compléter. Dans une note médicale, c’est dangereux. Si le médecin n’a jamais examiné les poumons, l’IA ne doit pas écrire « poumons clairs » simplement parce que la plupart des notes le disent.
Les instructions que nous donnons à l’IA se lisent donc comme un contrat : n’utiliser que ce qui a été dit pendant la consultation, ne jamais deviner un diagnostic, une dose ou un résultat, ne jamais ajouter de constatations « normales » par défaut, et omettre une section plutôt que la remplir d’hypothèses. Si le plan n’est pas clair, la note indique « En attente de révision par le clinicien ». Le médecin a toujours le dernier mot.
Pour les gestionnaires: Pour toute fonction d’IA à fort enjeu, définissez ce que l’IA ne doit jamais faire avant de définir ce qu’elle doit faire.
6. La personnalisation ne doit jamais faire tomber la fonction principale
Les cliniques et les médecins peuvent ajuster la rédaction de leurs notes et le modèle qui les écrit. Ces réglages sont utiles, mais un réglage défectueux ne doit jamais empêcher un médecin d’obtenir sa note. Chaque personnalisation revient au comportement standard en cas de problème.
Pour les gestionnaires: Demandez à votre équipe ce qui se passe quand la configuration d’un client est défectueuse. La bonne réponse : « il obtient quand même le résultat standard ».
7. Gardez les données de chaque client dans son couloir, jusqu’au bout
Les documents d’une clinique ne sont visibles que par cette clinique. Séparer les clients dans la base de données est la partie évidente. La partie moins évidente, c’est la recherche de l’IA elle-même : elle doit aussi se limiter aux documents du client, sinon elle pourrait citer ceux d’une autre clinique.
Pour les gestionnaires: Quand votre produit ajoute de l’IA, vérifiez que la séparation des clients tient aussi à l’intérieur des fonctions d’IA, pas seulement dans la base de données.
En bref
La bascule elle-même s’est bien passée, et la logique centrale du produit a à peine changé. Le travail résidait dans les décisions : où les données peuvent aller, comment revenir en arrière, comment traiter les vrais documents et ce que l’IA ne doit jamais faire. Ces décisions comptent plus que le choix du modèle d’IA.