Twenty au-delà du CRM : le back-office de vos données métier

Si vos biens, vos projets ou vos équipements vivent dans un tableur, et les demandes de votre site dans une boîte mail, il vous manque un endroit qui fasse foi. Twenty, un CRM libre au modèle de données ouvert, peut tenir ce rôle de back-office pour vos données métier. Nous l’utilisons ainsi pour Palmora, un portail immobilier que nous opérons.

Ce guide dit ce que cet usage permet, ce qu’il demande et où il s’arrête, sans refaire notre retour d’exploitation de Twenty en production ni notre comparatif entre Twenty, Dolibarr et Odoo.

En bref

• Twenty laisse créer ses propres objets, champs et relations : un bien, un projet ou un dossier y devient un objet à part entière, pas une opportunité détournée.
• Chaque objet créé est aussitôt accessible par l’API : votre site le lit, et les demandes des visiteurs y reviennent.
• L’usage tient si le modèle est pensé avant la saisie, si les échanges sont surveillés et si quelqu’un répond de l’outil.
• Ce n’est ni un ERP, ni une comptabilité, ni une gestion de stock, et une fois auto-hébergé, ses sauvegardes et ses mises à jour sont à votre charge.

Pourquoi un CRM peut-il servir de back-office ?

Un back-office de données métier, c’est l’endroit où l’équipe tient à jour les données de référence de l’activité, et d’où les autres outils les lisent. On le monte souvent avec un tableur partagé, une base sur mesure ou un CMS. Un CRM au modèle ouvert a sur eux un avantage : les contacts et les données métier vivent au même endroit, reliés entre eux.

La documentation du modèle de données de Twenty part des objets standard (personnes, entreprises, opportunités, notes, tâches) et prévoit des objets personnalisés pour le reste, comme des projets, des abonnements ou des événements. Sa page des fonctionnalités ajoute ce qu’un tableur ne donne pas : plus de vingt types de champs, des relations entre objets, des vues en tableau, en kanban ou en calendrier, l’import avec détection des doublons et l’export à tout moment. Les droits d’accès se règlent par rôle ; les descendre jusqu’à la fiche demande l’offre payante Organization, selon la page tarifaire de Twenty.

Quels objets mettre dans Twenty en dehors des contacts ?

Tout ce que votre équipe nomme, suit dans le temps et relie à des personnes. Quelques exemples :

La règle : un objet par chose que l’équipe nomme, et une relation chaque fois qu’on dit « le bien de ce propriétaire » ou « les interventions sur cette machine ». La documentation de Twenty le conseille pour les produits vendus : en faire un objet à part permet d’en gérer un, deux ou cent sans changer le modèle.

Ce n’est pas qu’un argument d’éditeur : plusieurs avis d’utilisateurs publiés sur Product Hunt, consultés le 4 octobre 2026, saluent la liberté de façonner l’outil autour de leur équipe plutôt que l’inverse. C’est le premier travail de notre offre CRM : un paramétrage dans votre vocabulaire, relié à votre site.

Comment votre site et vos outils lisent-ils ces données ?

Par l’API. Selon la documentation de l’API de Twenty, les API REST et GraphQL sont générées à partir du schéma de votre espace : un objet personnalisé y a ses accès dès sa création. Une seconde API, dite de métadonnées, modifie le schéma lui-même. Les clés ne s’affichent qu’une fois et dépendent d’un rôle, ce qui permet de limiter le site à ce qu’il doit lire.

Interroger Twenty à chaque visite rendrait le site dépendant du CRM : s’il ralentit ou s’arrête, le site aussi, et la même documentation indique une limite de 100 requêtes par minute et de 60 fiches par appel. Mieux vaut une synchronisation planifiée, qui lit les fiches publiables à heure fixe et met le site à jour.

Pour réagir sans attendre, les webhooks de Twenty signalent la création, la modification ou la suppression d’une fiche, objets personnalisés compris, avec une signature à vérifier. D’après cette documentation, une réponse en erreur est enregistrée comme un échec de livraison, sans nouvel essai décrit : le webhook déclenche, une relecture planifiée rattrape ce qui a été manqué.

