Nous avons bâti notre propre CRM : 282 entreprises, zéro contrat, et ce qui l’a remplacé

En bref

• Nous avons bâti notre propre CRM (un logiciel de gestion de la relation client, en React et Supabase, plus de 20 lots livrés) autour d’une théorie de prospection à froid sur la façon dont JPL décroche du travail. Il a fini par contenir 282 organisations prospects et 72 contacts. Le canal à froid a produit zéro contrat.
• Chaque mandat que nous avons réellement conclu remontait à une recommandation, à une relation déjà chaude ou à un client existant. Notre pipeline n’est pas un entonnoir. C’est un réseau de 30 à 50 personnes.
• Nous avons donc cessé de gérer nos relations dans l’application. Elles vivent maintenant dans de simples fichiers texte (markdown), un par personne (23 au départ, 38 six semaines plus tard), auxquels s’ajoute une revue où un agent IA signale qui est en retard et rédige le suivi. Une personne envoie chaque message. Rien ne part tout seul.
• Six semaines plus tard, le système a un seul résultat que nous pouvons lui attribuer : un échange au point mort avec un prospect, qui a repris vie. La revue a aussi exposé plus d’une fois notre propre négligence, et ces ratés sont la partie la plus utile de cette note.
• La limite, sans détour : la campagne à froid pour laquelle la liste a été montée n’a jamais été lancée, alors ceci ne démontre pas que la prospection à froid est morte. Ça montre que nous avions bâti l’outil pour une démarche de vente que nous ne pratiquons pas.

Il s’agit d’une note de terrain sur notre propre développement des affaires, pas une étude de cas client. Nous offrons des services de croissance numérique aux petites entreprises québécoises, et nous avons consacré beaucoup de temps à bâtir un logiciel pour gérer un pipeline que nous n’avions finalement pas. Voici ce que les chiffres ont dit, ce que nous avons mis à la place, et ce que six semaines d’usage ont montré ou non.

Ce que nous avons bâti, et la théorie derrière

L’application s’appelait ContactHub : une interface React sur Supabase, bâtie par incréments, avec plus de 20 lots livrés. Elle contenait des organisations et des contacts, recevait des pistes par webhook, vérifiait le site Web de chaque prospect (code d’état, HTTPS, temps de réponse, titre de page) et pouvait lancer des séquences de courriels. C’était une bonne réalisation. Le problème, c’était la prémisse. Elle supposait que JPL croît en trouvant des entreprises à qui elle n’a jamais parlé, en les qualifiant et en les faisant avancer par étapes, comme une équipe de vente avec des quotas couvre un territoire.

Nous l’avons alimentée comme le veut cette théorie. À la fin, elle contenait 282 organisations prospects et 72 contacts nominatifs, la plupart réunis pour une campagne d’appels à froid auprès d’entrepreneurs en construction du Québec. Le dernier enregistrement date du 28 juillet 2026.

D’où venaient vraiment nos contrats ?

Quand nous avons retracé l’origine de chaque mandat conclu par JPL, aucun ne venait de la liste à froid. Ils venaient de recommandations, de relations déjà chaudes, de démos données à des gens qui nous connaissaient déjà, de reprises de maintenance et de travaux supplémentaires pour des clients que nous servions déjà. Bilan du canal à froid : zéro.

La liste utile n’a jamais été celle des 282 organisations. C’était 30 à 50 personnes : des clients, les partenaires qui nous envoient du travail, notre comptable et la personne qui tient nos livres, à qui nous demandons des recommandations, quelques pairs. Un réseau de cette taille n’a pas besoin d’être qualifié. Il a besoin de suivi : répondre au courriel resté huit jours sans réponse, envoyer la relance promise pour octobre, prendre des nouvelles de quelqu’un qui s’est tu avant que le silence devienne la réponse.

Est-ce un argument contre la prospection à froid ou contre les CRM ?

Le canal à froid n’a jamais vraiment été testé. La campagne d’appels pour laquelle la liste a été montée n’a jamais été lancée, alors nous ne pouvons pas vous dire que la prospection à froid échoue pour une entreprise comme la nôtre. Ce que nous pouvons affirmer est plus modeste : nous avons bâti et entretenu un outil pour une démarche de vente que nous ne pratiquions pas, alors que celle que nous pratiquions n’avait aucun outil.

