Comment intégrer un assistant IA dans un logiciel vétérinaire sans compromettre la sécurité ?

Demander à une intelligence artificielle de résumer un document est devenu relativement banal.

Mais lui demander de retrouver l'historique médical d'un animal, d'analyser le planning d'une clinique, de préparer un rendez-vous ou de relancer des impayés, c'est une tout autre histoire.

Pour réaliser ces opérations, l'IA doit pouvoir accéder aux données du logiciel, comprendre son fonctionnement et interagir avec ses fonctionnalités.

Comment lui donner ces capacités sans compromettre la sécurité des données de la clinique ? Et surtout, sans lui accorder plus de droits qu'à l'utilisateur qui lui parle ?

C'est l'une des questions auxquelles nous avons dû répondre en développant Silice, l'assistant IA intégré à VetCoreSolution®, notre logiciel de gestion de clinique vétérinaire.

Notre approche repose sur un principe simple : l'intelligence artificielle doit utiliser les mêmes services et respecter les mêmes règles que le reste du logiciel.

Une architecture pensée pour accueillir l'intelligence artificielle

Intégrer un assistant IA à un logiciel métier ne devrait pas nécessiter de reconstruire le soft.

La clé, c'est de penser le logiciel, dès le départ pour permettre aux fonctionnalités de communiquer entre elles et avec des outils externes en respectant la chaine de sécurité.

Dès la conception de VetCoreSolution®, nous avons choisi de séparer les fonctionnalités métiers de leur interface utilisateur, avec des API qui permettent aux différents composants de communiquer entre eux.

Créer un rendez-vous, rechercher un animal, consulter une facture ou récupérer un historique médical : ces opérations reposent sur des services métiers déjà présents dans notre logiciel.

L'interface de VetCoreSolution® utilise ces services pour répondre aux actions de l'utilisateur. Pourquoi un assistant IA devrait-il passer par un autre chemin ?

C'est là qu'intervient le MCP (Model Context Protocol), un standard ouvert permettant aux assistants IA d'interagir avec des applications et leurs outils.

Dans VetCoreSolution®, notre couche MCP s'appuie directement sur les services métiers existants. Elle expose aux assistants les opérations auxquelles ils peuvent accéder, sans avoir besoin de dupliquer la logique du logiciel.

Silice peut ainsi rechercher des informations, interroger le planning, consulter des dossiers ou analyser des données en utilisant les mêmes mécanismes que l'application.

Et surtout, les règles métiers et les contrôles de sécurité restent ceux de VetCoreSolution®.

Pas besoin de tordre le logiciel pour y intégrer de l'IA.

La sécurité : aucun passe-droit pour l'IA

C'est probablement LE point le plus important de toute cette architecture.

Une IA interne ajoutée sur le tard peut disposer d'accès techniques bien supérieurs à ceux de l'utilisateur. Et si ces accès sont mal encadrés, la sécurité repose alors sur la capacité du modèle à respecter ses consignes.

Autrement dit, on lui donne les moyens de consulter des données interdites, puis on lui demande gentiment de ne pas le faire.

Pour ceux qui ont déjà utilisé des modèles d'IA, inutile d'expliquer pourquoi cette approche pose problème.

Chez CoreFactor, nous avons choisi une séparation beaucoup plus stricte.

Silice travaille avec les droits de l'utilisateur connecté. Pas davantage.

Prenons un exemple concret.

Un membre de la clinique n'a pas le droit de consulter les informations financières de l'établissement. Il demande pourtant à Silice :

« Quel est notre chiffre d'affaires ce mois-ci ? »

Il peut essayer... Mais Silice elle-même n'a aucun moyen d'accéder à ces informations.

Ce n'est pas une interdiction écrite dans ses consignes : ce sont les serveurs de VetCoreSolution® qui appliquent les permissions.

Notre architecture va même plus loin :

• Les outils disponibles sont filtrés selon les droits de l'utilisateur.
• Chaque appel est à nouveau contrôlé par le serveur, même si l'IA tente d'utiliser un outil auquel elle ne devrait pas accéder.
• Les autorisations d'un connecteur externe peuvent restreindre davantage les accès, jamais les étendre.
• Les règles d'authentification, y compris la double authentification lorsqu'elle est exigée, continuent de s'appliquer.

L'IA ne choisit donc pas les permissions qu'elle souhaite respecter.

Elle ne peut utiliser que les fonctionnalités que le logiciel l'autorise réellement à utiliser.

C'est une différence fondamentale : notre sécurité ne dépend pas de la fiabilité du raisonnement d'un modèle d'IA.

Silice prépare les actions, l'utilisateur garde le contrôle

Accéder aux données est une chose. Les modifier en est une autre.

