Puis-je connecter un modèle d'IA auto-hébergé à un CRM via MCP ?

Oui. Historis expose un serveur MCP derrière OAuth 2.1, et l'assistant à l'autre bout est votre choix, y compris un modèle open source auto-hébergé comme Llama, Mistral ou Qwen piloté par un hôte MCP open source. Le raisonnement se fait alors sur une infrastructure que vous opérez, donc vos notes client ne sont jamais envoyées à une IA tierce pour l'inférence.

Historis exécute-t-il sa propre IA sur mes données client ?

Non. Historis n'exécute aucun modèle. La recherche est du plein texte Postgres, pas un modèle, et les règles sont du markdown que vous écrivez, que le serveur rapproche de façon déterministe et transmet à votre assistant pour qu'il l'interprète. Rien de ce que vos clients vous confient n'est envoyé à un modèle exploité par Historis, parce qu'Historis n'en exploite aucun.

Mes données sont-elles utilisées pour entraîner un modèle d'IA ?

Non. Vos données ne sont jamais utilisées pour l'entraînement. Elles vivent dans un cloud UE mono-région managé, sous accord de traitement, et la seule IA qui les analyse est celle que vous branchez. Historis ne détient aucun modèle et n'en entraîne aucun.

Puis-je faire tourner Historis entièrement on-premise, 100 % sur mes serveurs ?

Non. L'inférence peut se faire entièrement chez vous avec un modèle auto-hébergé, mais le stockage reste dans le cloud UE mono-région managé d'Historis ; il n'y a pas d'Historis on-premise. La promesse exacte est inférence souveraine plus résidence UE sans entraînement, pas 100 % sur vos serveurs.

Puis-je contrôler ce qu'une IA connectée a le droit de faire ?

Oui. Vous définissez les permissions par organisation et par client connecté, à l'écran de consentement : lire les événements, lire les contacts, écrire. Par défaut, l'accès est en lecture seule. Chaque écriture d'un assistant est marquée d'un losange, attribuée et journalisée, et une modification erronée peut être annulée.

Notes

Apportez votre IA : le CRM n'exécute aucun modèle

18 juin 2026 · 5 min de lecture · Sven Le Cann — Historis

Historis n'exécute aucun modèle. Branchez votre propre IA via MCP, même open source et auto-hébergée : vos données client n'atteignent jamais une IA tierce.

La plupart des produits qui « font de l'IA » sont l'IA. Vous écrivez, vos données partent vers leur modèle, et vous faites confiance à leur politique sur ce qui suit. Historis prend le parti inverse. Il n'exécute aucun modèle. Vous apportez votre propre IA via MCP, et le serveur reste une couche déterministe de données et de permissions. Au bout de cette logique, votre IA peut être un modèle open source entièrement auto-hébergé. Dans ce cas, aucune donnée client n'est envoyée à un tiers pour qu'un modèle l'analyse.

Historis est un CRM de suivi client pour boutiques, construit autour d'une chronologie d'événements, et il expose cet historique à votre propre IA via MCP. Ce n'est pas un slogan, c'est l'architecture. Voici ce que « apportez votre IA » signifie vraiment. La limite honnête de la promesse compte tout autant.

Le serveur n'exécute aucun modèle, volontairement

Aucune inférence sur le chemin critique. La recherche s'appuie sur le plein texte de Postgres. Les règles sont du markdown que vous écrivez ; le serveur les stocke et les rapproche de façon déterministe, puis transmet le texte à votre assistant pour qu'il l'interprète. Il ne les exécute ni ne les « comprend » jamais côté serveur.

Et si une recherche sémantique est un jour ajoutée, ses embeddings viendraient aussi de votre côté. Aucune donnée confiée par vos clients ne transite par un modèle qu'Historis opérerait, pour la bonne et simple raison qu'il n'en opère aucun. Les réponses viennent de faits enregistrés.

Quelle IA pouvez-vous brancher ?

Historis parle un protocole ouvert, le Model Context Protocol, et fonctionne comme un serveur MCP derrière OAuth 2.1. L'assistant à l'autre bout, c'est votre choix :

