Cahier des charges d’un CRM : la trame pour consulter éditeurs et développeurs

Vous vous apprêtez à équiper vos équipes d’un CRM et à consulter des prestataires. Un cahier des charges CRM efficace tient en une dizaine de pages et sert les deux consultations possibles : demander des devis à des éditeurs de CRM du marché, ou faire développer votre propre outil. Il décrit vos processus de vente, vos données, vos intégrations et les indicateurs que vous suivez, sans imposer d’écran ni de technologie. Vous trouverez ici ce que le document doit permettre, une trame prête à copier, et la façon de lire les réponses pour choisir entre un CRM du marché et un CRM sur mesure.

À quoi sert un cahier des charges CRM ?

Le document a trois jobs.

• Obtenir des devis comparables. Un prestataire chiffre l’incertitude autant que le travail : chaque zone floue du document se retrouve dans le devis sous forme de marge ou d’hypothèse.
• Comparer sur une même base des réponses de natures différentes. Un éditeur répond « c’est standard », « c’est configurable » ou « c’est une option payante ». Une agence de développement répond « on le développe ». Sans trame commune, vous comparez un paramétrage avec un développement, deux achats différents.
• Servir de cadre au projet une fois le prestataire choisi : les critères d’acceptation du document deviennent les cas de test de la recette. Les processus décrits deviennent le cœur du cadrage.

Le document protège aussi l’objectif de départ. PwC, cabinet de conseil, a interrogé en 2025 des entreprises françaises sur leurs projets de transformation CRM menés autour de Salesforce : la moitié de ces entreprises ne considèrent pas leur projet comme réussi. La première cause citée est la perte de vue de l’objectif initial au fil du déploiement. Un cahier des charges écrit, daté et chiffré donne au projet une référence qui reste valable après des mois de paramétrage.

Les sections communes à tout projet logiciel, de l’expression de besoin aux critères d’acceptation, sont détaillées dans la trame générique de cahier des charges. Cet article reprend ce qui change pour un CRM : les processus, le modèle de données, les intégrations et le choix entre marché et sur mesure.

Décrire vos processus commerciaux avant les fonctionnalités

La liste de fonctionnalités vient en dernier. Un CRM suit d’abord votre cycle de vente, dont la description dicte tout le reste du document. Décrivez le parcours complet : comment un prospect entre dans l’entreprise, qui le qualifie, combien d’étapes séparent le premier contact de la signature, et qui intervient à chaque étape.

Décrivez le processus tel qu’il se vit aujourd’hui, avec ses contournements. Si vos commerciaux recopient les devis dans un fichier Excel partagé et valident les remises par messagerie interne, écrivez-le : ces contournements sont les besoins réels. Un prestataire y reconnaîtra ce que l’outil doit absorber. Chez Lonestone, la phase de cadrage commence par observer les commerciaux, l’ADV (l’administration des ventes) et les managers dans leur quotidien plutôt que par lire l’organigramme.

Ajoutez les règles de gestion que le CRM devra faire respecter. Un devis au-delà d’un certain montant exige la validation du directeur commercial. Une opportunité sans activité depuis 30 jours passe en alerte de relance. Un client qui signe déclenche la facturation et le transfert au service après-vente. Ces règles distinguent deux pipelines qui affichent pourtant les mêmes étapes.

graph TD
  A[Prospection<br/>le SDR qualifie le premier contact] --> B[Rendez-vous<br/>le commercial démontre et chiffre le besoin]
  B --> C[Devis<br/>l’ADV chiffre techniquement]
  C --> D[Négociation<br/>le directeur valide au-delà du seuil]
  D --> E[Signature<br/>l’ADV commande, facture, transfère au SAV]
  C -->|Affaire perdue| F[Relance automatique après 90 jours]

Un CRM couvre ensuite trois usages, que le document gagne à distinguer : opérationnel pour les commerciaux au quotidien, analytique pour la direction qui suit le pipeline, collaboratif pour partager l’information client entre les commerciaux, le marketing et le service après-vente. Le pipeline du schéma sert les trois.

