« API first » décrit un ordre de construction, pas une technologie. L'interface de programmation est conçue et documentée d'abord ; l'écran que voient les humains l'utilise ensuite, comme n'importe quel autre client.
La nuance paraît abstraite. Elle a une conséquence très concrète : dans un système construit ainsi, aucune fonction n'existe uniquement dans l'écran. Tout ce qu'une personne peut faire, un autre système peut le faire aussi.
Faites défiler latéralement pour voir toute la figure.
L'inverse, et pourquoi on le reconnaît tout de suite
Dans l'ordre habituel, l'application et l'écran sont construits d'abord, et une API est ajoutée plus tard parce qu'un client la demande.
Le résultat est toujours le même : l'API couvre une partie du système, pas tout. Les opérations courantes sont disponibles, les cas particuliers ne le sont pas, et ce sont justement les cas particuliers qui font l'intérêt d'une intégration. On s'en aperçoit au bout de trois semaines de projet, quand il faut demander un développement pour une action que n'importe qui peut faire en deux clics dans l'écran.
C'est le test le plus parlant, et il ne demande aucune compétence technique : demandez si toutes les opérations de l'écran sont disponibles par l'API. Une hésitation est une réponse.
Ce que cela change, et quand
Comme pour la modularité, l'effet ne se mesure pas au quotidien. Il se mesure au moment du changement.
Brancher une nouvelle boutique, remplacer une plateforme de paiement, ajouter une place de marché, raccorder un entrepôt supplémentaire : dans un ensemble construit API first, chacune de ces opérations est un chantier borné. Dans l'autre cas, c'est un projet avec une phase de développement.
Chez nous, cela prend la forme des intégrations e-commerce, des intégrations places de marché et du connecteur ERP : des raccordements existants là où ils ont du sens, et une API pour tout le reste. Le raisonnement général sur l'assemblage de briques est traité à part, dans l'architecture modulaire.
Les cinq questions à poser à tout le monde
Cinq critères, et pas un seul sur lequel ce texte prend position pour BizBloqs. Ce sont des questions à poser à n'importe quel éditeur, nous compris : ce sont de bonnes questions précisément parce que la réponse varie d'un fournisseur à l'autre, et parce qu'aucune ne demande d'écrire une ligne de code pour être vérifiée.
La documentation est-elle publique et à jour ? Une documentation accessible sans signer quoi que ce soit est le meilleur indicateur de maturité. Une documentation envoyée par courriel en PDF est un signal.
Peut-on obtenir un environnement de test en libre-service ? Un intégrateur doit pouvoir essayer avant de s'engager. Si chaque essai demande une démarche commerciale, l'intégration coûtera plus cher.
Le système prévient-il, ou faut-il l'interroger ? Un système qui envoie une notification quand une commande change d'état — un webhook — se branche proprement. Un système qu'il faut interroger toutes les minutes pour savoir s'il s'est passé quelque chose fonctionne, mais mal, et à grande échelle il coûte.
Que se passe-t-il si la même demande est envoyée deux fois ? C'est la question technique la plus révélatrice. Un réseau perd des réponses ; une intégration réessaie. Si une double demande crée deux commandes, l'intégration sera fragile pour toujours. La propriété qui évite cela s'appelle l'idempotence, et elle se demande par son nom.
Et sur la durée : comment les versions sont-elles gérées ? Une API qui change sans préavis casse les intégrations de ses clients, et c'est le genre de problème qui se découvre un vendredi soir.
Ce qu'une API ne règle pas
C'est l'illusion la plus coûteuse du sujet, et elle mérite un paragraphe entier.
Deux systèmes parfaitement raccordés peuvent ne pas être d'accord. L'un compte le stock réservé dans le disponible, l'autre non. L'un considère une expédition terminée au colis fermé, l'autre à la remise au transporteur. Les données circulent sans friction, et les rapports se contredisent.
Une API transporte fidèlement un désaccord. Ce qui le résout n'est pas technique : un système de référence par donnée, un propriétaire par événement, et une définition commune du SKU et des unités. C'est une décision d'organisation, et elle se prend avant le premier appel d'API.
Ce que nos API couvrent, et ce qu'elles ne couvrent pas
Autant être précis, parce que notre propre page anglaise sur ce sujet promet large.
Couvert : les données de stock et la disponibilité, les commandes et leur état d'exécution, les mouvements du magasin et les données de reporting d'exécution. C'est-à-dire ce que font le logiciel WMS et le logiciel de gestion des commandes.
Non couvert, parce que ce n'est pas notre métier : la prévision et le calcul des quantités à commander, le transport et l'optimisation de tournées, la recommandation produit, la tarification. Ces fonctions existent dans l'écosystème, chez leurs éditeurs, et une API sert précisément à les y laisser.
Pour les partenaires qui construisent ces assemblages, le cadre est décrit sur la page pour intégrateurs.
<!-- La FAQ est générée depuis le bloc `faq` de l'en-tête -->
BizBloqs expose le stock, les commandes et l'exécution par API, avec des raccordements prêts là où ils ont du sens. Pour poser les quatre questions ci-dessus à notre équipe technique, réserver une démo. Si votre ensemble est stable et que rien n'est à remplacer, l'API ne se paiera pas.
