En bref. Vos agences de recrutement (street, télémarketing) vous livrent des bulletins de domiciliation par centaines. Sans outil, chacun exige de créer et relier à la main cinq enregistrements dans quatre applications — contact, compte bancaire, mandat, jeton de paiement, abonnement. SDD Automation industrialise tout le circuit : les fichiers arrivent seuls, sont contrôlés par des règles que vous définissez, et chaque ligne validée devient un donateur régulier complet en une transaction. Tout ce qui n'est pas parfait s'arrête en quarantaine motivée — jamais dans votre base.

Le module a été pensé pour trois exigences du terrain : le volume (l'alimentation se fait par dépôt de fichiers, hors interface, en tâche de fond), la qualité (validation paramétrable, doublons arbitrés, audit complet des états) et la conformité (purge programmée des CSV nominatifs, journal d'export masquant IBAN et email, mandats signés rattachés à leur objet légal).

Concepts & objets

Accès & écrans

G.1 — Tableau de bord SDD (Dashboard)

Premier écran ouvert par le menu SDD Automation → Tableau de bord. C'est la vue de pilotage quotidienne : elle répond en un coup d'œil à « combien d'entrées attendent une action, et où ». Deux filtres généraux la pilotent, en haut à droite :

• Période — six boutons (Aujourd'hui · 7j · 30j · 90j · 1 an · Personnalisé) qui recalculent tous les compteurs et graphiques de la page sur la fenêtre temporelle choisie ; « 30j » est le réglage par défaut observé.
• Fournisseur — liste déroulante (« All suppliers » par défaut) qui restreint le tableau de bord à un seul fournisseur/agence source, pour isoler la performance d'import d'un partenaire en particulier.

Capture — Tableau de bord SDD, vue complète (période « 30j », tous fournisseurs).

Les 8 cartes indicateurs de la rangée supérieure, dans l'ordre où elles apparaissent à l'écran :

Sous les cartes, deux blocs d'analyse :

Deux tableaux supplémentaires apparaissent en bas de l'écran (hors capture) : Derniers fichiers importés (colonnes Nom, Source, Date, Lignes, Statut) et Imports quotidiens (histogramme du nombre d'imports par jour).

G.2 — Cockpit SDD : la fiche d'entrée, champ par champ

Le Cockpit SDD (menu Cockpit SDD) liste toutes les entrées, tous statuts confondus — c'est la table mère dont Warning, Quarantaine, Doublons et Rejections ne sont que des vues filtrées. Sur l'environnement observé, elle comptait 49 entrées.

Capture — Cockpit SDD, vue liste complète (1-49/49).

Colonnes : Nom du donateur, Email, IBAN, Montant, Fréquence, Statut, deux colonnes courtes non libellées (indicateurs de contournement/doublon), Error/Warning, Duplicate Resolution, Partenaire, Abonnement, Mandat SEPA, Fichier source, Date d'import. Chaque ligne est colorée selon son statut (vert = Terminé, rouge = Quarantaine/Rejeté).

Ouvrir une ligne affiche la fiche complète d'une entrée sdd.entry, reproduite ci-dessous sur l'exemple réel « Sofia Zerouali ».

Capture — Fiche d'entrée, partie haute : bandeau d'avertissement, sections Identité / Adresse / Données SDD.

Le bandeau jaune en haut de fiche (« ⚠ Avertissements ») n'apparaît que si le pipeline a laissé une remarque non bloquante sur l'entrée ; ici : [WARNING] Signature date is in the future (2027-07-01) — deferred-date mandate. — un mandat à date différée, toléré mais signalé.

La partie basse de la fiche (non re-capturée dans le second enregistrement) comprend quatre autres sections : Identification Legacy (Donor External ID, SDD Recruiter ID, Office Recruiter, Supplier Recruiter, Recruitment Type, Welcome Call), Profil / Action (Type, Knowledge, Channel, Action Code/Description, Remarque, Motivation), Opt-ins (Newsletter, Magazine online/offline, Phone, SMS) et Objets créés une fois l'entrée Terminée :

