Quand passer d'un tableur à un CRM ?

La plupart des entreprises commencent par suivre leurs clients dans un tableur : Excel, Google Sheets ou Airtable. Une ligne par client, une colonne pour l'étape de la vente, une autre pour la date de la dernière relance. Prenons une agence marketing d'une quinzaine de personnes. Ses prospects, ses devis et ses clients vivent dans un Google Sheets partagé, et cela fonctionne très bien. Pourtant, une question finit par se poser : faut-il passer à un CRM, et quand ?

Quelle est la réponse courte ?

Passez à un CRM quand vous avez besoin de relier vos données entre elles : vos contacts à leurs appels, vos opportunités aux missions signées, vos clients à leur compte sur votre plateforme. Tant qu'il s'agit de suivre un pipe commercial, un tableur bien tenu suffit, même avec beaucoup de lignes. Le volume et le nombre de personnes qui travaillent dans le fichier comptent aussi, mais seulement quand le fichier ne tient plus malgré la discipline de l'équipe.

Pourquoi un tableur peut-il suffire longtemps ?

Parce que l'outil est rarement le problème. Un tableur sait accueillir de gros volumes et plusieurs utilisateurs. Dans un grand groupe industriel, nous avons vu une équipe ajouter chaque jour des lignes dans un fichier Excel partagé sur Teams, puis une seconde équipe prendre le relais pour traiter chaque ligne à partir de réponses préconstruites. Les volumes étaient considérables, et pourtant le fichier tenait.

Ce qui le faisait tenir, c'était la discipline : chacun savait ce qu'il devait remplir, et quand. En effet, un tableur standardise peu, donc c'est à l'équipe de le faire. Il est tout de même possible d'y poser des règles : une liste déroulante dans Excel (avec la validation des données, un peu laborieuse), des types de colonnes dans Google Sheets, qui gère mieux ce point, ou encore des zones modifiables et d'autres verrouillées. Il faut alors un utilisateur référent qui surveille le fichier.

Un CRM aide à poser ces règles, mais il ne fait pas ce travail à votre place. Dans un CRM comme dans un tableur, le plus difficile reste l'adoption : que chacun sache ce qu'il doit faire et ce qu'il doit remplir.

Qu'est-ce qu'un tableur ne sait pas faire ?

Relier les choses entre elles. Reprenons l'agence. Elle se met à prospecter par téléphone, et son outil d'appel lui fournit la liste des prospects appelés, avec leur nom et leur prénom. Or ses opportunités sont dans le Google Sheets, ses missions signées dans un autre onglet et sa facturation dans un logiciel à part. Aucun lien n'existe entre ces sources.

Tant que la question est « où en est ce prospect ? », ce n'est pas un problème. En revanche, dès que la direction demande combien d'appels il faut pour signer une mission, ou quels clients rapportent le plus au regard du temps passé, il faut croiser plusieurs sources. L'agence fait alors ce que font beaucoup d'entreprises : un tableur par activité, des exports, puis des tableaux croisés dynamiques pour rapprocher le tout. Aujourd'hui, une IA peut faire ce rapprochement à partir de trois exports CSV, mais le travail reste à refaire à chaque nouvelle question.

