Intégration API : comment connecter vos systèmes métier

Que font concrètement les API et les webhooks ?

Imaginez la boutique en ligne, l’entrepôt et le logiciel de comptabilité comme trois bureaux distincts. S’ils ne sont pas connectés, un employé copie la commande d’un système à l’autre, vérifie les stocks par téléphone ou dans Excel, puis saisit à nouveau les données pour établir la facture.

Une API est un moyen standardisé pour qu’un système demande ou transmette des informations à un autre. La boutique en ligne peut demander le stock d’un produit, envoyer une nouvelle commande ou demander le statut d’un colis. C’est le système qui a besoin de l’information qui lance la communication.

Un webhook fonctionne dans le sens inverse. Lorsqu’un événement se produit, le système envoie une notification à une adresse prédéfinie. Par exemple, après un paiement réussi, le prestataire de paiement envoie un webhook à votre logiciel, qui modifie le statut de la commande et peut déclencher l’étape suivante.

Quels processus vaut-il mieux connecter en premier ?

Ne cherchez pas à tout connecter dès le départ. Choisissez un processus qui se répète souvent, ralentit l’équipe ou génère des erreurs coûteuses. Il s’agit généralement du traitement d’une commande, d’un contact client, d’un stock ou d’un paiement.

Boutique en ligne, entrepôt et ERP

Lorsqu’une nouvelle commande est passée, la boutique transmet les produits, les quantités, le client et le mode de paiement à l’ERP. L’ERP renvoie le stock et le statut de la commande, tandis que la boutique reçoit les quantités mises à jour en cas de changement dans l’entrepôt. Le risque de vendre un produit déjà épuisé est ainsi réduit.

Il faut définir à l’avance quel système fait foi pour le prix, le stock, le produit et le client. Si la boutique et l’ERP peuvent tous deux modifier la même valeur sans règle définie, l’intégration ne fera que propager le conflit plus rapidement.

Site web, CRM et équipe commerciale

Le formulaire de demande du site peut créer un lead dans le CRM avec sa source, le service demandé, le numéro de téléphone et le message. À partir de ces données, une tâche est créée pour un commercial, une confirmation est envoyée au client ou un processus spécifique est déclenché pour les demandes urgentes et standard.

Ici, le problème le plus fréquent n’est pas l’absence d’API, mais une définition imprécise du lead. Vous devez savoir quand créer un nouveau contact, que faire en cas de nouvelle demande et à qui attribuer la tâche. Si ces règles ne sont pas documentées, vous obtiendrez des clients en double et des demandes réparties de manière inégale.

Paiements, facturation et notifications

Un paiement réussi peut faire passer la commande au statut « payée », transmettre les données à l’ERP et déclencher la création d’une facture. Un e-mail ou un message peut également être envoyé au client. Il est important de ne pas créer la facture une seconde fois si le prestataire de paiement envoie la même notification plusieurs fois.

Site web, CRM et téléphonie

Lors d’un appel entrant, le système téléphonique peut transmettre le numéro au CRM afin d’ouvrir la fiche du client. Après l’appel, le système peut enregistrer le résultat, une tâche ou une note. C’est particulièrement utile lorsque les équipes commerciales et d’assistance traitent un grand nombre de demandes entrantes.

Pour les processus plus complexes, un ERP conçu autour de votre mode de fonctionnement réel peut faire la différence. Par exemple, un ERP sur mesure peut réunir les stocks, les ventes, les factures, les rôles et les rapports, au lieu de connecter des dizaines de tableaux incompatibles.

Quelles sont les options et combien coûtent-elles ?

Le prix dépend du nombre de systèmes, de la documentation disponible, du nombre d’objets à synchroniser, des règles de gestion des données et de la nécessité d’un panneau d’administration et d’un suivi. Les fourchettes indiquées sont données à titre indicatif pour la Bulgarie, en euros. Une estimation précise est possible après examen de la documentation API et du processus réel.

Avec un connecteur prêt à l’emploi, un prix bas ne signifie pas que le travail est terminé. Il faut vérifier les champs, les règles fiscales, les doublons, les arrondis, les paiements refusés et les retours. Pour une intégration personnalisée, le budget dépend surtout du nombre de scénarios et des exceptions, plutôt que du nombre de systèmes eux-mêmes.

Si le principal problème concerne la boutique et ses opérations, commencez par la création d’une boutique en ligne, en planifiant dès le départ les connexions avec les paiements, les transporteurs et les systèmes internes. Si vous avez déjà une boutique fonctionnelle, l’intégration peut être construite autour des possibilités API dont elle dispose.

Comment se déroule une intégration fiable ?

Une bonne intégration ne consiste pas simplement à faire « communiquer deux systèmes ». Elle définit ce qui se passe dans un scénario normal, en cas de retard, de données incorrectes ou de nouvel envoi. Le processus passe généralement par les étapes suivantes.

1. 01
   Décrire le processus

   Notez ce qui se passe aujourd’hui, du début à la fin. Qui saisit la commande, où le stock est-il vérifié, quand la facture est-elle émise et qui est informé en cas de problème ? C’est ici que l’on repère les actions manuelles et les endroits où l’information se perd.

2. 02
   Vérifier les systèmes et la documentation

   Vérifiez que chaque système dispose d’une API ou de webhooks, comment l’accès est authentifié, s’il existe un environnement de test et quelles sont les limitations. Avec un fournisseur externe, demandez la documentation, des exemples de requêtes et les règles applicables aux changements de l’interface.

3. 03
   Définir les données et les responsabilités

   Établissez la correspondance entre les champs : numéro de commande, SKU, quantité, prix, DDS, client, adresse et statut. Déterminez quel système peut modifier chaque valeur et ce qui se passe en cas de divergence.

