Étude de cas

Du chaos d'Excel à un CRM sur mesure en huit semaines : une étude de cas

Un grossiste de 14 personnes pilotait tout son processus commercial à partir d'un seul tableur partagé auquel personne ne se fiait vraiment. Voici exactement comment nous l'avons remplacé : ce que nous avons construit, ce que nous avons volontairement écarté et ce qui a changé ensuite.

Have a nice dayHave a nice day15 min de lecture
Du chaos d'Excel à un CRM sur mesure en huit semaines : une étude de cas

Il existe un type particulier de tableur qui fait tourner, sans bruit, une petite entreprise. Il a commencé comme une simple liste de clients et, en cinq ou six ans, il est devenu le fichier le plus important — et le plus dangereux — de la société. Tout le monde en dépend. Personne ne s'y fie. Et lorsqu'il finit par lâcher, c'est en général le pire jour possible. Voici l'histoire de l'un de ces tableurs, de l'entreprise de 14 personnes qui vivait à l'intérieur, et des huit semaines qu'il a fallu pour les en sortir.

Nous travaillons avec beaucoup de petites entreprises, et ce cas est anonymisé : le client nous a demandé de ne pas citer son nom, et les chiffres ici sont arrondis et illustratifs, pas des données auditées. Mais la situation est réelle, et si vous dirigez une entreprise à partir d'un tableur partagé qui se transforme peu à peu en fardeau, vous y reconnaîtrez sans doute plus de choses que vous ne le souhaiteriez. L'intérêt de l'écrire n'est pas d'exhiber un projet. C'est de montrer les vraies décisions, y compris celles où la réponse évidente était la mauvaise.

Tout au long du texte, j'ai essayé d'être honnête sur ce qui a été difficile, ce que nous avons écarté volontairement et d'où est venue la vraie valeur. Spoiler : pas de la partie à laquelle on s'attendait.

La situation : un fichier, quatorze personnes, zéro confiance

Le client est un grossiste régional : il achète des marchandises en gros et les revend à de petits détaillants et à une clientèle professionnelle. Quatorze personnes : une poignée au commercial, deux à l'entrepôt, une responsable de bureau, les deux dirigeants. Une entreprise saine, en croissance régulière, le genre de société trop grande pour être gérée de mémoire et trop petite pour avoir jamais acheté un « vrai » logiciel.

Toute leur activité commerciale tenait dans un seul tableur partagé sur un espace cloud. Clients, contacts, l'historique des commandes, qui doit quoi, des notes de relance, un système de couleurs que seule la responsable de bureau comprenait entièrement. Il comptait une quarantaine de colonnes et bien plus de mille lignes. Trois ou quatre personnes l'avaient ouvert à tout moment.

Vous devinez les symptômes. Deux personnes modifiant la même ligne, l'une écrasant l'autre sans bruit. Un commercial filtre le tableur, oublie de retirer le filtre, et la personne suivante panique parce que « la moitié des clients ont disparu ». Personne ne savait quel numéro de téléphone était le bon. Le rapport mensuel de chiffre d'affaires coûtait à la responsable de bureau presque une journée entière, à la main, et les dirigeants n'étaient pas tout à fait sûrs d'y croire. Le fichier avait été restauré à partir d'une sauvegarde deux fois en deux ans, après que quelqu'un eut supprimé ce qu'il n'aurait pas dû.

Ce n'était pas que le tableur était mauvais. C'était que quatorze personnes contournaient en silence la même douzaine de problèmes, chaque jour, et avaient cessé d'en remarquer le coût.
extrait de nos notes du premier atelier

Et voici ce qui compte : personne ne se plaignait fort. C'est le piège d'un tableur qui a dépassé sa fonction. La douleur s'étale en fine couche sur tout le monde et chaque jour, si bien qu'elle ne devient jamais une crise — elle devient simplement le climat. Les dirigeants nous ont appelés non pas à cause d'un désastre, mais parce qu'ils avaient perdu un bon client à cause d'une relance passée à la trappe, et cela les a enfin amenés à se demander combien d'autres avaient été perdus.

Un tableur surchargé sur un écran avec des dizaines de colonnes et des cellules aux couleurs qui se heurtent, plusieurs notes autocollantes collées au bord de l'écran, une employée de bureau frustrée se reflétant faiblement dans la vitre
Le fichier qui pilotait l'entreprise : quarante colonnes, mille lignes et un code couleur qu'une seule personne comprenait.

Pourquoi ne pas simplement acheter un CRM standard ?

