Points piégeux à connaître
Le module Contacts contient quelques comportements subtils qui peuvent surprendre la première fois. Cette page les regroupe pour éviter les mauvaises surprises et les tickets de support inutiles.
1. Contact sans email ni téléphone
Vous pouvez créer un contact avec uniquement un nom et un prénom. Aucun moyen de contact n'est techniquement obligatoire.
Conséquence : ce contact sera inatteignable pour toutes vos campagnes (SMS, email, push). Il existera dans votre base, comptera dans vos stats, apparaîtra dans la cartographie si vous lui mettez une adresse, mais ne recevra jamais de communication.
Comment auditer : dans la recherche avancée, section Coordonnées, activez les filtres :
- Possède un email = Non
- Possède un téléphone = Non
Vous obtenez la liste des contacts à compléter (ou à archiver s'ils ne sont plus pertinents).
2. Trois états distincts : nouveau, archivé, supprimé
Un contact peut être dans l'un de ces états :
| État | Description | Visibilité |
|---|---|---|
| Nouveau | Drapeau automatique sur tout contact qui vient d'être créé ou réactivé. Disparaît au premier accès dans une fiche. | Visible partout, avec un badge « nouveau ». |
| Archivé | Contact volontairement masqué (par exemple un fidèle qui a déménagé). | Caché par défaut des listes courantes. Pour le voir, activer le filtre Archivé = Oui dans la recherche avancée. |
| Supprimé | Soft delete — le contact est dans la « corbeille ». | Caché de toutes les vues. Récupérable manuellement. |
3. Fusion : irréversible et c1 disparaît au profit de c2
La fusion de deux contacts (depuis la fiche, modale Fusionner des contacts) est définitive. Le contact ouvert (c1) est écrasé par le contact choisi dans le menu (c2) — c1 disparaît.
Bon usage de la fusion :
- Vous trouvez deux fiches du même Yossi Cohen ? Ouvrez celle qui est la plus récente ou la plus complète, et fusionnez-la avec l'autre.
- Si vous hésitez, exportez d'abord les deux fiches en CSV avant de fusionner.
4. Hazkara vs Anniversaire : deux types distincts
Les rappels d'un contact peuvent être de deux types stockés dans le même champ :
- ANNIV — anniversaire d'une personne vivante.
- HAZKARA — commémoration annuelle d'un défunt.
Les deux ont la même structure mais sont fonctionnellement distincts : le hazkara est utilisé pour les rappels de décès, l'anniv pour les rappels de naissance. Ne les mélangez pas dans l'usage — l'interface les expose via deux modales différentes (Ajouter une hazkara vs Ajouter un anniversaire).
5. Champs personnalisés : pas d'unicité
Deux contacts peuvent avoir la même valeur dans le même champ
personnalisé, et c'est volontaire. Exemple : un champ texte voiture
peut avoir la valeur Renault sur cent contacts différents — c'est
attendu.
Conséquence sur la recherche :
- Filtre Inclure sur un champ texte commun → beaucoup de résultats, normal.
- Filtre Égal sur une seule valeur d'un champ texte → renvoie tous les contacts avec exactement cette valeur, pas un seul. Ne confondez pas avec une recherche par identifiant unique.
6. Email/Tél principal vs secondaires
Un contact a deux niveaux de coordonnées :
| Champ | Type | Usage |
|---|---|---|
email (chaîne) | Email principal | Celui utilisé par défaut pour les campagnes |
emails[].email (tableau) | Emails secondaires | Adresses additionnelles (perso, pro, anciens) |
tel (chaîne) | Téléphone principal | Celui utilisé par défaut pour SMS |
tels[].number (tableau) | Téléphones secondaires | Numéros additionnels |
Conséquences pratiques :
- Le filtre Email contient matche n'importe lequel des emails (principal ou secondaire).
- Le filtre Possède un email renvoie Oui dès qu'il y a au moins un email (principal ou secondaire).
- Lors d'un import avec mapping vers Email principal, vous écrasez l'email principal existant ; pour ajouter un email sans écraser, mappez vers Email secondaire.
7. Adresses et géolocalisation : principale vs secondaires
Un contact peut avoir :
- Une adresse principale (champs
adresse,postal,ville,pays). - Des adresses secondaires (tableau
adresses[], ex : bureau, résidence secondaire).
Chaque adresse a sa propre géolocalisation mémorisée. L'adresse
principale est identifiée en interne par MAIN, les secondaires par leur
identifiant unique.
Conséquences sur la cartographie :
- Un contact apparaîtra autant de fois que d'adresses géolocalisées.
- Sa route (tournée) est attachée à une adresse spécifique, pas au contact dans son ensemble : un même contact peut être sur la route A pour son domicile et la route B pour son bureau.
8. Recherche : insensible à la casse et aux accents
La recherche texte et les filtres sont insensibles à la casse et aux
accents. C'est rendu possible par la collation française MongoDB
(locale: fr, strength: 1).
Concrètement :
| Vous tapez | Trouve aussi |
|---|---|
cohen | Cohen, COHEN, Cöhen |
elie | Élie, ÉLIE, élie |
michael | Michaël, MICHAËL, Mickaël (proche mais différent) |
Attention quand même : michael ≠ mickael (l'un a un h, l'autre un
k). La normalisation ne corrige pas l'orthographe, juste la casse et
les diacritiques.
9. Export CSV : colonnes dynamiques selon votre organisation
Quand vous exportez les résultats d'une recherche, les colonnes peuvent varier selon les filtres actifs :
- Toujours présentes : Nom, Prénom, Email, Téléphone, Adresse, Code postal, Ville, Pays.
- Ajoutées si filtre financier actif : Total don (€), Nombre de dons.
Pour les exports plus avancés (champs personnalisés, catégories,
familles…), passez par le module Exploration
(/app/explorer) qui permet de bâtir un export sur-mesure.
10. Filtres sauvegardés : structure imbriquée
Une recherche sauvegardée stocke ses filtres dans une structure imbriquée complexe (objet avec sous-objets, modes Inclure/Exclure/Égal, plages de dates, plages de nombres…).
Conséquences :
- Quand vous chargez une recherche, le panneau de filtres se ré-initialise complètement, ce qui peut prendre une fraction de seconde.
- Si vous modifiez ne serait-ce qu'un seul filtre, le badge modifiée apparaît immédiatement.
- L'export ou le partage technique des filtres (URL, copier-coller) n'est pas supporté — passez par une recherche sauvegardée partagée.
11. Contacts décédés : champs liés
Marquer un contact comme décédé active plusieurs champs liés :
deceased(booléen) — vrai si décédé.deceasedDate— date du décès.deceasedHour— heure du décès.deceasedPere,deceasedMere,deceasedLocation— infos complémentaires utilisées pour les rappels de hazkara.
Un rappel hazkara est automatiquement préparé : il est synchronisé avec la date de décès et calculé selon le calendrier hébraïque.
12. Plusieurs organisations possibles (cas rare)
Techniquement, un contact peut appartenir à plusieurs organisations
(champ organisation qui peut être un tableau). C'est un cas
exceptionnel réservé aux scénarios de mutualisation (par exemple
deux communautés qui partagent un fichier contact commun).
Si ce n'est pas votre cas, ignorez ce point. Si vous êtes dans cette configuration, sachez que les modifications faites depuis une organisation se propagent à toutes les autres qui partagent le contact.
13. Suppression d'une catégorie : sans propagation
Supprimer une catégorie au niveau de l'organisation (Préférences) ne retire pas cette catégorie des contacts qui la portent. Les contacts gardent la chaîne de caractères de la catégorie dans leur fiche, mais elle n'apparaît plus dans les listes auto-complétées.
Conséquence : vous pourriez ne plus voir la catégorie dans la recherche par sélection, mais elle existe toujours dans les fiches.
Pour nettoyer : action de groupe de suppression de catégories massive depuis la recherche avancée, ou nettoyage individuel dans chaque fiche.
Récap : les 5 plus fréquents
Si vous ne devez retenir que cinq pièges :
- Archivé ≠ supprimé — un archivé est juste masqué, pas effacé.
- Fusion irréversible — le contact ouvert disparaît au profit du sélectionné.
- Soft delete réactivable — un contact « supprimé » réapparaît automatiquement si on tente de le recréer.
- Email principal ≠ tous les emails — distinguez
email(chaîne) deemails[](tableau). - Recherche insensible à casse + accents — pratique mais ne corrige pas l'orthographe.