CRM événementiel : événements, pas tâches

La plupart des outils qui organisent le travail tournent autour de la tâche : quelque chose que vous prévoyez de faire, que vous assignez et que vous cochez. Un CRM construit autour des événements, comme Historis, fonctionne autrement. Il enregistre ce qui s'est passé. Un appel, une commande, une réclamation, une visite, chacun daté et relié à la personne concernée.

Cette différence compte surtout dès qu'il y a plus d'une personne. Une liste de tâches appartient à celui qui l'a écrite. Un relevé de ce qui s'est passé appartient à l'entreprise. Quand toute votre équipe écrit dans la même timeline, et que les assistants IA avec qui elle travaille y écrivent aussi, vous ne tenez plus de listes séparées : vous construisez la mémoire de l'entreprise, ensemble, au fil de l'eau.

Pourquoi un CRM événementiel survit à la liste de tâches

Une tâche est un pense-bête que vous vous laissez pour plus tard. Faire X avant vendredi. Utile jusqu'au moment où elle est faite, puis elle disparaît. Une liste de tâches est conçue pour se vider d'elle-même.

Prenez cette ligne : « Marie a appelé pour la fuite, toujours sous garantie. » C'est un événement. Personne ne la coche ni ne la supprime. Elle reste. La semaine suivante, un collègue qui n'a jamais parlé à Marie peut la lire et reprendre là où ça s'était arrêté. Un an plus tard, c'est la raison pour laquelle quelqu'un se souvient du dossier garantie.

Les tâches se vident. Le relevé se remplit.

Tout le monde peut-il écrire dans la même mémoire en même temps ?

C'est là qu'une équipe en tire bien plus qu'une seule personne. Dans une app de tâches, ou un tableur utilisé comme liste de tâches partagée, chacun tient sa liste, et la vue d'ensemble vit dans la tête de quelqu'un ou dans une réunion hebdomadaire. Un CRM basé sur les événements, lui, tient une seule timeline, et toute l'équipe y écrit pendant que le travail se fait.

La personne au comptoir consigne la visite ; l'atelier ajoute ce qu'il a constaté ; le back-office enregistre le remboursement. Et l'assistant IA avec qui chacun travaille lit et écrit cette même timeline, où il classe ce qui a été dit et rédige le message suivant à partir de l'historique du client. Un seul relevé, écrit en parallèle par les gens et leurs agents.

Personne n'a besoin de s'arrêter pour se synchroniser, parce que le relevé est la synchronisation. Quand quelqu'un est en congé, malade ou s'en va, ce qu'il savait ne part pas avec lui. C'est déjà dans la timeline, prêt pour la personne suivante et l'agent suivant.

Comment votre IA travaille à partir de faits plutôt que d'une liste d'intentions

Un assistant ne peut s'appuyer que sur ce qu'il voit. Une liste de tâches, ce sont des suppositions sur le futur, tandis qu'une timeline partagée est un relevé de ce qui s'est réellement passé. C'est ce sur quoi vous voulez qu'un agent raisonne.

Quelqu'un demande à son assistant l'état d'un compte. Il lit la timeline, voit que la garantie est toujours ouverte et que le dernier appel date de trois jours, et rédige la relance, le tout à partir d'événements que l'équipe a réellement consignés.

Donnez maintenant à une dizaine de personnes leur propre assistant, tous pointés sur le même relevé. L'entreprise avance plus vite, et personne ne se retrouve à travailler sur une version différente de l'histoire. (Chaque assistant est le vôtre, connecté via MCP, le Model Context Protocol ; Historis n'exécute aucun modèle. Les lectures et écritures restent traçables : marquées, attribuées, journalisées et réversibles.)

Le relevé est l'actif

Les tâches ouvertes n'ont jamais été ce qu'il fallait garder. La mémoire de l'entreprise, oui. Le centième événement sur un client vaut plus que le premier, parce qu'il repose sur les quatre-vingt-dix-neuf précédents. Cette mémoire survit au turnover, grandit avec l'équipe, et c'est la chose la plus difficile à copier pour un concurrent.

Ce que Historis n'est pas

Historis n'est pas contre la planification. Les échéances et les relances existent, et le brief du jour fait remonter ce qu'il faut traiter. Elles sont simplement rattachées à l'événement qui les a créées, au lieu de vivre sur une liste séparée qui s'éloigne peu à peu du réel. Quand le dossier garantie de Marie est enregistré, la relance pour vérifier la réparation s'accroche à cet événement ; une semaine plus tard, elle remonte dans le brief, toute l'histoire juste en dessous.

Et si ce que vous voulez, c'est un tableau de projet avec sprints et burndown charts, c'est un autre type d'outil. Historis, c'est là où votre équipe enregistre ce qui s'est passé avec vos clients, et là où ses assistants vont le retrouver.

Pourquoi l'avons-nous construit comme ça ?

La mémoire d'une entreprise ne devrait pas dépendre de qui est présent ce jour-là. Elle devrait être écrite par tous ceux qui font le travail, et par les assistants qui les aident, et elle devrait rester là quand les gens changent.

C'est la même raison pour laquelle nous n'exécutons aucun modèle nous-mêmes et confions les règles d'automatisation à votre propre IA : la mémoire est à vous plutôt qu'à l'outil qui vient se poser dessus cette année. Alors nous avons fait du relevé, pas de la liste de tâches, la chose sur laquelle le produit est bâti.