Comment les demandes des visiteurs reviennent-elles dans Twenty ?

Par la même API, dans l’autre sens. Le formulaire du site envoie la demande à une petite fonction serveur, qui crée la fiche dans Twenty et la relie à la personne et à ce qui l’intéresse ; le côté site est détaillé dans notre guide sur les formulaires et la recherche sur un site statique.

Les workflows de Twenty prennent ensuite le relais. Déclenchés par un changement de fiche, un horaire, une action manuelle ou un webhook entrant, ils créent ou mettent à jour des fiches, envoient un email depuis un compte connecté ou appellent un autre service. Quand le traitement traverse plusieurs outils, un outil d’automatisation comme n8n fait le lien. Dans les deux cas, une automatisation qui échoue en silence est pire qu’une tâche manuelle, d’où notre méthode pour superviser des automatisations n8n.

Une règle ne se négocie pas : enregistrer la demande avant de notifier qui que ce soit. Si l’email échoue, la demande est quand même là.

Comment Palmora se sert-il de Twenty ?

Palmora est un portail d’annonces immobilières en Thaïlande, construit et opéré par nos soins, du site jusqu’au CRM qui reçoit les demandes. Son site Astro est servi en six langues, sur plus de 3 000 adresses. Twenty y est auto-hébergé et relié au site, et des workflows n8n l’alimentent chaque jour.

• Ce qui vit dans Twenty : la base des biens, source de vérité du site.
• Ce qui en sort : une synchronisation quotidienne vers le site, qui publie les biens automatiquement, traduits en six langues.
• Ce qui y revient : un bien déposé par un propriétaire arrive avec le statut « à valider » et une origine qui le distingue des biens rentrés par l’agence ; les demandes de recherche des visiteurs forment un objet personnalisé.

Tout passe par l’API GraphQL de Twenty. Une demande de rappel est enregistrée avant l’envoi de tout email, pour qu’un email en échec ne la fasse pas perdre, et l’équipe reçoit une alerte à chaque nouvelle demande. L’idée qui tient l’ensemble : consigner les interactions des visiteurs dans le même outil que les biens, pour mieux les traiter.

Nous faisons tourner Twenty en production pour nos clients depuis début 2025, et nous contribuons au projet open source ; les leçons d’exploitation sont dans notre retour sur Twenty en production.

Comment monter ce back-office, étape par étape ?

1. Listez les objets et leurs liens. Avant toute saisie, notez ce que l’équipe nomme et les phrases qui les relient. Un objet mal découpé se corrige plus tard, mais chaque correction touche les fiches, les vues et les intégrations.
2. Posez d’emblée les champs qui décident. Statut, origine, responsable : ils disent ce qui se publie, d’où vient une fiche et qui la traite.
3. Décidez qui lit quoi. Le site lit une copie synchronisée de ce qui est publiable, pas la base en direct, avec une clé d’API par usage et le rôle le plus étroit possible.
4. Faites revenir les demandes par l’API, enregistrées avant toute notification et reliées à la personne et à l’objet concernés.
5. Automatisez, puis surveillez. Les workflows de Twenty pour ce qui reste dans Twenty, n8n pour ce qui traverse plusieurs outils, une relecture planifiée pour rattraper un webhook manqué.
6. Nommez quelqu’un qui répond de l’outil. Il fait évoluer le modèle, applique les mises à jour et vérifie les sauvegardes.

Au-delà des réglages, Twenty permet aussi d’écrire une application, qui embarque ses propres objets, fonctions et composants d’interface.

Où cet usage s’arrête-t-il ?

