Une entreprise de vingt personnes utilise en moyenne cinq à huit outils différents. Un logiciel de gestion, une boutique en ligne, une caisse, une messagerie, un tableur, parfois un CRM, souvent WhatsApp. Chacun fait correctement son travail. Le coût ne vient pas des outils : il vient de l'espace entre eux.
Cet espace se remplit avec des personnes. Quelqu'un exporte un fichier, le retravaille, le réimporte ailleurs. Quelqu'un recopie une commande d'un écran vers un autre. Quelqu'un compare deux listes pour comprendre pourquoi elles diffèrent. Ce travail ne produit rien : il rattrape une absence de connexion.
Une API — une interface de programmation — est ce qui supprime cet espace. C'est le moyen par lequel deux logiciels échangent des données directement, sans passer par un humain et un fichier Excel.
Ce qu'une API supprime réellement
Le gain n'est pas seulement du temps. Il est de trois natures, et les deux dernières comptent davantage que la première.
La ressaisie. Une donnée est saisie une seule fois, à l'endroit où elle naît, puis circule. C'est le gain visible, celui qu'on chiffre facilement en heures.
Le décalage. Sans connexion, chaque système détient une photographie prise à un moment différent. La boutique affiche le stock d'hier soir, la caisse celui de ce matin. Avec une connexion, il n'existe qu'une seule vérité, à jour. C'est ce décalage qui produit les surventes, pas le manque de rigueur des équipes.
Le désaccord. Deux systèmes non connectés finissent toujours par diverger, et personne ne sait lequel a raison. Les réunions consacrées à réconcilier deux chiffres disparaissent le jour où il n'y a plus qu'une source.
Les connexions qui rapportent le plus
Toutes les intégrations ne se valent pas. Voici celles qui produisent un effet mesurable, par ordre de priorité.
| Connexion | Ce qu'elle supprime | Effet mesurable |
|---|---|---|
| Boutique en ligne ↔ stock | Ressaisie des commandes web | Fin des surventes |
| Caisse ↔ gestion | Consolidation manuelle du soir | Chiffre d'affaires en temps réel |
| Multi-dépôts ↔ vue centrale | Appels entre sites | Disponibilité réelle visible |
| Application mobile ↔ catalogue | Tarifs périmés sur le terrain | Commandes justes du premier coup |
| Marketplace ↔ catalogue | Mise à jour manuelle des fiches | Prix et stocks cohérents partout |
La première ligne est presque toujours celle par laquelle commencer. Une boutique en ligne déconnectée du stock physique vend ce qui n'existe plus, et chaque vente annulée coûte bien plus que la marge perdue : elle coûte le client.
Comment se passe une synchronisation
Le principe est simple, même sans culture technique. Deux logiciels s'échangent des messages structurés, dans un format que les deux comprennent, via une adresse sécurisée et une clé d'authentification.
Boutique en ligne G-stock
| |
|--- nouvelle commande ->| le stock est décrémenté
| |
|<--- stock mis à jour --| la fiche produit affiche la bonne quantité
| |
|<--- statut expédié ----| le client est informé
Deux modes existent, et leur différence est plus importante qu'elle n'en a l'air.
La synchronisation périodique interroge l'autre système à intervalle fixe, toutes les quinze minutes par exemple. Simple à mettre en place, elle suffit pour un catalogue ou des tarifs.
La synchronisation événementielle (webhook) envoie l'information à l'instant où elle se produit. Indispensable pour le stock : quinze minutes de retard suffisent à vendre deux fois la dernière pièce disponible.
Les questions à poser avant de choisir un logiciel
Ce point se vérifie avant la signature, jamais après. Un logiciel fermé se paie au moment où l'on veut en sortir ou l'entourer.
- L'API est-elle documentée publiquement, avec des exemples consultables sans compte client ?
- Est-elle comprise dans l'abonnement, ou facturée en supplément par appel ou par connecteur ?
- Couvre-t-elle la lecture et l'écriture ? Une API qui ne fait que lire ne permet aucune automatisation réelle.
- Existe-t-il des webhooks, ou seulement de l'interrogation périodique ?
- Quelles sont les limites d'appels, et que se passe-t-il quand on les dépasse ?
- Comment sont gérées les erreurs et les reprises après une coupure réseau ?
- Existe-t-il un environnement de test distinct de la production ?
La question 3 élimine à elle seule une bonne partie du marché. Beaucoup d'éditeurs annoncent une API qui se limite à exporter des données ; elle sert à faire des rapports, pas à connecter des systèmes.
Les pièges classiques
Connecter des données sales. Si vos références ne sont pas identifiées de façon unique et cohérente entre les deux systèmes, la synchronisation propagera le désordre à grande vitesse. Nettoyez le catalogue avant de connecter, jamais après.
Oublier le sens de la vérité. Pour chaque donnée, un seul système doit faire autorité. Qui détient la vérité sur le prix ? Sur le stock ? Sur la fiche client ? Sans cette décision écrite noir sur blanc, les deux systèmes s'écrasent mutuellement et la donnée devient aléatoire.
Ignorer les pannes. Le réseau tombera. La bonne question n'est pas « comment l'éviter » mais « que se passe-t-il pendant, et que se passe-t-il au retour ». Une intégration correcte met les messages en attente et les rejoue dans l'ordre.
Tout connecter d'un coup. Une intégration à la fois, stabilisée avant de passer à la suivante. Trois connexions lancées ensemble rendent tout diagnostic impossible.
Par où commencer
- Dessinez sur une feuille vos outils et, entre eux, les flux qui passent aujourd'hui par un humain.
- Chiffrez grossièrement le temps hebdomadaire consommé par chaque flux manuel.
- Prenez le flux le plus lourd et vérifiez que les deux outils disposent d'une API en lecture et écriture.
- Décidez, pour chaque donnée échangée, quel système fait autorité.
- Lancez la connexion en observation, comparez les deux systèmes pendant une semaine, puis basculez.
Le rôle du logiciel
Une API ne se juge pas à sa sophistication, mais au nombre de fichiers Excel qu'elle fait disparaître entre deux services.
G-stock expose une API REST documentée en lecture et écriture sur les produits, le stock, les clients, les commandes et les mouvements, avec des webhooks sur les événements de stock et de commande. Les connecteurs e-commerce existants s'appuient sur cette même API : ce que fait un connecteur, votre développeur peut le faire aussi.