CRM open source PME : alternative au SaaS rigide

Un dirigeant de PME qui cherche un CRM en 2026 tombe vite dans un choix inconfortable.

D'un côté, il y a les SaaS classiques : HubSpot, Pipedrive, Salesforce et tous les outils qui promettent de structurer la vente, le marketing et le support. Ce sont des produits puissants, mûrs, documentés. Mais dans beaucoup de PME de 5 à 50 salariés, ils finissent aussi par devenir chers, rigides et dépendants d'une personne qui sait où cliquer.

De l'autre côté, il y a la tentation du vibe-coding : demander à un collaborateur débrouillard, à un freelance ou à un agent de code de "faire notre CRM sur mesure". La promesse est séduisante. Un outil qui colle exactement au métier, sans abonnement lourd, sans menus inutiles, sans tunnel commercial. Le problème, c'est que le CRM n'est pas une petite app isolée. C'est souvent le coeur de la relation client. S'il casse, s'il perd des données, s'il gère mal les droits ou s'il ne tient pas dans le temps, l'entreprise le paie immédiatement.

Je crois de plus en plus à une troisième voie : partir d'un socle open source solide, puis le personnaliser avec du code assisté par IA, des automatisations et des agents, mais sans repartir d'une page blanche.

C'est ce que j'ai déployé sur un projet client autour de Twenty CRM : un CRM open source, auto-hébergeable, prolongé par des workflows n8n, des agents IA et des assistants métier comme OpenClaw ou Hermes. Je ne vais pas donner de nom client ni de chiffres internes. L'idée de cet article est plutôt de partager la grille de décision : quand garder un SaaS, quand éviter le vibe-coding pur, et quand construire sur un socle open source devient le meilleur compromis.

Pourquoi le sujet arrive maintenant

Le débat n'est pas seulement technique. Il est aussi économique.

Au 2 juin 2026, HubSpot reste une très belle entreprise. Son communiqué Q1 2026 indique une croissance de chiffre d'affaires de 23 % en publié par rapport à Q1 2025, 299 458 clients au 31 mars 2026 et une plateforme désormais présentée comme "agentic customer platform". Autrement dit, la baisse du cours de Bourse ne raconte pas une entreprise qui s'effondre.

Mais elle raconte quelque chose.

Le 29 mai 2026, le lookup historique de HubSpot affichait une clôture à 220,63 dollars. Barchart indiquait de son côté un plus haut 52 semaines à 611,00 dollars, atteint le 5 juin 2025, et une performance sur 52 semaines d'environ -55,55 % depuis le 30 mai 2025. Même si les chiffres de marché varient selon les sources, l'ordre de grandeur est clair : le marché revalorise brutalement certains SaaS.

Je ne lis pas ça comme "HubSpot ne sert plus à rien". Ce serait simpliste.

Je le lis plutôt comme un signal : les investisseurs doutent de plus en plus de la capacité des SaaS généralistes à capturer autant de valeur quand l'IA, les agents et le code assisté rendent les logiciels métier plus faciles à personnaliser. Si une PME peut connecter son CRM à ses workflows, générer ses propres agents et adapter son outil à son processus réel, elle accepte moins facilement de payer très cher pour une usine à gaz qu'elle n'utilise qu'à moitié.

La question devient donc très concrète : faut-il encore acheter un gros SaaS, construire son propre outil, ou assembler une solution plus souveraine sur un socle open source ?

Modèle 1 : le SaaS classique

Le SaaS classique reste souvent le bon choix quand l'entreprise veut aller vite, réduire le risque technique et utiliser des fonctionnalités déjà prêtes.

HubSpot, Pipedrive ou Salesforce apportent des choses très utiles :

une interface éprouvée,
des intégrations nombreuses,
des rôles et permissions,
un support,
une documentation,
des connecteurs marketing, vente et support,
des tableaux de bord,
une certaine rassurance pour les équipes.

