Pourquoi votre CRM a onze éditeurs de filtres

Ouvrez un CRM mature et faites ce test. Créez un filtre dans une vue en liste. Puis créez le même filtre sous forme de segment marketing. Puis comme condition dans une automatisation. Puis comme filtre de rapport. Quatre éditeurs, quatre jeux d’opérateurs légèrement différents, et au moins un endroit où il manque précisément ce dont vous avez besoin.

C’est presque universel dans la catégorie, et ce n’est pas parce que les équipes qui conçoivent ces produits sont négligentes. C’est le résultat prévisible d’un choix : traiter le filtrage comme une fonctionnalité plutôt que comme un moteur. Et c’est vous qui en payez le prix, chaque semaine, sous une forme difficile à nommer lors d’une évaluation mais évidente au quotidien.

Comment on en arrive là

Un CRM sort avec des vues en liste. Quelqu’un écrit un éditeur de filtres pour ces vues. Deux ans plus tard, l’entreprise ajoute le marketing, et l’équipe marketing a besoin de segmenter ses audiences. Elle pourrait réutiliser le filtre des vues en liste, mais ce code est lié à une interface en tableau, suppose une taille de page et se trouve dans un module qui n’appartient pas à l’équipe marketing. La décision pragmatique, celle que prendrait n’importe quel responsable technique raisonnable face à une échéance, consiste à écrire un éditeur de segments.

Puis arrivent les automatisations, qui ont besoin de conditions. Puis les rapports, qui ont besoin de filtres avec regroupement. Puis les permissions par fiche, qui sont en réalité un filtre appliqué de façon invisible à chaque requête. Puis la recherche par IA, qui doit transformer une phrase en requête. Chacun est construit par une équipe différente, à un trimestre différent, avec une échéance différente.

Rien n’est cassé. Chaque éditeur fonctionne. Mais ils divergent, et en matière de filtrage la divergence est particulièrement sournoise, car les différences restent invisibles jusqu’au moment où elles vous piègent :

• La vue en liste traite une chaîne vide et une valeur nulle comme la même chose. L’éditeur de segments, non.
• La vue en liste peut filtrer sur un champ d’une fiche liée. L’éditeur de rapports ne peut filtrer que sur l’objet qu’il a sous les yeux.
• La condition d’automatisation évalue les dates en UTC. La vue les évalue dans votre fuseau horaire. Les deux se défendent ; ensemble, c’est un bug qui vous coûtera un après-midi.
• Un éditeur propose « fait partie de ». Un autre ne propose que « est égal à », alors vous créez trois règles reliées par un OU.

Résultat : la réponse à « est-ce que je peux filtrer là-dessus ? » n’est jamais oui ou non. C’est « sur quel écran êtes-vous ? »

Ce que ça vous coûte vraiment

Trois choses, par ordre d’importance croissante.

Vous apprenez à filtrer plusieurs fois

Chaque nouvelle personne dans votre équipe apprend quatre éditeurs au lieu d’un, et les apprend en découvrant leurs différences. Cela se traduit par un ralentissement lent et impossible à attribuer pendant la prise en main, pour lequel personne n’ouvre de ticket.

La logique est ressaisie au lieu d’être réutilisée

Vous définissez « comptes grands clients sans activité depuis trente jours » dans une vue. Plus tard, vous voulez une campagne pour cette audience, alors vous la recréez dans l’éditeur de segments. Puis une automatisation, alors vous la recréez encore. Vous avez maintenant trois définitions d’une même idée, entretenues à la main. Quand la définition change (un grand client passe de 100 à 200 sièges), vous devez penser aux trois. Vous ne le ferez pas.

Les capacités arrivent de façon inégale, pour toujours

C’est celle qui s’aggrave avec le temps. Quand le produit ajoute un nouvel opérateur, il arrive dans l’éditeur que maintient l’équipe concernée. Au bout de cinq ans, l’écart entre votre filtre le plus complet et le plus limité est énorme, et chaque demande pour la feuille de route devient « dans lequel des cinq le voulez-vous en premier ? »

