Périmètre

Le périmètre répond à une seule question pour chaque mail qui arrive : ce mail a-t-il le droit d’entrer dans les workflows ? La décision est prise à la réception du mail, avant qu’un workflow ne s’exécute et avant qu’un modèle d’IA ne le voie. Un mail hors périmètre n’est traité par aucun workflow, mais il reste dans le miroir et visible dans le webmail : rien n’est supprimé ni caché.

Le périmètre ne regarde que l’expéditeur — son adresse et son domaine. L’aiguillage selon les destinataires, l’objet, le contenu ou les pièces jointes est le rôle des conditions de déclencheur, pas du périmètre.

Deux couches de règles

Trois couches décident si un mail peut entrer dans les workflows ; la première qui s’applique l’emporte

	Règles de l’organisation	Mes règles
Qui les définit	un administrateur, dans Administration → Périmètre	chaque membre pour lui-même, dans Réglages → Mon périmètre
S’appliquent à	tous les membres, toutes les boîtes	les boîtes du membre
Modes	exclusions seulement	« Tout traiter, sauf… » ou « Ne traiter que… »
Listes	Domaines, Adresses	Domaines, Adresses
Contournables	non : ni un membre ni un workflow ne peut les lever	—

L’organisation tranche d’abord. Ses règles valent pour tout le monde et ne sont pas contournables. Les règles de chaque membre s’appliquent ensuite, et ne peuvent que restreindre davantage, jamais élargir : un membre en mode « Ne traiter que… » qui liste un domaine exclu par l’organisation ne le fait pas revenir.

Usages typiques :

• organisation : exclure le domaine de l’entreprise, pour que le courrier interne n’entre jamais dans les workflows ; exclure des adresses sensibles (direction, ressources humaines, délégué à la protection des données) ;
• membre : exclure un contact personnel ou un client sensible ; ou, en mode « Ne traiter que… », ne laisser voir aux workflows que les mails de deux domaines clients.

Les règles de l’organisation

1. Ouvrez Administration → Périmètre (réservé aux administrateurs).
2. Sous « Règles de l’organisation » — « Les expéditeurs que les workflows ne traiteront jamais, pour tout le monde. » —, ajoutez des entrées dans Domaines et Adresses.
3. Enregistrez. La page confirme « Périmètre de l’organisation enregistré. »

La couche de l’organisation n’a pas de mode « ne traiter que », et c’est voulu : elle pourrait sinon ouvrir ce que les règles d’un membre élargiraient ensuite.

Mes règles

1. Ouvrez Réglages → Mon périmètre.
2. Sous « Mes règles », choisissez le Mode :
   • Tout traiter, sauf… (par défaut) — « Vos workflows voient tous vos mails, à l’exception des expéditeurs listés ci-dessous. » ;
   • Ne traiter que… — « Vos workflows ne voient que les mails des expéditeurs listés ci-dessous, et rien d’autre. »
3. Remplissez Domaines et Adresses, puis enregistrez (« Périmètre enregistré. »).

Ne traiter que… avec des listes vides

En mode « Ne traiter que… » avec des listes vides, plus aucun mail n’est traité par vos workflows. La page affiche un avertissement dans ce cas.

Le réglage par défaut — « Tout traiter, sauf… » avec des listes vides — traite tout. Un membre ne modifie que ses propres règles ; un administrateur ne peut pas modifier celles d’un autre membre.

La correspondance des entrées

Entrée	Correspond à	Exemple
Un domaine (client.example ou @client.example)	le domaine de l’expéditeur et ses sous-domaines	client.example correspond à anna@client.example et à anna@mail.client.example, mais pas à anna@autreclient.example
Une adresse complète (direction@entreprise.example)	cette adresse exacte	—