Pour une PME qui n'a aucun CRM, prendre un SaaS peut être beaucoup mieux que rester dans Excel, Notion, Gmail et la mémoire des commerciaux. Je ne veux pas faire semblant du contraire.

Le problème arrive après la mise en place.

Au début, on configure quelques pipelines, des champs, des listes, des séquences et des automatisations. Puis l'entreprise évolue. Les canaux se multiplient. WhatsApp, formulaires, appels, emails, devis, factures, relances, support, enrichissement, reporting. Les exceptions métier s'accumulent. Les commerciaux contournent l'outil. Les données se dupliquent. Les automatisations ne sont plus comprises par personne.

À ce moment-là, le SaaS devient rarement "simple". Il devient une spécialité.

Il faut alors un CRM manager interne, un administrateur HubSpot, un consultant Salesforce, un partenaire certifié, un freelance ou une agence. Ce n'est pas absurde. Mais pour une PME de 5 à 50 salariés, cela peut créer une dépendance lourde : l'outil appartient juridiquement à l'éditeur, mais opérationnellement à la seule personne qui comprend sa configuration.

Le coût n'est donc pas seulement l'abonnement. Le vrai coût total inclut :

le temps passé à configurer,
les licences par utilisateur,
les options nécessaires pour automatiser,
les prestations de mise en place,
les changements de plan,
les intégrations payantes,
la dette de configuration,
les contournements que les équipes inventent quand l'outil ne suit plus le terrain.

Le SaaS classique reste pertinent. Mais il ne faut plus le choisir par réflexe.

Modèle 2 : le CRM vibe-codé de zéro

Le deuxième modèle est la réaction inverse : "On va se faire notre CRM nous-mêmes."

Avec Codex, Claude Code, Cursor, Windsurf ou d'autres environnements, produire une première version d'outil métier est devenu beaucoup plus accessible. Un bon brief, quelques écrans, une base de données, une authentification, deux ou trois automatisations, et l'on peut obtenir une démo impressionnante en quelques jours.

Pour prototyper, c'est formidable.

Pour gérer la relation client d'une entreprise, c'est plus dangereux.

Un CRM n'est pas seulement une interface avec des fiches contacts et des opportunités. C'est un système de vérité. Il doit savoir :

qui peut voir quoi,
qui peut modifier quoi,
comment éviter les doublons,
comment tracer les changements,
comment importer et exporter les données,
comment gérer les erreurs d'automatisation,
comment sécuriser les secrets API,
comment sauvegarder et restaurer,
comment absorber plusieurs utilisateurs en même temps,
comment garder un historique fiable,
comment évoluer quand le processus commercial change.

Le vibe-coding pur sous-estime souvent ces sujets, parce que la démo ne les montre pas.

La première version semble marcher. Puis les problèmes de séquencement arrivent : un webhook se déclenche deux fois, une relance part avant la mise à jour du statut, un agent crée une note sur le mauvais contact, une tâche reste bloquée, une opportunité change de pipeline sans que personne ne comprenne pourquoi.

Ensuite viennent les problèmes de sécurité. Qui a accès à la base ? Où sont les clés API ? Les logs contiennent-ils des données client ? Les rôles sont-ils réellement appliqués côté serveur ou seulement masqués dans l'interface ? Que se passe-t-il si un ancien salarié garde un accès ?

Enfin, il y a la maintenance. Le code généré vite peut devenir difficile à reprendre. Les prompts initiaux disparaissent. Les conventions ne sont pas documentées. Le collaborateur qui avait "vibe-codé le CRM" change de poste. Le freelance n'est plus disponible. L'agent de code peut aider, mais il ne remplace pas une architecture claire.

Le vibe-coding n'est donc pas le problème. Le problème est de le confondre avec une stratégie produit.

Modèle 3 : socle open source, personnalisation IA, production maîtrisée

La troisième voie consiste à ne pas choisir entre outil fermé et bricolage complet.

