Le pattern de CRM personnel par IA utilise un agent pour scanner automatiquement Gmail et Google Calendar et construire des profils de contacts à partir de l’historique des interactions. Il adresse le mode d’échec du suivi dans les relations de conseil : des contacts qui s’éteignent parce que d’autres travaux ont pris le dessus. Il nécessite également une configuration soigneuse en raison de la sensibilité de l’accès à l’email.
Ce que fait le pattern
OpenClaw est l’implémentation la plus documentée. L’agent scanne automatiquement Gmail et Google Calendar et construit des profils à partir de l’historique d’interactions trouvé, sans saisie manuelle.
Les données stockées comprennent :
- Profils de contact — nom, organisation, rôle (déduit des signatures d’email et des invitations de calendrier), historique d’interactions
- Chronologie des interactions — dates des emails envoyés et reçus, dates de réunion, titres des événements de calendrier
- Score de santé de la relation — un signal composite basé sur la récence (quand avez-vous interagi pour la dernière fois ?) et la fréquence (à quelle fréquence interagissez-vous habituellement ?)
Les données vivent localement dans SQLite. L’agent stocke des embeddings vectoriels des résumés d’interactions à côté des enregistrements structurés, ce qui permet des requêtes en langage naturel sur l’historique des relations.
Requêtes en langage naturel sur l’historique des relations
Le stockage d’embeddings vectoriels signifie que vous pouvez poser des questions conversationnelles plutôt qu’écrire du SQL :
- « Avec qui dois-je faire un suivi cette semaine ? »
- « Quand ai-je parlé pour la dernière fois à quelqu’un chez Decathlon ? »
- « Quels prospects sont devenus silencieux le mois dernier ? »
- « Quel était le statut du projet Lafuma la dernière fois que je me suis manifesté ? »
L’agent comprend le contexte, pas seulement les correspondances de mots-clés. « Quelqu’un chez Decathlon » retourne des résultats sur toute personne dont l’email ou l’enregistrement de calendrier les associe à Decathlon — pas seulement les contacts qui ont « Decathlon » dans un champ spécifique.
C’est là que le pattern devient réellement utile plutôt qu’un simple exercice de collecte de données. Un CRM traditionnel vous demande de naviguer dans son interface, d’exécuter des vues filtrées et d’interpréter les résultats. Un CRM basé sur un agent répond à la façon dont vous pensez réellement à vos relations.
Rappels de suivi proactifs
L’élément proactif est ce qui distingue cela d’un simple journal de contacts passif. L’agent vous envoie des mises à jour quotidiennes de statut via WhatsApp ou Telegram, signalant les relations qui nécessitent de l’attention :
« Vous n’avez pas pris de nouvelles de Lafuma depuis 2 semaines. » « Votre dernier email à PVCP remonte à 10 jours et ils n’ont pas répondu. » « Vous avez un appel programmé avec Decathlon jeudi — la dernière interaction remonte à 3 semaines. »
Ce sont exactement les choses qui passent à travers les mailles quand vous êtes absorbé dans une migration de données ou une livraison de sprint. L’agent n’oublie pas. Il ne se laisse pas absorber par votre projet en cours. Il surveille la chronologie des relations par rapport aux seuils que vous avez définis et vous relance quand l’écart se creuse.
Les seuils sont configurables. Un prospect chaud que vous cherchez activement à convaincre peut être signalé après 3 jours de silence. Un client établi sous contrat récurrent peut ne pas nécessiter d’attention à moins que 2 semaines ne se soient écoulées. Vous définissez les règles une fois ; l’agent les applique en continu.
Commencer avec l’intégration calendrier uniquement
Le pattern complet nécessite l’accès à l’email, qui est l’une des intégrations à plus haut risque disponibles — il donne à un agent automatisé la capacité de lire l’intégralité de la boîte de réception. L’incident où la boîte de réception d’un chercheur a été massivement supprimée par un agent incontrôlé démontre le risque opérationnel de traiter l’accès à l’email comme un défaut.
Un point de départ pragmatique : implémenter le CRM avec l’intégration calendrier uniquement d’abord.
Les données calendrier vous donnent :
- Historique des réunions — avec qui vous avez rencontré, quand, à quelle fréquence
- Patterns de réunion — quels clients ont des check-ins réguliers planifiés, lesquels sont ad hoc
- Préparation des prochaines réunions — récupérer le contexte pour l’appel de demain sans avoir besoin de l’historique des emails
L’accès au calendrier est moins risqué que l’accès à l’email parce que le rayon d’impact d’un agent mal configuré est limité. Un agent lisant les calendriers pourrait exposer les titres de réunions et les participants au mauvais endroit ; il ne peut pas supprimer des emails ou transférer de la correspondance sensible.
Après avoir vu le setup calendrier uniquement se comporter de façon fiable pendant quelques semaines, vous pouvez évaluer si l’ajout de l’accès à l’email vaut la capacité supplémentaire qu’il apporte. Le principe de voir-avant-d’élargir s’applique ici de la même façon qu’au scoping de l’accès aux bases de données : commencer avec le minimum utile, élargir seulement après avoir fait confiance au comportement au niveau actuel.
L’architecture de stockage
Comprendre ce qui est stocké vous aide à évaluer les implications en matière de confidentialité.
Base de données SQLite (données structurées) : enregistrements de contacts, horodatages d’interactions, scores de relation, métadonnées de réunions.
Embeddings vectoriels (couche sémantique) : représentations compressées des résumés d’interactions — pas le texte complet des emails, mais des vecteurs sémantiques qui permettent la recherche par similarité. L’agent les utilise pour répondre à « qui ressemble à X » ou « quelles interactions se rapportent au sujet Y ».
Les deux sont stockés localement sur la machine faisant tourner l’agent. C’est la différence clé avec un CRM cloud : les données ne quittent pas votre infrastructure. Elles ne sont pas envoyées aux serveurs de Salesforce ni synchronisées avec un service tiers. Le modèle de confidentialité se rapproche davantage d’une « application locale avec capacités IA » que d’un « SaaS cloud avec fonctionnalités IA ».
Le modèle de stockage local signifie que les sauvegardes sont votre responsabilité. Un fichier SQLite qui n’est pas sauvegardé et vit sur une machine qui tombe en panne emporte l’historique des relations avec lui. Pour un consultant solo dont le business dépend de la continuité des relations, perdre ces données est un coût réel. Sauvegardez le répertoire de données OpenClaw dans le cadre de votre routine de sauvegarde régulière.
Ce que le pattern ne peut pas faire
L’évaluation honnête des limitations :
Il ne peut pas vous dire quoi dire. L’agent peut vous dire que vous devez faire un suivi avec un client. Il ne peut pas vous dire quel est le bon message, quand le contexte de la relation rend une approche particulière appropriée, ou si c’est une bonne semaine pour prendre contact étant donné ce que vous savez de leur situation. L’intelligence relationnelle est la vôtre ; l’agent suit la mécanique.
Les scores de santé des relations sont des approximations. « N’avez pas parlé depuis 2 semaines » est un signal, pas un tableau complet. Certaines relations client ont des périodes naturellement calmes — des phases de projet où il n’y a aucune raison de prendre contact. D’autres refroidissent soudainement d’une façon significative. L’agent ne peut pas distinguer ces cas ; vous le pouvez.
Le contexte des emails est superficiel. L’agent lit les lignes d’objet, les patterns expéditeur/destinataire et potentiellement les corps des messages (selon la configuration). Il ne comprend pas le registre émotionnel de l’interaction, l’histoire qui rend une phrase particulière significative, ou les dynamiques organisationnelles du côté client. L’intelligence relationnelle qu’il construit est meilleure qu’aucun enregistrement, mais elle est structurellement superficielle.
Consentement et confidentialité. Si les clients seraient mal à l’aise de savoir qu’un agent IA a lu votre correspondance email avec eux et construit un profil de relation à partir de celle-ci, c’est une considération pertinente. La plupart des contrats client n’abordent pas le traitement des données par IA, mais certains le font. Vérifiez les vôtres avant de connecter l’accès à l’email à un agent.
Ordre de mise en place pratique
- Commencer avec l’intégration calendrier uniquement. Faire fonctionner l’historique des réunions et la préparation des prochaines. Utiliser pendant 2 à 4 semaines.
- Définir vos seuils de suivi. Quelle période de silence est normale vs. un signal d’alerte ? Des règles différentes pour différents types de relations (client actif, prospect, ancien client, contact réseau).
- Configurer et tester les rappels proactifs. S’assurer que les messages sont utiles et non accablants. Ajuster les seuils selon ce que vous recevez.
- Évaluer l’accès à l’email. Après que le setup calendrier uniquement fonctionne bien, décider si la capacité supplémentaire du scan des emails vaut l’exposition additionnelle. C’est probablement le cas pour les relations client actives. Ce ne l’est peut-être pas pour les contacts plus anciens ou moins prioritaires.
- Mettre en place la sauvegarde. Avant que des données significatives ne s’accumulent, s’assurer que le fichier SQLite et le store d’embeddings sont inclus dans votre sauvegarde régulière.