Le symptôme : deux outils, une info, deux versions
Vous pilotez vos projets dans Notion. Votre pipe commercial vit dans le CRM, HubSpot, Salesforce ou Pipedrive selon la maison. Entre les deux, quelqu'un recopie à la main : le statut d'un projet qui doit remonter côté CRM, une note client qui doit redescendre côté Notion. Au début ça tient, parce que c'est une seule personne qui fait le pont dans sa tête.
Puis les deux versions divergent. Le champ « statut » dit une chose dans Notion et une autre dans le CRM, et plus personne ne sait laquelle fait foi. Ce n'est pas un problème d'outil. C'est un problème de discipline de données. Un champ sans propriétaire clair divergera toujours, que vous soyez sur Notion, un CRM ou un tableur partagé.
Pourquoi la synchronisation casse, la plupart du temps
« On a déjà essayé Zapier et ça a cassé. » Je l'entends souvent. Ce qui a cassé, ce n'est pas Zapier, Make ou n8n. C'est l'absence de contrat de données en amont : personne n'avait tranché qui décide de la valeur d'un champ, ni dans quel sens l'information doit circuler. Le connecteur a fait exactement ce qu'on lui a demandé, deux mises à jour concurrentes sur le même champ, sans arbitre pour trancher.
un outil de sync ne remplace jamais une décision qu'on n'a pas prise
La méthode : un champ, un propriétaire, un sens
Avant de brancher quoi que ce soit, on cadre la synchronisation comme on cadrerait n'importe quel process. Sept étapes, dans l'ordre.
- Désigner la source de vérité par type d'information. Le nom du contact, sa fonction, l'historique d'achat : propriété du CRM. L'avancement du projet, les livrables, les notes de réunion : propriété de Notion. Un champ, un seul propriétaire.
- Définir le sens de synchronisation. Commencer uni-directionnel, un outil source qui pousse vers un outil miroir, règle la majorité des cas. Le bi-directionnel n'entre en jeu que si les deux outils doivent réellement écrire sur le même champ, ce qui devient rare une fois les propriétaires posés.
- Mapper les champs, explicitement, un par un. Ce qui n'est pas mappé ne se synchronise pas, et c'est un choix assumé, pas un oubli.
- Brancher la sync via API ou connecteur (Make, Zapier, n8n), de façon déterministe. Une règle, une action, prévisible et reproductible à chaque exécution.
- Réserver le LLM aux transformations de langage. Résumer une fiche projet Notion en une note CRM lisible pour un commercial, par exemple.
- Tester sur un sous-ensemble. Une poignée de fiches, pas toute la base. On observe, on corrige le mapping, puis on élargit.
- Écrire le mémo. Qui possède quoi, dans quel sens l'information circule, comment relancer si ça casse.
Le LLM, à sa juste place
La tentation, avec les LLM disponibles aujourd'hui, c'est de leur confier tout le pont entre les deux outils : lire Notion, décider quoi faire, écrire dans le CRM. Ça marche en démo. Ça casse en production, parce qu'un LLM n'est pas déterministe : il peut interpréter différemment le même texte deux fois de suite. La sync elle-même doit rester une mécanique d'API, testable et prévisible. Le LLM intervient seulement là où le jugement de langage a de la valeur, condenser une fiche, reformuler un ton, jamais trancher qui a raison entre deux champs contradictoires.
C'est le même principe qui fait tourner mon second cerveau IA au quotidien : un contrat de données clair, posé avant tout branchement, pas un LLM à qui on délègue la décision.
Commencer petit, refuser le grand soir
La bonne échelle de départ, c'est un type d'objet (les fiches projet, par exemple), une poignée de champs, un sens unique. Une fois que ça tourne sans surprise pendant quelques semaines, vous élargissez. C'est la même logique que pour sortir du niveau 1 : on skillise un cas précis avant de généraliser, plutôt que de viser la synchronisation parfaite de toute la base dès le premier essai.
Si votre irritant côté CRM est plutôt l'enrichissement des leads à la main avant qu'ils y entrent, c'est un problème voisin, et j'en parle dans un autre article.