💡En bref
Pour chaque donnée, un seul système doit faire autorité ; les autres la reçoivent en lecture. Cette règle, décidée avant toute intégration, élimine la majorité des conflits de synchronisation. Les points délicats sont les données qui changent de maître au cours du parcours, comme l’identité au moment de l’inscription.
🔗Pourquoi cette décision précède la technique
La plupart des problèmes d’intégration ne sont pas techniques mais organisationnels : deux systèmes détiennent la même information, chacun la modifie, et personne n’a défini laquelle prévaut. Le connecteur, aussi bien construit soit-il, ne peut pas trancher à votre place.
Définir le système maître revient à répondre à une question simple pour chaque donnée : si les deux valeurs diffèrent, laquelle est vraie ? Cette question doit être posée avant d’écrire la moindre ligne de configuration.
🗂️Une matrice simple
| Donnée | Système maître | Systèmes en lecture |
|---|---|---|
| Identité avant inscription | CRM | — |
| Identité après inscription | Gestion administrative | CRM, LMS |
| Coordonnées de contact | Gestion administrative | CRM, LMS |
| Consentements et préférences | CRM | Emailing |
| Statut d’inscription | Gestion administrative | CRM |
| Progression pédagogique | LMS | CRM (synthèse) |
| Facturation et règlements | Gestion administrative | CRM (statut) |
| Historique des échanges | CRM | — |
Cette matrice tient sur une page et doit être validée par les responsables métier concernés, pas seulement par l’équipe technique. Elle constitue la référence en cas de désaccord ultérieur.
⚙️Gérer les points de bascule
Certaines données changent de maître au cours du parcours. C’est le cas typique de l’identité : le CRM la détient pendant la phase de candidature, la gestion administrative la reprend une fois l’inscription validée.
- Identifier l’événement exact qui déclenche la bascule.
- Verrouiller la modification dans le système qui perd la main.
- Informer les utilisateurs concernés du changement de règle.
- Prévoir une procédure pour les corrections exceptionnelles.
- Tracer les modifications effectuées après la bascule.
Sans verrouillage, les utilisateurs continuent naturellement à modifier là où ils ont l’habitude, et la règle devient théorique.
📥Traiter les conflits résiduels
Même avec des règles claires, des conflits surviennent : modification simultanée, synchronisation retardée, correction manuelle d’un côté. Prévoyez une politique explicite plutôt que de laisser le connecteur décider silencieusement.
- Priorité au système maître, sans exception automatique.
- Journalisation de la valeur écrasée, pour permettre une vérification.
- Alerte à un responsable au-delà d’un nombre de conflits.
- Procédure de correction documentée, avec un point d’entrée unique.
- Revue périodique des conflits, pour corriger la cause plutôt que le symptôme.
🛡️Le cas des données saisies par la personne
Un candidat qui met à jour son adresse dans son espace personnel crée une situation particulière : la donnée vient de l’extérieur du système. La règle recommandée consiste à traiter cette saisie comme une demande de modification, appliquée automatiquement sur les champs non structurants et validée pour les autres.
Cette approche préserve la fiabilité tout en évitant de rendre l’espace personnel inutile. Elle suppose de distinguer clairement les champs modifiables librement de ceux qui nécessitent une vérification.
📈Documenter et faire vivre la matrice
La matrice doit être accessible aux équipes, pas enfouie dans un document technique. Elle répond à des questions quotidiennes : où corriger une adresse, pourquoi un changement n’apparaît pas, à qui demander une modification.
Revoyez-la à chaque ajout d’outil ou de flux. Un nouvel outil connecté sans mise à jour de la matrice réintroduit exactement les problèmes que celle-ci avait permis d’éliminer.
Voir aussi : connecter CRM et ERP et traiter les doublons.
❓Questions fréquentes
Peut-on avoir deux systèmes maîtres pour la même donnée ?
Non, c’est précisément ce qu’il faut éviter. Si deux services ont besoin de modifier la même information, définissez un maître unique et une procédure de demande pour l’autre.
Que faire si le système maître est peu accessible aux équipes ?
Ouvrir un accès restreint aux personnes concernées ou mettre en place une procédure de demande simple. Contourner en modifiant ailleurs recrée immédiatement la divergence.
La matrice doit-elle couvrir toutes les données ?
Seulement celles partagées entre plusieurs systèmes. Les données propres à un seul outil ne posent pas de question d’autorité.
Qui décide en cas de désaccord entre services ?
Un arbitre désigné en amont, généralement le responsable des systèmes d’information ou de l’organisation. L’absence d’arbitre identifié laisse les conflits ouverts pendant des mois.
🚀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.