Le modèle de données : comptes, contacts, opportunités et vos objets métier

Presque tous les CRM reposent sur trois objets : le compte (l’entreprise cliente), le contact (la personne) et l’opportunité (l’affaire en cours). Ces objets suffisent rarement. Listez les objets propres à votre métier : le parc installé pour un industriel, les réservations et les lots pour un promoteur immobilier, les contrats et les échéances pour un assureur, les dossiers de candidature pour un cabinet de recrutement.

Cette liste oriente le choix entre les deux consultations. Si tous vos objets existent dans le modèle du CRM visé, la réponse à votre document sera du paramétrage. Si vos objets métier n’existent dans aucun outil du marché, la réponse sera un développement : votre document en fixe alors le périmètre. Pour Mom3nt, le SaaS de sales nurturing développé par Lonestone, le modèle de données dépasse le CRM classique : l’outil synchronise comptes, contacts et transactions depuis HubSpot, puis y ajoute des signaux externes et des recommandations d’action qu’aucun éditeur ne propose.

Indiquez les volumes : nombre de comptes actifs, d’opportunités ouvertes par mois, de champs par fiche, et la croissance attendue. Un CRM qui démarre avec 3 000 contacts n’a pas les mêmes besoins d’hébergement et de reporting qu’une base de 200 000 fiches avec un historique de dix ans à reprendre.

Quand une donnée comme la fiche client, le catalogue ou le devis vit à la fois dans le CRM et dans l’ERP, nommez l’outil maître de chaque donnée, celui où elle naît et où s’appliquent ses règles. Les recoupements entre les deux systèmes sont détaillés dans les différences entre ERP et CRM.

Rôles, droits et usages terrain

Listez chaque rôle avec ses droits et son contexte d’usage. Le commercial itinérant consulte ses fiches et saisit ses comptes-rendus sur son téléphone, entre deux rendez-vous, parfois avec un réseau faible. Le responsable ADV travaille au bureau sur grand écran et a besoin de filtres croisés. Le directeur suit le pipeline consolidé et accède aux marges par affaire. Le comptable exporte les affaires signées vers la facturation. Dans la réponse du prestataire, chaque rôle se traduit par des écrans et des règles d’accès.

L’usage terrain mérite une rubrique à lui seul, parce qu’il décide de l’adoption. Un compte-rendu de visite qui demande douze champs remplis en tout petit sur un écran de téléphone ne sera jamais saisi. Le CRM devient alors une base vide que personne ne consulte. Écrivez la saisie que vous attendez réellement : trois champs sur mobile, la synthèse du rendez-vous dictée, la date du prochain appel. Un document qui décrit les usages réels de chaque rôle protège le projet de l’écart entre l’outil installé et l’outil utilisé.

Intégrations : ce que le CRM doit échanger

Nommez chaque système avec lequel le CRM doit échanger, le sens de l’échange, sa fréquence, et ce que vous savez de l’API de l’autre outil. Joignez la documentation quand vous l’avez, et écrivez « à vérifier » quand vous ne l’avez pas : un prestataire préfère lire cette mention plutôt que de découvrir une API mal documentée au troisième sprint.

Les intégrations pèsent souvent plus lourd dans un devis que les écrans. Si votre ERP n’expose ses données que par un export nocturne, écrivez-le : le prestataire construira une synchronisation différente de celle d’une API temps réel. Pensez aussi aux usages futurs : l’IA conversationnelle ajoutée au CRM de Marvin Recruiter lit et écrit dans les données du CRM grâce à des API pensées pour cela dès la conception.

Reprise des données et RGPD

Décrivez l’existant sans l’idéaliser. La base de clients vit souvent dans trois fichiers Excel tenus par trois personnes, avec des doublons, des colonnes libres et des acronymes connus d’une seule personne. Un projet de CRM démarre par l’extraction, le nettoyage et le rattachement de ces données, puis par des imports par lots validés à chaque étape. Vos équipes continuent à travailler sur l’ancien outil pendant la transition. La bascule se fait quand tout est vérifié. Le même chantier s’applique à une reprise depuis un CRM du marché : les données s’exportent presque toujours, les workflows et les rapports se reconstruisent dans le nouvel outil.

