Quand on parle de “connecteurs” dans un projet informatique, on a tous déjà entendu cette promesse alléchante : “Ne vous inquiétez pas, les deux outils sont connectés via un connecteur”. Une phrase magique, balancée souvent un peu trop vite en phase d’avant-vente. Mais dans la réalité des projets, cette magie n’existe pas.

Le fantasme du bouton “ON”

Pour beaucoup (et on ne peut pas leur en vouloir), un connecteur, c’est une sorte de bouton “ON/OFF” : tu l’actives, et bim, les logiciels se parlent, les données circulent, la vie est belle.

Ce mythe est entretenu par des discours commerciaux bien rodés, où l’on te vend une interconnexion fluide, transparente et instantanée. Et pourtant, en tant que professionnel des systèmes d’information et habitué des projets d’intégration, je peux vous le dire sans détour : ce raccourci est dangereux.

Connecteur = développement + configuration + cadrage

Un “connecteur”, ce n’est pas un fichier magique. C’est une construction, un projet à part entière. Derrière ce mot se cache un combo de paramétrage, de développement sur mesure, et surtout d’analyse fonctionnelle approfondie.

Chaque outil a sa propre logique, sa propre manière de stocker et manipuler les données. Même entre deux entreprises qui utilisent exactement le même logiciel, comme Sage X3 par exemple, les structures de données, les règles de gestion et les paramétrages peuvent être radicalement différents.

Prenons le cas concret de l’interconnexion entre DocuWare (GED) et Sage X3. J’ai eu à mettre en place ce type d’interface dans plusieurs projets. Et bien, à chaque fois, même si l’activité des clients était similaire, je n’ai jamais pu réutiliser le même “connecteur” tel quel.

Sage X3 : même logiciel, usage différent

Sage X3 est un ERP très puissant mais extrêmement personnalisable. Résultat : deux clients dans le même secteur peuvent avoir des structures d’importation totalement différentes. Dans le cadre de l’intégration avec DocuWare, l’objectif était de permettre la création automatique de pièces comptables (ex. factures fournisseurs). On parle donc de modèles d’import.

En théorie, ces modèles peuvent être standard. Mais dans les faits, ils sont toujours ajustés. Pourquoi ? Parce que chaque client a ses propres règles de validation, de codification comptable, de gestion de TVA, de libellés, etc. Bref, même quand on a un “core model”, il faut l’adapter, systématiquement.

L’illusion de la transparence

L’utilisateur final, lui, ne voit que le résultat : sa facture passe de la GED à l’ERP, automatiquement. Et c’est très bien comme ça. Mais derrière cette fluidité apparente, il y a souvent plusieurs jours de cadrage, de dev, de tests, de corrections, d’allers-retours. C’est tout sauf plug & play.

Et c’est là qu’il faut être clair avec les clients. Leur faire comprendre qu’un “connecteur”, ça ne s’achète pas comme un câble HDMI. Il y a un vrai travail humain derrière. Ce n’est pas pour complexifier les choses ou faire peur, mais simplement pour poser les bonnes bases d’un projet réussi.

Pour une meilleure pédagogie en avant-vente

Mon message ici, c’est surtout un appel à la clarté. Les équipes commerciales, les consultants, les chefs de projet : on se doit d’expliquer tout ça aux clients, dès les premières discussions.

Oui, on peut connecter deux outils. Oui, à terme ce sera fluide. Mais non, ce n’est pas magique. Il faut cadrer, paramétrer, parfois développer. Et surtout, il faut comprendre le besoin fonctionnel métier avant de parler technique.

En faisant preuve de pédagogie dès l’avant-vente, on évite beaucoup de malentendus. Et surtout, on prépare le terrain à un projet plus serein, où chacun comprend mieux les enjeux et les contraintes.