C'est la première question que tout le monde pose, et c'est la bonne. Il existe des dizaines de bons CRM, peu chers. Nous avons sincèrement essayé de convaincre le client d'en adopter un : c'est presque toujours la réponse la plus rapide et la moins chère, et nous préférons perdre un développement plutôt que d'en vendre un dont personne n'a besoin.

Nous avons donc fait le test que nous faisons toujours : nous avons pris leur processus réel et tenté de le calquer sur deux outils CRM connus. Environ 80 % collaient bien. Ce sont les derniers 20 % qui ont tout fait capoter. Leur tarification reposait sur des paliers propres à chaque client et des remises sur volume qui ne correspondaient à aucun objet « affaire » standard. Leur historique de commandes devait se relier à un système d'entrepôt qu'ils ne voulaient pas remplacer. Et la manière dont ils suivaient leurs clients professionnels récurrents — qui recommandent par cycles souples plutôt que comme des ventes ponctuelles — n'existait tout simplement pas dans le modèle de pipeline standard.

Nous aurions pu forcer leur entreprise à entrer dans l'outil. Beaucoup de consultants l'auraient fait. Mais demander à quatorze personnes de changer leur manière de fixer les prix et de recommander pour que le logiciel soit content, c'est un excellent moyen de voir tout le monde revenir en silence au tableur en un mois. La seule raison pour laquelle l'ancien fichier a survécu si longtemps, c'est qu'il s'adaptait à eux. Ce qui le remplacerait devait faire de même.

À quoi ont vraiment ressemblé les huit semaines

Huit semaines, cela paraît rapide pour « un CRM sur mesure », et ce le serait — si nous avions tenté de construire un CRM complet. Nous ne l'avons pas fait. Nous avons construit la tranche étroite de CRM dont cette entreprise précise avait besoin, et écarté volontairement tout ce dont elle n'avait pas besoin. Cette discipline sur le périmètre est toute la raison pour laquelle le calendrier a tenu.

Voici à peu près comment les semaines se sont réparties. Dans la vraie vie, ce n'était pas aussi net — les semaines se chevauchent — mais la forme générale est honnête.

  1. 1
    Semaines 1-2 : Observer, ne pas concevoir
    Nous nous sommes installés avec l'équipe commerciale et la responsable de bureau et les avons regardés travailler le tableur pour de vrai. Pas une réunion de cadrage : de l'observation réelle. C'est là que nous avons trouvé les choses auxquelles personne ne pense à mentionner, comme le code couleur et les trois tableaux annexes « temporaires » devenus permanents.
  2. 2
    Semaines 2-3 : Nettoyer les données, décider de ce qui est vrai
    Avant de construire quoi que ce soit, nous avons démêlé le tableur lui-même : clients en double, contacts morts, trois façons différentes d'écrire le même nom d'entreprise. Pénible, peu glorieux, et le plus grand service que nous leur ayons rendu. On ne migre pas un désordre en espérant un système propre.
  3. 3
    Semaines 3-6 : Construire le cœur, entre leurs mains
    Clients, contacts, l'historique des commandes, les paliers de prix et le suivi des recommandes que les outils standard ne savaient pas faire. Nous leur montrions une version fonctionnelle chaque semaine et les laissions la casser, plutôt que de présenter un objet fini à la fin.
  4. 4
    Semaines 6-7 : Relier l'entrepôt et les rapports
    Un lien en lecture seule avec leur système d'entrepôt existant pour que l'historique des commandes se remplisse tout seul, plus le seul rapport qui comptait vraiment pour les dirigeants — chiffre d'affaires mensuel par client — généré à la demande au lieu d'être fait à la main.
  5. 5
    Semaine 8 : Migrer, former, faire tourner en parallèle
    Nous avons basculé les données nettoyées, formé l'équipe en deux courtes sessions, et gardé l'ancien tableur ouvert en lecture seule deux semaines de plus, comme filet de sécurité. Personne n'en a eu besoin passé les premiers jours, mais sa présence rendait le changement réversible — et c'est ce qui a poussé les gens à s'y engager.
Une petite équipe réunie autour d'un ordinateur portable dans le bureau d'un entrepôt, un développeur pointant un écran de CRM épuré et simple, lumière naturelle chaude, tout le monde penché en avant et investi
Des séances hebdomadaires de démonstration et de cassage : l'équipe a vu le système grandir et l'a façonné, au lieu de recevoir une boîte finie.

Ce que nous avons construit — et ce que nous avons laissé de côté

