Faire dialoguer vos outils

Cartographier vos flux avant d’écrire la première ligne

Un projet d’interconnexion commence par un inventaire rarement disponible en entier au démarrage : quels logiciels tournent, qui détient quelle donnée, quels échanges existent déjà sous forme de copier-coller. Nous suivons trois ou quatre objets du métier de bout en bout, un client, une commande, une intervention, un salarié, en notant chaque endroit où ils changent de support. Cette carte fait apparaître ce qu’aucun organigramme ne montre : un tableur intermédiaire dont dépendent deux services, un export que plus personne ne relit, une connexion ouverte avec le compte d’un salarié parti. L’audit technique se mène au même moment, sur les versions installées, les interfaces réellement disponibles et leurs quotas, la volumétrie annuelle, le format des identifiants. Les jours passés là se récupèrent au premier quota d’appels découvert à temps, plutôt qu’au milieu du développement. Sur un périmètre réduit à deux logiciels, l’exercice reste court, cas traité sur connecter deux logiciels entre eux.

Le sens de chaque flux, champ par champ

Un échange se décrit par quatre décisions : ce qui part, d’où, vers où, et qui gagne en cas de désaccord. Quand un seul logiciel sert à modifier la donnée, le sens unique suffit, et il se maintient bien plus facilement qu’un aller-retour. Le double sens se justifie quand les deux logiciels servent vraiment à modifier la même information, et il réclame alors une règle explicite sur chaque champ concerné. Nous ajoutons systématiquement un identifiant technique commun, invisible pour les utilisateurs, qui relie l’enregistrement d’un côté à celui de l’autre : sans lui, un rapprochement par nom ou par adresse électronique se casse au premier homonyme et à la première correction de saisie. Cette question devient épineuse sur le fichier clients, souvent présent dans trois outils à la fois, sujet traité sur synchroniser son CRM avec ses autres outils.

Temps réel, file d’attente ou synchronisation programmée

Le rythme se choisit flux par flux, entre trois modes. L’appel direct s’impose quand une réponse immédiate conditionne la suite du travail. La file d’attente sert dès que l’événement doit partir tout de suite alors que le logiciel destinataire répond lentement ou tombe parfois, typiquement un webhook envoyé par l’outil source dès qu’une donnée change : le message attend son tour et repart quand la voie se libère. Pour les gros volumes et les données qui bougent peu dans la journée, une synchronisation programmée de nuit fait l’affaire, ce que les équipes techniques appellent un ETL, un traitement qui extrait les données, les met en forme puis les recharge dans l’outil cible. Ce choix a des conséquences chiffrables, une API facturée à l’appel, un quota horaire, un serveur qui refuse les envois massifs aux heures de bureau. Ces limites viennent le plus souvent des services tiers auxquels vous vous branchez, sujet développé sur l’intégration d’une API tierce. Nous les regardons avant de fixer le rythme, pas à la première facture.

Les erreurs qu’une interconnexion doit rattraper toute seule

Un connecteur passe l’essentiel de sa vie à fonctionner et se juge sur les quelques heures où il échoue. Trois mécanismes font la différence. Chaque échange porte une référence unique, donc un envoi répété met à jour l’enregistrement existant au lieu d’en créer un second. Un lot interrompu au trois centième enregistrement repart du trois centième, sans rejouer les deux cent quatre-vingt-dix-neuf précédents. Enfin, une donnée refusée par l’outil destinataire, un client sans code postal, un article dont la référence a disparu du catalogue, s’écarte dans une file consultable plutôt que de bloquer tout ce qui la suit. Sans ces trois garde-fous, une panne d’une heure laisse derrière elle un travail de reprise manuelle bien plus long que la panne elle-même.

Trois visages de l’interconnexion, selon ce que vous reliez

Relier deux outils recouvre des chantiers différents selon ce qu’il y a de l’autre côté. Une API tierce impose ses propres règles, un fournisseur qui fixe seul ses quotas, ses jetons qui expirent et ses dates d’arrêt de version : le travail consiste à protéger votre outil des mauvais jours de quelqu’un d’autre. Synchroniser un CRM pose une question différente, celle de désigner quel logiciel fait autorité champ par champ quand deux outils décrivent le même client avec deux vocabulaires. Une interconnexion CRM/ERP est le cas le plus chargé des trois, parce qu’elle touche à l’argent : le tarif qui descend de la gestion vers la vente, la commande signée qui remonte, l’encours qui doit s’afficher avant la livraison plutôt qu’après. Le connecteur change de nature à chaque fois, la méthode de cadrage reste la même.

Connecter un logiciel qui n’expose rien

Certains logiciels métier installés il y a quinze ans ne proposent aucune API et n’en proposeront jamais. Ils restent connectables par d’autres voies. Un export programmé vers un dossier surveillé, une lecture directe de la base en respectant ses verrous, un fichier déposé sur un serveur d’échange : ces canaux fonctionnent, à condition de reconstruire ce qu’une API aurait donné d’emblée, la détection des doublons et l’ordre des opérations. La vraie question se pose ailleurs. Un outil fermé impose son rythme au reste du système, et cette contrainte pèse dans la décision de le garder ou de le remplacer. Quand les chiffres enfermés dedans servent au pilotage, les déverser vers une application de suivi d’activité vaut souvent mieux que dix ans de connecteur entretenu autour de lui.

Vos connecteurs vous appartiennent, y compris le jour où vous partez

À la mise en service, vous récupérez le code des connecteurs, la documentation de chaque flux, les accès aux serveurs et les droits qui vont avec. Ces flux tournent sur votre infrastructure et sous vos comptes techniques, donc leur fonctionnement ne tient à aucun contrat signé avec nous. Nous privilégions le code que vous détenez à une plateforme d’intégration propriétaire, dont la facture grossit avec vos volumes et qui garde vos règles d’échange enfermées dans une interface louée. Le code que nous écrivons s’appuie sur des technologies documentées publiquement, donc le prestataire suivant le lit et le modifie sans formation particulière. C’est ce qui rend le changement possible : votre décision de travailler avec quelqu’un d’autre ne met pas vos échanges à l’arrêt.