CRM sur mesure : coûts, délais et trois façons de le bâtir

Un CRM sur mesure est un outil de suivi client dont les objets, les champs et les étapes suivent votre métier plutôt qu'un gabarit commercial générique. Chez un courtier, il connaît le contrat, la compagnie, l'échéance et la pièce manquante. Chez un cabinet de conseil, il connaît la mission, le livrable et le taux journalier. Le « sur mesure » porte donc d'abord sur le modèle de données : quels objets existent, quels champs ils portent, comment ils se relient. Ce qui change d'une approche à l'autre, c'est qui écrit ce modèle et qui paie ce qu'il faut construire autour. Il faut une API pour brancher vos autres outils, la validation des saisies, les rôles qui disent qui voit quoi, et les écrans où votre équipe travaille chaque jour. Ces trois façons ne recoupent pas les « trois types de CRM » qu'on trouve dans les guides généralistes ; elles indiquent qui construit le vôtre et ce qui reste à votre charge.

Les trois approches livrent un CRM adapté à votre métier, mais elles ne laissent pas le même travail à votre charge. Le tableau résume qui construit quoi, d'après les pages des agences et des éditeurs lues en octobre 2026 et la documentation de Standards.

Développer un CRM de zéro vous donne un outil qui vous appartient entièrement ; la facture, elle, porte presque toujours sur autre chose que le modèle de données. Le modèle tient en une journée, puis un trimestre part dans l'API, la validation, les rôles et les écrans d'administration, comme le résume la documentation de Standards. Les agences chiffrent le projet entier, sans séparer le modèle de ce qu'il faut autour :

• Coût : « entre 5 000€ et 150 000€ et plus » selon Sokeo (page publiée en mai 2025, mise à jour en juin 2026).

• Maintenance : environ 15 % à 25 % du coût initial, chaque année (Sokeo, 2026).

• Jour de développeur en France : 500 € à 800 € (Sokeo, 2026).

• Délai : « 3 à 6 mois » pour un projet petit ou moyen, « jusqu'à 1-2 ans » pour un projet complexe selon Wess Soft, lu en octobre 2026.

Cette voie se justifie quand votre CRM est le produit lui-même, ou quand aucune plateforme n'accepte vos contraintes d'hébergement.

Paramétrer un CRM du marché est la voie la plus rapide pour une PME au cycle de vente classique : vous ajoutez des champs, renommez des étapes, et l'équipe s'y met sans attendre un développement. La limite arrive avec la première règle que l'éditeur n'a pas prévue, un objet qui n'est ni un contact ni une affaire, ou un lien entre deux fiches que les menus ne savent pas décrire. Salesforce pointe un autre coût sur sa propre page consacrée au CRM personnalisé, lue en octobre 2026. Si votre équipe n'utilise pas toutes les fonctionnalités d'un CRM très complet, « vous risquez de payer pour un grand nombre de fonctionnalités que vous n'utiliserez pas » (Salesforce). L'éditeur y recommande une voie médiane, un CRM du marché complété d'applications sur mesure. Elle tient tant que vos besoins restent proches du gabarit. Quand ils s'en éloignent, chaque écart se paie en module supplémentaire ou en développement chez un intégrateur.

Déclarer vos objets sur Standards est une troisième voie, pour une équipe qui a un développeur TypeScript : vous écrivez le modèle, et la plateforme sert tout ce qu'un développement de zéro vous ferait payer autour. En échange, vous dépendez de Standards, avec une sortie prévue : le schéma reste dans votre propre dépôt et chaque fiche reste accessible par l'API. Un objet se déclare en TypeScript avec object(name, label), chaque .attribute() ajoute un champ typé, et un appel à bundles.sync pousse le bundle() qui le contient vers votre espace Standards (documentation des objets). Standards en tire alors cinq choses : une API REST typée, la validation de chaque saisie, des permissions par objet et par action, une application où votre équipe travaille, et des outils MCP pour les agents IA, soumis aux mêmes droits.

