Cartographie des sources
Quels systèmes contiennent quelles entités, et quelle est l'autorité.
Intégrations et migration de données
Un système central ne peut pas fonctionner seul, ni avec des données auxquelles personne ne fait confiance.
Nous connectons Salesforce aux systèmes déjà utilisés par l'organisation, définissons des contrats d'interface clairs et migrons les données historiques via un processus contrôlé avec une réconciliation complète.
Topologie du flux de données
Comment les données entrent, sont gouvernées et consommées
Toute intégration stable commence par décider quel système est l'autorité de chaque entité. Tout le reste – protocole, fréquence et outils – découle de cette décision.
Topologie du flux de données
Systèmes sources
D'où proviennent les données
- ERP et systèmes financiers
- Site web, formulaires et campagnes
- Centre de contact et canaux de service
- Systèmes opérationnels
Couche de contrat et de contrôle
Ce qui est régi avant l'entrée
- Contrat d'interfacechamps, format, responsabilité
- Clé d'identité et idempotence
- Validation et qualité des données
- Nouvelles tentatives, journalisation et surveillance
Salesforce et consommation
Où la donnée devient décision
- Modèle de données central
- Automatisation et processus
- Rapports et tableaux de bord
- Agentforce sur les données gouvernées
Types de systèmes
Ce qui peut être connecté
- ERP
- Systèmes financiers et comptables
- Sites web et formulaires
- Automatisation marketing
- Téléphonie et CTI
- WhatsApp et canaux de messagerie
- Systèmes de service
- BI et entrepôts de données
- Systèmes opérationnels
- Systèmes RH
- Systèmes de documents et signature électronique
- API internes
- Webhooks
La connexion elle-même n'est presque jamais difficile. Le difficile est de décider qui est responsable de chaque champ, ce qui se passe lorsque deux systèmes mettent à jour la même valeur et comment détecter une défaillance avant qu'elle ne soit détectée par les utilisateurs.
Modèles d'intégration
Choisis pour leur tolérance aux pannes, non par commodité
| Modèle | Quand cela convient | Exemple typique | Ce qu'il faut observer |
|---|---|---|---|
| Requête-Réponse | Une réponse immédiate est nécessaire avant de poursuivre le processus | Vérification de stock ou de crédit lors de la création d'une commande | Dépendance directe de la disponibilité du système cible |
| Fire and Forget | La mise à jour est importante, mais ne bloque pas le processus | Envoi d'une mise à jour de statut à un système de reporting | Nécessite des tentatives et une surveillance |
| Synchronisation par lot | Grand volume, faible sensibilité à l'actualité des données | Synchronisation nocturne du catalogue ou des prix | Décalages d'actualité entre les systèmes |
| Piloté par les événements | Plusieurs consommateurs pour un même événement métier | Publier « commande approuvée » pour plusieurs systèmes | Nécessite la gestion du schéma et de l'ordre des événements |
| Virtualisation des données | Visualiser les données sans les copier | Afficher l'historique de facturation d'un système externe | La performance dépend de la source externe |
Requête-Réponse
- Quand cela convient
- Une réponse immédiate est nécessaire avant de poursuivre le processus
- Exemple typique
- Vérification de stock ou de crédit lors de la création d'une commande
- Ce qu'il faut observer
- Dépendance directe de la disponibilité du système cible
Fire and Forget
- Quand cela convient
- La mise à jour est importante, mais ne bloque pas le processus
- Exemple typique
- Envoi d'une mise à jour de statut à un système de reporting
- Ce qu'il faut observer
- Nécessite des tentatives et une surveillance
Synchronisation par lot
- Quand cela convient
- Grand volume, faible sensibilité à l'actualité des données
- Exemple typique
- Synchronisation nocturne du catalogue ou des prix
- Ce qu'il faut observer
- Décalages d'actualité entre les systèmes
Piloté par les événements
- Quand cela convient
- Plusieurs consommateurs pour un même événement métier
- Exemple typique
- Publier « commande approuvée » pour plusieurs systèmes
- Ce qu'il faut observer
- Nécessite la gestion du schéma et de l'ordre des événements
Virtualisation des données
- Quand cela convient
- Visualiser les données sans les copier
- Exemple typique
- Afficher l'historique de facturation d'un système externe
- Ce qu'il faut observer
- La performance dépend de la source externe
Migration de données
Dix étapes contrôlées
Profilage des données
Mesure de la complétude, de la duplication, des formats irréguliers et de l'historique manquant.
Règles de nettoyage
Ce qui est corrigé automatiquement, ce qui nécessite une décision métier et ce qui ne migre pas.
Cartographie
Champ par champ, incluant les transformations et les valeurs par défaut.
Clé d'identité
Une clé métier unique par entité pour éviter les doublons lors des chargements répétés.
Chargement de test
Un chargement complet dans un environnement de test avec des volumes réels.
Validation
Vérifications du nombre, de la somme et de l'échantillonnage par rapport à la source.
Réconciliation
Une comparaison formelle et une liste de différences approuvée.
Chargement définitif
Une fenêtre de basculement planifiée avec un point de retour arrière défini.
Contrôle continu
Métriques de qualité des données maintenues après le lancement.
La vie après le go-live
Une intégration est un système qui doit être opéré
Cycle opérationnel des intégrations
- 01
Surveillance
Mesure des succès, des échecs et des temps de réponse par interface.
- 02
Alertes
Un échec qui dépasse un seuil génère une alerte pour un responsable de processus identifié.
- 03
Gestion et correction
Nouvelle tentative contrôlée, correction manuelle documentée et analyse de la cause profonde.
- 04
Ajustement
Mise à jour du contrat d'interface ou de la règle métier, et enregistrement du changement.
↻ Le cycle se répète : chaque itération alimente la priorisation de la suivante
Continuez à partir d'ici
Services et guides associés
- Architecture CRM
- Data Cloud et unification des données
- Développement et automatisation
- Implémentation de Salesforce
- Guide : modèles d'intégration Salesforce
- Guide : migration de données Salesforce
- Guide : connecter Salesforce à l'ERP
- Guide : gestion des erreurs dans les intégrations
- Guide : définir une source de vérité
- Guide : éviter les doublons dans Salesforce
Foire aux questions
Intégrations et données — questions courantes
Quand choisir une intégration en temps réel et quand une intégration par lot ?
La question décisive est de savoir ce qui se passe si les données arrivent avec une heure de retard. Si la conséquence est une décision erronée face à un client, le temps réel est nécessaire. Si la conséquence est un rapport un peu moins à jour, le processus par lot est moins cher, plus stable et plus facile à maintenir. Une combinaison courante est le temps réel pour les entités clés et le lot pour l'enrichissement et les corrections.
Qu'est-ce qu'un contrat d'interface et pourquoi est-il critique ?
Un contrat d'interface définit par écrit quel système est la source, quels champs sont déplacés, dans quel format, ce qui se passe en cas de défaillance, ce qui identifie de manière unique un enregistrement et qui est responsable des changements. Sans lui, toute mise à jour d'un côté perturbe l'autre et personne ne sait pourquoi. C'est le document qui évite la plupart des échecs d'intégration réels.
Comment éviter les doublons lors d'une migration ?
On définit une clé d'identité métier pour chaque entité avant de charger les données, on effectue un profilage des données pour connaître l'étendue réelle de la duplication, on décide d'une règle de fusion explicite et on réalise une charge de test dans un environnement de test. Ce n'est qu'après avoir surmonté la réconciliation complète que la charge définitive est exécutée.
Que faire lorsque le système source n'est pas fiable ?
On ne cache pas le problème derrière une intégration. On définit la plage de qualité acceptable, on filtre ou on marque les enregistrements qui sont hors de cette plage et on définit un processus de correction à la source. Transférer des données déficientes vers Salesforce ne fait que transférer la méfiance vers le nouveau système.
Combien de temps prend une migration de données ?
La durée dépend de la qualité de la source, et non du volume. Un million d'enregistrements propres avec une clé claire est beaucoup plus rapide que cent mille enregistrements avec des doublons et un historique partiel. C'est pourquoi le profilage est effectué tôt, avant de compromettre un quelconque délai.
Une plateforme d'intégration dédiée est-elle nécessaire ?
Pas toujours. Pour une poignée d'interfaces stables, une approche basée sur les API et les événements de plateforme est suffisante. Une plateforme dédiée se justifie lorsqu'il existe de nombreux systèmes, des transformations complexes, des exigences de surveillance centralisée ou la nécessité de réutiliser la logique entre les processus.
Prochaine étape
Planifier une intégration ou une migration
Nous cartographierons les systèmes, les sources de vérité et le niveau de qualité requis, et construirons un plan qui pourra réellement être exécuté.