4. 04
   Construire un premier scénario simple

   Commencez par un flux, par exemple une nouvelle commande vers l’ERP ou un nouveau lead vers le CRM. N’intégrez pas en même temps toutes les notifications, tous les rapports et toutes les exceptions. Il sera ainsi plus facile de vérifier que la logique est correcte.

5. 05
   Tester avec des cas limites réels

   Testez un paiement refusé, une rupture de stock, un numéro de téléphone erroné, une commande retournée, un produit supprimé, une connexion interrompue et un webhook renvoyé. Ce sont précisément ces cas qui montrent si l’intégration est prête à fonctionner, et pas seulement si elle fonctionne en démonstration.

6. 06
   Suivi et transfert à l’équipe

   Prévoyez un journal des requêtes, une notification en cas d’erreur et un moyen de relancer le traitement. L’équipe doit pouvoir voir quelle commande est bloquée, pourquoi elle l’est et comment la corriger sans intervenir directement dans la base de données.

Qu’est-ce qui pose le plus souvent problème ?

Une requête est exécutée deux fois

Un webhook peut être envoyé à nouveau si le destinataire ne confirme pas sa réception à temps. Chaque événement doit donc avoir un identifiant unique, et le système doit vérifier s’il a déjà été traité. C’est particulièrement important pour les paiements, les factures et l’expédition des colis.

L’un des systèmes est indisponible

Si l’ERP ne répond pas, la commande ne doit pas disparaître. Elle doit être enregistrée dans une file d’attente, faire l’objet de nouvelles tentatives contrôlées et une notification doit être envoyée à un responsable si le problème persiste.

Les données ont des structures différentes

Un système peut utiliser des champs distincts pour le prénom et le nom, tandis qu’un autre utilise un seul champ pour le nom. Les SKU, les unités de mesure, les taux de DDS, les fuseaux horaires et les adresses diffèrent également souvent. Ces transformations doivent faire partie de l’intégration et non être laissées à la charge des employés.

Les accès sont trop larges

Les clés API et les mots de passe ne doivent pas être enregistrés dans le code ni envoyés par e-mail. Utilisez une connexion chiffrée, des accès distincts pour les environnements de test et de production, le principe du moindre privilège et une procédure de renouvellement des clés. Pour les données personnelles, il faut également vérifier les durées de conservation et les accès des employés.

Quand choisir un outil prêt à l’emploi et quand opter pour un développement sur mesure ?

Make ou Zapier sont pratiques pour envoyer une notification, créer une tâche ou transférer un formulaire simple. Ils permettent de tester une idée et d’automatiser un petit processus sans lancer un long projet. Mais pour des volumes plus importants, il faut prendre en compte les frais mensuels, les limites d’opérations et la dépendance à la plateforme externe.

Un plugin prêt à l’emploi convient lorsque la boutique et le système comptable ou de livraison prennent précisément en charge le scénario souhaité. Si vous modifiez la logique des commandes, ajoutez des tarifs spécifiques pour les entreprises ou travaillez avec plusieurs entrepôts, le plugin peut rapidement montrer ses limites.

Une intégration sur mesure se justifie lorsqu’une erreur peut entraîner une vente manquée, un stock incorrect ou une facture erronée. Elle est plus coûteuse au départ, mais permet d’appliquer votre propre logique, de garder le contrôle des données et de mieux gérer la récupération après une erreur. Si vous avez besoin de processus CRM, vous pouvez également envisager un système CRM sur mesure, plutôt que de disperser les formulaires entre e-mails, tableaux et chats.

Comment déterminer si l’intégration est réussie ?

Définissez des critères mesurables avant le développement. Par exemple : toutes les nouvelles commandes doivent parvenir à l’ERP, chaque lead doit avoir un responsable, chaque erreur doit être visible par un employé et aucun paiement ne doit créer deux factures. Ne mesurez pas seulement si les données sont « arrivées », mais si le processus se termine correctement.

Pour les processus plus complexes, vous pouvez partir d’un modèle existant et l’adapter. Dans la démo de l’ERP, vous pouvez voir les contacts, les projets, les tâches, les factures, le calendrier et les rapports réunis dans un même environnement. La démo ne remplace pas l’analyse de vos systèmes, mais elle aide à déterminer les objets, les rôles et les opérations dont vous avez réellement besoin.

Questions fréquentes

Quelle est la différence entre une API et un webhook ?

Avec une API, votre système envoie une requête pour recevoir ou transmettre des données. Avec un webhook, un autre système vous informe automatiquement lorsqu’un événement se produit, par exemple une nouvelle commande ou un paiement réussi.

Puis-je intégrer un ancien ERP sans API ?

Parfois, oui : באמצעות un import et un export CSV, un accès à la base de données, un connecteur prêt à l’emploi ou un module intermédiaire. Cette approche est généralement plus limitée qu’une API et exige une attention particulière à la duplication, à la sécurité et à la fréquence des échanges.

Combien de temps faut-il pour réaliser une intégration API ?

Un scénario simple entre des systèmes bien documentés peut être développé dans le cadre d’un projet court. Le délai augmente lorsqu’il faut intégrer plusieurs systèmes, composer avec une documentation inexistante, appliquer des règles spécifiques, migrer d’anciennes données ou mettre en place un panneau d’administration, un journal et un retraitement.

Qui doit assurer la maintenance de l’intégration après sa mise en production ?

Un responsable clairement désigné de votre côté et un support technique assuré par le développeur ou le fournisseur doivent être prévus. Un système externe peut modifier sa version d’API, un champ ou son mode d’authentification. La supervision et les notifications font donc partie de la maintenance, et non des options supplémentaires.