On part d'un produit open source qui a déjà résolu une partie des problèmes difficiles : interface, modèle de données, authentification, permissions, API, composants CRM, logique d'objets, vues, workflows, déploiement. Puis on le personnalise là où l'entreprise a vraiment besoin de différenciation.

Twenty est un bon exemple de ce mouvement.

La documentation présente Twenty comme une troisième option entre un logiciel facile à démarrer mais difficile à changer, et un logiciel flexible mais long à mettre en place. Le projet met en avant un coeur open source, l'auto-hébergement, l'export des données et une architecture que des équipes techniques peuvent étendre en React, TypeScript et PostgreSQL. La documentation self-hosting insiste aussi sur la propriété des données, la conformité liée à la résidence des données et la personnalisation.

Ce n'est pas magique. C'est précisément pour ça que c'est intéressant.

Avec un socle comme Twenty, on ne redéveloppe pas un CRM de zéro. On utilise une base existante, puis on personnalise :

les objets métier,
les vues utiles à l'équipe,
les champs vraiment nécessaires,
les automatisations entre CRM, devis, facturation et messagerie,
les agents IA qui préparent les actions,
les notifications de validation,
les scripts d'import et de nettoyage,
les connecteurs avec les outils existants.

Dans le projet client auquel je fais référence, l'intérêt n'était pas d'avoir "un CRM de plus". L'intérêt était de relier le CRM à un système de travail complet : automatisations, agents IA, assistant interne, logique de suivi commercial et capacité de faire évoluer l'outil sans attendre qu'un éditeur ajoute le bon bouton.

C'est exactement le type d'architecture que je décrivais déjà dans mon retour d'expérience sur l'analyse d'appels commerciaux avec n8n et Twenty CRM. Le CRM devient une base opérationnelle. La valeur se crée dans les flux autour : transcription, scoring, notes, messages, relances, enrichissement, validation et reporting.

Le bon tableau de décision pour une PME

Le choix ne dépend pas d'une préférence idéologique pour le SaaS ou l'open source. Il dépend du contexte de l'entreprise.

Critère	SaaS classique	CRM vibe-codé de zéro	Socle open source personnalisé
Démarrage	Rapide si le besoin est standard	Très rapide en prototype	Moyen, car il faut cadrer et déployer
Coût initial	Souvent lisible, parfois sous-estimé	Faible en apparence	Projet à cadrer sérieusement
Coût moyen terme	Licences, options, consultants	Maintenance imprévisible	Infra, maintenance, évolutions ciblées
Personnalisation	Forte dans le cadre prévu	Totale, mais risquée	Forte sur une base déjà structurée
Sécurité	Mûre côté éditeur	À construire	À opérer proprement
Données	Chez l'éditeur	Chez vous si bien conçu	Chez vous en self-hosting
Maintenance	Dépend de l'éditeur et des admins	Dépend du code produit	Dépend du socle et de votre intégrateur
Scalabilité PME	Bonne, mais parfois chère	Incertaine	Bonne si l'architecture est pensée
Agents IA	De plus en plus intégrés	Tout est possible, donc tout est à sécuriser	Agents connectés à un modèle existant

En pratique, je recommanderais souvent :

SaaS si le processus commercial est standard, si l'équipe veut peu de technique et si le budget licences ne pose pas de problème.
Prototype vibe-codé si l'entreprise veut tester une idée, valider un workflow ou créer un outil interne non critique.
Socle open source personnalisé si le CRM devient un actif métier, si la donnée doit rester maîtrisée, si les workflows sont spécifiques et si l'entreprise accepte d'être accompagnée sérieusement.

La dernière condition est importante. Un CRM open source personnalisé n'est pas un raccourci pour éviter la compétence. C'est un moyen de mieux investir cette compétence.

Ce qu'il faut absolument cadrer avant de construire

Avant de toucher à l'outil, je poserais cinq questions.

1. Quel est le vrai processus commercial ?

Pas le pipeline rêvé. Le vrai.

