---
title: Faire valider les fiches et les envois
description: Choisir les créations, modifications et envois du CRM qui attendent une validation humaine, régler qui décide dans Workflows, valider ou refuser une demande et suivre la sienne.
url: "https://illizeo.com/centre-aide/crm-validations/"
updated: "2026-11-08"
category: CRM
---

# Faire valider les fiches et les envois

Votre espace peut décider que certaines créations ou modifications de fiches du CRM, et certains envois vers des clients ou des membres, passent par une validation humaine avant d'être définitifs. Tant qu'une personne n'a pas décidé, rien n'est écrit ni envoyé. Cet article explique comment régler ce qui est soumis, qui décide, comment valider ou refuser une demande, et ce que vit le demandeur pendant l'attente. Il s'adresse aux administrateurs du CRM, aux valideurs et aux commerciaux.

## Avant de commencer

- Le module CRM doit être activé pour votre espace (voir [Activer et administrer le module CRM](https://illizeo.com/centre-aide/crm-activer-et-administrer/)).
- Les réglages : « Réglages du CRM : consulter » pour ouvrir **Paramètres › CRM › Validations**, « Réglages du CRM : modifier » pour les enregistrer.
- Les demandes, droit « Validations : consulter » (matrice des rôles, menu CRM) : il donne l'entrée **CRM › Validations** et montre les demandes des personnes de votre portée, en plus des vôtres.
- La décision, droit « Validations : valider ou refuser » : il permet de décider les demandes des personnes de votre portée, jamais les vôtres.
- La portée vise le demandeur. Elle se règle par rôle dans la carte **Portées CRM**, domaine **Validations**, opérations **Lire** et **Décider** (voir [Les réglages du CRM](https://illizeo.com/centre-aide/crm-reglages/)). Par défaut, seul le rôle Administrateur détient ces deux droits, avec la portée **Tous**.
- Armer un circuit dans Workflows demande les droits des workflows (voir [Créer et modifier un workflow](https://illizeo.com/centre-aide/workflows-creer-et-modifier/)).
- Demander ne demande aucun droit particulier : chaque geste garde ses droits habituels.

## Par défaut, rien n'est soumis

Tant que personne n'a rien coché dans **Paramètres › CRM › Validations**, le CRM écrit et envoie comme d'habitude. Les réglages disent **ce qui** attend une décision. Le circuit de Workflows dit **qui** décide.

## Régler ce qui est soumis

1. Ouvrez **Paramètres › CRM › Validations**.
2. Pour chaque objet, **Compte**, **Contact**, **Opportunité ou dossier** et **Adhésion**, cochez au besoin **Création soumise à validation**.
3. Sous **Modification soumise pour ces champs**, cochez les champs dont le changement doit attendre une décision.
4. Sous **Pour ces origines (aucune cochée : toutes)**, cochez les origines visées par la règle de cet objet.
5. Dans **Envois vers un tiers**, cochez les envois à faire valider.
6. Cliquez sur **Enregistrer**.

**Appliquer le préréglage** remplit le formulaire avec une proposition : la création des quatre objets soumise pour les origines IA, API et Formulaire public, la modification des identifiants légaux d'un compte, et l'envoi d'un appel de cotisation. Rien n'est enregistré avant **Enregistrer**.

![La page Validations des réglages du CRM : le préréglage proposé, puis pour le compte la case Création soumise à validation, les champs soumettables et les origines.](https://i0.wp.com/illizeo.com/wp-content/uploads/2026/11/crm-validations-01.fr_.png?resize=800%2C1086&quality=80&ssl=1)
Paramètres › CRM › Validations : par objet, la création, les champs et les origines soumis ; puis les envois.

### Les champs qui peuvent être soumis

| Objet | Champs |
| --- | --- |
| Compte | Raison sociale, Identifiants légaux, Adresses, Propriétaire, Secteur, Notes, Étiquettes, Champs personnalisés |
| Contact | Prénom, Nom, E-mails, Téléphones, Fonction, Propriétaire, Notes, Champs personnalisés |
| Opportunité ou dossier | Nom, Montant, Devise, Date de signature prévue, Propriétaire, Champs personnalisés |
| Adhésion | Catégorie, Contact référent, Propriétaire, Note |

### Les origines

| Origine | Ce qu'elle couvre |
| --- | --- |
| Saisie à l'écran | Ce que vous créez ou modifiez dans les écrans du CRM. |
| Import | Chaque ligne d'un import de fichier ou d'un autre CRM, et le réimport d'un export complet. |
| API | Une écriture faite avec un jeton API, par exemple depuis un outil d'automatisation. |
| IA | Les fiches créées par **Créer les fiches** depuis un e-mail préparé par l'IA. |
| E-mail relevé | Les mêmes fiches préparées par l'IA, puisqu'elles viennent toujours d'un e-mail de la file : une règle qui vise cette origine les soumet aussi. |
| Formulaire public | Aucune écriture du CRM ne porte aujourd'hui cette origine : la cocher seule ne soumet rien. |

### Les envois vers un tiers

Trois envois peuvent être soumis : **Envoi d'un devis**, **Envoi d'un appel de cotisation** et **Invitations à un événement**. Un envoi soumis ne part qu'après la décision, y compris par l'API, et quel que soit le mode choisi : par e-mail ou remis autrement. La réponse rédigée par l'IA n'est pas dans cette liste : elle ne part jamais d'Illizeo (voir [L'intelligence artificielle dans le CRM](https://illizeo.com/centre-aide/crm-intelligence-artificielle/)).

## Ce qui se passe quand un geste est soumis

- **Une création** n'écrit rien : la fiche n'existe pas encore. Elle n'apparaît dans aucune liste, aucun rapport, aucun webhook. Tant qu'elle attend, une seconde création de la même fiche est refusée, qu'elle soit soumise ou non : même raison sociale ou même organisation pour un compte, même adresse e-mail pour un contact, même club et même membre pour une adhésion.
- **Une modification** attend tout entière dès que l'un des champs soumis change, pas seulement ce champ : la fiche garde ses anciennes valeurs jusqu'à la décision. Un champ renvoyé à l'identique ne soumet rien. Les étiquettes et les champs personnalisés font exception : dès qu'une modification les contient, elle est soumise, même s'ils n'ont pas changé.
- **Un passage d'étape** qui change le montant, la devise ou la date de signature d'une opportunité attend comme une modification : l'affaire reste à son étape. Validé, le passage est refait en entier.
- **Une réaffectation de plusieurs comptes**, quand le propriétaire est soumis, pose une demande par compte. Rien n'est réaffecté avant les décisions.
- **Un envoi** ne part pas. Le devis, l'appel de cotisation ou les invitations restent dans leur état.
- **Un import** pose une demande par ligne soumise. Ces lignes sont comptées « En attente de validation » dans le compte rendu de l'import. Une simulation les compte sans poser de demande.
- **Une écriture par l'API** reçoit une réponse 202 avec l'identifiant de la demande. L'intégration lit ensuite l'état de la demande par l'API, avec un jeton qui porte la ressource « CRM — demandes de validation » (voir [Importer, exporter et utiliser l'API](https://illizeo.com/centre-aide/crm-import-export-et-api/)).

## Qui décide : le circuit

Chaque demande démarre un circuit du moteur de workflows, selon son déclencheur : « Création d'une fiche à valider », « Modification d'une fiche à valider » ou « Envoi vers un tiers à valider ».

![Schéma : une création, une modification ou un envoi n'est écrit aussitôt que s'il n'est pas soumis ; soumis, il devient une demande en attente qui démarre un circuit de Workflows ; une étape d'approbation la confie au supérieur hiérarchique ou à l'approbateur du workflow, une fin sans approbation la confie aux détenteurs du droit Validations : valider ou refuser ; refusée, rien n'est écrit et le motif part au demandeur ; validée, le geste est rejoué au nom du demandeur.](https://i0.wp.com/illizeo.com/wp-content/uploads/2026/11/crm-validations-flux-01.fr_.png?resize=800%2C648&quality=80&ssl=1)
De la saisie à la décision : les réglages disent ce qui attend, le circuit dit qui décide.

- **Sans workflow actif** pour ce déclencheur, la demande suit le circuit de repli : le supérieur hiérarchique du demandeur décide. Ce circuit apparaît dans Workflows à la première demande, sous le nom « Circuit de repli — supérieur hiérarchique ».
- **Trois circuits sont livrés inactifs**, dans la catégorie CRM de **Paramètres › Gérer les employés › Workflows** : « Création par l'IA : validation », « Identifiant légal modifié : validation » et « Envoi d'un appel de cotisation : validation ». Chacun envoie la demande au responsable du demandeur quand sa condition est remplie : origine IA, champ Identifiants légaux, ou type d'envoi appel de cotisation.
- **Un workflow actif prend toutes les demandes de son déclencheur.** Celles qu'il termine sans étape d'approbation, par exemple une création venue de l'API quand seul « Création par l'IA : validation » est actif, attendent un valideur du CRM : tous les détenteurs de « Validations : valider ou refuser » dont la portée couvre le demandeur sont prévenus.
- Seule une décision humaine compte, et jamais celle du demandeur lui-même.
- À tout moment, un détenteur de « Validations : valider ou refuser » dans sa portée peut décider depuis le CRM. Le circuit encore ouvert est alors annulé.

Armer un circuit ne soumet rien par lui-même : sans la case correspondante dans **Paramètres › CRM › Validations**, aucune demande ne lui parvient.

Le valideur désigné reçoit une notification et un e-mail. S'il peut décider dans le CRM (« Validations : valider ou refuser », dans une portée qui couvre le demandeur), ils mènent à la demande dans le CRM. Sinon, ils mènent à **Flux de travail**, onglet **Approbations** (voir [Approuver, refuser ou déléguer une demande](https://illizeo.com/centre-aide/workflows-approuver-une-demande/)).

## Consulter et décider les demandes

Ouvrez **CRM › Validations**. La liste montre vos demandes et celles des personnes de votre portée, les plus récentes en tête. Filtrez-la par **Statut** et par **Objet**. Chaque ligne donne la **Demande** (son libellé, le geste et la date), l'**Objet**, l'**Origine**, le **Demandeur** et le **Statut**.

![La liste CRM › Validations : colonnes Demande, Objet, Origine, Demandeur et Statut, avec une création de compte proposée par l'IA en attente.](https://i0.wp.com/illizeo.com/wp-content/uploads/2026/11/crm-validations-02.fr_.png?resize=800%2C500&quality=80&ssl=1)
Les demandes de validation : les vôtres et celles de votre portée, filtrables par statut et par objet.

| Statut | Signification |
| --- | --- |
| En attente | Personne n'a encore décidé. Rien n'est écrit ni envoyé. |
| Validée | Le geste du demandeur a été rejoué et appliqué. |
| Refusée | Rien n'a été écrit ni envoyé. Le motif est sur la demande. |
| Validée, non appliquée | La demande a été validée, mais le geste n'a pas pu être rejoué : rien n'a été écrit. La raison est sur la demande. |

Cliquez sur une demande pour l'ouvrir. Elle indique le geste et l'objet, l'**Origine**, le **Demandeur**, la date de la demande et, une fois tranchée, la date de la décision et son auteur. Une création montre **Ce qui sera créé**, champ par champ ; une modification, **Avant / après**. Une demande d'envoi ou de fiches préparées par l'IA n'a pas de tableau : son titre donne le numéro du devis ou de l'appel, le titre de l'événement, ou le nom de l'organisation proposée.

![La fiche d'une demande en attente : statut, Création · Compte, origine IA, demandeur, date, le tableau Ce qui sera créé, et les boutons Refuser et Valider.](https://i0.wp.com/illizeo.com/wp-content/uploads/2026/11/crm-validations-03.fr_.png?resize=800%2C216&quality=80&ssl=1)
Une demande à décider : ce qui sera créé, champ par champ, avant toute écriture.

1. Cliquez sur **Valider** ou sur **Refuser**. Ces boutons n'apparaissent que si vous pouvez décider cette demande.
2. Pour valider, ajoutez au besoin un **Commentaire**. Pour refuser, saisissez le **Motif (obligatoire)** : le demandeur le recevra.
3. Confirmez avec **Valider** ou **Refuser**.

![La fenêtre Refuser la demande : rien ne sera écrit ni envoyé, le demandeur reçoit le motif ; champ Motif (obligatoire), boutons Annuler et Refuser.](https://i0.wp.com/illizeo.com/wp-content/uploads/2026/11/crm-validations-04.fr_.png?resize=512%2C340&quality=80&ssl=1)
Refuser une demande : le motif est obligatoire et part au demandeur.

Validée, la demande rejoue le geste du demandeur, à son nom, avec ses droits du jour et sur l'état présent du CRM. Si le geste n'est plus possible, par exemple parce qu'un droit lui a été retiré ou qu'un doublon est apparu entre-temps, la demande passe en **Validée, non appliquée** et rien n'est écrit. Une fois validée, le lien **Ouvrir la fiche** mène à la fiche créée ou modifiée. Une demande déjà tranchée ne se décide pas deux fois : « Cette demande a déjà été tranchée. »

## Côté demandeur : pendant l'attente

- Quand votre geste est soumis, le message « Envoyé en validation : rien n'est écrit tant qu'une personne n'a pas validé. » s'affiche, avec **Voir la demande**. C'est le cas à la création ou à la modification d'un compte, d'un contact, d'une opportunité ou d'une adhésion, à l'envoi d'un devis ou d'un appel de cotisation, aux invitations à un événement et à la création des fiches préparées par l'IA.
- Un envoi groupé d'appels de cotisation dit combien d'envois attendent : « … envoi(s) en attente de validation : ils partiront après la décision. », avec **Voir les demandes**.
- Si la même fiche attend déjà une validation, le message le dit : « La même fiche attend déjà une validation : rien n'est écrit tant qu'une personne n'a pas décidé. »
- Un passage d'étape ou une réaffectation de comptes soumis s'affiche comme un échec, avec le message « Cette modification attend une validation : rien n'est écrit tant qu'une personne ne l'a pas approuvée. » (« Ces modifications attendent… » pour plusieurs comptes), sans lien vers la demande. La demande est pourtant bien posée.
- La fiche ne montre rien de l'attente : une fiche à créer n'existe pas encore, une fiche modifiée garde ses anciennes valeurs. Pour des fiches préparées par l'IA, l'e-mail de la file affiche « Fiches en attente de validation ».
- Vous suivez vos demandes dans **CRM › Validations**. Sans le droit « Validations : consulter », l'entrée n'est pas dans le menu : vos demandes s'ouvrent par le lien du message ou de la notification.
- Vous ne pouvez pas retirer une demande vous-même. Pour l'abandonner, demandez au valideur de la refuser.

### La décision

Vous recevez une notification et un e-mail : « CRM : modification validée », « CRM : modification refusée », avec le motif, ou « CRM : modification validée mais non appliquée ». Un clic ouvre la demande. Après un refus ou un échec, rien n'a été écrit : ressaisissez le geste si besoin. Des fiches préparées par l'IA reviennent à revoir : vous les corrigez et les soumettez de nouveau, ou vous les écartez.

## Notifications, e-mails et journal

- Les notifications et les e-mails de ces demandes se coupent dans **Paramètres personnels › Notifications**, ligne « CRM — validations : demandes à décider, demandes validées ou refusées » (voir [Choisir ses notifications](https://illizeo.com/centre-aide/notifications-mes-preferences/)).
- Les textes des quatre e-mails se personnalisent dans **Paramètres › Gérer Illizeo › Email**, catégorie CRM : « CRM — une modification à valider (au valideur que le circuit désigne) », « CRM — modification validée (au demandeur) », « CRM — modification refusée (au demandeur, avec le motif) » et « CRM — modification validée mais non appliquée (au demandeur) ». Aucun ne reprend les valeurs saisies : la demande se lit à l'écran.
- Le journal du CRM garde chaque demande, chaque décision avec son auteur et l'avant / après, et chaque changement des réglages des validations.

## À savoir

- Les droits du demandeur sont relus au moment de la décision : une demande validée après le retrait de son droit échoue sans rien écrire.
- L'effacement d'un contact au titre de la protection des données efface aussi les demandes de validation de sa fiche, quel que soit leur état.
- Modifier les réglages ne change pas les demandes déjà posées : elles attendent leur décision.

## Questions fréquentes

### Qui est prévenu quand une demande est posée ?

Le valideur que le circuit désigne : le supérieur hiérarchique du demandeur tant qu'aucun workflow n'est actif, ou l'approbateur du workflow actif. Quand un workflow termine la demande sans étape d'approbation, ce sont les détenteurs de « Validations : valider ou refuser » dont la portée couvre le demandeur. S'il n'y en a aucun, la demande attend sans que personne ne soit prévenu.

### Le valideur ouvre la demande mais ne voit ni Valider ni Refuser.

Il lui manque « Validations : valider ou refuser » dans une portée qui couvre le demandeur, ou c'est sa propre demande. S'il est le valideur désigné par le circuit, il décide dans **Flux de travail**, onglet **Approbations**, là où mène son avis, même sans droit dans le CRM : sa décision s'applique comme une décision prise dans le CRM.

### *Similaire*