Un cahier des charges CRM doit permettre de prendre une décision, pas seulement d’accumuler des fonctionnalités. Il traduit les objectifs commerciaux, marketing et de service client en exigences vérifiables. Il sert ensuite à consulter des éditeurs ou des intégrateurs, à comparer leurs réponses et à encadrer le déploiement.
La bonne méthode consiste à partir des usages réels, des données disponibles et des irritants rencontrés par les équipes. Le document doit aussi préciser ce qui n’entre pas dans le projet, le budget complet, les responsabilités, les livrables et les conditions de validation. Cette approche limite les réponses commerciales difficiles à comparer et les demandes ajoutées trop tard.
Le rôle du cahier des charges CRM
Le cahier des charges est le document de référence d’un projet de gestion de la relation client. Il présente le contexte, les résultats attendus, les processus concernés, les utilisateurs, les données, les contraintes techniques et les modalités du projet. Il donne aux candidats suffisamment d’informations pour proposer une réponse adaptée et chiffrable.
Son rôle ne se limite pas au choix d’un logiciel. Il doit accompagner plusieurs décisions successives :
- confirmer que le projet répond à un problème métier identifié ;
- délimiter une première version réaliste du CRM ;
- sélectionner une solution et, le cas échéant, un intégrateur ;
- contrôler les écarts entre la demande initiale et la proposition retenue ;
- préparer le paramétrage, la migration, les tests et la formation ;
- vérifier que le système livré répond aux critères convenus.
Un document trop général produit des réponses imprécises. À l’inverse, une spécification excessivement détaillée peut figer prématurément la solution et écarter des options plus simples. Le bon niveau consiste à être précis sur le résultat attendu, les règles de gestion et les contraintes, tout en laissant aux candidats la possibilité d’expliquer leur méthode.
Il faut également distinguer le besoin de la solution imaginée. « Réduire les ressaisies lors de la création d’un client » exprime un résultat métier. « Ajouter un bouton à droite de la fiche contact » impose déjà une interface. Le premier énoncé laisse au prestataire la possibilité de proposer une automatisation, une intégration ou une modification du processus.
Préparer le projet avant la rédaction
La qualité du document dépend du travail réalisé en amont. Une réunion de direction ne suffit pas pour décrire l’activité quotidienne. Il faut confronter la vision des décideurs à celle des commerciaux, du marketing, du service client, de l’administration des ventes et des équipes techniques concernées.
Constituer un groupe de travail représentatif
Désignez un pilote chargé de centraliser les contributions et de préparer les arbitrages. Identifiez ensuite un représentant de chaque population utilisatrice. Le service informatique doit intervenir sur les flux, l’authentification, l’hébergement, la sécurité et la maintenance. Les fonctions juridique ou conformité peuvent être sollicitées lorsque les traitements, les contrats ou les conditions de conservation l’exigent.
Précisez dès le départ qui propose, qui valide et qui tranche. Sans cette gouvernance, les demandes contradictoires restent ouvertes jusqu’au paramétrage, où elles deviennent plus coûteuses à traiter.
Auditer l’existant sans se limiter aux logiciels
L’audit doit recenser les outils utilisés, mais aussi les fichiers parallèles, les échanges par courriel et les tâches manuelles. Pour chaque étape du parcours client, relevez :
- l’acteur responsable et les autres intervenants ;
- l’événement qui déclenche l’action ;
- les informations consultées ou saisies ;
- les validations et règles de gestion ;
- les outils et fichiers mobilisés ;
- les erreurs, délais, doublons ou pertes d’information constatés.
Cette cartographie permet d’éviter un piège fréquent : reproduire dans un nouvel outil un fonctionnement inefficace. Certaines difficultés relèvent du logiciel, d’autres d’une responsabilité mal définie, d’une donnée absente ou d’un processus inutilement complexe.
Fixer des objectifs observables
Une formule telle que « améliorer la relation client » est trop vague pour guider le choix. L’objectif doit préciser la situation à améliorer et la manière de constater le résultat. Il peut s’agir, par exemple, de centraliser l’historique accessible aux équipes autorisées, de rendre obligatoire la qualification de certaines opportunités ou de suivre le délai de traitement d’une demande.
Pour chaque indicateur, documentez la définition, la source, le responsable et la valeur de départ lorsqu’elle est disponible. N’annoncez pas une cible chiffrée sans base fiable. Si la mesure actuelle n’existe pas, prévoyez d’abord la création d’un référentiel et une période d’observation.
La trame complète d’un cahier des charges CRM
La trame suivante peut être utilisée comme plan de rédaction. Elle convient à une consultation structurée et peut être allégée pour un projet plus simple.
1. Présentation de l’entreprise et du contexte
Présentez l’activité, les marchés servis, l’organisation commerciale, les canaux de contact et les catégories d’utilisateurs. Mentionnez les particularités qui influencent réellement le projet : plusieurs établissements, équipes itinérantes, ventes indirectes, cycles longs, contrats récurrents ou gestion de plusieurs marques, par exemple.
Expliquez l’origine du projet et les limites du dispositif actuel. Distinguez les faits observés des hypothèses. Un historique dispersé entre plusieurs outils est un constat ; l’affirmation qu’un CRM résoudra automatiquement les difficultés de coordination reste une hypothèse à éprouver.
2. Objectifs, périmètre et hors-périmètre
Listez les objectifs par ordre de priorité et rattachez chacun à un indicateur. Décrivez les équipes, entités, pays, canaux et processus concernés par la première phase. Ajoutez explicitement le hors-périmètre : fonctions reportées, données qui ne seront pas reprises, filiales non concernées ou outils qui resteront en place.
Cette frontière évite qu’une réponse commerciale inclue des fonctions séduisantes mais secondaires. Elle facilite aussi la construction d’un déploiement par étapes.
3. Utilisateurs, rôles et droits
Indiquez les profils prévus et leurs principales actions : consulter, créer, modifier, valider, exporter ou administrer. Ne vous contentez pas du nombre d’utilisateurs. Un responsable commercial, un chargé de compte, un agent du support et un administrateur n’ont ni les mêmes besoins ni les mêmes droits.
Précisez les restrictions attendues selon l’équipe, le territoire, l’entité ou la nature des données. Demandez comment les droits sont attribués, révisés et retirés. La traçabilité des actions sensibles, les modalités d’authentification et la gestion des départs doivent également être abordées lorsque le contexte le justifie.
4. Processus et besoins fonctionnels
Organisez les exigences par processus plutôt que par catalogue de modules. Un projet peut notamment couvrir :
- la prospection : origine, qualification, affectation et suivi des contacts ;
- la vente : comptes, opportunités, étapes, activités, prévisions et validations ;
- le marketing : segmentation, consentements, campagnes et transmission des contacts ;
- le service client : demandes, priorités, affectations, historique et escalades ;
- le pilotage : tableaux de bord, définitions des indicateurs et fréquence d’actualisation ;
- la mobilité : actions nécessaires en déplacement et comportement en cas de connexion limitée.
Pour chaque processus, décrivez le scénario normal, les exceptions importantes, les validations et le résultat attendu. Cette présentation est plus exploitable qu’une succession de cases « oui/non ».
5. Données, reprise et qualité
Inventoriez les sources : ancien CRM, ERP, formulaires du site, messageries, fichiers ou applications métiers. Pour chacune, précisez le responsable, le format, le volume estimé lorsqu’il est connu, la qualité constatée et l’historique à conserver.
Le cahier des charges doit répartir les responsabilités entre l’entreprise et le prestataire pour l’extraction, le nettoyage, le dédoublonnage, la transformation, l’import et le contrôle. Définissez les règles de rapprochement des comptes et contacts, ainsi que le traitement des données incomplètes. Prévoyez une migration d’essai et une validation métier avant la reprise finale.
6. Intégrations et exigences non fonctionnelles
Documentez chaque flux avec l’ERP, le site web, la messagerie, la téléphonie ou les autres applications : données échangées, sens du flux, fréquence, système de référence et comportement attendu en cas d’erreur. Le nom d’une intégration ne suffit pas pour en estimer la complexité.
Ajoutez les exigences qui ne correspondent pas directement à une fonction : performance, disponibilité attendue, sauvegarde, réversibilité, journalisation, accessibilité, compatibilité, évolutivité et administration. Pour la protection des données, ne retenez pas une simple affirmation commerciale. Vérifiez notamment les responsabilités contractuelles, les traitements prévus, les sous-traitants pertinents, les lieux d’hébergement annoncés et les mécanismes d’exercice des droits applicables à votre situation.
Le choix entre SaaS et hébergement interne doit découler des ressources, contraintes, besoins d’intégration et responsabilités acceptées par l’entreprise. Aucun modèle n’est préférable dans l’absolu. Les conditions de mise à jour, de maintenance, de sortie et de récupération des données sont aussi importantes que le mode d’hébergement.
Version simplifiée pour une TPE
Pour un premier projet limité, une trame courte peut tenir autour de huit blocs : contexte, trois objectifs prioritaires, utilisateurs, processus commercial, fonctions indispensables, données à importer, outils à connecter, budget et calendrier. Ajoutez une matrice distincte des exigences et deux ou trois scénarios de démonstration.
Cette version n’autorise pas à ignorer la sécurité, la réversibilité ou la qualité des données. Elle évite seulement les développements documentaires sans rapport avec la taille du projet.
Formuler des exigences mesurables et priorisées
Une exigence utile comporte un identifiant, un utilisateur concerné, un besoin, une priorité et une preuve d’acceptation. La formulation peut suivre ce modèle : « En tant que [rôle], je dois pouvoir [action] afin de [résultat], avec [règle ou contrainte]. »
| Formulation insuffisante | Formulation exploitable | Critère de vérification |
|---|---|---|
| Le CRM doit gérer les prospects. | Un commercial doit pouvoir qualifier un prospect avec une origine, un responsable, un statut et une prochaine action. | Création d’un prospect test, attribution et contrôle des champs obligatoires. |
| Il faut des tableaux de bord. | Le responsable doit consulter les opportunités par étape, équipe et période selon des définitions communes. | Reproduction d’un jeu de données fourni et contrôle des filtres. |
| L’outil doit être connecté à l’ERP. | Le statut du compte et les références nécessaires doivent être transmis selon un flux et une fréquence définis. | Test d’un transfert normal, d’une modification et d’un rejet. |
Classez ensuite les demandes selon trois niveaux :
- Indispensable : son absence empêche un processus critique ou rend la solution inacceptable.
- Souhaitable : elle apporte un gain réel, mais un contournement raisonnable existe.
- Évolution future : elle ne doit pas alourdir la première phase, tout en restant compatible avec la trajectoire envisagée.
Le mot « indispensable » doit rester exceptionnel. Demandez au groupe de travail ce qui se passerait concrètement si la fonction n’était pas disponible au lancement. Cette question révèle souvent des préférences présentées à tort comme des contraintes.
Pour les besoins majeurs, demandez aux candidats de qualifier leur réponse : fonction standard, paramétrage, extension, développement spécifique, outil tiers ou non-couvert. Exigez aussi une explication des dépendances et des coûts associés. Une case cochée ne dit rien sur l’effort nécessaire ni sur la maintenance future.
Encadrer le budget, les livrables et le déploiement
Le budget ne doit pas être réduit au prix des licences. Demandez une présentation séparée des coûts initiaux, récurrents et optionnels. Cette décomposition facilite la comparaison et rend visibles les hypothèses de chaque candidat.
| Poste | Questions à documenter |
|---|---|
| Logiciel | Quels utilisateurs, fonctions, environnements et limites sont inclus ? |
| Paramétrage | Quels processus, profils, règles et tableaux de bord sont couverts ? |
| Intégrations | Quels flux, connecteurs, tests et mécanismes de supervision sont prévus ? |
| Données | Qui extrait, nettoie, transforme, importe et contrôle chaque source ? |
| Accompagnement | Quelles formations, documentations et actions d’adoption sont incluses ? |
| Exploitation | Quelles modalités de support, maintenance, mise à jour et évolution s’appliquent ? |
| Charge interne | Quels collaborateurs seront mobilisés pour les ateliers, tests et formations ? |
Le planning doit faire apparaître les dépendances plutôt qu’une simple date de lancement. Prévoyez des jalons pour le cadrage, la consultation, les démonstrations, l’éventuelle preuve de concept, la conception, le paramétrage, la migration d’essai, les tests, la formation et le déploiement. Ajoutez un responsable et une condition de validation à chaque jalon important.
La liste des livrables peut comprendre le dossier de conception, la configuration documentée, les interfaces, le plan de migration, les rapports de tests, les supports de formation, la documentation d’administration et les éléments nécessaires à la réversibilité. Leur contenu et leur format doivent être précisés pour éviter qu’un simple compte rendu soit considéré comme une documentation complète.
La conduite du changement commence avant le lancement. Identifiez des référents métier, expliquez les règles communes et prévoyez un canal de remontée des difficultés. Après le déploiement, suivez des signaux d’usage adaptés : complétude de certaines données, régularité des mises à jour, utilisation des processus convenus ou demandes d’assistance. Une connexion fréquente ne prouve pas, à elle seule, une bonne adoption.
Comparer les CRM et préparer la recette
La comparaison doit s’appuyer sur une grille construite avant la réception des propositions. Elle peut inclure l’adéquation fonctionnelle, l’expérience utilisateur, les données, les intégrations, la sécurité, la capacité d’accompagnement, le coût total et les conditions contractuelles. Attribuez un poids à chaque famille en fonction de vos priorités, puis appliquez la même méthode à tous les candidats.
| Critère | Éléments à examiner | Preuve attendue |
|---|---|---|
| Couverture métier | Processus prioritaires, exceptions, automatisations | Démonstration sur vos scénarios |
| Utilisation | Simplicité des tâches fréquentes, mobilité, administration | Test par de futurs utilisateurs |
| Architecture et données | Flux, migration, sécurité, réversibilité | Description technique et engagements |
| Prestataire | Méthode, équipe, responsabilités, support | Plan de projet et livrables proposés |
| Coût total | Dépenses initiales, récurrentes et évolutives | Chiffrage détaillé et hypothèses |
Une note globale ne doit pas masquer un critère éliminatoire. Une solution bien notée en moyenne peut rester incompatible avec une exigence de sécurité, une intégration critique ou une contrainte contractuelle. Identifiez ces conditions avant la consultation.
Préparez également des scénarios de démonstration identiques : création et qualification d’un prospect, conversion en opportunité, changement de responsable, traitement d’une exception ou production d’un tableau de bord. Fournissez un contexte et des données fictives cohérentes. Vous évaluerez ainsi le déroulement réel au lieu d’assister à une présentation générique.
Les critères d’acceptation du cahier des charges peuvent ensuite alimenter le plan de recette. Chaque test doit mentionner les prérequis, les données utilisées, les étapes, le résultat attendu et le statut. Les anomalies doivent être classées selon leur impact et assorties d’une règle de traitement avant la mise en production.
Pour compléter cette démarche, la présentation des éléments essentiels d’un cahier des charges CRM proposée par Pilot’in offre un autre point de vue sur le cadrage des processus, des exigences techniques, du budget et du planning. Comme pour toute ressource publiée par un prestataire, ses recommandations doivent être confrontées aux contraintes propres à l’entreprise.
FAQ sur le cahier des charges CRM
Quelle longueur prévoir pour un cahier des charges CRM ?
La longueur dépend du périmètre. Une TPE peut cadrer un projet simple en quelques pages complétées par une matrice des besoins. Une PME ou une ETI devra généralement détailler davantage les processus, les données, les intégrations, la sécurité, les livrables et les critères de recette. La précision utile compte davantage que le nombre de pages.
Qui doit rédiger et valider le cahier des charges ?
Un responsable de projet doit coordonner la rédaction, mais les futurs utilisateurs, les responsables métiers, la direction, le service informatique et, si nécessaire, les fonctions juridique ou conformité doivent contribuer. La validation finale doit appartenir à une instance clairement désignée afin d’éviter des arbitrages tardifs.
Faut-il choisir le CRM avant de rédiger le cahier des charges ?
Non. Le cahier des charges doit partir des objectifs, des processus et des contraintes de l’entreprise, et non des fonctionnalités d’un outil déjà présélectionné. Une veille préalable reste utile, mais elle ne doit pas transformer le document en justification d’une décision prise à l’avance.
Comment prioriser les fonctionnalités CRM ?
Classez chaque exigence selon son importance métier, son urgence et son caractère bloquant. Une répartition simple entre indispensable, souhaitable et évolution future suffit souvent. Chaque besoin prioritaire doit aussi comporter un scénario d’usage et un critère permettant de vérifier qu’il est réellement couvert.
Quels coûts intégrer au budget d’un projet CRM ?
Le budget doit couvrir les licences ou l’abonnement, le paramétrage, les intégrations, la migration et le nettoyage des données, les développements spécifiques, la formation, l’assistance, la maintenance et les évolutions. Il faut également estimer la charge de travail des équipes internes pendant le projet et après le lancement.
Conclusion
Un cahier des charges CRM efficace relie chaque investissement à un usage, un responsable et une preuve de réussite. En cadrant les processus, les données, le coût total, les livrables et la recette avant la consultation, l’entreprise compare des propositions réellement comparables et conserve la maîtrise de son projet jusqu’au déploiement.
