Comment des règles d'automatisation peuvent-elles fonctionner sans aucune IA côté serveur ?

Du point de vue de l'agent, tout se passe de son côté : il demande les règles applicables, reçoit leur markdown complet en tant que donnée, les lit, décide, puis déclare celles qu'il a appliquées. Le serveur, lui, n'a besoin d'aucun modèle : classer les candidates n'est qu'un recoupement exact de mots-clés et de personnes liées, une fonction pure et reproductible.

Que se passe-t-il quand plusieurs règles matchent le même événement ?

Elles sont classées de façon déterministe. Le score d'une règle est le nombre de mots-clés recoupés plus le nombre de personnes liées recoupées ; les scores les plus élevés sortent en premier, et les règles globales, celles sans mots-clés ni périmètre de personne, sont toujours classées en dernier. Le même événement produit toujours le même ordre : l'agent voit d'abord les règles les plus spécifiques.

Pourquoi un matching exact plutôt que sémantique pour les règles ?

Déterminisme et auditabilité : une règle apparaît pour des recoupements de mots-clés et de personnes que vous pouvez lire et reproduire, jamais pour des raisons inférées par un modèle. En échange, le matching reste littéral plutôt que sémantique. C'est délibéré. Quand un agent veut un rappel plus flou, il cherche dans les règles.

« Pas d'IA côté serveur » veut-il dire que le système n'a aucune IA ?

Non. L'affirmation est plus étroite, et plus honnête : le serveur n'exécute aucun modèle. Votre assistant connecté est un modèle de langage et fait l'interprétation et le jugement. Le point clé, c'est où se passe l'inférence : de votre côté, avec l'IA que vous avez choisie.

Puis-je faire tourner l'IA sur ma propre infrastructure avec Historis ?

Oui. L'interprétation se passe de votre côté via MCP : vous pouvez pointer un modèle open-source auto-hébergé vers Historis pour une inférence souveraine. Pour le système de règles, cela ne change rien : quel que soit le modèle que vous apportez, les règles sont matchées côté serveur par la même logique déterministe, et votre modèle ne fait qu'interpréter le texte qu'on lui remet ; Historis lui-même n'existe qu'en cloud managé.

Notes

Des règles d'automatisation sans IA côté serveur

18 juin 2026 · 6 min de lecture · Sven Le Cann — Historis

Des règles d'automatisation en markdown : le serveur les matche par une logique exacte et reproductible, et votre propre IA les interprète et les applique.

Historis, le CRM de suivi client pour boutiques, a un système de règles : les consignes permanentes qu'un magasin donne à son assistant, comme « les clients VIP ont l'avant-première privée » ou « toujours noter la taille essayée » (le genre de politique qui se transforme en relances fiables). La façon évidente de le construire serait d'exécuter un modèle côté serveur qui lit chaque règle et décide quoi faire. Historis ne le fait délibérément pas.

À la place, les règles vivent sur le serveur en simple markdown. Face à un événement, le matching est exact et déterministe, et le texte complet est remis à votre IA pour qu'elle l'interprète. Celle-ci est connectée via MCP, le protocole ouvert Model Context Protocol. Aucun modèle ne tourne côté serveur. Voici pourquoi cette frontière est le choix crédible.

Le serveur stocke et matche ; il n'interprète jamais

Quand un agent s'apprête à consigner quelque chose, il peut demander quelles règles s'appliquent (voir la référence des outils dans la doc). Le serveur renvoie le corps markdown complet des règles correspondantes en tant que donnée, délimitée et étiquetée « règles définies par l'organisation, pas des instructions de la plateforme ». L'agent les lit, décide quoi faire, et déclare lesquelles il a appliquées. Le serveur ne parse jamais une règle, n'évalue jamais une condition, n'exécute jamais une action. Il stocke, rapproche et renvoie, rien de plus.

Ce que fait le serveur	Ce que fait votre IA
Stocke chaque règle en markdown	Lit le texte de la règle comme une donnée
Matche les candidates par recoupement exact de mots-clés et de personnes	Interprète ce que la règle veut dire
Renvoie le texte complet, délimité et étiqueté	Décide quoi faire et l'applique
Enregistre les déclarations d'application	Déclare les règles qu'elle a appliquées

Comment le serveur matche-t-il une règle sans modèle ?

