> ## Documentation Index > Fetch the complete documentation index at: https://docs.didit.me/llms.txt > Use this file to discover all available pages before exploring further. # Blueprints de dossiers : attribution et contenu > Configurez l'attribution, l'escalade et le transfert des dossiers par catégorie avec Didit, et installez les quatre préréglages intégrés. Une politique de revue, représentée sous forme de blueprint dans l'API, définit les exigences applicables à une catégorie de dossier. Gérez les politiques sous **Gestion des dossiers > Attribution > Politiques de revue**. Les dossiers enregistrent la version de la politique en vigueur à leur ouverture, de sorte que les modifications ultérieures ne modifient pas silencieusement une revue en cours. L'éditeur soumet la version qu'il a ouverte lorsque vous enregistrez. Si un autre réviseur a publié une version plus récente, l'enregistrement renvoie un conflit et votre brouillon reste ouvert. Examinez la dernière version de la politique avant d'appliquer à nouveau vos modifications. Les intégrations API peuvent envoyer `expected_version` avec une mise à jour de politique pour la même protection ; une version obsolète renvoie `409` sans modifier la politique. *** ## Réglages généraux | Réglage | Description | | - | - | | **Nom** | Jusqu'à 24 caractères | | **Description** | Facultative, texte libre | | **Qui traite les dossiers** | Groupe d'agents assignables, obligatoire, au moins un membre (« Sélectionnez au moins un assigné ») | | **Attribution** | **Manuellement** ou **Automatiquement** | | **Transfert de dossier** | Interrupteur ; lorsqu'il est activé, les dossiers peuvent être transférés vers un autre blueprint actif de la même application | | **Escalade** | Interrupteur et sélecteur du blueprint cible | | **Revue à 4 yeux** | Association avec un blueprint vérificateur, voir [Revue à 4 yeux](https://docs.didit.me/fr/console/case-management/four-eyes.md) | | **Exiger une note de résolution** | Interrupteur ; lorsqu'il est activé, la note de la boîte de dialogue Résoudre devient obligatoire | | **Délai par défaut** | Délai facultatif en heures pour les nouveaux dossiers ; un délai explicite sur le dossier prévaut | ### Attribution automatique L'attribution automatique sélectionne un réviseur autorisé ayant le moins de dossiers actifs dans l'ensemble de l'organisation, dans la limite de la capacité configurée. Les agents en ligne sont privilégiés lorsqu'ils sont disponibles ; sinon, les agents hors ligne éligibles peuvent recevoir des dossiers. Lorsque tous les réviseurs éligibles ont atteint leur capacité, le dossier reste non attribué. La résolution d'un dossier ou la connexion d'un agent peut retirer un dossier de la file d'attente lorsque la capacité est disponible. ### Escalade et transfert L'escalade déplace un dossier vers un blueprint cible fixe (sa file d'attente, sa configuration de contenu) en une seule action. Le transfert de dossier permet à l'agent de choisir n'importe quel blueprint actif de la même application pour y déplacer un dossier. Ces deux options sont masquées sur la page du dossier, sauf si le blueprint actuel les active, et sont bloquées côté serveur (400) si elles sont tentées alors qu'elles sont désactivées. Un blueprint ne peut pas se référencer lui-même comme cible d'escalade ni comme vérificateur de la revue à 4 yeux. ### Sources associées La colonne de droite d'un blueprint affiche : * **Sources de création de dossiers** : configurations AML, règles de transaction et nœuds de workflow qui acheminent actuellement de nouveaux dossiers vers ce blueprint, avec des raccourcis vers chacun d'eux. * **Reçoit des escalades depuis** : autres blueprints dont la cible d'escalade pointe vers celui-ci. ## Enregistrer et publier les modifications de politique **Enregistrer le brouillon** conserve vos modifications sans affecter les nouveaux dossiers ou les dossiers existants. Une nouvelle politique reste non publiée et ne peut être sélectionnée ni pour un dossier ni pour une règle d'acheminement tant que vous n'avez pas choisi **Publier**. Rouvrir l'éditeur restaure le brouillon enregistré. **Publier** devient disponible une fois que les modifications en cours ont été enregistrées. La publication applique cette version aux nouveaux dossiers ; les dossiers existants conservent les exigences de revue qu'ils ont acceptées. **Historique des versions** enregistre chaque configuration publiée, l'heure de publication et l'auteur de la publication, lorsqu'il est connu. Les politiques créées avant la disponibilité de l'historique des versions voient leur configuration actuelle enregistrée lors de la publication suivante. **Abandonner le brouillon** demande une confirmation et ramène l'éditeur à la configuration publiée. Abandonner un brouillon jamais publié le supprime. L'enregistrement d'un brouillon et la vérification de publication contrôlent à la fois la version publiée et la révision du brouillon. Si quelqu'un d'autre modifie l'une ou l'autre, le serveur renvoie `409` et votre éditeur ouvert conserve vos modifications non enregistrées. Un brouillon basé sur une politique publiée plus ancienne doit être vérifié par rapport à la politique actuelle avant publication. Les mises à jour directes par `PATCH` de l'API restent des publications immédiates et sont également enregistrées dans l'historique des versions. ### Brouillons de règles d'acheminement Les règles d'acheminement utilisent les mêmes actions **Enregistrer le brouillon**, **Publier**, **Abandonner le brouillon** et **Historique des versions**. Enregistrer un brouillon ne modifie pas la règle utilisée pour l'attribution automatique ni l'aperçu de la règle publiée. Les modifications non publiées doivent être enregistrées avant de pouvoir être publiées. La publication vérifie que la politique de revue et l'équipe sélectionnées sont toujours actives et appartiennent à la même application. Si un autre éditeur modifie la règle ou son brouillon, l'opération renvoie un conflit et préserve le travail le plus récent. Les nouvelles règles utilisent d'abord **Enregistrer le brouillon** et restent inactives jusqu'à ce que **Publier** crée la version 1. Pour les intégrations API, définissez `publish=false` lors de la création d'une politique ou d'une règle d'acheminement afin d'utiliser ce cycle de vie. Si cette option est omise, la création immédiate est conservée pour les intégrations existantes. ## Bibliothèque de préréglages Installez l'un des quatre préréglages intégrés depuis la galerie des préréglages de politiques de revue. L'installation copie le préréglage dans votre application en tant que blueprint entièrement modifiable ; vous pouvez ensuite modifier librement n'importe quel réglage sans affecter le catalogue. L'installation est idempotente pour chaque préréglage : réinstaller un préréglage déjà installé n'a aucun effet. | Préréglage | Contenu du dossier | | - | - | | **Screening hit** | Contrôle AML (informations financières et identité), identité (informations personnelles, aperçu des risques) | | **Enquête LCB-FT** | Contrôle AML (informations financières), identité (informations personnelles, coordonnées, aperçu des risques, documents PoI) | | **Activité suspecte** | Identité (informations personnelles, aperçu des risques, documents PoI), informations financières (moyens de paiement, transactions) | | **Revue KYC** | Identité (tous les champs), résumé de la vérification | Aucun des préréglages ne préconfigure l'attribution, l'escalade, la revue à 4 yeux ou le transfert : ces décisions d'acheminement vous appartiennent toujours, blueprint par blueprint. ## Contenu du dossier L'onglet **Contenu du dossier** contrôle les onglets et les champs qui apparaissent sur la page du dossier, sous forme de six sections activables : | Section | Champs | | - | - | | **Liste de contrôle** | Activation, rendre optionnelle pour la résolution, et la liste des éléments de la liste de contrôle, voir [Liste de contrôle](https://docs.didit.me/fr/console/case-management/checklist.md) | | **Contrôle AML** | Informations AML financières, informations AML sur l'identité | | **Identité** | Informations personnelles, tags du demandeur, coordonnées, aperçu des risques, justificatifs d'identité, justificatifs de domicile | | **Vérifications** | Synthèse des vérifications | | **Rapports** | Rapports FIU | | **Données et sources financières** | Moyens de paiement, transactions financières | Un modèle sans section activée affiche tout de même l'onglet Vue d'ensemble du dossier, mais sans les blocs de contenu supplémentaires. > [!TIP] > > Utilisez une échéance par défaut de la politique pour donner aux nouveaux dossiers un délai de traitement cohérent. > Les réviseurs peuvent toujours modifier la priorité et l'échéance d'un dossier donné. > La modification de la politique ne modifie pas les échéances des dossiers existants. ## Supprimer un modèle La suppression d'un modèle aboutit toujours et n'affecte pas ses dossiers : les dossiers existants conservent leur référence au modèle, et ses paramètres (sections de contenu, escalade, transfert, binôme à quatre yeux) continuent de s'appliquer à eux. Un modèle supprimé n'apparaît plus dans les listes de modèles et ne peut plus être choisi comme cible de transfert. Si le modèle du maker est supprimé alors qu'une de ses résolutions attend l'approbation à quatre yeux, une résolution refusée laisse le dossier sur le modèle du checker au lieu de le renvoyer au modèle du maker. Pour retirer proprement un modèle, transférez ses dossiers actifs vers un autre modèle avant de le supprimer. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.