Le système fini n'est, honnêtement, pas impressionnant à regarder. C'était le but. Il fait un petit nombre de choses de la manière dont cette entreprise travaille réellement, et rien d'autre. La discipline d'écarter des choses est ce qui l'a gardé utilisable.

Ce qui est entré : une fiche client et contact propre avec une source unique de vérité pour les numéros de téléphone et les adresses ; l'historique des commandes récupéré automatiquement depuis le système d'entrepôt ; leurs vrais paliers de prix et remises sur volume ; une vue simple des cycles de recommande pour que les commerciaux voient qui doit racheter ; des rappels de relance pour que les clients silencieux ne filent pas ; et le rapport mensuel de chiffre d'affaires, généré en deux clics.

  • Ce que nous avons volontairement laissé de côté : un module marketing — ils ne font pas de campagnes e-mail, cela aurait été du poids mort.
  • Une application mobile — l'équipe commerciale travaille à son bureau et l'entrepôt a des tablettes ; une vue web adaptative a suffi.
  • Un moteur de « scoring de prospects » ou de prévision — à la mode, mais ils voulaient de la clarté sur les clients existants, pas des prédictions.
  • Toute fonction d'IA, au lancement — il n'y avait pas encore de problème de nature linguistique à résoudre, donc ajouter de l'IA aurait été de la décoration.
  • Des niveaux d'autorisation granulaires — quatorze personnes de confiance n'ont pas besoin de quatorze niveaux d'autorisation ; nous avons fait simple.

Cette dernière catégorie compte autant que la première. Chaque fonction que vous ajoutez est quelque chose à maintenir, à expliquer et à rater. Une petite entreprise n'a pas besoin du CRM dont une société de 500 personnes a besoin, et prétendre le contraire, c'est ainsi qu'un projet de huit semaines en devient un de huit mois. Nous avons laissé clairement de la place pour ajouter les pièces manquantes plus tard — mais seulement si un besoin réel se manifestait, pas parce qu'une liste de fonctions paraissait maigre.

La partie vraiment difficile n'était pas le logiciel

Si vous avez lu jusqu'ici en pensant que la difficulté serait technique, voici la surprise : le développement était le plus facile. Le plus dur, c'était la gravité du tableur. Les gens avaient des années de mémoire musculaire dans ce fichier. Certains avaient des tableaux annexes privés qu'ils n'avaient jamais mentionnés. Un commercial, très poliment, ne voulait pas être « suivi » par un système après des années passées à travailler à partir de ses propres notes.

Nous n'avons pas réglé cela avec du logiciel. Nous l'avons réglé en rendant le nouveau système véritablement plus rapide pour lui dès le premier jour — ses clients, sa liste de recommandes, ses relances, moins de saisie qu'avant — de sorte qu'il devienne le chemin le plus facile plutôt que celui imposé. La quinzaine de fonctionnement en parallèle a fait le reste. Quand les gens voient que l'ancienne méthode est toujours là en cas de besoin, ils cessent de s'y accrocher. Retirez-la trop tôt et ils se braquent.

Remplacer le tableur était un travail de logiciel. Remplacer l'habitude du tableur était le vrai projet — et c'est la partie que la plupart des développements ignorent.
ce que nous avons dit aux dirigeants lors de la remise
Un tableau de bord CRM épuré et minimaliste sur un écran de bureau affichant une liste de clients ordonnée et un seul graphique de chiffre d'affaires, calme et dégagé, un ordinateur portable fermé et un café à côté, le tableur chaotique a disparu
Le remplaçant est, à dessein, ennuyeux : quelques choses faites de la manière dont l'entreprise travaille réellement.

Ce qui a changé ensuite

Les chiffres d'abord, avec l'honnête réserve qu'il s'agit des propres chiffres arrondis du client pour les mois suivant le lancement, pas d'un audit indépendant — utiles comme tendance, pas comme garantie pour votre entreprise.

QuoiAvant (tableur)Après (CRM sur mesure)
Rapport mensuel de chiffre d'affaires~6 heures, à la mainEnviron deux clics
« Où est le numéro de téléphone actuel ? »Un pari quotidienUne fiche, fiable
Frayeurs de perte / écrasement de donnéesDeux fois en deux ansAucune jusqu'ici
Clients silencieux qui s'en vontPersonne ne connaissait le chiffreListe de recommande visible
Montée en compétence d'un nouvel arrivant sur le systèmeDes semaines de savoir non écritEnviron un après-midi
Avant et après, selon les estimations approximatives du client lui-même.

