Implémenter avec Claude
Un document Markdown autonome, pensé pour être lu par un assistant IA : déposez-le dans le projet de votre système de gestion médical et demandez à Claude Code d'implémenter le contrat — routes, schémas, règles, pièges et tests de conformité inclus.
APIBORNE_IMPLEMENTATION.md
Le brief d'implémentation complet du Kiosk Integration Contract, autonome et optimisé pour un agent IA — également lisible par un humain pressé.
Le principe
Ce guide en ligne est fait pour les humains ; les assistants de code comme Claude Code travaillent mieux avec un document unique, autonome et structuré, posé dans le projet. Le fichier ci-dessus condense tout le contrat en un seul Markdown : l'agent n'a pas besoin de naviguer sur ce site pour implémenter — et il sait où télécharger les swaggers quand il lui faut un schéma exhaustif.
Ce que le document contient
- Le socle transversal : base path imposé, authentification à deux headers (et l'ordre de validation), CORS, corps d'erreur normalisé,
context.configetvendorData; - Les 12 routes de communication, une par une : sémantique, corps et réponses JSON complets, règles non négociables (idempotence du check-in,
proposedTicket, multi-RDV, NIR avec espaces…) ; - Les formes minimales conformes pour chaque fonctionnalité que vous n'avez pas (toutes les routes sont obligatoires — listes vides, 204, 404, 401) ;
- Les 6 routes de configuration et la contrainte « mêmes ids que vos RDV », plus le vocabulaire standard des 41
documentType; - Les 5 services sortants (tickets partagés, push de statuts…) avec leur authentification ;
- Un plan par phases avec cases à cocher, une définition de fini en 12 tests exécutables, et la liste des pièges connus relevés sur de vraies intégrations.
Comment l'utiliser avec Claude Code
# 1. Déposez le fichier à la racine du projet de votre système de gestion médical
curl -sSO https://developers.apiborne.com/claude/APIBORNE_IMPLEMENTATION.md
# 2. Lancez Claude Code dans le projet, puis :
> Lis APIBORNE_IMPLEMENTATION.md et implémente le Kiosk Integration Contract
> dans ce projet. Commence par me poser les questions de la section 1,
> puis déroule le plan par phases de la section 8 en cochant les cases.
> Ne me dis pas que c'est fini tant que les 12 tests de la section 9 ne passent pas.Le prompt de lancement importe peu dans le détail — l'essentiel est de pointer le fichier et d'exiger le passage des tests de la section 9. L'agent posera d'abord les questions de cadrage (section 1 du document), puis déroulera les phases : socle d'auth, parcours minimal en 5 routes, routes de configuration, reste du contrat, canal sortant.
git clone https://github.com/ApiBorne/ApiborneDemoImpl dans un dossier voisin) : quand un point de sémantique est ambigu, comparer avec le handler de la démo tranche immédiatement.Vérifier ce que l'IA a produit
Ne prenez pas le « c'est fini » de l'agent pour argent comptant — la boucle de vérification est la même que pour un humain, et elle est outillée :
- les 12 tests de la définition de fini (curl, rejouables tels quels) ;
- la sonde config-check de l'admin ApiBorne (indicateur bouclier) une fois le serveur exposé — via ngrok pour un serveur local ;
- le banc de test des endpoints de l'admin (page Test du contrat) : chaque route de lecture exécutée avec de vraies entrées, rapport de conformité en face ;
- un parcours complet sur borne en simulation pour les écritures (check-in, documents), avec le rejeu du check-in comme test final.
Le tout est détaillé dans Tester votre implémentation et la check-list de conformité.