Ce n’est pas non plus un argument contre les CRM. Une équipe de plusieurs vendeurs, quelques centaines d’occasions d’affaires en cours et des prévisions de ventes à défendre a besoin d’étapes de pipeline, de dossiers partagés et de rapports, et les CRM établis font bien cela. La leçon, c’est l’adéquation à la démarche. La nôtre, c’est une seule personne d’expérience aux commandes et quelques dizaines de relations, et pour ça, une base de données avec un tableau kanban n’était pas le bon outil.

L’application tourne encore et contient toujours la liste. Elle n’est simplement plus l’endroit où vivent nos relations.

Ce qui l’a remplacé : un fichier par personne

Le remplacement est un dossier de fichiers texte (markdown) sur notre propre machine, un par personne plutôt que par entreprise, parce que les relations se tissent avec des personnes et que l’entreprise n’est qu’un champ. Chaque fichier s’ouvre sur un court en-tête : le type de relation (client, prospect, apporteur d’affaires, partenaire, pair), comment elle a commencé, son degré de chaleur, la date du dernier vrai échange, la prochaine date à laquelle nous nous sommes engagés, le plus long silence que nous acceptons, le canal préféré, et une ligne qui dit ce qui est en suspens et de quel côté. Dessous, un journal des contacts, le plus récent en premier, une ligne chacun.

Trois règles font l’essentiel du travail.

• Les listes sont de l’inventaire, pas des relations. Un nom sur une liste achetée ou moissonnée sur le Web n’a pas de fichier. Il n’entre dans le registre que lorsqu’une vraie conversation à double sens existe.
• Rien n’est envoyé automatiquement, jamais. L’agent rédige. Une personne lit, corrige et envoie.
• Juger si une relation est chaude ou refroidie revient à une personne. La revue signale le silence. Elle ne décide jamais qu’une relation a refroidi.

Il n’y a pas d’interface à bâtir, pas de base de données à héberger et pas de pipeline de déploiement. L’interface, c’est l’agent de programmation IA dans lequel nous travaillons déjà toute la journée, et qui lit 38 petits fichiers en quelques secondes. À cette échelle, un index serait superflu.

La revue : qui est en retard, et quoi dire

La revue lit chaque fichier, vérifie les preuves, signale dans un ordre de priorité fixe et rédige un brouillon pour chaque signalement.

L’étape 2 ne faisait pas partie de la première conception. Elle a été ajoutée après la première semaine, pour la raison ci-dessous.

Six semaines d’usage

Nous voulions que la revue tourne chaque semaine. En pratique, elle a produit trois rapports écrits en six semaines, lancés à la main, pas selon un horaire. Voici ce que chacun a trouvé.

La première revue a signalé 15 relations sur 23. Une part était de la vraie négligence, celle qui s’accumule quand personne ne regarde. Une part était l’erreur du registre, et c’est de là que sont venues les leçons utiles.

Le registre accusait un retard pouvant atteindre trois semaines sur la réalité. Les échanges étaient consignés dans les dossiers clients (un livrable envoyé, une facture, une note) sans jamais se rendre au registre, alors la première revue a signalé cinq relations actives comme en souffrance. Le correctif a été une règle, pas plus de discipline : le registre est un index, les dossiers clients et la boîte courriel sont la preuve, et quand ils se contredisent, la preuve la plus récente l’emporte. La revue de septembre a ajouté la boîte courriel comme troisième source, et depuis la fin de septembre, cette vérification est une étape fixe pour chaque personne avant que quiconque soit signalé.

Un brouillon n’est pas un contact. La revue de septembre a trouvé trois messages rapportés comme préparés pour l’envoi qui ne sont jamais apparus dans le dossier des éléments envoyés, et trois fichiers dont la date de dernier échange était en fait la date de rédaction d’un brouillon. Sur papier, nous étions en contact. Dans la boîte courriel, non.