La rubrique RGPD liste les données personnelles collectées, leurs finalités, leur durée de conservation, l’hébergement visé et la personne qui répondra aux demandes de droits. Pour une PME B2B classique, ces quelques lignes suffisent. Dans la santé, les contraintes montent d’un cran : le CRM développé par Lonestone pour un groupement de coopération sanitaire est hébergé HDS (la certification obligatoire pour les données de santé), connecté aux référentiels métier et journalisé conformément, des exigences qui avaient écarté tous les CRM du marché consultés. Vos contraintes réglementaires, quand elles existent, appartiennent à la rubrique contraintes du document, lue aussi bien par un éditeur que par une agence.

Reporting : les indicateurs qui changent une décision

La rubrique reporting ne liste que les indicateurs qui déclenchent une décision. Le taux de conversion par étape du pipeline oriente le coaching commercial, la durée moyenne du cycle éclaire les prévisions de facturation, la valeur pondérée du pipeline arbitre les embauches. La méthode pour choisir ses indicateurs est détaillée dans la construction d’un tableau de bord de gestion.

Précisez qui voit quoi : le commercial pour son pipeline, le responsable pour son équipe, la direction pour la vue consolidée. Recensez aussi les tableaux que vos équipes recomptent aujourd’hui à la main dans Excel : cette liste préfigure le module de reporting et montre ce que l’outil actuel ne couvre pas.

La trame d’un cahier des charges CRM, prête à copier

Le tableau résume les rubriques propres à un CRM. Les rubriques communes à tout projet logiciel, contexte, utilisateurs, critères d’acceptation, budget, modalités de consultation, sont reprises dans la trame générique de cahier des charges.

Copiez ensuite la trame vide dans votre éditeur de texte.

# Cahier des charges : CRM [nom du projet]

## 1. Contexte et objectifs
- L’entreprise, le problème actuel, deux ou trois objectifs chiffrés

## 2. Processus commerciaux
- Le cycle de vente réel, étape par étape, qui fait quoi
- Les règles de gestion : validations, alertes, relances
- Les contournements actuels : Excel, messagerie, fichiers partagés

## 3. Modèle de données
- Comptes, contacts, opportunités, objets propres au métier
- Volumes actuels et croissance attendue
- L’outil maître de chaque donnée partagée avec l’ERP

## 4. Rôles et usages
- Rôle, nombre, droits, appareil, contexte
- La saisie attendue sur mobile

## 5. Intégrations
- Système, sens de l’échange, fréquence, documentation de l’API
- Usages IA à prévoir

## 6. Reprise de données
- Sources : fichiers, ancien CRM
- Nettoyage, mapping, import par lots, bascule

## 7. RGPD et contraintes
- Données personnelles, finalités, durées, hébergement, référent
- Contraintes réglementaires, techniques, appareils

## 8. Reporting
- Les indicateurs qui changent une décision
- Qui voit quoi

## 9. Critères d’acceptation
- Une phrase vérifiable par fonctionnalité indispensable

## 10. Budget et calendrier
- Fourchette de budget
- Date clé et raison de cette date

Lire les réponses et choisir entre marché et sur mesure

Envoyez le même document aux éditeurs, aux intégrateurs et aux agences de développement. Les réponses se comparent sur cinq points : la nature de la réponse, le coût, votre métier propre, la dépendance et le délai.

Un CRM du marché suffit quand votre cycle de vente suit un parcours standard avec moins d’une vingtaine de commerciaux : la comparaison des CRM pour PME montre qu’un outil configuré fait alors le travail pour un abonnement raisonnable. Le sur mesure devient rentable quand vous payez surtout des licences, des options et des heures pour contourner les limites : les licences d’un CRM installé coûtent 50 à 100 € par utilisateur et par mois, soit 30 000 à 60 000 € par an pour 50 utilisateurs. Chaque développement spécifique dans un outil du marché coûte deux à trois fois le même développement sur une stack standard. Une enquête menée en 2025 par le cabinet Ascend2 avec l’éditeur Insightly auprès d’équipes commerciales ajoute un argument : 94 % des commerciaux interrogés utilisent moins des trois quarts des fonctionnalités de leur CRM. Vous payez l’outil que vos équipes n’ouvrent pas.

