Relier deux logiciels métier peut éviter des ressaisies, mais une synchronisation mal définie peut aussi créer des doublons ou écraser une information à jour. Avant de connecter les outils, décidez où chaque donnée fait foi, comment reconnaître un même dossier, quel système peut la modifier et comment l’équipe verra qu’un échange a échoué.
Cette préparation s’applique à un formulaire de site envoyé vers un outil commercial, à un logiciel de planning qui reçoit des dossiers ou à un outil métier conçu pour l’entreprise. Une connexion technique ne décide pas à votre place du sens des champs et des responsabilités. Ces règles doivent être compréhensibles par les personnes qui suivent le processus. Pour cadrer un besoin plus large, la page consacrée aux logiciels métier sur mesure présente le service réellement proposé par l’agence.
Décrire l’échange avant de choisir une connexion
Écrivez le trajet d’une information sous la forme « quand ceci arrive, cette donnée est transmise ici, puis telle personne fait telle action ». Par exemple : lorsqu’un prospect remplit le formulaire du site, son nom, son adresse de contact, le service demandé et la date de réception sont ajoutés au suivi commercial. L’équipe examine ensuite le dossier et complète les informations de qualification.
Listez seulement les champs nécessaires à cette étape. Un outil n’a pas besoin de recevoir toutes les données disponibles dans l’autre. Pour chaque champ, notez son nom dans les deux logiciels, son format, s’il est obligatoire et la règle appliquée lorsqu’il manque. « Téléphone » peut être facultatif dans le formulaire mais ne doit pas devenir une chaîne vide qui remplace une valeur déjà vérifiée dans l’outil de suivi.
Un tableau court aide à partager la définition :
| Information | Origine de référence | Destination | Contrôle à prévoir |
|---|---|---|---|
| Identifiant du dossier | Outil de suivi | Logiciel métier | Une seule fiche par identifiant |
| Adresse de contact | Formulaire, puis validation par l’équipe | Outil de suivi | Signaler une adresse absente ou invalide |
| Statut du traitement | Outil où l’équipe suit les étapes | Autre outil si nécessaire | Ne pas remplacer un statut plus récent |
| Date de transmission | Système qui envoie l’information | Journal ou fiche liée | Comparer l’heure d’envoi et de réception |
Les noms et champs de ce tableau sont des exemples : vérifiez les possibilités réelles de vos logiciels avant de retenir une règle.
Choisir une source de référence pour chaque donnée
Quand deux outils contiennent le même champ, désignez celui qui peut le modifier. L’outil où une information apparaît n’est pas toujours celui où elle est tenue à jour. Une adresse de contact peut venir du site à l’origine, puis être corrigée après vérification par une personne dans le CRM. Si la prochaine synchronisation remplace cette correction par l’ancienne valeur, l’automatisation défait le travail de l’équipe.
Évitez la règle vague « les deux outils se mettent à jour mutuellement ». Elle ne dit pas quoi faire si une même donnée est modifiée des deux côtés, si les horloges diffèrent ou si une transmission arrive en retard. Commencez plutôt par un sens clair : un outil crée le dossier et l’autre le reçoit, ou bien le système de suivi renvoie un nombre limité de champs vers le site.
Pour chaque donnée partagée, écrivez : l’outil autorisé à la créer, celui qui peut la corriger, les systèmes qui la consultent et le comportement prévu en cas de conflit. Cette source de référence peut différer selon les champs. Le statut du dossier peut être tenu dans un outil métier tandis que l’adresse de contact est corrigée dans le CRM.
Reconnaître le même dossier sans se fier au seul nom
Une synchronisation répétée doit savoir si elle crée un nouveau dossier ou met à jour un dossier déjà connu. Un nom de personne ou d’entreprise ne suffit pas toujours : plusieurs personnes peuvent porter le même nom, et une entreprise peut être écrite de plusieurs façons. Choisissez une clé stable présente ou attribuée à la création, comme un identifiant de dossier conservé entre les systèmes.
Si aucun identifiant commun n’existe, définissez un rapprochement contrôlé. Par exemple, le système peut chercher une adresse électronique normalisée puis mettre en attente les correspondances ambiguës au lieu de fusionner automatiquement les dossiers. Une fusion erronée peut mêler des échanges ou des tâches appartenant à deux clients différents.
Dans sa documentation de synchronisation Dataverse, Microsoft décrit notamment les clés alternatives et l’opération « upsert », qui met à jour un enregistrement correspondant ou en crée un en l’absence de correspondance. Il s’agit de mécanismes propres à Dataverse ; pour un autre outil, vérifiez l’équivalent disponible et les conditions de rapprochement qu’il applique (documentation Microsoft).
Définir les règles de mise à jour et de conflit
Précisez quelles modifications doivent être transmises : création, changement de statut, correction d’un champ ou fermeture d’un dossier. Vous pouvez limiter la première version à la création et à quelques mises à jour choisies. Cette restriction rend plus facile de voir quels changements sont attendus et où ils doivent apparaître.
Pour un champ modifiable dans plusieurs outils, choisissez une règle avant le lancement : une seule application peut écrire, une personne tranche les conflits, ou une règle documentée sélectionne la version à conserver. Ne supposez pas que « la dernière modification gagne » est sans risque : une arrivée tardive peut contenir une valeur ancienne, surtout si la date de mise à jour n’a pas le même sens dans les deux systèmes.
Définissez aussi ce qui n’est pas synchronisé. Les notes internes, les pièces jointes, les commentaires ou certaines informations personnelles ne doivent pas être copiés automatiquement sans besoin identifié. La CNIL recommande de limiter les données et permissions au nécessaire et de tracer les échanges lorsqu’une API partage des données. Ces principes sont utiles au cadrage technique ; ils ne remplacent pas l’examen des règles applicables au traitement concerné.
Prévoir une reprise lisible quand un échange échoue
Une connexion doit rendre les échecs visibles à quelqu’un. Demandez quelles informations seront accessibles : dossier concerné, étape en erreur, date, nombre de tentatives et motif disponible. Évitez de présenter une demande comme « traitée » si le système l’a seulement reçue avant qu’une étape ultérieure échoue.
Fixez une procédure simple : qui reçoit l’alerte, qui vérifie la donnée à la source, comment la transmission est relancée et comment éviter qu’une relance crée un doublon. Pour une erreur permanente, comme un champ obligatoire absent, une personne doit pouvoir corriger la fiche ou la mettre en attente. Pour une panne temporaire, une nouvelle tentative peut être prévue, sous réserve que le mécanisme reconnaisse les dossiers déjà créés.
Conservez un relevé suffisamment utile pour comprendre le parcours et repérer les écarts, sans copier des contenus sensibles inutilement. La fiche CNIL sur la sécurité des API recommande des journaux pertinents, une documentation des formats échangés et une réaction possible aux comportements inhabituels. Adaptez le niveau de suivi aux données et aux conséquences d’une erreur.
Limiter les accès de la connexion
Un outil connecté reçoit des permissions. Faites l’inventaire de ce que le compte technique peut lire, créer ou modifier, puis retirez les droits qui ne servent pas au flux prévu. Séparez si possible les accès destinés au fonctionnement quotidien des accès d’administration. Prévoyez aussi qui peut renouveler ou révoquer les identifiants de connexion.
La CNIL recommande de définir des profils d’habilitation selon les missions et de limiter les droits aux seules données nécessaires. Pour un flux entre outils, cette vérification concerne autant le compte technique que les personnes qui peuvent consulter les journaux ou relancer une transmission (CNIL — gérer les habilitations). Si des données personnelles circulent, faites valider les accès et la durée de conservation par les personnes responsables dans votre organisation.
Tester des cas représentatifs avant la mise en service
Avant d’activer l’échange pour tout le monde, testez avec des dossiers contrôlés dans un environnement de test si les outils le permettent. Vérifiez au minimum :
- une création complète et une création avec un champ facultatif absent ;
- une transmission répétée du même événement ;
- un dossier qui existe déjà dans l’outil de destination ;
- une valeur corrigée par une personne avant une mise à jour ultérieure ;
- une erreur de format ou une connexion interrompue ;
- une relance, puis le contrôle du résultat dans chaque outil.
Pour chaque essai, comparez le nombre de dossiers, les identifiants, les champs transmis et les statuts obtenus. Demandez à une personne qui suit le processus de vérifier si elle peut retrouver la demande et savoir quoi faire ensuite. Les tests techniques confirment que les systèmes échangent ; le contrôle métier confirme que l’équipe comprend le résultat.
Lancez ensuite un périmètre réduit et examinez les premiers échanges à une fréquence définie. Notez les doublons, les corrections manuelles, les échecs et les retards. Si le suivi est clair et les résultats cohérents, vous pourrez élargir les champs ou les étapes. Sinon, corrigez d’abord la règle de référence ou de reprise.
Commencer par un flux limité et vérifiable
Une intégration utile commence par une seule tâche répétitive et une donnée dont le trajet est compréhensible. Documentez la source, l’identifiant, les champs, le sens de la mise à jour, les permissions et la procédure d’erreur. Gardez un responsable qui peut répondre aux questions et vérifier les transmissions.
Quand plusieurs outils doivent soutenir un processus propre à l’entreprise, un logiciel métier conçu autour des usages de l’équipe peut être cadré avec ses données, ses rôles et ses contrôles. Pour examiner votre cas, vous pouvez décrire le processus à relier : quels outils sont concernés, quelle tâche se répète et ce qui doit se passer lorsqu’un transfert échoue.