Auto-héberger un CRM : pourquoi nous avons quitté le SaaS

Le marché des CRM SaaS ne manque pas d’options. Salesforce, HubSpot, Pipedrive, Zoho — chacun avec ses niveaux de tarification, sa matrice de fonctionnalités et son responsable de compte prêt à expliquer pourquoi le niveau supérieur est exactement ce dont votre entreprise a besoin. Nous avons utilisé plusieurs de ces outils au fil des ans et avons constaté qu’au-delà d’un certain point, la proposition de valeur s’inverse.

Les coûts sont le symptôme le plus visible. Pipedrive démarre raisonnablement, puis augmente avec le nombre de licences utilisateur. L’offre gratuite de HubSpot répond aux besoins jusqu’au jour où elle ne suffit plus ; le passage à une formule payante représente alors une hausse substantielle du coût. Salesforce opère dans une catégorie entièrement différente : c’est un logiciel d’entreprise tarifé en conséquence, nécessitant des administrateurs dédiés pour le configurer et le maintenir. Pour un cabinet de conseil gérant quelques centaines de contacts et une poignée d’opportunités commerciales actives, aucune de ces structures tarifaires n’est particulièrement avantageuse.

Mais le calcul des coûts ne concerne pas uniquement les frais d’abonnement. Il y a aussi la question de ce que vous achetez réellement.

Le problème de la dépendance au fournisseur

Les fournisseurs de CRM SaaS vendent de la commodité. En échange, ils restent dépositaires de vos données, le contrôle sur l’interface, et la capacité de modifier la tarification à leur discrétion. Ce n’est pas une observation controversée — c’est le modèle. Salesforce a augmenté ses prix plusieurs fois. HubSpot a restructuré l’accès aux fonctionnalités selon les formules. Pipedrive a remanié et renommé sa gamme de formules. Chacune de ces décisions relève pleinement des droits du fournisseur, et chacune crée des frictions pour les clients qui ont construit leurs flux de travail sur les conditions précédentes.

La question de la portabilité des données est plus importante que la plupart des discussions ne le reconnaissent. Chaque CRM majeur offre une fonctionnalité d’exportation, généralement en CSV. Mais un export CSV de vos données de contact n’est pas la même chose que vos données CRM. Les relations entre contacts et entreprises, l’historique des activités, la chronologie des opportunités commerciales, les champs personnalisés — ces éléments sont rarement préservés correctement lors d’un export. En pratique, migrer d’un CRM SaaS signifie reconstruire une partie significative de votre historique opérationnel à partir de zéro. Les données sont techniquement les vôtres, mais les récupérer sous une forme utilisable nécessite un effort substantiel.

Twenty CRM et l’option d’auto-hébergement

Twenty (twenty.com) est un CRM open source qui s’est imposé comme une alternative sérieuse aux offres commerciales. Le code est activement développé, le modèle de données est bien structuré, et l’interface est véritablement utilisable. Il tourne sur PostgreSQL, ce qui signifie que les outils de base de données standard s’appliquent directement. Le projet n’est pas un dépôt de code amateur — il dispose d’une équipe financée derrière lui et d’une feuille de route claire.

Nous l’avons déployé sur notre infrastructure Hetzner existante, la même instance CX53 qui héberge notre site web et d’autres services derrière Traefik. La configuration Docker Compose fournie par Twenty est simple. Les services principaux sont le serveur API, le frontend, la base de données PostgreSQL et Redis pour la mise en cache et la gestion des files d’attente. La charge totale en ressources pour une petite équipe est modeste : la pile logicielle consomme moins de 2 Go de RAM au repos.

Le processus de configuration a pris environ deux heures, incluant la configuration DNS et la terminaison SSL via notre proxy inverse Traefik existant. La documentation Twenty couvre clairement la procédure de déploiement Docker. Les variables d’environnement sont bien documentées, les contrôles de bon fonctionnement donnent les résultats attendus, et la migration initiale des données s’exécute automatiquement au premier démarrage. Il n’y a pas eu d’obstacles significatifs.

Ce que l’analyse des coûts montre réellement

Faire tourner Twenty auto-hébergé sur une infrastructure que nous exploitons déjà n’entraîne pratiquement aucun coût supplémentaire. Sur une infrastructure dédiée, le coût est la facture mensuelle du serveur. Notre Hetzner CX53 tourne à environ 30 € par mois et héberge plusieurs services — le CRM est un locataire dans un environnement partagé, pas la raison d’être du serveur.

