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 monte en flèche par siège. Le niveau gratuit de HubSpot est fonctionnel jusqu'au moment où il ne l'est plus, à quel point le passage à un plan payant est substantiel. 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 de deals actifs, aucune de ces structures tarifaires n'est particulièrement efficiente.

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 l'enfermement

Les fournisseurs de CRM SaaS vendent de la commodité. En échange, ils conservent la garde 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é le bridage des fonctionnalités entre ses niveaux. Pipedrive a introduit des minimums de sièges sur des plans qui n'en avaient pas auparavant. Chacun de ces mouvements est entièrement dans les droits du fournisseur, et chacun crée des frictions pour les clients qui ont construit leurs workflows 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, les chronologies des deals, les champs personnalisés — ceux-ci survivent rarement proprement à 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 hobby — 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. La charge totale en ressources pour une petite équipe est modeste : la stack 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 le chemin de déploiement Docker. Les variables d'environnement sont bien documentées, les healthchecks fonctionnent comme prévu, 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à ne coûte effectivement rien en termes incrémentaux. 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'existence du serveur.

Comparez cela aux alternatives SaaS courantes. Pipedrive coûte 24 à 67 $ par siège par mois selon le niveau. Pour une équipe de trois personnes, c'est 72 à 201 $ par mois, soit 864 à 2 412 $ par an. Le niveau Professional de HubSpot, qui débloque l'automatisation et le reporting personnalisé, coûte 800 $ par mois pour cinq sièges. Salesforce Essentials — le point d'entrée — commence à 25 $ par siège par mois, mais les fonctionnalités dont la plupart des équipes commerciales ont réellement besoin se trouvent au niveau Professional à 75 $ par siège.

Aucun de ces chiffres n'est déraisonnable pour les grandes organisations commerciales où l'adoption du CRM génère directement une valeur de pipeline mesurable. Mais pour un cabinet de conseil technique où le CRM est principalement une base de données de contacts et un historique d'engagement, 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 dumps 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 snapshots mensuels retenus un an. Les requêtes sont illimitées. Vous pouvez joindre les tables CRM à vos propres données, construire des rapports personnalisés contre le schéma brut, ou alimenter les données de contact dans d'autres systèmes internes sans limites de taux 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 taux API qui deviennent des contraintes architecturales à grande échelle. Le niveau gratuit de HubSpot limite les requêtes à 500 par jour. Les limites de Pipedrive varient selon le plan. 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, la seule contrainte est la capacité du serveur.

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. Ce sont des événements à faible probabilité pour les grands fournisseurs, mais non nulle. Posséder vos données signifie posséder le modèle de risque, et non 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'UI et dans le schéma API. Pas d'exports de configuration, pas de déploiements sandbox, pas de tickets de support, pas de mise à niveau de niveau requise.

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 soutenir toute une industrie de services professionnels autour de lui. 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 du plan que vous payez.

L'approche Twenty — schéma ouvert, contrôle local — signifie que lorsqu'un engagement 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 de deals 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échargé 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 snapshots quotidiens, 12 mois pour les snapshots mensuels.

Les tests de récupération s'exécutent trimestriellement : restaurer la sauvegarde dans une base de données de staging, vérifier les comptages 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 € par mois pour 1 To ; nos sauvegardes CRM consomment une petite fraction de cette allocation.

La discipline opérationnelle requise ici est modeste. Les jobs de sauvegarde s'exécutent comme des tâches cron sur l'hôte, journalisent leurs résultats dans un système de monitoring, 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, l'économie peut ne pas favoriser le changement. Le seuil de rentabilité n'est pas purement financier — c'est aussi une fonction des compétences et de la bande passante réelles de votre équipe.

Quand ça ne l'est pas

Si votre organisation a besoin d'intégrations d'entreprise profondes — un CRM connecté à une plateforme d'automatisation marketing, un CDP et un data warehouse, tous maintenus par une fonction RevOps dédiée — l'auto-hébergement est la mauvaise direction. 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éconstruits.

De même, si personne dans votre équipe ne peut diagnostiquer un conteneur Docker défaillant, lire des logs PostgreSQL, ou restaurer depuis une sauvegarde de base de données, la charge opérationnelle dépassera rapidement les économies de coûts. Le chemin d'auto-hébergement nécessite un niveau de base de compétence 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 ces certifications doivent s'appliquer à votre propre infrastructure. 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 deals et la journalisation des activités fonctionnent tous comme prévu. L'interface est suffisamment claire pour que l'intégration 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 le reporting client et le suivi d'engagement que nous construisons nous-mêmes plutôt que d'acheter en tant qu'add-on SaaS.

La maintenance est inférieure à ce qui était anticipé. Twenty publie des mises à jour à un rythme régulier ; les déployer consiste à extraire 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, le chemin auto-hébergé 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 profondes, 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.