Le MCP ApiBorne expose à un assistant IA près d'une centaine d'outils : statistiques, configuration des bornes, diagnostics, actions à distance. Chaque outil a un nom, un schéma d'entrée, une description, et le serveur applique une confirmation avant toute écriture. Autrement dit, tout ce qu'il faut pour faire une API. Il ne manquait que la porte HTTP.
Nous l'avons ouverte sans dupliquer une ligne de logique métier : l'API REST est dérivée du même registre d'outils que le MCP. Un outil ajouté pour l'assistant existe immédiatement en REST, avec sa documentation. C'est ce qui garantit que les deux ne divergeront jamais.
Un endpoint par opération
Plutôt que de réinventer des ressources REST classiques, l'API suit le découpage qui existe déjà : une opération, un endpoint. Le corps de la requête est exactement le schéma d'entrée de l'outil, la réponse est son résultat brut en JSON. Trois routes suffisent à tout découvrir.
/api/v1/toolsLe catalogue des opérations visibles pour votre clé, avec leur famille et un drapeau lecture / écriture.
/api/v1/tools/{nom}L'appel d'une opération. Corps JSON validé strictement : une clé inconnue est refusée, pas ignorée.
/api/v1/openapi.jsonLe document OpenAPI 3 de votre portée, prêt pour Swagger Editor ou un générateur de client.
curl -X POST https://api.apiborne.com/api/v1/tools/get_kiosk_stats \
-H "Authorization: Bearer abk_votre_cle" \
-H "Content-Type: application/json" \
-d '{ "period": "last7days" }'# 1. Sans confirm : le serveur renvoie l'aperçu du changement, rien n'est écrit
curl -X POST https://api.apiborne.com/api/v1/tools/update_kiosk_messages \
-H "Authorization: Bearer abk_votre_cle" \
-H "Content-Type: application/json" \
-d '{ "messages": { "checkInDoneMessage": "Merci, installez-vous en salle d'attente." } }'
# → 200 { "confirmationRequired": true, "preview": { ...avant / après... } }
# 2. Avec confirm : écriture, et entrée dans l'historique avec l'auteur « API abk_… »
curl -X POST https://api.apiborne.com/api/v1/tools/update_kiosk_messages \
-H "Authorization: Bearer abk_votre_cle" \
-H "Content-Type: application/json" \
-d '{ "messages": { "checkInDoneMessage": "Merci, installez-vous en salle d'attente." }, "confirm": true }'Ce que l'API couvre
Tout le périmètre du MCP, soit, à la date de publication, 93 opérations pour une clé globale et 73 pour une clé de licence, réparties en 18 familles. En voici les principales.
Statistiques
Passages, check-ins, appels guichet, par borne et par période.
Configuration borne
Messages, critères d'admission, documents requis, tickets, motifs guichet, langues.
Tableaux et guichets
Tableaux d'appel, guichets, groupes de guichets, écrans de salle d'attente.
Diagnostics
« Pourquoi ce ticket n'a pas été accueilli ? », « pourquoi ces documents ne sont pas validés ? ».
Actions sur les bornes
Recharger l'accueil, redémarrer, ouvrir la télémaintenance, à distance.
Thèmes et médias
Médiathèque, thèmes à jetons, génération d'images par IA (portée globale).
Historique
Lecture de l'historique de configuration et annulation d'un changement.
Documentation embarquée
Les fiches produit que lit l'assistant IA, disponibles aussi en JSON.
Une clé, deux portes, les mêmes garde-fous
La même clé que le MCP
Créée sur la page « Clés API & MCP » de l'administration, affichée une fois, révocable, avec expiration optionnelle.
Le même cloisonnement
Une clé de licence ne voit que son établissement. Les opérations globales n'existent pas dans son catalogue : 404, pas 403, rien n'est divulgué.
La même confirmation
Sans confirm, un aperçu et rien d'écrit. Avec, l'écriture. Impossible de modifier une borne par accident depuis un script.
Le même historique
Chaque écriture est tracée avec l'auteur « API » et le préfixe de la clé, et s'annule en un clic depuis l'administration.
Un quota raisonnable
120 appels par minute et par clé, avec un en-tête Retry-After quand il est atteint.
Un OpenAPI qui ne peut pas se périmer
Les documents d'API vieillissent mal : écrits à la main, ils décrochent du code à la deuxième évolution. Celui-ci n'est écrit par personne. Il est construit à la demande depuis le registre des outils, à partir des schémas de validation et des descriptions que lit déjà l'assistant IA. Quand un développeur ajoute un outil au MCP, l'endpoint REST, son schéma et sa documentation apparaissent dans le même mouvement.
Nous l'avons éprouvé de la façon la plus simple : un client TypeScript généré depuis ce document, et les appels rejoués contre le serveur. Un linter OpenAPI du marché le valide sans erreur.
Les statuts HTTP ont un sens
Là où le MCP aplatit toute erreur en un message pour l'assistant, l'API conserve les codes : 400 pour une entrée invalide avec le détail du champ fautif, 403 et 404 pour les droits et le périmètre, 429 pour le quota, 500 pour une vraie panne. Un script peut réagir correctement sans lire du texte.
Plus strict que le MCP, volontairement
Un assistant IA tolère qu'on ignore une clé qu'il a inventée. Un script, non : une faute de frappe sur « confirm » doit être refusée, pas silencieusement ignorée. La validation REST rejette donc toute clé inconnue, et le dit.
Trois usages que nous avons en tête
Supervision centralisée
Un groupe de centres remonte chaque matin les statistiques de passage de toutes ses bornes dans son tableau de bord, et déclenche un rechargement si une borne n'a pas servi depuis l'ouverture.
Configuration pilotée par le RIS
Un éditeur ou un intégrateur synchronise les critères d'admission et les documents requis depuis le référentiel du logiciel métier, au lieu de les ressaisir dans deux outils.
Diagnostic dans le support interne
Le service informatique d'un établissement branche « pourquoi ce ticket n'a pas été accueilli ? » dans son outil de ticketing, et lit la réponse argumentée sans ouvrir l'administration.
Deux API, deux sens, un système ouvert
Vos outils → ApiBorne
L'API REST d'administration décrite ici, et le MCP pour les assistants IA. Même registre, même clé, même périmètre : la configuration, les statistiques, les actions. Jamais de données de patients.
La borne → votre logiciel de rendez-vous
Le contrat d'intégration public, documenté sur le portail développeurs : ce qu'un éditeur de RIS implémente pour que la borne identifie ses patients et dépose ses documents. Avec, depuis cet automne, une extension optionnelle « rendez-vous du jour » qui divise par cinquante les appels du tableau d'appel et accélère l'identification à la borne.
Questions fréquentes sur l'API REST
Faut-il une clé différente pour l'API REST et pour le MCP ?
Non. Une seule clé, créée sur la page « Clés API & MCP » de l'administration, ouvre les deux portes. Elle est affichée une seule fois à la création, révocable à tout moment, et peut porter une date d'expiration. Un assistant IA et un script maison peuvent donc partager la même clé, ou en avoir chacun une pour mieux tracer qui a fait quoi.
Quelle est la portée d'une clé ?
Une clé de licence ne voit et ne modifie que son établissement : les opérations réservées au niveau global (thèmes, anomalies globales, génération d'images, annonces) n'existent tout simplement pas dans son catalogue ni dans son document OpenAPI, et répondent 404 si on les appelle. Une clé globale, réservée au superadmin, doit préciser la licence visée à chaque appel.
Comment une écriture est-elle protégée contre une erreur de script ?
Par la même convention que le MCP : un appel d'écriture sans le drapeau de confirmation renvoie un aperçu du changement et n'écrit rien ; il faut rappeler l'opération avec confirm à vrai pour appliquer. Chaque écriture est ensuite tracée dans l'historique de configuration avec l'auteur « API » et le préfixe de la clé, et peut être annulée depuis l'administration.
L'API expose-t-elle des données de patients ?
Non, pas plus que le MCP. Le périmètre est la configuration des bornes, des statistiques agrégées, des diagnostics et des actions sur les bornes. Aucune identité de patient, aucun rendez-vous nominatif, aucun ticket individuel ne transite par ces endpoints : ces données restent dans votre logiciel métier.
Le document OpenAPI est-il tenu à jour à la main ?
Non, et c'est le point important. Il est construit à la demande à partir du registre des outils du serveur, avec les descriptions que lit déjà l'assistant IA. Un nouvel outil ajouté au MCP apparaît dans l'API REST et dans le Swagger sans qu'une ligne de documentation ne soit écrite à part. Nous l'avons validé en générant un client TypeScript depuis ce document et en rejouant les appels.
Est-ce la même API que celle du portail développeurs ?
Non, elles vont dans des sens opposés. Le portail developers.apiborne.com documente le contrat qu'un éditeur de logiciel de rendez-vous implémente pour que la borne lui parle. L'API REST d'administration, elle, permet à vos propres outils de parler à ApiBorne. La première s'adresse aux éditeurs, la seconde aux centres et à leurs intégrateurs.
Ouvrir la configuration à un assistant IA était une promesse d'autonomie. L'ouvrir à vos propres outils en est une autre, plus ancienne et tout aussi importante : vous n'êtes pas prisonnier de nos écrans. Ce que l'assistant sait faire, vos scripts le savent aussi, avec la même clé, les mêmes garde-fous et le même historique.
Un projet d'intégration en tête ?
L'API REST et le MCP sont inclus dans l'abonnement. Nous créons une clé sur un environnement de test et vous explorez le Swagger avec nous.
Claude est une marque d'Anthropic, PBC. ApiBorne est un produit indépendant : la compatibilité repose sur le standard ouvert Model Context Protocol.