Comparez cela aux alternatives SaaS courantes (tarifs catalogue en octobre 2026). Pipedrive coûte 14 à 79 $ par licence utilisateur par mois avec une facturation annuelle, selon le niveau. Pour une équipe de trois personnes, c’est 42 à 237 $ par mois, soit 504 à 2 844 $ par an. Sales Hub Professional de HubSpot, qui débloque l’automatisation et les rapports personnalisés, coûte 90 $ par licence utilisateur par mois avec une facturation annuelle, auxquels s’ajoutent des frais uniques d’intégration de 1 500 $. Starter Suite de Salesforce — le point d’entrée — coûte 25 $ par utilisateur par mois, mais les fonctionnalités dont la plupart des équipes commerciales ont réellement besoin se trouvent dans Pro Suite à 100 $ par utilisateur par mois.

Aucun de ces chiffres n’est déraisonnable pour les grandes organisations commerciales où l’adoption du CRM génère directement une valeur mesurable dans le portefeuille d’opportunités commerciales. Mais pour un cabinet de conseil technique où le CRM est principalement une base de données de contacts et un historique des missions, le calcul est différent. La charge opérationnelle d’un déploiement auto-hébergé se mesure en heures par an, pas par semaine. Le seuil de rentabilité est atteint rapidement.

La propriété des données en pratique

Lorsque vos données CRM résident dans une base de données PostgreSQL que vous contrôlez, les implications opérationnelles sont concrètes. Les sauvegardes sont des exports de base de données standard — nous exécutons des exports pg_dump quotidiens automatisés vers Hetzner Object Storage, conservés 30 jours avec des instantanés mensuels conservés un an. Les requêtes sont illimitées. Vous pouvez joindre les tables CRM à vos propres données, créer des rapports personnalisés directement à partir du schéma brut, ou transmettre les données de contact à d’autres systèmes internes sans limites de débit d’exportation ni quotas d’appels API.

Cela importe plus qu’il n’y paraît au premier abord. Les CRM SaaS imposent des limites de débit de l’API qui deviennent des contraintes architecturales à grande échelle. Dans les formules Free et Starter de HubSpot, les applications privées partagent une limite de 250 000 requêtes par jour et de 100 requêtes par tranche de 10 secondes (en octobre 2026). Les limites de Pipedrive varient selon la formule. Lorsque vous devez synchroniser les données CRM avec des systèmes externes — outils de facturation, gestion de projet, tableaux de bord personnalisés — ces limites définissent ce qui est architecturalement faisable. Avec une base de données PostgreSQL auto-hébergée, il n’y a pas de quota imposé par le fournisseur ; les contraintes pratiques deviennent la capacité du serveur, vos propres contrôles d’accès et le maintien de la compatibilité des intégrations avec le schéma de Twenty au fil de son évolution.

Il y a aussi la question de ce qui arrive à vos données si le fournisseur est acquis, modifie ses conditions, ou cesse ses activités. La probabilité de tels événements est faible pour les grands fournisseurs, mais elle n’est pas nulle. Posséder vos données signifie maîtriser le modèle de risque, plutôt que de le déléguer.

Personnalisation sans partenaire de développement

Twenty est construit sur une API GraphQL avec un modèle de données piloté par les métadonnées. L’ajout de champs personnalisés à n’importe quelle entité prend quelques secondes dans l’interface — vous définissez le type de champ, il apparaît immédiatement dans l’interface et dans le schéma API. Pas d’exports de configuration, pas de déploiements dans un environnement de test isolé, pas de tickets d’assistance, pas de passage à une formule supérieure.

C’est qualitativement différent de ce qu’offrent les CRM SaaS. Salesforce permet une personnalisation étendue, mais le modèle de personnalisation est suffisamment complexe pour faire vivre tout un secteur de services professionnels. Pipedrive permet des champs personnalisés sur la plupart des objets, mais la personnalisation de l’interface est limitée. Les capacités de personnalisation de HubSpot dépendent fortement de la formule à laquelle vous souscrivez.

L’approche Twenty — schéma ouvert, contrôle local — signifie que lorsqu’une mission nécessite de suivre des informations que le modèle de données par défaut ne couvre pas, vous l’étendez directement. Pour un cabinet de conseil qui doit parfois suivre des structures d’opportunités commerciales inhabituelles ou des métadonnées spécifiques au client, cette flexibilité s’est révélée véritablement utile.

Stratégie de sauvegarde

Notre configuration de sauvegarde est intentionnellement simple. Un pg_dump automatisé quotidien de la base de données PostgreSQL Twenty, compressé et téléversé vers Hetzner Object Storage. Les données d’application — images de profil, pièces jointes — résident dans un volume Docker sauvegardé via restic selon le même calendrier. La rétention est de 30 jours pour les instantanés quotidiens, 12 mois pour les instantanés mensuels.

Les tests de récupération s’exécutent trimestriellement : restaurer la sauvegarde dans une base de données de préproduction, vérifier le nombre de lignes, contrôler ponctuellement l’intégrité des données. Une restauration complète depuis la sauvegarde vers une instance Twenty opérationnelle prend environ 15 minutes — acceptable pour un outil qui n’est pas sur le chemin critique des opérations en temps réel. Hetzner Object Storage coûte 6,49 € par mois (hors TVA, en octobre 2026), avec 1 To de stockage inclus ; nos sauvegardes CRM consomment une petite fraction de cette allocation.