Un assistant capable de consulter le dossier d'un animal est utile. Un assistant capable de créer ou modifier des informations directement dans le logiciel peut l'être encore davantage.

Mais une IA peut se tromper.

Elle peut mal interpréter une demande, sélectionner le mauvais rendez-vous ou proposer une information incomplète. Il serait dangereux de considérer que toutes ses propositions doivent automatiquement devenir des opérations définitives.

C'est pourquoi nous avons adopté un fonctionnement précautionneux pour Silice.

Silice ne modifie jamais directement les données de la clinique.

Lorsqu'un utilisateur lui demande de créer un rendez-vous, de modifier une fiche client ou de préparer une tâche, l'assistant recherche les informations nécessaires et construit une proposition.

Cette proposition est ensuite présentée dans l'interface de VetCoreSolution®, sous une forme que l'utilisateur peut examiner.

Il peut alors la valider, la refuser ou la corriger.

Ce n'est qu'au moment de la validation que l'application exécute réellement l'action, à travers ses API habituelles et avec les permissions de l'utilisateur.

La différence est importante : ce n'est pas l'IA qui écrit dans la base de données. C'est l'application, sur décision de l'utilisateur.

Ce principe accompagnera également les nouvelles fonctionnalités de Silice, notamment la relance des impayés, prévue prochainement.

L'assistant pourra regrouper les factures concernées et préparer les messages de relance, par email ou SMS. Mais les envois resteront soumis à la validation de l'utilisateur.

L'IA propose. Vous gardez le contrôle.

C'est l'un des fondements du contrat de confiance que nous souhaitons établir avec les utilisateurs de VetCoreSolution®.

Silice travaille dans le logiciel, pas à côté

Cette architecture a une autre conséquence importante : Silice ne se limite pas à être une fenêtre de conversation supplémentaire.

Elle peut s'appuyer sur les informations et les fonctionnalités de VetCoreSolution® pour accompagner les utilisateurs dans leur travail quotidien.

Silice peut également orienter l'utilisateur vers les fiches et les informations qu'elle retrouve directement dans le logiciel.

L'objectif n'est donc pas de créer un chatbot où il faudrait copier-coller les données de la clinique pour obtenir une réponse.

L'objectif est que l'assistant travaille avec les informations déjà présentes dans VetCoreSolution®, au sein du logiciel que les équipes utilisent quotidiennement.

Une plateforme ouverte : Silice n'est pas votre seule option

Nous avons conçu Silice pour proposer une expérience directement intégrée à VetCoreSolution®.

Mais nous ne pensons pas qu'un éditeur de logiciel doive imposer un assistant IA unique à ses utilisateurs.

C'est aussi tout l'intérêt d'une architecture fondée sur des standards ouverts.

La couche MCP utilisée par Silice est également accessible aux assistants externes compatibles. Une clinique peut ainsi connecter d'autres outils, notamment ChatGPT, Claude ou des solutions développées par des concurrents.

Cette ouverture ne signifie évidemment pas que n'importe quel assistant peut librement accéder aux données de la clinique.

Les connexions externes reposent sur des mécanismes d'authentification et d'autorisation, notamment OAuth, avec un consentement explicite et des permissions encadrées.

Chaque assistant accède uniquement aux fonctionnalités qui lui sont ouvertes, dans les limites des droits de l'utilisateur et de celles définies pour son connecteur.

Et comme pour Silice, ces contrôles sont effectués par les serveurs de VetCoreSolution®, pas par le modèle d'IA.

Le choix de l'assistant ne doit jamais remettre en cause les règles de sécurité du logiciel.

Cette ouverture s'inscrit dans une démarche plus large que nous avions déjà présentée dans un précédent PointTech : construire une plateforme vétérinaire capable de communiquer avec d'autres outils, plutôt qu'un écosystème fermé.

L'IA doit s'adapter au logiciel, pas contourner ses règles

L'intelligence artificielle ouvre des possibilités considérables pour simplifier le quotidien des cliniques vétérinaires.

Mais lui donner accès à des données et à des fonctionnalités métiers implique une responsabilité particulière.

Le véritable enjeu ne consiste pas seulement à choisir un modèle performant ou à lui fournir un grand nombre d'outils. Il consiste à construire une architecture dans laquelle ses capacités restent maîtrisées.

Pour VetCoreSolution®, nous avons fait le choix de nous appuyer sur les services existants, de conserver les contrôles de permissions côté serveur, de soumettre les modifications à la validation de l'utilisateur et de permettre l'intégration d'assistants externes.

Notre objectif n'est pas simplement d'ajouter de l'IA dans VetCoreSolution®.

C'est de permettre à l'intelligence artificielle de travailler véritablement dans le logiciel, aux côtés des équipes vétérinaires, sans sacrifier la sécurité de leurs données ni leur liberté de choix.