Ce n’est pas un ERP. La documentation de l’API prend une facture comme exemple d’objet personnalisé, mais un objet n’est pas un module de facturation : numérotation, taxes, obligations légales et écritures comptables resteraient à construire, puis à maintenir. Il en va de même pour un stock. Quand devis, factures et stock doivent vivre dans le même outil que les clients, un ERP comme Dolibarr ou Odoo est plus juste, comme l’explique notre guide pour choisir entre Twenty, Dolibarr et Odoo. La comptabilité reste dans votre logiciel comptable.

Auto-hébergé, il est sous votre responsabilité. Le guide de mise à jour de Twenty demande de sauvegarder la base avant de commencer ; les migrations s’exécutent ensuite au démarrage. Sauvegardes, mises à jour et surveillance du serveur sont à prévoir, chez vous ou chez un prestataire ; notre guide sur la sauvegarde d’un serveur à soi dit ce qui fait vraiment perdre des données.

La licence encadre la modification du code. Selon le fichier de licence du projet, le cœur de Twenty est sous AGPL v3, et les fichiers marqués « Enterprise » relèvent d’une licence commerciale. Une exception couvre les applications qui dialoguent avec Twenty par ses interfaces publiées (API, webhooks, kits de développement) sans incorporer ni modifier son code : elles ne passent pas sous AGPL de ce seul fait. Modifier le code de Twenty et le servir sur un réseau oblige en revanche à proposer le code source modifié à ses utilisateurs.

Le produit est jeune sur certains points. Plusieurs avis d’utilisateurs sur Product Hunt jugent certaines parties moins abouties que chez des CRM plus anciens. Listez vos indispensables et vérifiez-les avant de vous engager.

Twenty est-il le bon back-office pour vous ?

Oui, si votre activité tient dans des objets reliés à des personnes, que votre site doit publier ces données et que les demandes doivent revenir au même endroit. Commencez par un objet et un flux, par exemple les demandes du site, puis étendez. Si vous préférez ne pas porter l’installation vous-même, notre offre CRM installe Twenty dans votre vocabulaire et le relie à votre site : 4 500 € pour Twenty ; les sauvegardes, les mises à jour et la supervision peuvent ensuite être assurées en abonnement. Tous nos guides sur le sujet sont réunis dans la rubrique sur les CRM libres et leur mise en place.

Questions fréquentes

Un CRM ou un ERP : quelle différence, et faut-il les deux ?

Un CRM suit la relation : contacts, demandes, opportunités, échanges. Un ERP gère les opérations : devis, factures, stock, comptabilité. Twenty est un CRM au modèle ouvert, capable de porter des objets métier, mais pas les règles d’une facturation ou d’un stock. Une petite structure peut se contenter d’un CRM relié à son logiciel comptable ; quand les processus se croisent, un ERP comme Dolibarr ou Odoo devient plus simple que deux outils à synchroniser.

Comment relier son CRM à sa comptabilité et à son site ?

Par l’API, avec une règle : une seule source de vérité par donnée. Le site lit une copie synchronisée de ce que le CRM publie et y renvoie les demandes. La comptabilité reste dans son logiciel, et un outil d’automatisation comme n8n fait passer ce qui doit passer, par exemple un client signé. Chaque échange se surveille : une synchronisation arrêtée sans alerte peut passer inaperçue longtemps.

Peut-on utiliser Twenty comme back-office d’un site Astro ?

Oui, c’est le montage de Palmora : un site Astro en six langues dont les biens viennent de Twenty, synchronisés chaque jour, et dont les demandes de recherche y reviennent par l’API GraphQL. Avec une synchronisation, le site ne dépend pas du CRM à chaque visite et l’équipe ne saisit qu’une fois. Il faut en revanche un traitement de synchronisation fiable et surveillé, et une fonction serveur pour les formulaires.

Peut-on héberger son CRM soi-même ?

Oui. Twenty s’installe sur votre serveur avec Docker Compose, selon sa documentation d’auto-hébergement, et sa page tarifaire indique que le cœur libre s’auto-héberge sans frais de licence. En échange, les sauvegardes, les mises à jour et la surveillance vous reviennent : à faire vous-même, avec une personne formée, ou à confier à un prestataire.