L'attrait du concept
Le fantasme est séduisant. Ça ressemble au code au feeling—cette tendance TikTok où quelqu'un génère un logiciel fonctionnel en décrivant ses intuitions à une IA.
Certains outils CRM utilisent désormais le langage naturel. Vous tapez des requêtes et des commandes. L'IA exécute. Mais voilà le détail qui ne cadre pas avec le fantasme : il faut savoir exactement ce que vous demandez.
Plus important encore : quelqu'un doit le maintenir.
Où le code au feeling échoue
Le code au feeling fonctionne en démo parce que l'IA invente la structure à la volée. Temporaire. Jetable. Parfait pour 30 secondes.
Un CRM n'est pas temporaire. Vos Contacts, Deals et objets personnalisés doivent vivre quelque part. Ils doivent signifier la même chose demain. D'autres personnes doivent les comprendre. Les permissions doivent tenir bon.
Cela signifie que quelqu'un possède le modèle de données.
Quand vous codez un CRM au feeling, ce quelqu'un, c'est vous.
Ce que vous héritez réellement
Construire un CRM signifie répondre à des questions difficiles :
Qu'est-ce qui constitue un « Prospect Qualifié » dans votre entreprise ?
Quand un Deal doit-il passer en « Négociation » ?
Qui peut consulter les prévisions de revenus ?
Que se passe-t-il quand quelqu'un quitte l'entreprise ?
Pourquoi ce champ est-il obligatoire et celui-ci optionnel ?
Les Contacts peuvent-ils être liés à plusieurs Comptes, ou seulement un ?
Ce sont des questions de données, pas des questions d'interface. Une interface en langage naturel ne les résout pas. Elle cache simplement l'interface derrière un chat.
Une fois que vous avez défini votre schéma, vous en possédez l'évolution.
Nouveau processus de vente ? Vous le mettez à jour. Une acquisition amène une deuxième équipe avec une terminologie différente ? Vous la réconciliez. Un changement réglementaire nécessite de nouveaux champs ? Vous les ajoutez et remplissez les anciens enregistrements.
Sans formulaires, cela signifie qu'aucun vendeur de CRM ne vous tient la main. Cela signifie que vous êtes l'administrateur CRM, le gestionnaire de données, et la personne qui répond « qu'est-ce que le pipeline ? » à 14 h le mardi.
La dette de versionnage et de maintenance
Le code au feeling s'adapte mal à l'échelle parce que :
Pas de documentation. Vous avez demandé à l'IA de construire quelque chose conversationnellement. Personne n'a noté pourquoi. Six mois plus tard, personne ne sait à quoi sert un champ.
Dérive du schéma. Sans examen formel, les champs sont renommés, mal utilisés ou abandonnés. La qualité des données se dégrade silencieusement. Vous ne pouvez pas suivre facilement quelle version du schéma vous utilisez ou pourquoi elle a changé.
Goulot d'étranglement à une personne. Vous l'avez construit en discutant avec une IA. Seul vous le comprenez. Quand vous êtes en vacances, rien ne change. Quand vous partez, quelqu'un hérite d'une boîte noire.
Fragilité de l'intégration. Si votre schéma CRM change, vos intégrations API, automatisations et rapports aval se cassent. Coder au feeling un changement ne se propage pas proprement à travers les dépendances.
Lacunes d'audit. Si vous devez prouver qui a changé quoi et quand, un log de chat n'est pas un changelog. Vous perdez l'enregistrement institutionnel de l'évolution du schéma.
Pas de discipline de versionnage. La plupart des équipes implémentent le versionnage pour une raison : rollback, test, déploiements progressifs. Le code au feeling saute généralement tout cela. Vous mutez directement en production.
C'est pourquoi les implémentations CRM exigent de la discipline. Non pas à cause des formulaires. À cause de la gouvernance.
Le vrai coût : travail vs. paiement mensuel
Voici ce que la plupart des équipes ne calculent pas : le coût d'exploitation de votre propre CRM.
Un gestionnaire de données à temps plein ou un administrateur CRM coûte entre 50 000 € et 65 000 € par an, plus les 20 à 30 heures par mois qu'il consacre à répondre aux questions de schéma, à corriger les problèmes de qualité des données, à documenter l'évolution de la plateforme et à gérer les bugs et autres problèmes.
Un CRM hébergé comme OSTRATA, avec une tarification mensuelle équitable, délègue la plupart de ce fardeau. Vous payez pour l'infrastructure, l'isolation multi-tenant, les intégrations API et les améliorations continues des produits. Vous ne payez pas pour une personne qui gère votre couche de données.
Le compromis est simple :
Coder votre propre CRM au feeling : Vous économisez sur les licences. Vous payez en travail et en dette de maintenance.
Utiliser OSTRATA : Vous payez un petit montant mensuel. Votre schéma reste le vôtre. L'IA dans Operations vous permet d'interagir naturellement via chat. Vous définissez Contacts, Deals et objets personnalisés dans Setup une seule fois, puis vous opérez sans friction de formulaires. Vous n'embauchez pas un gestionnaire à temps plein.
Si votre équipe est petite et que vous voulez vraiment posséder l'ensemble de la couche de données, le code au feeling peut avoir du sens. Mais si vous déléguez l'infrastructure, le versionnage, la multi-location, l'isolation des permissions (RLS), la gestion des API et les intégrations (Google Drive, Calendar, Gmail, Telegram)—vous payez déjà quelqu'un. Autant que ce soit le produit, pas une personne.
Ce que vous échangez réellement
Le fantasme : le langage naturel est plus rapide que les formulaires.
La réalité : le langage naturel est plus rapide pour la saisie de données, mais seulement si votre schéma est déjà stabilisé.
Le vrai coût est :
Discipline initiale (comme pour tout CRM)
Gouvernance permanente (possiblement plus importante, car il est plus facile de muter)
Un seul opérateur qui comprend l'ensemble du système
Aucune connaissance institutionnelle du pourquoi les choses sont ainsi
Une dette technique invisible qui s'accumule avec le temps
Quand le code au feeling pour CRM a du sens
Cela fonctionne dans des contextes spécifiques :
Fondateurs en solo ou petites équipes (< 5 personnes) où une personne possède toutes les décisions de données.
Schémas à fort renouvellement (organisations expérimentales qui re-conçoivent mensuellement et acceptent l'instabilité).
Outils personnels ou départementaux qui n'ont pas besoin de se synchroniser dans l'entreprise.
Cela échoue quand :
Plusieurs équipes doivent utiliser les mêmes données
Vous ne pouvez pas vous permettre un gestionnaire de données à temps plein (ou l'équivalent salarial)
La conformité ou les pistes d'audit sont importantes
L'outil doit survivre à votre mandat
Vous devez annuler un changement de schéma
La position honnête
Le chat en langage naturel est véritablement meilleur pour :
Vitesse quand vous savez ce que vous cherchez
Réduire les clics et la friction de navigation
Rendre les requêtes ad hoc naturelles
Permettre aux utilisateurs non techniques d'opérer sans formation
Ce n'est pas meilleur pour :
Éviter le travail de définir votre modèle de données
Ignorer la discipline des schémas propres
Accélérer l'implémentation CRM (même rigueur, interface différente)
Distribuer la propriété et l'imputabilité
Construire la mémoire institutionnelle des décisions de schéma
La vraie leçon
Coder un CRM au feeling est possible. C'est aussi séduisant parce que cela semble rapide.
Mais vous ne contournez pas la partie difficile. Vous l'internalisez.
Un CRM bien géré nécessite :
Un schéma défini
Des significations de champs documentées
Des règles de permission
Un processus de gouvernance et de versionnage
Quelqu'un responsable de tout cela
Les interfaces en langage naturel n'éliminent pas ces éléments. Elles rendent simplement l'élimination optionnelle en apparence.
Si vous voulez aller vite sans embaucher un administrateur CRM, considérez ce pour quoi vous payez réellement : un produit hébergé qui gère l'infrastructure, la sécurité, le versionnage et la plomberie d'intégration. Vous possédez toujours votre schéma. Vous interagissez toujours via chat en langage naturel. Vous ne maintenez simplement pas le moteur.
La question n'est pas de savoir si le code au feeling semble plus rapide. C'est de savoir si vous êtes la personne qui devrait posséder votre couche de données entière—et son évolution—pour les trois prochaines années, ou si un petit paiement mensuel a plus de sens.