D'où viennent les leads ? Qui les qualifie ? Où sont les échanges ? Quand crée-t-on une opportunité ? Quand prépare-t-on un devis ? Qui valide une remise ? Quand relance-t-on ? Quand une opportunité est-elle perdue ? Quelles informations doivent absolument être fiables ?

Un CRM personnalisé mal cadré reproduira le désordre existant avec une meilleure interface.

2. Quelle donnée doit devenir fiable ?

Toutes les données n'ont pas la même valeur.

Dans une PME, je préfère identifier quelques objets critiques : contacts, entreprises, opportunités, devis, appels, messages, tâches, factures, statuts. Puis décider ce qui doit être contrôlé, dédupliqué, enrichi, historisé et synchronisé.

Le but n'est pas d'avoir beaucoup de champs. Le but est d'avoir les bons champs, utilisés par les bons workflows.

3. Quelles actions l'agent IA peut-il faire ?

Un agent connecté au CRM peut être très utile. Il peut résumer un appel, préparer une note, proposer une relance, détecter une opportunité chaude, créer une tâche, préremplir un devis ou signaler une incohérence.

Mais il ne doit pas tout faire seul.

J'appliquerais la même logique que dans l'article sur la validation humaine des agents IA en production : l'agent peut lire et préparer beaucoup de choses, mais les actions qui engagent l'entreprise doivent passer par des seuils, des permissions et parfois une approbation humaine.

4. Qui opère le self-hosting ?

L'auto-hébergement n'est pas seulement "mettre Docker sur un serveur".

Il faut gérer :

les mises à jour,
les sauvegardes,
la restauration,
les variables d'environnement,
les clés API,
le monitoring,
les logs,
les accès administrateurs,
les certificats,
les alertes,
le plan de retour arrière.

Sur une stack comme Hetzner, Coolify et n8n, c'est tout à fait accessible pour une PME bien accompagnée. Mais il faut l'assumer comme une responsabilité de production.

5. Quel est le plan de réversibilité ?

La promesse de l'open source et du self-hosting n'a de valeur que si l'entreprise peut réellement sortir ses données.

Avant de déployer, je veux savoir :

comment exporter les contacts,
comment exporter les opportunités,
comment récupérer l'historique,
comment documenter les champs personnalisés,
comment reconstruire l'environnement,
comment reprendre le projet si je ne suis plus là demain.

C'est un sujet de confiance. Une PME ne doit pas remplacer un lock-in SaaS par un lock-in prestataire.

Ma valeur ajoutée dans ce modèle

Le sujet n'est pas seulement de "connaître Twenty".

Un CRM manager classique peut être excellent pour configurer un outil, nettoyer des pipelines, former les commerciaux et mettre de l'ordre dans les données. C'est un vrai métier. Mais le modèle open source personnalisé demande aussi d'autres compétences.

Il faut savoir parler au dirigeant de processus commercial, puis parler au serveur de déploiement, puis parler au CRM via API, puis parler à l'agent IA, puis parler à l'équipe qui devra utiliser l'outil tous les jours.

C'est là que mon positionnement apporte quelque chose de différent.

Je peux prendre le problème comme un système complet :

cadrage métier avec le dirigeant,
choix entre SaaS, open source et développement spécifique,
self-hosting sécurisé quand il est pertinent,
connexion aux workflows n8n,
intégration d'agents IA,
garde-fous de validation humaine,
documentation de reprise,
amélioration progressive avec le code assisté par IA.

OpenClaw et Hermes s'insèrent bien dans cette logique. Un assistant OpenClaw peut donner aux équipes une interface de travail plus naturelle au-dessus des outils. Un agent Hermes peut orchestrer des actions plus avancées, avec les bons garde-fous. Mais la valeur n'est pas l'agent en lui-même. La valeur est le système dans lequel il agit : données propres, droits maîtrisés, actions traçables, validations claires.

Autrement dit, je ne vends pas "un CRM vibe-codé". Je construis une base opérationnelle que l'entreprise peut comprendre, utiliser et faire évoluer.

Les erreurs à éviter