Capture — Fiche d'entrée, partie basse : sections Identification Legacy / Profil / Opt-ins / Objets créés.

Deux sections supplémentaires, conditionnelles, n'apparaissent que dans des cas particuliers : Quarantine Bypass (motif et justification, uniquement si un Superviseur a forcé le traitement — voir G.5) et Duplicate Resolution (partenaires candidats, uniquement si l'entrée est passée par l'état Doublon).

La barre de statut et ses 6 états

En haut de chaque fiche, une barre de statut (« Statusbar ») matérialise le cycle de vie de l'entrée. Le mode développeur permet d'afficher l'infobulle technique native du champ, reproduite ici mot pour mot :

Capture — Infobulle développeur du champ state, obtenue en survolant la barre de statut en mode debug.

Les boutons d'action contextuels

Selon le statut courant de l'entrée, jusqu'à quatre boutons apparaissent en haut à gauche de la fiche, avant la barre de statut :

G.3 — Historique des fichiers (File History)

Accessible depuis le menu Historique des fichiers, cette liste recense tous les fichiers CSV traités à l'exception de ceux qui ont fini en erreur totale (ceux-ci vivent dans Import Errors, G.4). La liste est en lecture seule — on n'y modifie rien, on y consulte l'historique.

Capture — Vue liste, 3 fichiers, tous en statut Terminé.

Ouvrir une ligne affiche la vue formulaire du fichier, avec ses boutons statistiques et l'onglet Entrées :

Capture — Fiche « AD_Manual testing.csv » : 15 entrées, toutes Terminées.

G.4 — Import Errors

Séparé volontairement de l'Historique des fichiers : cette liste ne contient que les fichiers dont aucune ligne n'a pu être traitée — des cas qui exigent une action, contrairement au reste de l'historique qui est informatif. Sur l'environnement observé, elle comptait 4 fichiers.

Capture — 4 fichiers en erreur, chacun avec le même type de message.

