Infrastructure et stockage
Sheets, base de données ou CRM, et ce qui sert de source de vérité.

Gardez tout le marché au même endroit, hors de votre CRM, et n’envoyez au CRM que les comptes que quelqu’un travaille réellement. Cet endroit peut rester longtemps un Google Sheet. L’important : qu’un seul stockage soit désigné comme source de vérité, que chaque ligne ait une clé stable et qu’un seul système ait le droit d’écrire chaque champ.
L’échec classique, c’est un CRM rempli de milliers de comptes que personne n’a touchés, à côté de trois exports qui se contredisent. Les commerciaux cessent de croire à tout cela et reprennent leurs propres listes.
Choisissez le stockage selon votre volume et votre équipe
| Critère | Tableur | Base de données (Postgres, BigQuery) | CRM |
|---|---|---|---|
| Taille confortable | Jusqu’à quelques dizaines de milliers de lignes | Des millions de lignes | Les comptes en cours de travail |
| Qui peut s’en servir | Tout le monde, tout de suite | Ceux qui écrivent du SQL, ou via un outil par-dessus | Les sales, dans leur outil quotidien |
| Historique des modifications | Faible (historique des versions) | Complet si vous le prévoyez | Par champ, selon l’offre |
| Plusieurs écritures automatisées | Risqué | Prévu pour | Via son API, avec des limites |
| Tâches planifiées | Limitées | Natives | Selon le produit |
| Meilleur rôle | Le TAM d’une petite équipe | Le TAM quand il tourne avec du code | La relation avec le compte |
Un fichier Google Sheets accepte jusqu’à 10 millions de cellules, mais il ralentit bien avant, surtout avec des recherches entre onglets. En pratique, je resterais sur un tableur tant qu’une ou deux personnes maintiennent la liste, et je migrerais quand l’un de ces cas se présente :
- Deux processus automatisés doivent écrire en même temps.
- Vous voulez un historique de ce qui a changé sur chaque compte.
- Le recalcul des formules ralentit l’équipe.
- Les signaux sont devenus une grosse table interrogée chaque semaine.
Migrer trop tôt coûte plus cher que migrer tard : une base que personne dans l’équipe ne sait interroger devient un stockage que personne ne lit.
Donnez un seul propriétaire à chaque champ
La plupart des conflits de données viennent de deux systèmes qui écrivent le même champ. Tranchez une fois pour toutes et mettez le tableau dans votre documentation.
| Champ | Écrit par | Lu par |
|---|---|---|
| Domaine, SIREN, nom de l’entreprise | TAM | CRM, outil d’envoi |
| Secteur, effectif, localisation | TAM | CRM |
| Score de fit, tier | TAM | CRM |
| Signaux | TAM | CRM, commerciaux |
| Propriétaire du compte, étape du deal, activité | CRM | TAM (lecture seule) |
| Statut client | CRM | TAM, pour exclure |
| Désinscriptions | Le système qui les reçoit, recopiées aussitôt dans la table de suppression | Tous les systèmes avant tout envoi |
La règle de synchronisation : une valeur vide n’écrase jamais une valeur remplie, et seul le propriétaire d’un champ peut le modifier.
Un schéma qui tient la route
Utilisez le domaine comme clé primaire, comme expliqué dans le chapitre sur la déduplication. Pour un compte sans site web, générez une clé à partir du numéro du registre, comme siren-123456789.
CREATE TABLE companies (
domain text PRIMARY KEY,
siren char(9) UNIQUE,
name text NOT NULL,
naf text,
headcount_band text,
tier char(1),
fit_score int,
status text DEFAULT 'active',
crm_id text,
source text,
enriched_at date
);
CREATE TABLE contacts (
contact_id bigserial PRIMARY KEY,
domain text REFERENCES companies,
full_name text,
job_title text,
persona text,
linkedin_url text UNIQUE,
email text,
email_verified_at date,
source text,
enriched_at date
);
CREATE TABLE signals (
signal_id bigserial PRIMARY KEY,
account_domain text REFERENCES companies,
signal_type text NOT NULL,
signal_value text,
source text,
event_date date,
detected_at date,
used_in_campaign text
);
CREATE TABLE suppression (
match_value text PRIMARY KEY,
match_type text NOT NULL,
reason text,
added_at date NOT NULL
);
CREATE TABLE enrichment_log (
run_id bigserial PRIMARY KEY,
run_date date,
action text,
source text,
rows_sent int,
rows_filled int,
cost numeric
);
source et enriched_at rendent la table maintenable : ils disent ce qui est périmé et quel fournisseur a produit une valeur fausse. enrichment_log vous donne le coût réel par compte et le taux de remplissage par source, que vous devriez sinon reconstituer.
Dans un tableur, reprenez la même structure avec un onglet par table : companies, contacts, signals, suppression, log. Formatez chaque identifiant en texte : le format nombre supprime les zéros en tête des codes et le signe plus des numéros de téléphone. Gardez les formules dans un onglet de vue séparé, pour qu’un tri ou un import ne puisse pas les casser.
Un upsert qui respecte la règle des valeurs vides ressemble à ceci :
INSERT INTO companies (domain, siren, name, naf, headcount_band, source, enriched_at)
VALUES ($1, $2, $3, $4, $5, $6, CURRENT_DATE)
ON CONFLICT (domain) DO UPDATE SET
siren = COALESCE(EXCLUDED.siren, companies.siren),
naf = COALESCE(EXCLUDED.naf, companies.naf),
headcount_band = COALESCE(EXCLUDED.headcount_band, companies.headcount_band),
source = EXCLUDED.source,
enriched_at = EXCLUDED.enriched_at;
Prévoyez comment la donnée circule entre les systèmes
Trois mouvements couvrent la plupart des configurations.
| Mouvement | Quand | Comment |
|---|---|---|
| Enrichissement vers le TAM | À la construction, puis à chaque rafraîchissement | Outil d’enrichissement sur le tableur, ou script qui appelle une API |
| Du TAM vers le CRM | Quand un compte atteint un tier que les sales vont travailler | Import filtré avec le domaine comme clé, puis stockage du crm_id |
| Du CRM vers le TAM | Chaque semaine | Export ou lecture API du statut client, du propriétaire et des deals ouverts |
Commencez par des imports et des exports à la main, à jour fixe. C’est plus lent, mais vous verrez les erreurs et vous saurez exactement quoi automatiser ensuite. Tout ce que vous automatisez doit aller dans un seul sens par champ et garder une trace de ce qui a été écrit.
Voici ce que cela donne avec Derrick (un outil que j’ai cofondé, tenez-en compte). Chaque surface correspond à une étape différente. Pour une liste travaillée en lignes, l’application web ou la barre latérale Google Sheets : vous choisissez une fonctionnalité, vous mappez une colonne et le résultat arrive dans de nouvelles colonnes. Pour une tâche planifiée, un back-end ou un workflow sans code dans Zapier, Make ou n8n, l’API expose les mêmes actions au même coût en crédits. Pour une vérification rapide depuis un assistant IA, il y a le serveur MCP. L’API et le serveur MCP commencent au plan Plus.
Derrick s’occupe de l’enrichissement, et vos fiches vivent dans le CRM ou la base choisie plus haut. Pour transférer les résultats vers HubSpot ou Salesforce, passez par un export suivi d’un import, ou par une tâche écrite sur l’API. La méthode ci-dessus fonctionne de la même façon avec n’importe quel fournisseur d’enrichissement, ou avec une personne qui remplit des colonnes.
Protégez ce qui a demandé des mois de travail
Une liste construite à coups de crédits et d’heures mérite une hygiène de base, et quelques habitudes suffisent.
| Risque | Habitude |
|---|---|
| Un mauvais tri ou import mélange les lignes | Protégez les colonnes clés et gardez les imports bruts dans leur propre onglet |
| Écrasement massif par erreur | Copie datée hebdomadaire du fichier, ou dump planifié de la base |
| Tout le monde voit les données personnelles | Restreignez les accès par rôle et partagez des vues au niveau entreprise par défaut |
| Les données de contact se dispersent via les exports | Un seul emplacement pour les contacts, et suppression des copies de travail une fois la campagne terminée |
| Personne ne sait ce que signifie une colonne | Un onglet dictionnaire : champ, définition, propriétaire, fréquence de mise à jour |
Votre prochaine étape : rédigez le tableau de propriété des champs pour votre propre configuration, nommez la source de vérité en une phrase et créez les cinq onglets ou tables ci-dessus. Migrez votre liste actuelle en remplissant source et enriched_at, car la maintenance du TAM repose sur ces deux colonnes.