Le temps du rapport était l'argument qui comptait pour les dirigeants — récupérer presque une journée par mois, c'est de l'argent réel. Mais le changement qu'ils ont continué à mentionner des mois plus tard était plus discret : ils ont cessé de s'inquiéter pour le fichier. Cette anxiété de fond, « les données sont-elles justes, est-ce que ça va lâcher ? », a tout simplement disparu. On ne peut pas, ironie, l'inscrire dans un tableur, mais c'est ce qui leur a fait dire que l'argent avait été bien dépensé.

La liste de recommande a payé d'une manière que nous n'avions pas tout à fait prévue. En quelques mois, l'équipe commerciale avait renoué avec plusieurs clients professionnels devenus dormants en silence — exactement le genre de négligence qui avait déclenché le projet au départ. Un compte récupéré a plus que couvert le développement. Ce n'est pas une promesse que cela vous arrivera ; c'est un exemple de l'endroit où la valeur a tendance à se cacher dès que les gens peuvent vraiment voir leurs clients.

Le tableur qui fait tourner votre entreprise est-il devenu trop étroit ?

Si vos données commerciales ou clients vivent dans un seul fichier partagé dont tout le monde dépend et auquel personne ne se fie, c'est en général le moment d'en parler. Nous examinerons d'abord votre processus réel et vous dirons honnêtement si vous avez vraiment besoin d'un CRM sur mesure — ou si une solution standard suffirait.

Découvrez comment nous construisons des CRM pour les petites entreprises

Questions fréquentes

Huit semaines, est-ce réaliste pour un CRM sur mesure ?
Oui — mais seulement parce que nous avons construit un système délibérément étroit, pas un CRM d'entreprise complet. Le calendrier tient lorsque vous cadrez fermement : définissez la tranche précise dont l'entreprise a besoin, nettoyez d'abord les données et laissez de côté tout le non-essentiel. Un cahier des charges « tout faire » est ce qui transforme huit semaines en huit mois. La discipline réside dans ce que vous choisissez de ne pas construire.
Devrions-nous réparer le tableur plutôt que de le remplacer ?
Parfois, oui. Si le problème est surtout du désordre — doublons, pas de structure — un nettoyage sérieux et quelques règles peuvent vous offrir un an ou deux. Le remplacement a du sens quand les problèmes sont structurels : plusieurs personnes qui modifient en même temps, pas de vrai reporting, pas de traçabilité, des données auxquelles on ne peut se fier. Si votre tableur a été restauré depuis une sauvegarde plus d'une fois, vous avez dépassé le stade de la réparation.
Combien coûte un projet comme celui-ci ?
Nous ne pouvons pas avancer de chiffre sans voir votre processus — cela dépend entièrement de ce dont vous avez réellement besoin par rapport à ce que vous pensez avoir besoin. Mais le vrai levier sur le coût, c'est le périmètre, pas le taux horaire. Une première version bien cadrée qui règle la vraie douleur revient bien moins cher qu'une plateforme tentaculaire « à l'épreuve du futur », et c'est aussi celle qui est réellement utilisée. Nous commençons toujours par essayer de réduire le périmètre.
Migrer des années de données depuis un tableur, est-ce risqué ?
La migration elle-même présente peu de risque si vous faites d'abord le travail ennuyeux : nettoyer et dédoublonner les données, vous accorder sur ce qui fait office de source de vérité, et garder le fichier d'origine en lecture seule comme filet de sécurité. Le vrai risque n'est pas de perdre des données — c'est de migrer des contradictions et de la confusion dans un système flambant neuf. C'est pourquoi le nettoyage compte plus que le déplacement.
L'équipe l'utilisera-t-elle vraiment, ou reviendra-t-elle à ses anciennes habitudes ?
C'est la vraie question, et elle relève du déploiement, pas du logiciel. Les gens reviennent en arrière quand le nouvel outil est plus lent pour eux ou quand on leur arrache l'ancien brutalement. Nous évitons les deux : rendre le nouveau système véritablement plus rapide dès le premier jour pour ceux qui l'utilisent le plus, et faire tourner l'ancienne méthode en parallèle jusqu'à ce que plus personne ne s'y tourne. L'adoption que l'on force a tendance à s'effondrer ; celle que l'on gagne a tendance à durer.
Have a nice day
Have a nice day
La rédaction

Have a nice day est un studio logiciel qui aide les petites et moyennes entreprises à se digitaliser — automatisation, IA et logiciels sur mesure qui fonctionnent au quotidien, pas seulement sur des diapositives.

Prestations associées