La première erreur est de choisir l'open source uniquement pour réduire la facture. C'est rarement le bon angle. Oui, le coût moyen terme peut être inférieur à un gros SaaS dans certains cas. Mais seulement si l'architecture est simple, documentée et maintenue. Sinon, la facture se déplace simplement de la licence vers le chaos.

La deuxième erreur est de tout personnaliser trop tôt. Un socle open source donne envie de modifier beaucoup de choses. Il faut résister. Je préfère commencer par les flux qui créent vraiment de la valeur : capture de leads, qualification, suivi des opportunités, notes automatiques, relances, devis, reporting.

La troisième erreur est de négliger l'adoption. Un CRM très bien conçu qui n'est pas utilisé ne sert à rien. Les commerciaux doivent gagner du temps. Le dirigeant doit mieux voir. L'administratif doit moins ressaisir. Si l'outil demande plus d'effort que l'ancien bricolage, il sera contourné.

La quatrième erreur est de laisser l'agent IA agir sans journal. Chaque action importante doit être traçable : source, décision, données utilisées, résultat, éventuelle validation. C'est indispensable pour la confiance.

La cinquième erreur est de confondre propriétaire et souverain. Avoir le code et le serveur ne suffit pas. Il faut aussi comprendre l'architecture, documenter les choix, maîtriser les accès et savoir restaurer les données.

Par quoi commencer

Pour une PME qui se pose la question aujourd'hui, je ne commencerais pas par "quel CRM choisir ?".

Je commencerais par un audit court :

Cartographier le cycle commercial réel.
Lister les outils déjà utilisés.
Identifier les données qui circulent entre formulaire, email, téléphone, devis, facture et support.
Repérer les doublons, ressaisies et points de rupture.
Classer les actions selon leur risque.
Décider ce qui mérite un SaaS standard, une automatisation ou un socle open source.
Construire un premier périmètre limité, utilisable en production.

Le bon premier projet n'est pas "remplacer tout HubSpot". C'est souvent :

centraliser les contacts et opportunités,
automatiser la création de notes depuis les appels ou messages,
préparer les relances,
connecter le CRM à l'outil de devis,
mettre en place un assistant interne qui retrouve les informations,
ajouter une validation humaine avant les actions sensibles.

Puis seulement ensuite, on élargit.

C'est la même logique que pour l'automatisation de workflows : on ne cherche pas le grand soir logiciel. On construit une boucle fiable, on mesure l'adoption, on corrige, puis on ajoute une couche.

Sources consultées

Sources consultées le 2 juin 2026 :

Conclusion

Le SaaS n'est pas mort. Le vibe-coding n'est pas magique. L'open source n'est pas gratuit au sens opérationnel.

Mais quelque chose change vraiment.

Pendant des années, une PME devait choisir entre un logiciel standard trop rigide et un développement spécifique trop lourd. Les agents de code, les CRM open source modernes et les plateformes d'automatisation rendent possible un troisième modèle : partir d'une base solide, puis l'adapter précisément au métier.

Ce modèle demande plus de responsabilité qu'un SaaS prêt à l'emploi. Il demande du cadrage, de la sécurité, du self-hosting, des sauvegardes, des droits, des tests, des validations et une vraie documentation. Mais en échange, l'entreprise récupère quelque chose de précieux : un outil qui n'est pas seulement loué, mais compris.

Pour une PME de 5 à 50 salariés, c'est souvent là que se trouve la meilleure décision : ne pas construire un CRM de zéro, ne pas subir une usine à gaz, mais créer une base commerciale personnalisable, connectée aux workflows réels et prête pour les agents IA.

Si vous réfléchissez à sortir d'un SaaS trop rigide, à structurer votre CRM ou à connecter Twenty, n8n, OpenClaw ou Hermes à vos processus commerciaux, c'est exactement le type de chantier que je prends en charge côté agents IA et automatisation de workflows. L'objectif n'est pas de faire une belle démo. L'objectif est de construire un système que votre équipe peut utiliser lundi matin.