CRM ou Excel : protocole de décision 2026

Verdict : le point de bascule est une preuve manquante

Le volume de contacts ne décide pas du passage à un CRM. Le point de bascule apparaît lorsque l'équipe ne peut plus répondre de façon reproductible à des questions simples : qui est responsable de cette opportunité, quelle est la prochaine action, qu'a promis le prospect, pourquoi le montant prévisionnel a changé et peut-on récupérer l'historique si l'outil disparaît ?

Un tableur bien gouverné peut répondre à ces questions. Un CRM mal configuré peut ne pas y répondre. Il faut donc tester le système commercial, pas comparer une liste de fonctions.

La règle de décision proposée ici est simple : si le tableur échoue à un test important et qu'un CRM démontre qu'il le résout sans créer un risque supérieur de données, d'adoption ou de dépendance, la migration est justifiée. Sinon, corrigez d'abord le processus.

Les sept preuves à demander au système actuel

Ne notez pas « oui » après une démonstration. Tirez vingt opportunités au hasard, ajoutez cinq cas problématiques et conservez le résultat de chaque test. C'est ce corpus qui permettra de comparer le tableur et les CRM candidats.

Ce qu'un tableur fait réellement bien

Le tableur est rapide à modifier, transparent et adapté à une analyse ponctuelle. Une équipe peut ajouter une colonne, construire un calcul ou contrôler un lot sans demander de paramétrage. Il fonctionne particulièrement bien lorsque :

• le processus contient peu d'étapes stables ;
• une personne ou un petit nombre d'acteurs tient le registre ;
• les interactions sont peu nombreuses et retrouvables dans un autre système maîtrisé ;
• aucune automatisation complexe n'est nécessaire ;
• les accès, sauvegardes et versions sont déjà contrôlés ;
• la prévision repose sur des règles simples et écrites.

Le tableur échoue moins par manque de fonction que par manque de gouvernance. Des colonnes libres, des statuts non définis et plusieurs copies locales transforment progressivement un registre en collection d'opinions incompatibles.

Ce qu'un CRM peut améliorer — sous conditions

Un CRM peut imposer des champs, attribuer les opportunités, journaliser des événements, déclencher des tâches et produire des vues communes. Ces capacités deviennent utiles quand plusieurs rôles se passent un dossier, quand le cycle comporte de nombreuses interactions ou quand la prévision doit être recalculée fréquemment.

Mais l'outil n'invente pas les règles. Une relance automatique sans critère d'arrêt peut contacter une personne opposée à la prospection. Une étape « proposition » non définie n'améliore pas la prévision. Une synchronisation de courriels trop large peut centraliser des données inutiles. Un historique abondant n'est pas forcément un historique pertinent.

Pour chaque automatisation, documentez :

1. l'événement qui la déclenche ;
2. les données utilisées ;
3. la personne responsable du résultat ;
4. les cas où elle doit s'arrêter ;
5. la trace permettant de comprendre ce qui s'est passé.

Test 1 — propriétaire et prochaine action

Prenez les opportunités considérées comme ouvertes. Chaque ligne doit avoir un propriétaire actif et une prochaine action datée. Les mentions vagues comme « à suivre » ou « relancer bientôt » échouent au test.

Mesurez ensuite :

• la part des opportunités sans propriétaire ;
• la part sans prochaine action ;
• les actions échues sans décision ;
• les dossiers attribués à une personne absente ou partie ;
• le délai de réattribution d'un portefeuille test.

Un CRM est utile s'il réduit ces anomalies grâce à des règles réellement utilisées. Il ne l'est pas si l'équipe continue à gérer la prochaine action dans ses notes personnelles.

Test 2 — historique et passage de relais

Choisissez cinq dossiers actifs, cinq perdus et cinq gagnés. Demandez à une personne qui ne les connaît pas de répondre : quel était le besoin, quelles objections ont été exprimées, quel engagement a été pris et pourquoi le dossier a changé d'étape ?

Le test ne demande pas d'importer tous les messages. Il vérifie que les décisions utiles sont liées au bon dossier. Si l'information reste dispersée entre courriels, agenda, téléphone et notes, comparez le temps de reconstitution avec le temps nécessaire dans le CRM pilote.

Le contre-cas important : une synchronisation automatique peut produire trop de bruit. Si l'utilisateur ne distingue plus une décision d'un fil de messages sans rapport, le système centralise sans rendre l'information exploitable.

Test 3 — prévision reproductible

Figez une date et demandez à deux responsables de calculer séparément le pipeline. Ils doivent utiliser la même définition :

• quelles étapes entrent dans la prévision ;
• quel montant est retenu ;
• quelle date de conclusion est utilisée ;
• quand une opportunité inactive sort du calcul ;
• comment une probabilité est déterminée.

