L’absence de connecteur dans un catalogue ne signifie pas que deux logiciels ne peuvent pas échanger. Ils peuvent proposer une API, des notifications, un import de fichiers ou un autre point d’entrée autorisé. La difficulté consiste moins à déplacer une première ligne qu’à assurer un échange fiable dans la durée.

Une connexion doit reconnaître les éléments déjà traités, supporter les pannes et expliquer les erreurs. Sans ces mécanismes, elle remplace parfois une ressaisie visible par des incohérences silencieuses. Avant de choisir une plateforme d’automatisation, il faut définir les données, les responsabilités et les conséquences d’un échec.

Décrire le flux avant de chercher l’outil

Choisissez une opération précise : créer un dossier après une commande, mettre à jour un contact ou transmettre un statut. Évitez de commencer par « synchroniser les deux logiciels », formulation qui laisse indéfinis les champs et les règles de priorité.

Désignez la source de référence de chaque information. Le nom commercial peut être maintenu dans le CRM tandis que le statut de paiement vient de la comptabilité. Si les deux systèmes peuvent modifier le même champ, il faut définir les conflits et les priorités. La fréquence doit répondre au besoin. Un traitement nocturne peut suffire pour un rapport ; un stock partagé peut exiger davantage de réactivité. Le temps réel ajoute des contraintes et ne doit pas être choisi automatiquement pour paraître moderne.

Documentez les entrées, les sorties et les exclusions. Une création, une modification et une suppression ne sont pas le même événement. Le flux doit également préciser les cas qui nécessitent une validation humaine plutôt qu’une action automatique.

Commencez par une seule direction maîtrisée.

Une synchronisation bidirectionnelle peut être nécessaire, mais elle crée plus de situations à traiter : boucles, conflits et suppressions croisées. Elle doit être justifiée par le travail réel.

Examiner les interfaces autorisées

Une API permet de lire ou modifier des données selon une documentation. Vérifiez les objets accessibles, les méthodes, les droits et les conditions de l’offre. Une API limitée à la consultation ne permet pas forcément de créer les éléments attendus.

Un webhook envoie une notification lorsqu’un événement se produit. Il peut réduire les interrogations répétées de l’API. Il ne garantit pas toujours une livraison immédiate, ordonnée ou unique. Les garanties exactes dépendent du fournisseur.

Un export et un import de fichiers peuvent constituer une solution robuste pour un rythme différé. Ils demandent un format stable et des règles de reprise. Une automatisation n’a pas besoin d’être instantanée pour apporter une valeur. La base de données ne doit être utilisée directement que dans un cadre autorisé et documenté. Une écriture contournant la logique applicative peut casser les relations ou les contrôles. Le fait de disposer techniquement d’un accès ne prouve pas qu’il constitue une interface de développement supportée.

Demandez aux éditeurs quelles méthodes ils maintiennent. Les interfaces non documentées et les appels internes observés dans un navigateur peuvent changer sans engagement. Ils ne doivent pas être assimilés à une API publique stable.

Choisir entre intermédiaire et développement

Une plateforme d’intégration peut orchestrer des appels, transformer les données et gérer certains essais. Vérifiez qu’elle supporte effectivement l’authentification et les opérations nécessaires, pas seulement le nom des logiciels dans une liste commerciale.

Un développement spécifique peut convenir à des règles complexes, des volumes particuliers ou une exigence de contrôle. Il implique une maintenance, une surveillance et une documentation. Un petit script non suivi peut devenir plus fragile qu’une solution manuelle organisée.

Comparez le coût complet : abonnement, opérations facturées, hébergement, développement et entretien. Un flux comportant plusieurs étapes peut consommer plusieurs unités à chaque dossier. Les erreurs et reprises peuvent également augmenter le volume.

La responsabilité des données doit être examinée si un intermédiaire reçoit des informations personnelles. Le contrat, les accès et les transferts éventuels font partie du choix. Le connecteur ne disparaît pas du périmètre de sécurité parce qu’il ne stocke les données que temporairement.

Une preuve de concept limitée doit confirmer les points difficiles : authentification, pièce jointe, volume et règle de mise à jour. Un formulaire de démonstration rempli une fois ne valide pas toute l’intégration.

Construire une correspondance explicite

Associez chaque champ source à une destination et à une règle de transformation. Les dates, devises, listes de valeurs et unités doivent être définies. « Statut » peut signifier des choses différentes dans les deux systèmes.