La discipline opérationnelle requise ici est modeste. Les opérations de sauvegarde s’exécutent comme des tâches cron sur l’hôte, journalisent leurs résultats dans un système de supervision, et alertent en cas d’échec. C’est une pratique d’infrastructure standard que toute équipe gérant des charges de travail serveur devrait déjà avoir en place.

Quand l’auto-hébergement a du sens

L’argument en faveur de l’auto-hébergement d’un CRM est le plus fort lorsque plusieurs conditions s’alignent. Votre équipe a une véritable capacité opérationnelle pour exécuter des conteneurs Docker et gérer une base de données PostgreSQL — c’est un prérequis réel, pas une formalité. Vous exploitez déjà une infrastructure serveur avec de la capacité disponible. Votre cas d’usage CRM est relativement stable, c’est-à-dire que vous ne dépendez pas de la feuille de route du fournisseur pour des fonctionnalités dont vous aurez besoin dans le trimestre à venir.

Les arguments sur les coûts et la propriété des données sont réels, mais ils sont secondaires par rapport à la question de la capacité opérationnelle. L’auto-hébergement échange de l’argent contre du temps et de l’expertise. Si le temps opérationnel de votre équipe est plus coûteux qu’un abonnement SaaS, le calcul économique peut ne pas justifier le changement. Le seuil de rentabilité n’est pas purement financier — c’est aussi une fonction des compétences et de la disponibilité réelles de votre équipe.

Quand l’auto-hébergement n’est pas adapté

Si votre organisation a besoin d’intégrations poussées avec les systèmes de l’entreprise — un CRM connecté à une plateforme d’automatisation marketing, une plateforme de données clients (CDP) et un entrepôt de données, tous maintenus par une fonction RevOps dédiée — l’auto-hébergement n’est pas la bonne solution. L’écosystème d’intégration autour des CRM commerciaux est riche parce que les fournisseurs ont investi des années à le construire. Une instance Twenty auto-hébergée se connecte via son API GraphQL ou un accès direct à la base de données. Elle n’a pas une bibliothèque de 500 connecteurs prêts à l’emploi.

De même, si personne dans votre équipe ne peut diagnostiquer un conteneur Docker défaillant, lire des journaux PostgreSQL, ou restaurer depuis une sauvegarde de base de données, la charge opérationnelle dépassera rapidement les économies de coûts. L’auto-hébergement nécessite un socle de compétences en infrastructure que toutes les équipes n’ont pas — et acquérir cette compétence a un coût en soi.

Les exigences de conformité peuvent également modifier l’équation. Si votre entreprise opère sous des réglementations qui nécessitent une gestion certifiée des données de la part des fournisseurs de technologie — attestations SOC 2, audits ISO 27001 — un déploiement auto-hébergé signifie que vous ne pouvez pas vous appuyer sur l’attestation d’un fournisseur de CRM ; le CRM entre dans le périmètre de vos propres contrôles et audits. Que ce soit un avantage ou une charge dépend de votre posture de conformité existante.

Ce que nous exploitons réellement

Notre déploiement Twenty en production fonctionne depuis plusieurs mois sans incident significatif. La gestion des contacts, les fiches d’entreprises, le suivi des opportunités commerciales et la journalisation des activités fonctionnent tous comme prévu. L’interface est suffisamment claire pour que la prise en main n’ait nécessité aucune formation formelle. L’API GraphQL s’est révélée utile pour extraire le contexte CRM dans d’autres outils internes — spécifiquement pour la production de rapports clients et le suivi des missions, des outils que nous construisons nous-mêmes plutôt que d’acheter sous forme de module SaaS complémentaire.

La maintenance est inférieure à ce qui était anticipé. Twenty publie des mises à jour à un rythme régulier ; les déployer consiste à télécharger la nouvelle image Docker et redémarrer le service, généralement en moins de cinq minutes. La base de données PostgreSQL n’a nécessité aucune intervention manuelle au-delà de la vérification de routine des sauvegardes.

La décision n’était pas idéologique. Nous n’avons pas quitté le CRM SaaS parce que le SaaS est intrinsèquement mauvais ou parce que l’auto-hébergement est intrinsèquement vertueux. La décision était opérationnelle : pour notre cas d’usage spécifique, la solution auto-hébergée est plus simple, moins cher, et nous donne un meilleur contrôle sur des données qui nous appartiennent. Pour une organisation avec des contraintes différentes — une équipe commerciale plus grande, des exigences d’intégration plus poussées, ou une capacité d’infrastructure limitée — la conclusion pourrait être différente. L’essentiel est de faire le calcul explicitement plutôt que de se rabattre par défaut sur le modèle d’abonnement parce que c’est le chemin de moindre résistance.