• La casse est ignorée, dans toute l’adresse : Direction@Entreprise.example et direction@entreprise.example sont la même entrée.
• Les entrées sont normalisées à l’enregistrement : minuscules, « @ » de tête retiré, point final retiré. « La liste affichée après enregistrement est celle qui s’applique. »
• Pas de joker ni de motif : une entrée de domaine couvre déjà ses sous-domaines.
• Chaque liste compte 500 entrées au plus (« Liste pleine : 500 entrées au maximum. »).
• Un mail sans expéditeur lisible n’est jamais exclu par une exclusion, et il est exclu en mode « Ne traiter que… ».

L’ordre d’évaluation

Pour chaque nouveau mail, les vérifications se font dans cet ordre, et la première qui s’applique tranche :

1. Adresses de l’organisation, puis domaines de l’organisation → « Exclu — périmètre organisation ».
2. Règles du membre :
   • « Tout traiter, sauf… » : une adresse ou un domaine listé → « Exclu — périmètre membre » ;
   • « Ne traiter que… » : un mail dont l’expéditeur n’est pas listé → « Exclu — périmètre membre ».
3. Garde-fous → « Exclu — garde-fou » (voir ci-dessous). Un mail de liste de diffusion ou d’expéditeur no-reply peut encore être réclamé par un workflow dont le déclencheur le vise explicitement : il se lit alors « Traité ».
4. Sinon, le mail est dans le périmètre, et les conditions des déclencheurs de vos workflows publiés sont évaluées : « Reçu non matché » si aucune ne correspond, « Traité » si au moins un workflow se lance.

Le sort de chaque mail, et la règle qui l’a décidé, s’affichent sous Activité → Mails reçus, dans la colonne « Décidé par ». Le tableau de bord compte les mails écartés (« Par le périmètre ou un garde-fou »).

Seuls les mails susceptibles de lancer un workflow sont évalués : les nouveaux mails livrés après la connexion de la boîte, hors Envoyés, Spam, Corbeille et Brouillons. Voir Boîtes mail et miroir.

Les garde-fous

Après les règles de périmètre, quatre garde-fous arrêtent les mails qu’une automatisation générique ne doit pas toucher. Ils sont toujours actifs et ne se désactivent pas.

Garde-fou	Affiché	Détecte
envoyé par soi-même	« Garde-fou : message envoyé par soi-même »	un message produit par Loop & Roll lui-même (par un workflow ou le webmail) qui revient par la synchronisation — ce qui empêche un workflow de répondre à ses propres messages
réponse automatique	« Garde-fou : réponse automatique »	les réponses automatiques : absence du bureau et assimilées, reconnues à leurs en-têtes (Auto-Submitted, X-Autoreply…) et à leurs objets typiques
liste de diffusion	« Garde-fou : liste de diffusion »	les mails de listes de diffusion et de newsletters, reconnus à leurs en-têtes (List-Id, List-Unsubscribe, priorité « bulk »…)
expéditeur no-reply	« Garde-fou : expéditeur no-reply »	les expéditeurs dont l’adresse, avant le @, ressemble à une adresse no-reply (noreply, donotreply…)

Viser ces mails explicitement. Les garde-fous liste de diffusion et no-reply s’effacent devant un déclencheur qui demande ces mails dans ses conditions : signals.isMailingList égal à true (« Liste de diffusion = oui ») ou signals.isNoReply égal à true (« Expéditeur no-reply = oui »). Le mail est alors proposé à ce workflow, et à lui seul : tous les autres continuent de l’ignorer, et le mail s’affiche « Traité » pour le workflow qui l’a pris. La condition doit être la raison pour laquelle le mail correspond — un déclencheur qui ne le réclame que par une autre branche d’un groupe « au moins une » ne lève pas le garde-fou. Une newsletter envoyée depuis une adresse no-reply peut être réclamée en visant l’un ou l’autre signal.