Une vue enregistrée, un segment marketing, une condition de workflow, un filtre de rapport et une question posée à l’IA devraient être le même objet passant par le même compilateur.

L’alternative, et ce qu’elle exige

L’alternative consiste à faire du filtrage un moteur que tout le reste utilise. Une seule représentation d’un filtre (une définition structurée et sérialisable) et un seul compilateur qui la transforme en requête de base de données. Chaque écran devient une manière différente de construire ou d’afficher ce même objet.

Ce n’est pas gratuit. Cela exige une discipline vraiment inconfortable :

1. Le format de filtre doit être conçu avant les fonctionnalités qui l’utilisent, c’est-à-dire au moment où vous êtes le moins sûr des besoins.
2. Chaque partie qui l’utilise doit accepter les règles communes, y compris celles qui gênent son propre écran.
3. Personne n’a le droit d’ajouter un petit cas particulier. Un cas particulier dans un moteur commun, c’est un cas particulier dans cinq produits.
4. Il vous faut des tests de conformité, car une divergence subtile dans le compilateur devient une divergence subtile partout à la fois.

En contrepartie, les capacités arrivent partout en même temps. Quand nous ajoutons le parcours des fiches liées, il apparaît le même jour dans les vues, les segments, les conditions d’automatisation, les rapports, les permissions et la recherche par IA, non pas parce que cinq équipes se sont coordonnées, mais parce qu’il n’y a jamais eu qu’une seule implémentation.

Ce qui nous a surpris

Nous pensions que le bénéfice serait un gain d’efficacité technique. Le plus gros bénéfice, ce sera l’IA.

Quand vous posez une question sur vos données à un copilote IA, il doit produire quelque chose. S’il produit du texte, vous ne pouvez pas le vérifier. S’il produit du SQL brut, il peut inventer une requête qui ne respecte pas vos permissions, ou qui est fausse d’une manière subtile que vous ne remarquerez pas.

Comme nous avons déjà un seul et unique format de filtre, la recherche en langage courant que nous construisons produit ce format. Elle arrive bientôt, et c’est pour cela qu’elle sera fiable. Trois conséquences en découlent sans effort supplémentaire, et aucune n’était la raison de notre choix :

• Elle ne peut pas exprimer un filtre que le produit ne sait pas exécuter : le format est la contrainte.
• Elle hérite automatiquement des permissions, car le compilateur est le même que celui qui applique l’accès par fiche dans l’interface.
• Vous pouvez lire ce qu’elle a écrit, le corriger et l’enregistrer comme vue. La réponse est vérifiable, et une réponse vérifiable est une réponse à laquelle vous pourrez un jour confier d’agir seule.

La décision d’architecture qui ressemblait à du simple rangement interne est ce qui rendra la recherche par IA fiable plutôt que décorative. C’est souvent ainsi avec les fondations : la raison pour laquelle vous êtes content de les avoir posées est rarement celle pour laquelle vous les avez posées.

Comment le vérifier vous-même

Inutile de croire une promesse d’architecture sur parole. Pendant l’essai de n’importe quel CRM, consacrez dix minutes à ceci :

1. Créez dans une vue en liste un filtre un peu tordu, qui implique une fiche liée et une valeur vide.
2. Essayez de créer exactement le même filtre comme audience de campagne.
3. Recommencez comme condition d’automatisation, puis encore comme filtre de rapport.
4. Posez à l’IA une question qui devrait produire ce même filtre, et regardez si vous pouvez examiner ce qu’elle a exécuté.

Si les cinq concordent, le produit a un moteur. Sinon, vous avez trouvé les onze éditeurs, et vous savez déjà auquel des cinq il manquera l’opérateur dont vous aurez besoin au quatrième mois.