💡En bref
Une architecture solide s’organise autour de la personne — prospect, candidat, étudiant, alumni — reliée aux programmes, candidatures, sessions, événements, transactions et interactions. La réussite dépend moins du nombre d’applications connectées que de la qualité du modèle : champs bien nommés, statuts non ambigus, absence de doublons.
🔗La personne comme entité centrale
Le premier choix structurant consiste à modéliser une seule entité personne, qui traverse tous les statuts : prospect, candidat, étudiant, ancien élève. Créer des entités séparées selon le statut produit des doublons systématiques et rend impossible toute vision du parcours complet.
Le statut devient alors un attribut, pas un type d’objet. Une même personne peut être candidate à un programme, étudiante dans un autre et ancienne élève d’un troisième, sans que cela crée trois fiches.
🗂️Les objets à relier
| Objet | Relation | Rôle |
|---|---|---|
| Candidature | Personne × Programme | Porte les étapes et la décision |
| Inscription | Personne × Session | Porte la participation effective |
| Interaction | Personne × Date | Historique des échanges |
| Transaction | Personne × Dossier | Paiements et échéances |
| Entreprise | Personne × Organisation | Employeur, financeur, partenaire |
| Événement | Personne × Événement | Intérêt et engagement |
Cette structure permet de répondre à des questions courantes sans requête complexe : combien de candidatures par programme, quel délai moyen entre première interaction et inscription, quels candidats ont participé à un événement puis abandonné.
⚙️Définir des statuts non ambigus
Les statuts sont la source la plus fréquente d’incohérence. Chacun doit avoir une définition écrite, une condition d’entrée et une condition de sortie. « En cours » ou « à traiter » sont des statuts trop vagues pour être exploitables.
- Une définition en une phrase pour chaque statut.
- Un événement précis qui déclenche le passage au statut suivant.
- Un responsable identifié pour chaque étape.
- Une durée cible, permettant de détecter les dossiers bloqués.
- Un statut terminal explicite, y compris pour les abandons et refus.
Documentez les motifs de sortie négative — refus, désistement, sans suite — car ils constituent l’information la plus utile pour améliorer le taux de transformation.
📥Nommer les champs correctement
Un champ mal nommé sera mal rempli. Les règles sont simples : un nom explicite, une seule information par champ, un format contraint lorsque c’est possible, et une aide contextuelle pour les cas ambigus.
Évitez les champs libres pour des informations structurantes. Un champ texte « situation » se remplira de vingt formulations différentes et deviendra inexploitable en analyse. Une liste fermée, quitte à prévoir une valeur « autre » avec précision, préserve la qualité des données.
🛡️Prévoir la gouvernance
- Qui peut créer un champ, et selon quelle procédure ?
- Qui valide les automatisations avant activation ?
- Qui contrôle les doublons, et à quelle fréquence ?
- Qui revoit les droits d’accès, et selon quel calendrier ?
- Qui décide de la suppression d’un champ inutilisé ?
Ces questions semblent administratives, mais elles conditionnent la fiabilité de tout l’écosystème. Un CRM sans gouvernance accumule en deux ans des dizaines de champs créés pour un besoin ponctuel et jamais supprimés.
📈Anticiper le multi-campus
Dans les structures à plusieurs sites, il faut gérer les droits avec finesse : les équipes locales doivent garder leur autonomie, tandis que la direction a besoin d’une vision consolidée. Le campus devient alors une dimension présente sur les objets principaux, pas une simple étiquette.
Prévoyez également le cas des personnes concernées par plusieurs campus — un candidat qui postule à deux sites, un intervenant qui enseigne sur trois. Ce cas apparaît toujours et doit être traité dans le modèle plutôt que contourné.
Voir aussi : traiter les doublons et gérer les droits en multi-campus.
❓Questions fréquentes
Faut-il séparer prospects et étudiants dans deux bases ?
Non. Une entité unique avec un statut permet de suivre le parcours complet et évite les doublons. La séparation empêche notamment d’analyser le trajet entre première demande et inscription.
Combien de champs personnalisés créer ?
Le moins possible, et uniquement pour des informations utilisées dans une action ou un rapport. Chaque champ inutilisé dégrade la lisibilité et la qualité de la saisie.
Comment gérer un candidat qui postule à plusieurs programmes ?
Par plusieurs candidatures rattachées à la même personne. Créer un contact par candidature produit des doublons et fausse tous les indicateurs.
Quand faut-il revoir son modèle de données ?
Lors d’un changement d’organisation, de l’ajout d’une nouvelle activité, ou lorsque les équipes contournent l’outil avec des tableurs. Ce contournement signale presque toujours un manque du modèle.
🚀Passer de la méthode à l’outil
Loop réunit la gestion administrative, la conformité Qualiopi, le financement, le LMS et le suivi des apprenants dans une seule plateforme — sans double saisie entre vos tableurs et vos outils métier.