Type de connexion	Où se fait le raisonnement	Ce qui quitte votre infrastructure
Assistant hébergé (Claude, ChatGPT, Cursor)	Le cloud de l'éditeur	Le contexte que l'assistant lit via MCP
Agent programmatique (un SDK, un script, une automatisation)	Là où vous déployez votre code	Ce que ce code envoie au modèle qu'il appelle
Modèle open source auto-hébergé (Llama, Mistral, Qwen via Ollama ou vLLM), piloté par un hôte MCP open source (l'application qui pilote le modèle : LibreChat, Open WebUI, Cline)	Votre propre machine	Rien vers un fournisseur d'IA

Dans tous les cas le modèle est le vôtre et Historis est la donnée sur laquelle il travaille. Nous sommes le substrat, pas le cerveau.

Avec une inférence souveraine, quelque chose part-il vers le modèle ?

C'est la partie que les grands produits d'IA ne peuvent structurellement pas offrir : ils sont le modèle, donc vos données doivent les atteindre. Avec un modèle open source auto-hébergé pointé sur Historis, le raisonnement se fait sur une infrastructure que vous opérez. Vos notes client ne sont jamais envoyées à un fournisseur d'IA tiers pour l'inférence ; l'intelligence peut rester entièrement chez vous, en local.

Concrètement, la gérante d'une boutique demande à un Llama local, piloté par LibreChat, ce que Mme Durand a acheté à sa dernière visite et quelle relance est prévue. Le modèle lit la chronologie dans Historis via MCP et raisonne sur la machine du magasin. Aucune IA tierce ne voit la question, ni l'historique derrière.

La limite honnête

On préfère poser la limite clairement plutôt que de laisser « souverain » en dire plus qu'il ne devrait. Deux choses distinctes :

L'inférence peut se faire à 100 % chez vous : avec un modèle auto-hébergé, rien n'est envoyé à un tiers pour être analysé.
Le stockage, lui, reste chez Historis : vos données vivent dans notre cloud UE, mono-région, couvertes par un accord de traitement et jamais utilisées pour l'entraînement, mais pas sur vos propres serveurs. Il n'y a pas d'Historis on-premise aujourd'hui. (Comment ces données sont isolées et protégées est détaillé dans sécurité.)

La promesse exacte est donc inférence souveraine + résidence UE, sans entraînement, pas « 100 % sur vos serveurs ». Quand un produit vous dit la différence d'emblée, vous pouvez faire confiance à la partie qu'il promet.

Comment gardez-vous le contrôle de ce que fait l'agent ?

Apporter votre IA n'aurait guère de sens si vous ne pouviez pas la borner. Vous décidez ce que chaque client connecté peut faire, par organisation et par client : lire les événements, lire les contacts, écrire. Le choix se fait à l'écran de consentement, en lecture seule par défaut.

Et chaque écriture d'un assistant est marquée d'un ◆, attribuée et journalisée, si bien que vous distinguez toujours son travail du vôtre et pouvez annuler une modification erronée (une suppression, elle, est destructrice). Un cas d'usage concret : garder vos relances sur les rails avec votre propre agent. (Plus de détails dans pourquoi laisser une IA écrire dans votre CRM est sûr et comment une surface agent multi-tenant reste étanche.)

Pourquoi est-ce rare ?

La voie courante pour avoir de l'IA, c'est d'utiliser un produit qui est une entreprise d'IA : vous ne pouvez pas y pointer votre propre modèle, et la promesse que vos données n'entraîneront pas leur modèle se cache souvent derrière des paliers commerciaux ou des minimums de sièges qu'un indépendant ne peut pas atteindre.

Même les CRM open source qui vous laissent auto-héberger l'application traitent rarement l'IA « à apporter soi-même » comme un choix à part entière (voir Historis vs Twenty). Ici, le comportement par défaut s'inverse. Le modèle et les clés restent à vous ; le serveur ne détient aucun modèle et n'en entraîne aucun, et tout cela se vérifie.

Pourquoi on l'a construit comme ça

C'est tout le sens de « vous et votre IA ». Le système garde votre historique correct, cadré et traçable ; l'intelligence est la vôtre, à choisir et, si vous voulez, à héberger vous-même. Historis est le substrat déterministe sur lequel votre assistant travaille, conçu pour que brancher le modèle le plus privé que vous puissiez faire tourner ne soit pas un contournement mais le chemin prévu.

Questions fréquentes

Puis-je connecter un modèle d'IA auto-hébergé à un CRM via MCP ?: Oui. Historis expose un serveur MCP derrière OAuth 2.1, et l'assistant à l'autre bout est votre choix, y compris un modèle open source auto-hébergé comme Llama, Mistral ou Qwen piloté par un hôte MCP open source. Le raisonnement se fait alors sur une infrastructure que vous opérez, donc vos notes client ne sont jamais envoyées à une IA tierce pour l'inférence.
Historis exécute-t-il sa propre IA sur mes données client ?: Non. Historis n'exécute aucun modèle. La recherche est du plein texte Postgres, pas un modèle, et les règles sont du markdown que vous écrivez, que le serveur rapproche de façon déterministe et transmet à votre assistant pour qu'il l'interprète. Rien de ce que vos clients vous confient n'est envoyé à un modèle exploité par Historis, parce qu'Historis n'en exploite aucun.
Mes données sont-elles utilisées pour entraîner un modèle d'IA ?: Non. Vos données ne sont jamais utilisées pour l'entraînement. Elles vivent dans un cloud UE mono-région managé, sous accord de traitement, et la seule IA qui les analyse est celle que vous branchez. Historis ne détient aucun modèle et n'en entraîne aucun.
Puis-je faire tourner Historis entièrement on-premise, 100 % sur mes serveurs ?: Non. L'inférence peut se faire entièrement chez vous avec un modèle auto-hébergé, mais le stockage reste dans le cloud UE mono-région managé d'Historis ; il n'y a pas d'Historis on-premise. La promesse exacte est inférence souveraine plus résidence UE sans entraînement, pas 100 % sur vos serveurs.
Puis-je contrôler ce qu'une IA connectée a le droit de faire ?: Oui. Vous définissez les permissions par organisation et par client connecté, à l'écran de consentement : lire les événements, lire les contacts, écrire. Par défaut, l'accès est en lecture seule. Chaque écriture d'un assistant est marquée d'un losange, attribuée et journalisée, et une modification erronée peut être annulée.