Les identifiants sont centraux. Un nom ou une adresse ne sont pas toujours des clés fiables. Conservez une correspondance entre identifiant source et identifiant destination afin de reconnaître les éléments déjà créés. Les changements de nom ne doivent pas produire automatiquement un nouveau dossier. Les champs vides demandent une décision : ignorer, effacer ou signaler ? Une absence de valeur dans une extraction partielle ne doit pas forcément supprimer une information déjà renseignée. La règle doit tenir compte de l’autorité du système source.

Les pièces jointes peuvent nécessiter plusieurs étapes : téléchargement autorisé, contrôle, dépôt et rattachement. Un lien temporaire ne constitue pas une copie durable. Vérifiez la récupération des fichiers et métadonnées d’un service en ligne lorsque le flux dépend de ces éléments.

Les transformations doivent être testables. Conservez quelques cas de référence avec données fictives et résultat attendu. Un changement de champ ou de format doit déclencher une vérification avant de traiter toute la production.

Éviter les doublons quand une requête est répétée

Une requête peut arriver à destination alors que sa réponse n’atteint pas l’émetteur. Si celui-ci recommence sans précaution, il peut créer deux dossiers ou envoyer deux notifications. L’idempotence consiste à rendre une répétition sans effet supplémentaire indésirable pour une même opération logique.

Utilisez le mécanisme prévu par l’API lorsqu’il existe, selon sa documentation. Une clé d’idempotence ou un identifiant métier peut aider. Sa portée et sa durée de conservation ne sont pas universelles ; elles doivent être comprises.

Pour les événements, conservez un registre des identifiants traités ou une méthode équivalente. La vérification doit être conçue pour les traitements simultanés : deux travailleurs ne doivent pas décider au même instant que l’événement est nouveau, puis créer chacun un élément. Un webhook peut être reçu plusieurs fois ou dans un ordre différent. Si un ancien événement arrive après un plus récent, une mise à jour naïve peut rétablir un état périmé. Selon le service, il peut être nécessaire de consulter l’état actuel ou d’utiliser une version documentée plutôt que la seule heure de réception.

Ne promettez pas une livraison « exactement une fois » sans garantie de bout en bout. Il est souvent plus réaliste de prévoir les répétitions et de rendre leurs effets sûrs. L’utilisateur doit pouvoir comprendre ce qui a été créé et à partir de quel événement.

Gérer les erreurs selon leur nature

Une erreur d’authentification ne se traite pas comme une saturation temporaire. Un champ invalide ne sera pas corrigé en répétant la même demande cent fois. Classez les échecs pour choisir l’action : correction de données, renouvellement d’accès, attente ou intervention.

Les limites de débit doivent être respectées. Utilisez les indications documentées du service et un délai de reprise adapté. Accélérer les appels lorsque le fournisseur demande d’attendre peut aggraver le problème et conduire à un blocage.

Une file de travail facilite les reprises. Elle peut enregistrer l’événement reçu avant un traitement plus long, puis conserver les cas non résolus. L’accusé de réception doit correspondre à une étape durable définie ; répondre « succès » sans rien conserver peut perdre silencieusement une opération.

Préparez une file d’exceptions avec référence, cause, statut et responsable. Les erreurs ne doivent pas rester dans un journal technique que personne ne consulte. Les informations visibles doivent permettre de corriger sans exposer des secrets ou des données excessives.

Les reprises manuelles doivent elles aussi éviter les doublons. Un bouton « relancer » peut être dangereux s’il ne vérifie pas qu’une partie de l’opération a déjà réussi. Le processus doit savoir reprendre au bon point ou vérifier l’état distant.

Un rapprochement périodique peut compléter le flux d’événements. Il compare les éléments attendus entre les applications et signale les absences ou divergences. Ce contrôle ne doit pas écraser automatiquement les différences : certaines peuvent être légitimes. Il sert à détecter un événement manqué ou une reprise incomplète, puis à déclencher une correction traçable. Le rythme doit suivre le risque et le délai accepté par le métier.

Protéger les accès et vérifier les messages entrants

Créez des comptes ou autorisations dédiés, avec le périmètre nécessaire. Évitez de faire dépendre durablement l’intégration du compte personnel d’un salarié. Son départ ou un changement de rôle pourrait interrompre le flux.