Un CRM, ou plus largement une base de données dédiée, sert de passerelle. Il fait parler entre eux vos contacts, vos opportunités, vos deals et vos missions, et selon votre activité les comptes de vos utilisateurs ou votre stock. Chaque élément est relié aux autres : quand vous ouvrez un contact, vous retrouvez ses appels, ses opportunités et ses missions, et vous passez de l'un à l'autre. Dans Attio, par exemple, vous créez vos propres objets et vous les reliez entre eux, au point d'en faire la source de vérité de l'entreprise (le nombre d'objets custom dépend de votre plan). Ces données, envoyées ensuite dans une base SQL avec leurs identifiants, se croisent par de simples jointures.

Comment savoir si c'est le moment ?

Le premier signal, et le plus net, est le besoin de croiser vos données. Si vos questions de pilotage vous obligent à exporter plusieurs fichiers et à les rapprocher à la main, votre tableur a atteint sa limite, quel que soit son nombre de lignes. Il vous faut un outil qui relie vos données : c'est le moment de passer à un CRM.

Le second signal est le volume, combiné au nombre de personnes qui écrivent dans le fichier. Il n'existe pas de seuil universel en nombre de lignes. La vraie question est de savoir si votre équipe arrive encore à garder le fichier propre. Si les doublons, les colonnes que chacun remplit à sa façon et les lignes que personne ne met à jour se multiplient malgré des règles et un référent, le fichier ne tient plus, et un CRM vous apportera le cadre qui manque.

Si aucun de ces deux signaux ne vous parle, gardez votre tableur et soignez sa tenue : vous n'avez pas encore besoin d'un CRM. Si l'un des deux vous parle, c'est le moment.

Ce passage n'est pas un échec du tableur. Un fichier que l'on pousse longtemps devient peu à peu chaotique, parce qu'on y crée des colonnes et des onglets au fil des besoins : quand on fait le travail, on crée ce qui manque, et structurer est un autre travail. Dans un atelier, on trace des marquages au sol, puis les machines changent et le standard ne correspond plus, alors on remet l'atelier à plat. La donnée suit la même règle, et passer d'un tableur à un CRM est l'une de ces remises à plat.

Quelles sont les options, maintenant que l'IA a changé la donne ?

Le point de départ reste le même : un tableur, ou Airtable si vous voulez aller un peu plus loin dès le début. En solo, Obsidian est aussi une piste sérieuse : il est gratuit, ses notes sont des fichiers texte et ses canvas sont du JSON. Et si ses fichiers vivent dans un dossier SharePoint synchronisé, un collaborateur qui installe Obsidian avec les mêmes plugins peut travailler dans les mêmes fichiers.

Pour la suite, en revanche, le choix s'est élargi. Avant l'IA, on passait à un CRM du marché comme Attio, ou à un ERP et une plateforme de données, comme Odoo ou Databricks. Ces options restent valables : Attio, avec une personne en interne qui le maîtrise vraiment, peut relier à peu près tout ce dont une entreprise a besoin. Mais une nouvelle voie s'est ouverte : construire son propre outil, avec une base SQL et une interface développée à l'aide d'un assistant de code comme Claude Code ou Codex. Elle est très flexible, elle grandit avec l'entreprise, et une fois le développement payé, l'hébergement coûte très peu. En contrepartie, vous portez vous-même la sécurité et la gouvernance de vos données, ce qui demande un DSI expérimenté.

Un exemple : Blast a poussé Airtable très loin, puis a construit ses propres outils

Blast a présenté 2026 comme son année de la structuration. Pendant des années, la plateforme d'investissement a poussé Airtable très loin, au point d'y suivre ses leads, et ce jusqu'à dépasser soixante collaborateurs. Pour se structurer, Blast a recruté deux personnes à temps plein et a choisi de construire ses propres outils, réunis sous le nom Blast. 360°, dont un outil intégré de suivi de la relation investisseurs, plutôt que d'adopter un logiciel du marché.

Ce cas montre deux choses. D'une part, un outil comme Airtable peut porter une entreprise bien plus loin qu'on ne le croit. D'autre part, le jour où il ne suffit plus, construire sur mesure est devenu une option réaliste, et pas seulement pour les grands groupes.

Questions fréquentes

Excel, Google Sheets ou Airtable : lequel tient le plus longtemps ?

Airtable va le plus loin, et il fournit une API : un jeton suffit pour en sortir les données. En revanche, sortir les données d'un Excel stocké sur SharePoint demande de créer une application et d'obtenir une autorisation, sauf si vous restez dans l'environnement Microsoft, où Power BI se branche directement.

Que devient le tableur une fois le CRM en place ?

Il change de rôle. Le suivi client part dans le CRM, mais le tableur reste un très bon terrain d'essai pour vos premiers tableaux de bord. Voir Tableur, CRM, base SQL : comment faire grandir la donnée de votre entreprise ? et Comment structurer les données d'un tableau de bord dans Excel ou Google Sheets ?

Comment relier deux objets dans Attio ?

Par une relation, ou par un objet intermédiaire quand la liaison porte elle-même des informations. Voir Attio : relation many-to-many ou objet intermédiaire, comment choisir ? Pour le cas des appels, voir Attio : faut-il enregistrer ses appels dans une note ou dans un objet ?

Comment croiser les données du CRM avec celles des autres outils ?

En les envoyant régulièrement vers un tableur ou une base SQL. Voir Comment envoyer automatiquement vos données Attio vers Google Sheets ou une base SQL ?