Le message d'erreur observé sur les quatre fichiers est identique dans sa structure : « File read successfully but no usable entry: all N line(s) ended as duplicate or quarantine (0 valid). Nothing was processed. » — un message qui rassure autant qu'il alerte : le fichier a été lu correctement (ce n'est pas un problème technique de format), mais aucune de ses lignes n'était exploitable, chacune ayant fini en doublon ou en quarantaine.

Capture — Fiche « AD-Date Antérieure.csv », statut Erreur, avec l'empreinte SHA-256 du fichier.

G.5 — Quarantaine & Doublons

Deux vues filtrées du Cockpit SDD, correspondant aux deux dérivations possibles du pipeline lorsqu'une entrée ne peut pas être traitée immédiatement.

Quarantaine

Ne montre que les entrées à l'état Quarantaine. Sur l'environnement observé, cette liste comptait 17 entrées, cohérent avec la carte « QUARANTAINE » du tableau de bord.

Capture — Liste Quarantaine (1-17/17) : 15 IBAN invalides, 2 problèmes de date de signature.

Deux motifs de blocage cohabitent sur cette capture, illustrant deux familles différentes de règles :

• [QUARANTINE] Invalid IBAN (too short) — la règle « Valid IBAN » (IBAN requis et valide) a détecté un format non conforme.
• [QUARANTINE] Field 'Signature Date': cannot compare value '' with '2026-02-06 (today −6 Months)'. — la règle « Signature date range » (Field check) a tenté de comparer la date de signature à une date relative (aujourd'hui moins 6 mois) et a échoué parce que le champ était vide dans le fichier source.

Capture — Fiche « Mehdi Fassi » (1/17), bloquée pour date de signature invalide ; noter l'absence de champ « Partenaire » renseigné : tant que l'entrée reste en quarantaine, aucun objet natif n'est créé.

Cette capture confirme un point de conception important : sur une entrée en quarantaine, les champs Partenaire et la section Objets créés restent vides — le pipeline s'arrête avant toute création, ce qui garantit qu'aucun donateur « à moitié créé » ne pollue la base (voir la plus-value « atomicité » du thème 1).

Doublons

Seconde dérivation du pipeline : une entrée est classée « Doublon » (et non « Quarantaine ») lorsqu'elle correspond potentiellement à un donateur déjà présent en base (même IBAN, même email, ou même IBAN avec un nom différent — cas fréquent d'un compte joint). Sur l'environnement observé, cette liste était vide :

Capture — « Doublons », état vide. Les colonnes révèlent la structure attendue : Contournement, Est un doublon, Duplicate Resolution notamment.

Une fois résolue (bouton « Resolve: Existing Partner » ou « Resolve: New Partner », selon que le doublon correspond à la même personne ou à une personne distincte), l'entrée repasse en Pending et le pipeline reprend son cours normal.

G.6 — Warning

Autre vue filtrée du Cockpit SDD : les entrées à l'état Terminé mais dont le pipeline a laissé un avertissement non bloquant dans le champ Error/Warning. Contrairement à la Quarantaine, ces entrées ont bien été traitées jusqu'au bout — le message sert uniquement à attirer l'attention sur un point à vérifier a posteriori.

Capture — Liste Warning (1/1) : « Signature date is in the future (2027-07-01) — deferred-date mandate. »

Colonnes identiques à celles du Cockpit SDD complet (Nom du donateur, Email, IBAN, Montant, Fréquence, Statut, Error/Warning, Duplicate…, Partenaire, Abonnement, Mandat SEPA, Fichier source, Date d'import) — la seule différence est le filtre appliqué sur le contenu du champ Error/Warning et sur le statut Terminé.

G.7 — Rejections : rejets manuels et exports

Ce menu regroupe trois écrans liés au traitement manuel des entrées (par opposition au traitement automatique par les règles) : la liste des entrées rejetées, l'assistant d'export, et l'historique des exports générés.

Capture — « Rejected Entry List » avec une entrée rejetée manuellement : « Dimitri Lambda ».

Cette liste se peuple lorsqu'un opérateur clique sur le bouton Rejeter depuis une fiche d'entrée (voir G.2) et choisit un motif prédéfini ou saisit un texte libre. Colonnes : Nom du donateur, Email, IBAN, Montant, Fréquence, Statut, Contournement, Est un doublon, Error/Warning, Duplicate Resolution, Partenaire, Abonnement, Mandat SEPA, Fichier source, Date d'import.

Ouvrir l'entrée rejetée affiche sa fiche complète, avec le motif de rejet effectivement renseigné cette fois-ci — un exemple concret que la fiche « Sofia Zerouali » (G.2) ne pouvait pas montrer puisqu'elle n'a jamais été rejetée :

Capture — Fiche « Dimitri Lambda », statut Rejeté. Noter le double bandeau : le motif de rejet (gris) et l'avertissement de quarantaine d'origine (jaune), tous deux conservés pour traçabilité.

Le bouton Nouvel Export (ou le menu Rejections → Export Rejected Entries) ouvre l'assistant qui permet de générer un fichier CSV des rejets à transmettre à une agence :

Capture — Assistant « Export Rejected Entries », tous filtres au repos.

Capture — Sélecteur calendrier du champ « Rejection Date — From » : notez les numéros de semaine ISO affichés en colonne de gauche (31 à 36).

Capture — « Dossier Rejects » (historique des exports) à l'état vide : « Aucun export pour l'instant. »

Une fois un export généré via l'assistant, il apparaît ici avec : Fichier, Date d'export, Exporté par, Entrées (nombre), Taille, Supplier, Period — From / To, et Server Path (chemin du dossier rejects\ où le fichier est physiquement déposé).

Configuration initiale (administrateur)

G.8 — Configuration, en détail

Le menu Configuration, réservé au profil SDD Administrator, regroupe six sous-menus. C'est le cœur technique du module : chaque comportement automatique décrit dans les thèmes 1 à 9 de ce document trouve ici son réglage correspondant.

Capture — Les 6 entrées du menu Configuration.

G.8.1 — Settings

L'écran de réglages généraux, organisé en cartes. La page ne s'enregistre qu'au clic sur le bouton violet Save Settings, fixé en haut de l'écran.

Capture — Haut de la page Settings : colonne gauche (dossiers, traitement automatique) et colonne droite (facturation, RGPD).

En faisant défiler la page, trois cartes supplémentaires apparaissent :

Capture — Cartes « Mandate PDF Sync » et « UTM – Marketing Attribution ».

Enfin, tout en bas de la page, un rappel des formats acceptés et des raccourcis :

Capture — « Supported import formats » et « Shortcuts ».

G.8.2 — Règles de validation

Capture — 8 règles actives, toutes en sévérité « Bloquant » sur cet environnement.

Ouvrir la règle « Allowed Frequency » donne la structure exacte d'une règle, champ par champ :

Capture — Fiche complète de la règle « Allowed Frequency » (5/8).

G.8.3 — CSV Field Mapping

Chaque fournisseur nomme les colonnes de son fichier à sa façon ; le mapping fait le lien avec les champs internes du module. Sur l'environnement observé, 3 mappings actifs sont configurés :

Capture — Liste des mappings (1-3/3), tous actifs.

Ouvrir un mapping (exemple « Blue_Import ») affiche l'outil de correspondance colonne par colonne :

Capture — Haut de la fiche « Blue_Import » : Mandate Code → MANDATE_CODE, Gender → GENDER, Firstname → FIRSTNAME, etc.

Champs observés sur ce mapping : Mandate Code, Gender, Language, Firstname, Lastname, Company Name, Street, House Number, Box Number, Zip, City, Country (code), Signature Date, Amount, SDD Frequency, IBAN, BIC, Phone, Mobile, Birthdate, Email, Action Code, Action Description, Channel — puis, plus bas :

Capture — Suite du mapping et nouvelle section « Opt-in Mailing Lists ».

Champs supplémentaires : Opt-in Magazine (offline/online), Opt-in Phone, Opt-in SMS, SDD Recruiter ID, Remarque, National ID Number, Nationality (code), Company Number (BCE), Is Company, Donor External ID, Start Date — ainsi qu'une ligne de mapping vers MAILING_LIST sans champ interne affecté (visible mais non lié).

Un second fournisseur observé (« Supplier_02_MDM ») illustre bien la diversité des conventions de nommage à absorber : IBAN → Sdd_iban_debitor, Mandate Code → Sdd_mandatereference, SDD Frequency → Recurrent, National ID Number → NN, Company Number (BCE) → BTW — confirmant que le mapping est bien nécessaire fournisseur par fournisseur, chacun avec ses propres intitulés de colonnes.

G.8.4 — Archived Imports

Capture — « Processed Files », état vide sur cet environnement (filtre Fournisseur actif dans la barre de recherche).

Liste des fichiers du dossier processed\ (imports réussis), avec les colonnes Fournisseur, Fichier et Taille (Ko). Trois actions sont proposées sur cet écran : Refresh (rafraîchit la liste depuis le serveur), Download (télécharge le fichier) et Delete (le supprime définitivement du serveur). Cet écran complète la purge automatique RGPD réglée en G.8.1 en offrant aussi une action manuelle.

G.8.5 — Motifs de rejet

Capture — Les 6 motifs proposés dans l'assistant Rejeter, avec leurs règles liées.

Les 6 motifs observés : Invalid or unrecognised IBAN · Incorrect or incomplete personal information · Donor already has an active subscription · Amount does not meet membership conditions · Cancellation request or refusal by donor · Other — specify below.

G.8.6 — Quarantine Bypass Reasons

Capture — Les 4 motifs proposés dans l'assistant « Forcer le traitement ».

Motifs proposés lorsqu'un Superviseur ou Administrateur clique sur le bouton rouge Forcer le traitement depuis une fiche en quarantaine (voir G.5) : IBAN manually validated with the client · Exception granted by management · Data manually corrected after verification · Other reason (specified in notes). Chaque motif dispose des mêmes champs que les autres référentiels du module : Motif (libellé), Sequence (ordre d'affichage) et Actif (désactiver au lieu de supprimer conserve l'historique des contournements déjà tracés). Le motif choisi est tracé sur l'entrée (section Quarantine Bypass) et dans le chatter : chaque contournement de règle bloquante reste justifié et auditable a posteriori.

Objets natifs créés — Mandat SEPA & Abonnement

Ces deux écrans ne font pas partie du module SDD Automation à proprement parler — ce sont les objets natifs Odoo Enterprise (respectivement sdd.mandate et sale.order) que le pipeline crée et relie automatiquement à l'issue d'un traitement réussi. Ils sont documentés ici pour montrer concrètement ce que produit une entrée « Terminée ».

Capture — Fiche mandat native, généré automatiquement pour « Henry Louis ».

Capture — Fiche abonnement native S04356, pour « Dupont Emma ».

Procédures

Traiter la vague du jour

1. Les agences ont déposé leurs CSV pendant la nuit ; le scan planifié les a importés (verrou anti-doublon). Ouvrez Dashboard : volumes par fournisseur, répartition des états — vous savez en trente secondes si la vague est saine.
2. Passez dans Import Errors : s'il y a des fichiers illisibles, prévenez l'agence (gabarit modifié ? encodage ?) et faites redéposer. Un fichier en erreur n'a rien créé.
3. Traitez la quarantaine (procédure dédiée ci-dessous) puis les doublons.
4. Dans le SDD Cockpit, sélectionnez les entrées « en attente » et cliquez Process : le pipeline crée les 5 objets par donateur. Les rares échecs repartent en quarantaine avec leur motif.
5. Vérifiez le Dashboard en fin de traitement : la vague doit finir avec 0 en attente, une quarantaine résiduelle documentée et les rejets prêts à l'export.

Résoudre une entrée en quarantaine

1. Ouvrez l'entrée depuis ▸ Quarantine : le motif indique la règle déclenchée et le champ concerné.
2. Cas corrigeable (faute de frappe IBAN, date mal saisie) : corrigez le champ sur l'entrée puis Revalidate — elle repasse toutes les règles.
3. Cas assumé (règle trop stricte pour ce cas précis) : Force Processing, en choisissant un motif de bypass. Le passage forcé reste tracé et attribué.
4. Cas nécessitant le donateur (signature illisible, IBAN invérifiable) : 🎫 Escalate to Support crée un ticket Donor Care lié ; l'entrée attend la réponse.
5. Cas définitif : Reject avec motif, puis Confirm Rejection. L'entrée rejoint la file d'export vers l'agence.

Arbitrer un doublon

1. Dans ▸ Duplicates, comparez l'entrée aux candidats proposés : même IBAN = très probablement la même personne ; même nom seul = vérifiez l'adresse et la date de naissance.
2. Resolve: Existing Partner rattache le bulletin au contact existant (le mandat et l'abonnement seront créés sur sa fiche) ; Resolve: New Partner assume une création distincte.
3. En cas de doute, escaladez : mieux vaut un ticket qu'un donateur dédoublé — ou pire, fusionné à tort.

Exporter les rejets vers une agence

1. ▸ Rejections ▸ Export Rejected Entries : filtrez par fournisseur et période.
2. Exporter en CSV : le fichier part avec les motifs ; IBAN et emails sont masqués dans le journal d'export (RGPD).
3. Archivez l'échange : le taux de rejet par agence est un indicateur contractuel précieux.

Ajouter un nouveau fournisseur

1. Créez le sous-dossier FTP à son nom et remettez-lui ses accès.
2. Créez son mapping dans CSV Field Mapping à partir d'un fichier d'exemple.
3. Faites déposer un fichier de test de quelques lignes ; contrôlez la vague dans le Cockpit avant d'ouvrir les volumes réels.

Bonnes pratiques

Questions fréquentes

Résolution de problèmes