10. Intégrations

L'API

Tout ce dont une intégration a besoin, c'est du JSON sur HTTPS, sur le sous-domaine propre à l'entreprise, authentifié par une clé d'API créée par un administrateur et affichée une seule fois. Les décimaux sont des chaînes — les nombres JSON sont des flottants, ce que ne sont ni les quantités ni les montants. La référence de l'API liste chaque point d'accès.

Une application utilisée par de nombreuses entreprises, comme Syncomatic, ne demande pas de clé : elle envoie l'utilisateur vers Foudra, l'utilisateur se connecte et l'autorise, et elle obtient un jeton qui agit au nom de cet utilisateur et figure dans les applications connectées, où chacun peut déconnecter ce qu'il a autorisé.

La règle de conception, partout : l'API fait foi, et les écritures sont prudentes. Les scripts créent des brouillons qu'un humain approuve ; les machines rendent compte de ce qu'elles ont fait ; rien d'extérieur au système ne peut engager de l'argent ni inventer du stock.

Données personnalisées

Chaque article, poste de travail et ordre de fabrication porte un bloc JSON opaque que le système valide, stocke et n'interprète jamais. Il est destiné aux intégrations : l'emplacement du G-code d'un article imprimé, l'adresse réseau d'une imprimante, la densité d'un filament. Modifiez-le sur la page Custom data (données personnalisées) de l'entité ou via l'API, et laissez le système ignorer ce qu'il contient.

Trois cas de figure

Un ETL depuis un fournisseur. Un script prend l'export de commande d'un fournisseur, résout ses références via GET /api/sourcing, et publie une commande en brouillon avec POST /api/purchase-orders. Une référence inconnue fait échouer toute la requête en indiquant la ligne ; associez-la dans l'approvisionnement et réessayez. Au bout de quelques commandes, votre table d'approvisionnement est la table de correspondance.

Une machine qui fabrique. Un gestionnaire de ferme d'impression interroge GET /api/workstations/{id}/next tant que son imprimante est libre, démarre l'opération, imprime, la termine avec la quantité (et bientôt le filament réellement utilisé), puis remet le poste à l'état libre. Quand il a besoin d'un humain, il passe à l'état bloqué et envoie une tâche avec PUT /api/tasks/{source}. La conception complète se trouve dans le dépôt, sous docs/integrations/print-manager.

Extraire des données. Un système de vente qui a besoin des quantités lit GET /api/stock ; un tableau de bord externe lit GET /api/parts. Des clés en lecture seule pour des usages en lecture seule.

Être prévenu

Les webhooks, c'est le système qui appelle l'extérieur quand quelque chose se produit : un ordre de fabrication se termine, le stock change. Un administrateur indique une URL et les événements qu'elle souhaite recevoir ; chaque message est signé, renvoyé si le destinataire est indisponible, et journalisé. L'événement est écrit dans la même transaction que le changement qu'il annonce : rien n'est donc annoncé qui ne se soit produit.

Un système qui demande du travail et veut savoir quand il est fait. Le centre de contrôle des missions déclenche une révision avec POST /api/work-orders, en donnant la coque comme référence de l'ordre. Quand la dernière opération est terminée, le webhook work_order.completed renvoie cette référence, et le navire peut être remis en service. Foudra n'apprend jamais ce qu'est une coque.

L'interrogation périodique fonctionne toujours pour tout et donne toujours un résultat juste ; un webhook ne fait que supprimer l'attente.

Suite : le rythme.