Les secrets doivent être stockés dans un mécanisme adapté et renouvelés selon la politique retenue. Ils ne doivent pas apparaître dans les journaux ni dans les exports de configuration destinés à circuler. Prévoyez la révocation en cas d’incident.

Pour les webhooks, vérifiez l’authenticité selon le protocole du fournisseur : signature, secret et autres contrôles documentés. Une adresse difficile à deviner ne constitue pas une authentification suffisante. Les protections contre les répétitions malveillantes doivent être distinguées du simple traitement des doublons ordinaires.

Limitez les données transmises. Un logiciel de planning n’a pas forcément besoin de tous les détails d’une fiche client. La minimisation réduit l’exposition et simplifie souvent la maintenance du flux.

Utiliser une automatisation d’interface en dernier recours raisonné

La RPA automatise des interactions avec une interface, par exemple des clics et des saisies. Elle peut aider lorsqu’aucune autre méthode autorisée ne répond au besoin. Elle reste sensible aux changements d’écran, de libellé et de session.

Elle ne doit pas contourner une protection, un contrôle d’accès ou les conditions du service. Si une authentification impose une validation humaine, prévoyez un parcours approuvé ou demandez une interface adaptée au fournisseur. Désactiver une sécurité pour laisser un robot agir n’est pas une solution de maintenance.

Le robot doit détecter les situations inattendues et s’arrêter proprement. Un bouton déplacé ne doit pas conduire à valider une autre action. Utilisez un environnement de test et des contrôles de résultat, pas seulement une suite de coordonnées d’écran.

Comparez cette fragilité au coût d’une importation différée ou d’un changement d’outil. La RPA peut être utile, mais son temps d’entretien doit être prévu. Une démonstration réussie sur une session ne prouve pas un fonctionnement durable.

Utiliser un échange de fichiers avec un vrai protocole

Lorsque les applications ne proposent pas l’API nécessaire, un fichier intermédiaire peut suffire. Définissez son nom, son format, son emplacement et la manière d’indiquer qu’il est complet. Un destinataire ne doit pas commencer à lire un fichier encore en cours d’écriture.

Selon l’environnement, un dépôt temporaire puis une publication contrôlée peuvent être utilisés. Leur comportement doit être vérifié sur le système concerné. Ne supposez pas qu’un renommage ou un déplacement possède les mêmes garanties sur tous les supports.

Ajoutez un identifiant de lot et un inventaire utile : nombre de lignes, date et éventuellement empreinte selon le besoin. Le contrôle doit vérifier que le lot attendu est arrivé et qu’il n’a pas déjà été traité. Une copie du même fichier sous un autre nom ne devrait pas déclencher une nouvelle opération métier.

Le destinataire doit produire un résultat de traitement : accepté, partiellement rejeté ou refusé, avec les références nécessaires à la correction. Une absence de fichier d’erreur ne constitue pas toujours une preuve de réussite. Les lots rejetés doivent rejoindre une file surveillée.

Prévoyez la conservation limitée des fichiers et leur protection. Les exports peuvent contenir plus de données que nécessaire si l’on utilise un modèle standard non filtré. Les droits du dossier de transit doivent être aussi maîtrisés que ceux des applications.

Cette approche peut être moins immédiate qu’un webhook, mais plus simple à exploiter pour un besoin quotidien. Le bon choix dépend du délai accepté et de la capacité à vérifier le traitement, pas du prestige technique de l’interface.

Mettre en service avec une preuve de rapprochement

Testez les créations, modifications, doublons, pièces, erreurs et interruptions. Vérifiez également les volumes et les reprises après une panne. Les essais doivent utiliser un périmètre autorisé et des données de démonstration adaptées.

Une première phase peut fonctionner en parallèle d’un contrôle humain, sans exécuter deux fois les mêmes actions. Comparez les éléments source et destination : nombre, identifiants, champs critiques et statuts. Un total global identique peut masquer des affectations incorrectes.

Définissez une alerte de silence. Un flux qui ne reçoit plus aucun événement peut être cassé sans produire d’erreur. La surveillance doit donc examiner ce qui était attendu, selon le rythme du métier.

Attribuez un propriétaire, une documentation et une procédure de suspension. Lorsque l’un des logiciels change son API ou sa tarification, l’intégration doit être revue. Une connexion fiable est un petit service à exploiter, pas un assemblage que l’on oublie après le premier transfert réussi.