Votre équipe n'attend pas le développeur pour avancer. Dans l'application, une personne qui a le droit de modifier la structure (le propriétaire de l'espace, ou un rôle que vous lui donnez) ajoute des champs, des vues kanban, des onglets filtrés et des objets. La synchronisation suivante les laisse en place, et ce que votre code a déclaré ne peut être ni supprimé ni retypé depuis l'application (propriété du schéma).

Ce qui ne vient pas tout seul : vos règles métier propres et vos intégrations avec des outils que Standards ne connaît pas. Elles restent du code, mais du code qui appelle une API déjà typée plutôt qu'une base à construire. La page développeurs montre le SDK, la CLI et le serveur MCP.

Un projet de CRM sur mesure suit le même ordre, que vous développiez de zéro, paramétriez un CRM du marché ou déclariez vos objets sur Standards. Atalanta décrit le cadrage, les maquettes, une première version et la maintenance, et Wess Soft des étapes proches ; la reprise des données s'y ajoute dès que vos clients vivent dans un tableur.

1. Cadrer les objets avec les personnes qui saisiront : le client, le contrat, l'échéance, et ce qui les relie. Ce cadrage devient ensuite, tel quel, la déclaration TypeScript du premier objet sur Standards.

2. Maquetter les écrans avant de les construire. Sur Standards, un objet synchronisé sans vue déclarée reçoit le tableau et la fiche par défaut de l'espace, qui servent de première maquette.

3. Livrer par versions, en commençant par l'objet qui fait le plus mal, celui qui vit aujourd'hui dans un tableur. Avec Standards, chaque synchronisation garde les champs et les vues que l'équipe a ajoutés entre deux versions.

4. Reprendre les données du tableur ou de l'ancien outil. Avec Standards, un script s'en charge en appelant l'API REST de l'objet déclaré, la même que celle de vos intégrations.

5. Prévoir la maintenance, que Sokeo chiffre en 2026 à 15 % à 25 % du coût initial par an pour un développement de zéro. Avec Standards, la plateforme garde l'API, la validation, les rôles et les écrans ; vos règles métier et vos intégrations restent à votre charge.

L'IA fait baisser le coût d'écriture d'un CRM sur mesure. Ce qui doit rester juste dans la durée coûte toujours autant. Un agent de code comme Claude Code écrit en quelques minutes une page publique, une règle de prix ou une tâche planifiée. Il écrit moins bien les tables, les migrations, l'écran d'administration, l'authentification et les permissions : c'est là, selon la documentation de Standards, que les applications écrites par IA se dégradent (vibecoding sur Standards). Sur Standards, cette couche n'est pas à écrire, et l'agent s'en tient à ce qu'il écrit bien. L'exemple documenté est le catalogue des modèles d'IA que lit chaque déploiement de Standards : 42 attributs, 10 onglets de vue, deux files de travail, et aucun composant d'administration dans son dépôt. Selon la même page, tout part d'un seul fichier TypeScript, d'où le catalogue tire à la fois son interface d'administration et l'outil que votre agent interroge.

Dans l'application Standards, l'assistant IA a une façon de travailler « Architecte » qui « conçoit objets, champs et vues avec vous, dans un brouillon que vous publiez » : rien n'existe tant que vous n'avez pas publié. Claude Code, Codex ou Cursor lisent et écrivent vos fiches par MCP, avec les droits de la clé qui les connecte : une clé qui ne peut pas écrire ne leur donne aucun outil d'écriture.

Prenons un cabinet fictif de courtage en assurance, 12 personnes, qui suit ses clients dans un tableur et ses contrats dans les extranets des compagnies. L'exemple montre l'ordre des étapes, pas une mesure : les durées réelles dépendent de vos données et de vos outils.

Le cabinet n'a écrit ni API, ni écran d'administration, ni gestion des rôles. Il a écrit son modèle un objet après l'autre, au rythme où l'équipe les adoptait.