Les garde-fous « envoyé par soi-même » et « réponse automatique » ne se lèvent jamais : une condition signals.isAutoReply égal à true ou signals.isFromSelf égal à true ne se vérifie jamais. Le périmètre passe toujours avant : un mail exclu par l’organisation ou par vos propres règles n’atteint aucun workflow, pas même celui qui vise les listes de diffusion.

Ce que fait encore un mail hors périmètre

	Dans le périmètre	Hors périmètre
Conservé dans le miroir	oui	oui
Visible dans le webmail, trouvable par la recherche	oui	oui
Lance des workflows	si un déclencheur correspond	jamais
Analysé par l’analyseur et envoyé à son IA	oui	non — seulement compté (« écartés par le périmètre, ni groupés ni envoyés à l’IA »)
Utilisé pour proposer des profils du carnet	oui	non
Lu par les outils de l’assistant de workflows	oui	non
Utilisé pour un essai, un lancement manuel ou un rejeu	oui	non — refusé (workflow.message_out_of_scope)
Utilisé pour évaluer un prompt (échantillon, exemples few-shot)	oui	non — écarté

Un cas à connaître :

• Le contexte du fil. Quand un mail dans le périmètre arrive dans un fil, les messages précédents du même fil peuvent être donnés comme contexte à un nœud IA, même si leur expéditeur est hors périmètre.

Quand les règles changent

Un changement de périmètre s’applique aux mails qui arrivent ensuite. Les mails déjà reçus ne sont pas réévalués : élargir votre périmètre ne traite pas les mails qu’il excluait auparavant, et le restreindre n’annule pas les exécutions déjà lancées. Ce que vous lancez à la main suit en revanche le périmètre du moment : une fois un expéditeur exclu, un essai, un rejeu ou l’assistant ne traitent plus ses mails, même reçus avant.

Ma politique de déclenchement

L’onglet Mon périmètre porte aussi « Ma politique de déclenchement » : ce qui se passe quand plusieurs de vos workflows correspondent au même mail.

• Tous ceux qui correspondent (par défaut) : chaque workflow qui correspond a sa propre exécution.
• Le premier qui correspond, et lui seul : les workflows sont essayés dans l’ordre de priorité et le premier qui correspond est le seul à s’exécuter, à la manière des règles Outlook. L’ordre est le Rang de l’onglet Réglages de chaque workflow, de 0 à 9999, le plus petit d’abord ; les workflows sans rang passent après, dans l’ordre de création.

Quelle que soit la politique, un workflow ne s’exécute qu’une fois par mail, même quand plusieurs de ses déclencheurs mail correspondent. La politique est décrite avec les autres règles de déclenchement dans Déclencheurs et conditions.

Ce que le périmètre n’est pas

• Pas un sélecteur de boîte. Un workflow publié écoute toutes les boîtes non déconnectées de son propriétaire. Pour limiter un workflow à une boîte, utilisez une condition de déclencheur sur les destinataires (par exemple recipients.emails égal à l’adresse de la boîte).
• Pas un filtre de conservation. Aucune option ne tient les mails de certains expéditeurs hors du miroir.
• Pas une affaire entre membres. Les boîtes, workflows et exécutions de chaque membre lui appartiennent ; les boîtes d’un autre membre ne sont jamais traitées par vos workflows.

Par l’API

Route	Qui	Quoi
GET / PUT /api/v1/admin/scope	administrateurs	les règles de l’organisation : { "excludedDomains": […], "excludedEmails": […] }
GET / PUT /api/v1/scope	le membre connecté	ses propres règles : { "mode": "exclude" | "include", "domains": […], "emails": […] }
GET / PUT /api/v1/dispatch-policy	le membre connecté	la politique de déclenchement : { "mode": "all" | "priority" }

PUT remplace l’objet entier, et la réponse rend les listes normalisées. Le rang d’un workflow se règle avec PATCH /api/v1/workflows/:id et { "dispatchPriority": 0 } (ou null).

Pages liées

• Boîtes mail et miroir
• Déclencheurs et conditions
• Gouvernance
• Analyseur