Faire parler deux logiciels qui s'ignorent

Toute PME a au moins deux logiciels qui devraient se parler et qui ne le font pas. Un CRM et une comptabilité. Un outil de planning et une facturation. Une boîte mail et à peu près tout le reste.

Entre les deux, il y a quelqu’un. Cette personne lit d’un côté, comprend, et saisit de l’autre. Elle est le connecteur, et elle ne le sait pas toujours.

Ce que coûte un connecteur humain

Il est lent, mais ce n’est pas le pire.

Il est indisponible — en congés, en réunion, malade. Le lien s’arrête avec lui, et l’information s’accumule en attendant son retour.

Il est silencieux : quand il se trompe, rien ne le signale. L’erreur se découvre plus tard, souvent au pire moment.

Il est sans mémoire : personne ne peut dire pourquoi telle donnée a été saisie ainsi il y a trois mois.

Les quatre façons de relier deux outils

Elles ne se valent pas, et le choix dépend surtout de ce que les logiciels acceptent.

L’interface officielle. Beaucoup de logiciels en exposent une, prévue pour ça. C’est la voie la plus solide : elle est documentée, versionnée, et elle survit aux mises à jour. Quand elle existe, la question ne se pose pas.

Le fichier d’échange. L’un exporte, l’autre importe, à intervalle régulier. Rustique, mais robuste et facile à vérifier. C’est souvent la bonne réponse pour un besoin quotidien qui n’exige pas l’instantané.

Le déclenchement par événement. Un logiciel prévient qu’il s’est passé quelque chose, l’autre réagit. Le plus élégant quand c’est disponible, mais il faut prévoir ce qui se passe si le message se perd.

L’accès direct à la base de données. Techniquement possible, presque toujours une mauvaise idée : rien ne garantit que la structure survivra à la prochaine version de l’éditeur. À réserver aux cas où rien d’autre n’existe, et en sachant ce qu’on prend comme risque.

Les trois questions qui comptent plus que la technique

Qui détient la vérité ? Pour chaque information partagée, un seul système doit faire foi. C’est la règle qui évite les divergences silencieuses, celles qu’on découvre six mois plus tard sans savoir laquelle des deux versions croire.

Que fait-on quand ça échoue ? Une connexion tombera : le serveur d’en face sera indisponible, un format changera, une donnée sera refusée. Ce qui distingue une intégration sérieuse d’un script bricolé, c’est ce qui se passe à ce moment-là — reprise automatique, alerte, ou silence.

Une intégration qui n’a pas prévu ses pannes n’est pas terminée. Elle attend simplement la première.

Comment sait-on que ça marche encore ? Un lien automatique est invisible tant qu’il fonctionne. Sans contrôle, son arrêt ne se remarque qu’à la première conséquence visible — souvent des semaines plus tard.

Par où commencer

Prenez le trajet d’information qui vous coûte le plus, et décrivez-le en trois lignes : ce qui entre, ce qui doit sortir, et qui fait le lien aujourd’hui.

Si ces trois lignes tiennent, la connexion est faisable. Si elles ne tiennent pas, le problème n’est pas technique : c’est le processus qui n’est pas clair, et aucun connecteur ne réglera ça.

Le diagnostic part de votre description et vous dit ce qui serait construit, en moins d’une minute.