Vos systèmes fonctionnent. Mais pas ensemble.
Votre site connaît la commande. L’entrepôt connaît le stock. La comptabilité connaît le paiement. Le CRM connaît le client. Et quelqu’un, dans votre équipe, déplace encore l’information entre eux à la main.
Reconnaissez-vous ceci ?
La même commande est saisie dans deux systèmes, parfois trois.
Le stock est juste à un endroit et faux à un autre, sans qu’on sache lequel croire.
Un rapport mensuel prend une demi-journée parce que les chiffres vivent dans quatre plateformes.
Un client demande où en est sa commande : il faut ouvrir trois écrans pour répondre.
Vous avez acheté deux bons logiciels et il reste un trou entre les deux.
Une personne est devenue l’intégration, et elle part bientôt en congé.
Personne n’achète un trou
Les systèmes arrivent un par un, et chacun résout son propre problème. La boutique a besoin d’un site. La finance d’un logiciel comptable. L’entrepôt d’une gestion de stock. Chaque décision est sensée le jour où elle est prise, et chacune est prise par des personnes différentes.
Ce que personne n’achète, c’est l’espace entre les deux. Il finit donc comblé par quelqu’un : une personne qui sait que le numéro de commande ici est la référence là-bas, que l’export du mardi doit être corrigé avant import, et que le stock n’est fiable qu’après la synchronisation du matin. Ce savoir est rarement écrit.
Cela tient jusqu’à ce que le volume augmente, ou que cette personne s’en aille. La panne est silencieuse : l’information n’est pas perdue, seulement en retard, ou saisie deux fois, ou légèrement différente à deux endroits.
Vous avez peut-être déjà les bons systèmes
La première question n’est pas quoi remplacer, mais ce qui sait déjà parler. La plupart des plateformes achetées ces dix dernières années disposent d’une API, et quand deux systèmes en ont une, les relier coûte une fraction du prix et du risque d’un remplacement.
Nous recommandons donc parfois d’en faire moins. Si votre comptabilité et votre boutique exposent déjà ce dont l’autre a besoin, la réponse est une intégration, pas une nouvelle plateforme. Et quand le coût réside dans la ressaisie elle-même, c’est un problème d’automatisation des processus.
Un système est propriétaire de chaque donnée
Le difficile n’est pas de déplacer les données, mais de décider quel système a raison quand deux se contredisent — et ils se contrediront, parce qu’ils ont été modifiés à quelques secondes d’intervalle par des personnes différentes.
Le premier travail de conception est donc la propriété : la boutique possède la commande, l’entrepôt possède le stock, la comptabilité possède le fait que ce soit payé. Tout le reste détient une copie, et une copie n’écrase jamais l’original. Lorsqu’un conflit est réellement possible, il est signalé à une personne plutôt que tranché en silence.
Une API, c’est un système qui en interroge un autre. Un webhook, c’est un système qui en prévient un autre qu’il s’est passé quelque chose. Un traitement planifié vérifie ou synchronise à un rythme adapté. La plupart des intégrations réelles utilisent les trois : un niveau de stock mérite peut-être l’instantané, le reporting mensuel certainement pas.
Quand il n’y a pas d’API
Les systèmes anciens ou spécialisés n’ont souvent aucune API. Cela ne les met pas hors de portée.
Selon ce que le système autorise, la voie d’accès peut être une interface directe avec la base de données, un échange de fichiers sécurisé et planifié, un intergiciel, ou un connecteur écrit pour ce système en particulier. Nous avons emprunté ces chemins assez souvent pour savoir lesquels vieillissent bien.
Comment nous procédons
Comprendre
Cartographier l’existant : les systèmes, les données que chacun possède, et les gestes manuels construits autour.
Décider
Convenir de ce qui doit être relié, de ce qui reste en l’état, et de ce qui ne vaut pas la peine d’être automatisé.
Construire
Mettre en place la liaison — API, webhook, traitement planifié ou connecteur sur mesure, selon ce que les systèmes permettent.
Basculer
Faire tourner l’ancien et le nouveau en parallèle, rapprocher les résultats, basculer quand les chiffres concordent.
Rester
Surveiller, corriger quand un fournisseur modifie son API, continuer d’améliorer. Nous construisons, nous exploitons, nous restons.
Nous avons déjà résolu cela
Urban Industry — streetwear, Eastbourne
Urban Industry vend 2 500 produits de plus de cent marques, via sa propre boutique, des marketplaces et en magasin. Le problème n’était aucune plateforme en particulier : le stock, les commandes et la logistique vivaient à des endroits différents, et l’entreprise grandissait plus vite qu’on ne pouvait les rapprocher à la main.
La chaîne à tenir est simple à décrire et difficile à tenir manuellement : boutique → paiement → stock et commandes → expédition. Chaque passage de relais était une personne.
Nous avons construit une plateforme B2C qui donne à l’équipe une vue unique du stock, des commandes et de la logistique sur tous les canaux, puis nous l’avons reliée vers l’extérieur : PayPal et Checkout by Amazon pour le paiement, une vitrine sur mesure comme vendeur premium sur Amazon UK, et MetaPack pour que les commandes parviennent aux clients du monde entier.
Ce que cela implique généralement
API et intégration
Relier les systèmes que vous utilisez déjà, pour qu’ils cessent d’avoir besoin d’une personne au milieu.
Logiciels sur mesure
Quand l’espace entre deux systèmes demande quelque chose de conçu pour s’y placer.
Les questions qu’on nous pose
Pouvez-vous intégrer un logiciel développé par quelqu’un d’autre ?
En général oui — c’est même le cas le plus courant. Ce qui compte est ce que le système expose et les accès qu’on nous donne, pas qui l’a écrit.
Et si l’un de nos systèmes n’a pas d’API ?
Nous regardons alors une interface base de données, un échange de fichiers sécurisé, un intergiciel, ou un connecteur sur mesure. C’est plus de travail qu’une API documentée, et nous vous dirons lequel avant de commencer.
Devons-nous remplacer quelque chose ?
Souvent non. Si vos systèmes font leur travail, la réponse est la liaison entre eux. Nous préférons vous le dire plutôt que vous vendre une reconstruction.
Combien de temps prend une intégration ?
Cela dépend presque entièrement du système le moins bien documenté. Entre deux plateformes modernes, quelques jours ; avec une base ancienne non documentée, l’essentiel du temps passe à la comprendre plutôt qu’à écrire du code.
Assurez-vous le suivi ensuite ?
Oui. Une intégration casse quand un tiers modifie son API, ce qui n’est pas une hypothèse. Nous surveillons celles que nous construisons.
Dites-nous quels systèmes doivent se parler.
Vous n’avez pas besoin de connaître la réponse technique. Dites-nous ce qui vous gêne. Nous partirons de là.
Nous construisons et exploitons des systèmes d’entreprise depuis 2000. L’équipe qui le construit reste pour le faire tourner.
Engageons la conversation