Comparez les résultats et expliquez les écarts. Un CRM ne vaut pas par son graphique, mais par la capacité de deux personnes à obtenir le même chiffre à partir des mêmes règles. Si les étapes servent seulement à exprimer une intuition, le graphique automatise une donnée instable.

Test 4 — droits, départ et incident

Créez un utilisateur de test, attribuez-lui un portefeuille, retirez certains droits puis désactivez-le. Vérifiez :

• que les opportunités restent accessibles aux personnes autorisées ;
• que les actions et notes ne disparaissent pas ;
• que l'export est limité aux rôles prévus ;
• que les modifications sensibles sont retrouvables ;
• que l'accès est effectivement coupé dans les intégrations connectées.

La CNIL recommande d'adapter la journalisation aux risques et aux besoins de sécurité. Un journal n'a de valeur que si son accès, son contenu et sa durée sont maîtrisés. Le guide ANSSI sur l'architecture de journalisation aide à examiner la collecte, le transport, le stockage et l'analyse des traces.

Test 5 — données de prospection et durée de conservation

La migration n'autorise pas à conserver indéfiniment toutes les lignes accumulées. La CNIL indique notamment, dans son référentiel commercial, une durée de trois ans à compter de la collecte ou du dernier contact émanant du prospect pour les données de prospects ; la situation des clients et les obligations applicables doivent être examinées séparément.

Avant l'import, ajoutez ou reconstituez lorsque c'est possible :

• la provenance de la donnée ;
• la date de collecte ;
• la date et la nature du dernier contact ;
• la finalité ;
• le canal de prospection ;
• l'existence d'une opposition ;
• la règle de conservation applicable.

Une date d'ouverture d'un courriel ou une relance automatique ne doit pas être utilisée mécaniquement pour prolonger la durée. La base et les règles de prospection varient selon le canal, le destinataire et la relation existante ; vérifiez les pages CNIL citées plutôt qu'une règle simplifiée copiée dans le CRM.

Protocole de migration par échantillon

Étape 1 — geler et documenter la source

Conservez une copie en lecture seule, datée et protégée. Notez le propriétaire du fichier, ses feuilles, ses formules, ses listes de valeurs et les autres copies connues.

Étape 2 — définir le schéma cible

Pour chaque champ, écrivez sa définition, son format, sa source, son caractère obligatoire et sa règle de mise à jour. Distinguez personne, organisation, opportunité et activité ; ne les regroupez pas dans une seule ligne.

Étape 3 — qualifier avant de nettoyer

Marquez les données sans provenance, obsolètes, opposées ou inutiles. Une suppression motivée est souvent plus sûre qu'une normalisation silencieuse. Gardez un journal des décisions de nettoyage, pas les données supprimées au-delà du nécessaire.

Étape 4 — importer un lot test

Utilisez un échantillon contenant doublons, caractères particuliers, champs vides, plusieurs contacts d'une même société et opportunités liées. Comparez le nombre d'objets source et cible et contrôlez chaque relation.

Étape 5 — rejouer les sept tests

Attribuez, relancez, transférez, filtrez, prévoyez et exportez. Injectez un doublon et désactivez un utilisateur. Documentez tout contournement manuel.

Étape 6 — tester l'export avant l'import complet

Récupérez les personnes, entreprises, opportunités, activités, pièces ou liens utiles et dictionnaires de champs. Vérifiez que les identifiants permettent de reconstruire les relations hors de l'outil.

Étape 7 — élargir avec contrôle de totaux

Importez par lots, comparez les totaux et anomalies, puis faites valider un échantillon par les utilisateurs. Le tableur source reste en lecture seule jusqu'à la clôture ; il ne devient pas une seconde base active.

Matrice de décision finale

Contre-cas : quand rester sur un tableur

Restez sur un tableur lorsque le processus est simple, les règles stables, les acteurs peu nombreux, les accès maîtrisés et les sept preuves disponibles. Le coût d'administration d'un CRM peut alors dépasser son bénéfice.

Vous pouvez aussi conserver le tableur comme outil d'analyse ponctuelle, même après migration. Il ne doit simplement pas redevenir une base concurrente où les statuts et montants divergent du système principal.

Limites et date de révision

Ce protocole ne recommande pas un éditeur précis et ne promet aucun délai de migration. Le temps dépend de la qualité des données, du nombre d'objets, des intégrations, des règles de droits et des anomalies découvertes. Les capacités d'import, d'export et de journalisation doivent être testées dans la version contractuelle du produit.

Les règles de prospection et de conservation doivent être vérifiées selon le canal, la relation et la finalité. Révisez ce guide lors d'une évolution CNIL importante, d'un nouveau canal, d'une modification du schéma commercial ou d'une migration majeure.