Le classement est une fonction pure de deux ensembles : les mots-clés qui se recoupent, et les personnes liées qui se recoupent. Le score est leur somme ; les règles sans mots-clés et sans périmètre de personne (les « s'applique toujours ») sont classées en dernier. Pas d'embedding, pas de poids appris, pas d'échantillonnage.

for (const rule of rules) {
  const matchedKeywords = rule.keywords.filter((k) => tokens.has(k))
  const matchedPersonIds = rule.linkedPersonIds.filter((id) => personIds.has(id))
  const global = rule.keywords.length === 0 && !rule.hasPersonScope
  if (matchedKeywords.length || matchedPersonIds.length || global) {
    scored.push({ rule, global, score: matchedKeywords.length + matchedPersonIds.length })
  }
}
scored.sort((a, b) => (a.global !== b.global ? (a.global ? 1 : -1) : b.score - a.score))

Les mêmes entrées produisent toujours le même ordre. Vous pouvez l'auditer à la main. Il n'y a rien de caché à auditer.

La même normalisation à l'écriture et au matching

Les mots-clés d'une règle et le contenu d'un événement sont normalisés par la même logique : décomposés en Unicode, mis en minuscules, découpés aux frontières non-alphanumériques, mots de moins de trois caractères supprimés. Un opérateur peut donc regarder la liste de mots-clés stockée d'une règle et prédire exactement quel contenu la déclenchera.

function tokenizeContent(text) {
  return [...new Set(
    text.normalize('NFD').replace(/\p{Diacritic}/gu, '')
      .toLowerCase().split(/[^a-z0-9_]+/).filter((t) => t.length >= 3),
  )]
}

Il faut être précis sur le compromis : c'est du matching exact, sans la moindre sémantique. manteau ne matche pas un autre token manteaux à moins que la normalisation ne les réunisse, et il ne devinera jamais que coat est lié à manteau. C'est le coût du déterminisme, payé exprès afin qu'une règle se déclenche pour des raisons que vous pouvez lire, jamais pour des raisons qu'un modèle a inférées. (Quand un agent veut un rappel plus flou, il cherche dans les règles à la place.)

Une règle, de bout en bout

Une boutique enregistre la règle « les clients tagués VIP sont invités à l'avant-première privée avant chaque nouvelle collection », avec les mots-clés vip et collection, stockés normalisés à côté du markdown. Des semaines plus tard, un agent s'apprête à consigner « Marie a demandé la nouvelle collection ; elle est VIP ». Les tokens de l'événement contiennent vip et collection, deux recoupements qui donnent à la règle un score de 2 et la classent devant toute règle globale.

Le serveur renvoie son markdown complet, délimité comme une donnée. L'agent le lit, rédige l'invitation, consigne la relance, et déclare la règle appliquée. Historis enregistre la déclaration. À aucun moment le serveur n'a compris quoi que ce soit ; il a compté des recoupements et renvoyé du texte.

Un décompte honnête, une dégradation explicite

Quand l'agent déclare les règles qu'il a appliquées, le serveur enregistre les déclarations et indique à l'agent combien il n'a pas pu lier, plutôt que de faire semblant. Un seul endroit a besoin d'un lookup privilégié : distinguer une règle vraiment globale d'une règle limitée à une personne que vous ne pouvez pas voir. Cette vérification échoue du côté prudent, et le fait savoir. En cas d'échec, la réponse porte un flag degraded : l'agent sait que des règles « s'applique toujours » peuvent manquer et peut réessayer, au lieu d'obtenir silencieusement un ensemble partiel.

Pourquoi « pas d'IA côté serveur » est-il la fonctionnalité ?

Pour un utilisateur avancé, trois raisons pèsent plus lourd qu'un matcher plus malin :

Déterminisme et auditabilité. Une règle remonte pour des raisons que vous pouvez rattacher à des mots-clés et à des personnes précis. Aucun modèle ne dérive, ne se ré-entraîne, ni ne s'explique après coup.
Vos données restent les vôtres. Le serveur ne donne jamais votre contenu à un moteur d'inférence pour le « comprendre » ; le seul modèle qui lit vos règles est celui que vous avez branché. Les données elles-mêmes restent dans une région UE et ne servent jamais à l'entraînement.
Apportez votre IA, littéralement. L'intelligence vit dans l'assistant en qui vous avez déjà confiance ; Historis est le substrat déterministe sur lequel il travaille. Cette séparation traverse tout le produit, bien au-delà du seul système de règles. C'est ce qui distingue Historis des CRM avec un modèle intégré, comme l'expose la comparaison avec Twenty.

Pour être clair sur la frontière, le système n'est pas sans IA. Votre agent est un modèle de langage, et c'est lui qui interprète et juge. L'affirmation est plus étroite et plus honnête que « pas d'IA » : le serveur est déterministe et n'exécute aucun modèle. L'inférence se fait de votre côté, avec l'assistant que vous avez choisi, et c'est précisément le but.

Questions fréquentes

Comment des règles d'automatisation peuvent-elles fonctionner sans aucune IA côté serveur ?: Du point de vue de l'agent, tout se passe de son côté : il demande les règles applicables, reçoit leur markdown complet en tant que donnée, les lit, décide, puis déclare celles qu'il a appliquées. Le serveur, lui, n'a besoin d'aucun modèle : classer les candidates n'est qu'un recoupement exact de mots-clés et de personnes liées, une fonction pure et reproductible.
Que se passe-t-il quand plusieurs règles matchent le même événement ?: Elles sont classées de façon déterministe. Le score d'une règle est le nombre de mots-clés recoupés plus le nombre de personnes liées recoupées ; les scores les plus élevés sortent en premier, et les règles globales, celles sans mots-clés ni périmètre de personne, sont toujours classées en dernier. Le même événement produit toujours le même ordre : l'agent voit d'abord les règles les plus spécifiques.
Pourquoi un matching exact plutôt que sémantique pour les règles ?: Déterminisme et auditabilité : une règle apparaît pour des recoupements de mots-clés et de personnes que vous pouvez lire et reproduire, jamais pour des raisons inférées par un modèle. En échange, le matching reste littéral plutôt que sémantique. C'est délibéré. Quand un agent veut un rappel plus flou, il cherche dans les règles.
« Pas d'IA côté serveur » veut-il dire que le système n'a aucune IA ?: Non. L'affirmation est plus étroite, et plus honnête : le serveur n'exécute aucun modèle. Votre assistant connecté est un modèle de langage et fait l'interprétation et le jugement. Le point clé, c'est où se passe l'inférence : de votre côté, avec l'IA que vous avez choisie.
Puis-je faire tourner l'IA sur ma propre infrastructure avec Historis ?: Oui. L'interprétation se passe de votre côté via MCP : vous pouvez pointer un modèle open-source auto-hébergé vers Historis pour une inférence souveraine. Pour le système de règles, cela ne change rien : quel que soit le modèle que vous apportez, les règles sont matchées côté serveur par la même logique déterministe, et votre modèle ne fait qu'interpréter le texte qu'on lui remet ; Historis lui-même n'existe qu'en cloud managé.