La mise en place du registre a oublié une relation. Un prospect avait accepté en juillet que nous lui réécrivions en octobre. Cette conversation s’était déroulée dans la boîte courriel de notre ancien nom de domaine, que la mise en place n’avait pas couverte, alors le fichier n’existait pas. Elle a été repérée début septembre et le suivi est parti le 1er octobre, comme promis.

Les trois cas étaient des lacunes de notre propre suivi, antérieures au registre. Le registre est simplement l’endroit où elles ont enfin fait surface.

Le résultat que nous pouvons lui attribuer

Un seul pour l’instant, et nous n’en exagérons pas la portée. Un prospect pour qui nous avions préparé une version préliminaire en juillet n’avait pas répondu depuis la fin de ce mois, même après une relance en août. En vérifiant les preuves, nous avons vu qu’une part du silence venait de nous : un de nos courriels de juillet contenant le lien vers cette version était parti par erreur à notre propre adresse. Chaque revue gardait le fil sous nos yeux, et celle de septembre a fixé une date pour le relancer ou le fermer en toute connaissance de cause. À cette date, nous avons envoyé un court message pour prendre des nouvelles. La réponse est arrivée le jour même : ils veulent continuer, ils comptent payer le travail, et ils reviendront dans quelques semaines avec un seul lot de modifications regroupées.

C’est un fil ravivé, pas un contrat signé. C’est aussi exactement ce que l’ancienne application n’allait jamais produire, parce que le problème n’a jamais été de trouver cette personne. C’était de se souvenir d’elle.

Ce que ça coûte, et ce que ça ne fait pas

Le registre n’a ni étapes de pipeline, ni prévisions, ni tableaux de bord, ni accès partagé pour une équipe. Il dépend d’un agent IA capable de lire des fichiers locaux et une boîte courriel, et d’une personne prête à lire les brouillons avant que quoi que ce soit parte. Les fichiers contiennent des renseignements personnels (noms, courriels, notes de relation), alors ils sont conservés sur notre propre machine plutôt que dans une application hébergée. L’agent IA qui les lit demeure toutefois un service externe, et en vertu de la Loi 25 du Québec, confier des renseignements personnels à un fournisseur externe entraîne des obligations. Quitter le CRM hébergé a réduit la question. Il ne l’a pas fait disparaître.

Ce qu’il fait bien est limité, mais précis : il remarque le silence, et il met un brouillon utilisable devant nous au moment où le silence commence à coûter quelque chose. Pour une entreprise dont la croissance passe par quelques dizaines de personnes, c’est finalement l’essentiel du travail.

Une petite entreprise de services a-t-elle besoin d’un CRM ? Trois questions d’abord

Pas toujours. Cela dépend de la façon dont votre travail arrive et du nombre de personnes que compte vraiment votre pipeline.

• D’où viennent vos cinq derniers contrats ? Retracez chacun jusqu’à sa première conversation. Si la plupart ont commencé par une recommandation ou un client existant, votre système devrait être bâti autour de ces gens-là, pas autour d’une liste d’inconnus.
• Combien de personnes compte votre vrai pipeline ? Si la réponse est sous la centaine, vous n’avez peut-être pas besoin de logiciel du tout. Un fichier par personne et un coup d’œil hebdomadaire à qui s’est tu peuvent suffire.
• Qu’est-ce qui se perd vraiment ? Chez nous, c’était le suivi : la relance promise pour octobre, le courriel laissé sans réponse pendant huit jours. Peu importe l’outil choisi, jugez-le sur sa capacité à repérer ça.

Si vous voulez ce genre de montage dans votre propre entreprise (un système simple qu’un agent IA tient à jour, avec une personne responsable de chaque message), c’est le travail que fait notre service d’automatisation. Nous avons écrit sur l’idée plus large dans notre article sur l’automatisation par IA pour les opérations d’affaires.

Nous avons bâti un bon CRM pour une entreprise que nous ne sommes pas. Le remplacement est plus petit, moins cher et plus proche de la façon dont notre travail arrive vraiment : par des gens que nous connaissons déjà, tant que nous pensons à leur répondre.