Points clés
- Auto-hébergé veut dire que l'app, la base et l'AI tournent sur une infrastructure que vous contrôlez.
- La raison habituelle est la résidence, l'isolation ou un réseau qui ne peut pas parler à l'internet public.
- La plupart des « CRM on-prem » envoient encore les prompts AI à un modèle cloud. Posez cette question à part.
- Qivity runs on Docker with PostgreSQL and Redis. Lilly is an optional add-on that then runs on your infrastructure, with egress optional.
Un CRM auto-hébergé est un logiciel que vous faites tourner sur une infrastructure que vous contrôlez : vos VM, votre cluster Kubernetes, votre cloud privé. L'application, la base et — si le produit est honnête — l'assistant AI vivent tous là.
Ce n'est pas la même chose que « nous avons une région de datacentre à Mumbai ». La résidence d'une base SaaS est utile. Ce n'est pas de l'auto-hébergement.
Quand le CRM auto-hébergé est le bon choix
- Un régulateur ou un contrat client nomme le lieu de traitement plus étroitement qu'une région d'éditeur ne peut satisfaire.
- Le réseau est air-gap, ou une sortie est un incident.
- Vous opérez déjà PostgreSQL et préférez l'étendre plutôt qu'ouvrir une nouvelle surface d'attaque SaaS.
- Les achats n'accepteront pas un sous-traitant de modèle de fondation, et l'assistant du CRM doit continuer à marcher quand même.
Si rien de cela n'est vrai, un déploiement hébergé bien tenu est plus simple. L'auto-hébergement est un choix d'exploitation, pas un badge.
Le piège AI
Beaucoup de CRM on-premise appellent encore un modèle hébergé. Vous avez alors payé une base privée et un prompt public. Un CRM AI privé garde l'inférence dans la même frontière. L'option auto-hébergée de Qivity inclut Lilly sur des modèles locaux. La comparaison d'architectures est la version courte.
Ce que vous opérez vraiment
L'empreinte de Qivity est délibérément ennuyeuse : Docker, PostgreSQL, Redis. Les sauvegardes sont des sauvegardes de base. Les mises à niveau sont des tirages d'images. Il n'y a pas d'appliance propriétaire ni d'obligation qu'un partenaire « lève l'org ».
Il vous faut encore quelqu'un qui sache faire tourner des conteneurs et restaurer une base. Si cette personne n'existe pas, n'auto-hébergez pas par geste politique. Utilisez l'hébergé, gardez l'AI locale au déploiement, et revenez-y quand l'équipe est prête.
Questions pour l'éditeur
- L'AI tourne-t-elle dans la même install, avec la sortie coupée ?
- Quelle base possédons-nous, et pouvons-nous en faire un dump ?
- Quel est le chemin de mise à niveau sans une semaine de services professionnels ?
- SSO, export d'audit, conservation des sauvegardes — dans le produit ou en construction sur mesure ?
Parlez-nous si l'auto-hébergement est une exigence plutôt qu'une préférence. Apportez la contrainte (air-gap, région, DPA) plutôt qu'un « on-prem » générique. La contrainte décide de l'install.