En partie, et la nuance compte. Chaque application générée expose une API REST complète — une famille de routes par type de données — mais elle est protégée par le cookie de session : il n'existe pas encore de clé d'API permettant à un autre logiciel de s'y connecter seul. Sans écrire une ligne, vous disposez en revanche de l'export JSON et CSV de chaque jeu de données, de l'import de fichiers sur les données de mesure, et d'un accès direct à la base si vous hébergez vous-même. Et comme le code vous appartient, ajouter une clé d'API reste un travail standard.
Ce que l'application expose vraiment
Une application générée n'est pas une interface posée sur une base opaque : elle est construite comme une application web classique, avec une API REST derrière ses écrans. Pour chaque type de données décrit dans votre demande, le moteur émet la même famille de routes : lister et créer, puis lire, modifier et supprimer un enregistrement précis. Une suppression n'efface d'ailleurs rien définitivement — elle passe par la corbeille, et une route de restauration existe pour l'annuler.
Ces routes ne sont pas un supplément optionnel : ce sont exactement celles que les écrans de l'application utilisent eux-mêmes. Il n'y a donc pas d'un côté une « vraie » API interne et de l'autre une API publique appauvrie — c'est la même, et elle est dans le code que vous récupérez.
La limite à connaître : pas de clé d'API aujourd'hui
Dès qu'une application demande une connexion — le cas par défaut pour des données de gestion — ses routes sont protégées : chaque appel doit porter le cookie de session signé émis à la connexion, et un compte en lecture seule se voit refuser toute écriture côté serveur, quel que soit le chemin emprunté.
Cette protection a une conséquence directe, qu'il vaut mieux connaître avant de s'engager : il n'existe pas, aujourd'hui, de clé d'API ni de jeton permettant à un autre logiciel de s'authentifier seul, sans navigateur. Un outil tiers ne peut donc pas interroger l'application de machine à machine tel quel. Nous préférons l'écrire noir sur blanc plutôt que de laisser « l'application a une API » suggérer davantage.
Ce qui fonctionne sans développer une ligne
L'écran Paramètres propose l'export de chaque jeu de données, au format JSON ou CSV. C'est le chemin le plus court vers un tableur, un outil de reporting ou un comptable : les données sortent quand vous le décidez, dans des formats que tout le monde lit.
Dans l'autre sens, les données de mesure — relevés, traces, séries produites par un appareil — reçoivent une route et un bouton d'import de fichier : CSV, et GPX pour les traces. Enfin, si vous hébergez l'application vous-même, sa base PostgreSQL est la vôtre : un outil de reporting peut s'y connecter en lecture directement, sans passer par l'API.
Si vous avez besoin d'une intégration complète
Le point à retenir est qu'aucune de ces limites n'est un verrou. L'application est un projet Next.js et Prisma standard, exportable en ZIP ou poussé sur votre dépôt GitHub : ajouter une authentification par clé d'API à des routes qui existent déjà est un travail balisé pour un développeur, sur du code lisible.
C'est la différence avec un outil dont l'intégration dépend d'un connecteur que l'éditeur propose ou ne propose pas. Ici, la question n'est jamais « est-ce que la plateforme le permettra ? » mais seulement « qui l'écrit ? » — et le jour où vous le faites, vous n'avez rien à demander à personne.