Le calcul complet entre achat et développement est détaillé dans l’arbitrage entre logiciel du marché et sur mesure. Si vous partez d’un CRM installé, la reprise de données et la reconstruction des workflows sont dans les alternatives à Salesforce. Pour consulter des équipes de développement, le comparatif des agences françaises qui développent des CRM sur mesure rassemble les profils selon leur stack et leurs références.

graph TD
  A{Votre cycle de vente suit-il un parcours standard ?} -->|Oui| B[CRM du marché<br/>la trame compare les éditeurs]
  A -->|Votre métier a ses étapes et ses objets propres| C{Payez-vous déjà des options<br/>et des contournements ?}
  C -->|Non, moins de 20 utilisateurs| D[CRM configurable<br/>avec vos objets métier écrits dans la trame]
  C -->|Oui, licences et heures qui s’accumulent| E[CRM sur mesure<br/>la trame devient le cadre du développement]

Lonestone a vécu les deux côtés du document. Son CRM interne a démarré par un MVP de quelques sprints sur les opportunités et le pipeline, puis s’est enrichi au fil des besoins : marges, facturation projet, automatisations IA pour préparer les rendez-vous. Un groupement de coopération sanitaire a écarté tous les CRM du marché consultés faute d’hébergement HDS et d’intégration à ses référentiels métier. Son cahier des charges a servi directement de cadre au développement. Dans les deux cas, le cahier des charges a été écrit court : le projet a grandi par sprints.

Le budget et les délais à écrire noir sur blanc

Donnez une fourchette de budget dans le document. Les clients qui la cachent reçoivent trois devis construits sur trois idées différentes du projet. Ceux qui l’annoncent reçoivent des réponses qui tiennent dans l’enveloppe, avec ce qui en sort signalé explicitement.

Pour un développement sur mesure, les fourchettes du marché français sont détaillées dans le prix d’un CRM sur mesure : autour de 5 000 € pour un premier périmètre fonctionnel utile, jusqu’à 100 000 € pour le remplacement complet d’un CRM installé, migration, intégrations et formation comprises. La maintenance annuelle coûte ensuite 15 à 25 % du montant initial. Côté délais, un premier livrable couvrant contacts, pipeline et fiches clients se développe en 2 à 3 semaines, un CRM complet avec intégrations ERP et usage mobile en 2 à 4 mois, un remplacement complet avec migration en 4 à 8 mois. Côté CRM du marché, ajoutez au devis l’onboarding obligatoire, les options et les développements spécifiques éventuels : ces lignes décident du coût réel à trois ans.

Indiquez aussi la date qui compte vraiment, avec sa raison. « Le renouvellement de nos licences en mars », « le salon où nos commerciaux doivent suivre les affaires sur mobile » : cette date et sa raison orientent le périmètre de la première version bien mieux qu’un souhait de mise en production au plus vite.

En méthode agile, le document fixe les objectifs, le budget et les contraintes. Son périmètre fonctionnel devient un backlog repriorisé à chaque sprint avec le prestataire. Le cahier des charges reste la référence à laquelle les arbitrages de mi-parcours se raccrochent.

Lonestone développe des CRM sur mesure depuis 2014 pour plus de 200 clients accompagnés, avec des ingénieurs qui ont pour la plupart entre 10 et 25 ans d’expérience. Envoyez-nous votre document, même incomplet : vous repartez avec les questions qu’un développeur poserait au troisième sprint, des conseils et un devis détaillé, gratuitement. Pour écrire la trame avec une équipe, l’offre de cadrage Shape livre un cahier des charges fonctionnel, les parcours, les maquettes et une estimation, sans engagement de développement ensuite. La suite se joue sur l’approche CRM sur mesure de Lonestone.