§ 00 / produits / goatcheese

GoatCheese. Décrivez l'application ; obtenez l'application.

Toute application de gestion est le même squelette habillé de données différentes : des tables, des écrans pour les modifier, une API, des utilisateurs et des rôles, un journal de qui a changé quoi. GoatCheese fait de ce squelette un produit de génération. Vous écrivez un schéma qui nomme vos entités, leurs champs et qui peut y toucher ; une commande le transforme en application fonctionnelle et documentée. Votre effort va aux dix pour cent qui sont réellement votre métier.

c'est quoi
moteur de génération en ligne de commande, piloté par schéma
conçu par
APIgoat, à l'interne
version
v0.9
en production
six applications
IA
aucune pour le construire · construit pour elle
§ 01 / l'idée

Un schéma entre, une application sort.

Le schéma est l'unique source de vérité. Tout ce qui suit en est dérivé et peut l'être à nouveau.

Session illustrative — sortie condensée. GoatCheese est un outil en ligne de commande ; tout ce qu'il fait est une commande que vous pouvez scripter, lancer en CI ou confier à un assistant IA.

01/décrire

Écrire le schéma

Un seul fichier lisible : les entités (clients, soumissions, projets…), leurs champs et types, leurs relations, et quels rôles peuvent lire, écrire ou supprimer chacune. C'est le modèle de l'entreprise, pas un tas de configuration — un responsable produit peut le suivre.

02/build

Lancer une commande

gc build. Le moteur lit le schéma et produit l'application entière : base de données, écrans d'administration, API, authentification, permissions, journal d'audit, un serveur MCP pour les assistants IA, commandes de déploiement et de sauvegarde, et la documentation qui va avec. Des minutes, pas des sprints.

03/étendre

Ajouter ce qui est à vous

Les règles métier — tarification, approbations, notifications, connecteurs vers d'autres systèmes — vivent dans des hooks et des classes d'enveloppe à côté du code généré, jamais dedans. Changez le schéma, régénérez : votre logique est toujours là.

§ 02 / ce qu'une génération produit

Les quatre-vingt-dix pour cent que personne ne veut écrire deux fois.

Chaque pièce ci-dessous est générée depuis le schéma, cohérente avec toutes les autres, et jetée puis régénérée dès que le modèle change.

01

Base de données

Tables, clés, relations et index créés depuis le schéma ; migrations quand il change. Aucune définition de table écrite à la main qui finit par diverger.

02

Interface d'administration

Listes, formulaires, filtres, recherche et exports pour chaque entité, façonnés par les mêmes rôles qui protègent l'API. Prêts dès le premier jour, raffinés ensuite.

03

API REST

Un point d'accès cohérent par entité — lister, lire, créer, modifier, supprimer — chaque route vérifiée contre la matrice des rôles avant de s'exécuter.

04

Utilisateurs, rôles, sessions

Connexion par jetons de courte durée et rafraîchissement rotatif, droits par rôle jusqu'à l'entité et au champ, et OAuth 2.1 en option pour que d'autres applications et des assistants IA se connectent au nom d'un utilisateur identifié.

05

Journal d'audit

Qui a fait quoi, sur quel enregistrement, quand — consigné à chaque écriture, dans l'administration comme par l'API. La question « qui a changé ça ? » a une réponse.

06

Serveur MCP

L'application est exposée aux assistants IA par le Model Context Protocol : mêmes entités, mêmes permissions, lectures séparées des écritures, écritures confirmées avant exécution.

07

Vérification de sécurité

Chaque génération et chaque déploiement se termine par un audit : couverture des règles d'accès, en-têtes, attributs des cookies, secrets, permissions de fichiers, dépendances. Les constats arrivent dans un rapport avant d'arriver en production.

08

Déploiement et sauvegarde

Des commandes pour livrer une version, exécuter les migrations et prendre ou restaurer une sauvegarde — les corvées d'exploitation font partie de la génération, pas d'une réflexion après coup.

09

Documentation

Documentation de référence du modèle de données et de l'API, régénérée à chaque build, pour que ce qui est écrit soit ce qui tourne réellement.

§ 03 / pourquoi ça tient

Des règles qui gardent une application générée maintenable.

Les générateurs de code ont mauvaise réputation : rapides le premier jour, impossibles à maintenir au sixième mois. Ce sont ces contraintes qui font la différence.

généré vs écrit
Une frontière nette entre les deux. Les fichiers générés ne sont jamais modifiés à la main ; la logique sur mesure vit dans des hooks et des enveloppes. Régénérer est toujours sûr, donc le schéma reste honnête.
une seule source de vérité
Base de données, écrans, API, permissions, outils IA et documentation lisent tous le même schéma. Ajoutez un champ une fois et il apparaît partout, avec les bonnes règles d'accès, dans la même génération.
les permissions d'abord
Les rôles sont déclarés à côté des données qu'ils protègent et appliqués à chaque porte — administration, API et MCP. Il n'y a pas de chemin pour les contourner parce qu'aucun chemin n'a été écrit à part.
sans IA — construit pour l'IA
Le moteur lui-même n'a aucun modèle dans la boucle : même schéma, même application, à chaque fois — déterministe, vérifiable, reproductible. Ce qu'il construit est fait pour l'IA : chaque application expose un serveur MCP, pour qu'un assistant comme Claude y travaille au nom d'un utilisateur identifié avec les mêmes droits, par des outils qui exposent des opérations d'affaires — « créer une soumission », « enregistrer un paiement » — plutôt que des tables brutes.
ennuyeux par conception
Stockage conventionnel, pile web conventionnelle, des fichiers lisibles. Assez moderne pour être productif, assez mûr pour rester silencieux à 3 h du matin.
éprouvé, pas publié
Un outillage interne, mûri sur six applications en production et des années d'arrière-guichets clients. Vous n'achetez pas le moteur ; vous obtenez ce qu'il construit — et le projet suivant part de plus loin.
§ 04 / construit avec

Pas une démo. La fondation sous tout ce qui est ici.

Chaque produit APIgoat et la plupart des arrière-guichets clients des dernières années sortent du même moteur. Chacun expose son propre serveur MCP.

01/chatbot

APIchatbot

Plateforme de chatbot IA multi-locataire : clients, bibliothèques de documents, clés, facturation à l'usage et portail client — toutes des entités du schéma, plus la logique de recherche dans des hooks.

page produit →
02/facturation

BillBoy

Facturation et suivi du temps pour travailleurs autonomes : clients, projets, feuilles de temps, dépenses avec numérisation de reçus, factures propres.

billboy.apigoat.com →
03/crm

CRM LL-TEQ

Contacts, entreprises, soumissions, factures, paiements et documents pour une entreprise de services sur le terrain — pilotée au quotidien depuis un assistant IA.

04/trading

apigtbot

Plateforme de bot crypto en mode papier : exécutions, stratégies, décisions et P&L comme entités ; les démons et flux de marché comme services sur mesure à côté.

05/comptabilité

GoatCheese comptabilité

Comptabilité et suivi du temps : clients, fournisseurs, factures, paiements, dépenses, projets — le moteur qui tient les livres de son propre auteur.

06/éducation

apigTutor

Un tuteur de français vocal pour enfants avec application mobile et administration parentale — l'arrière-guichet et les données de progression générés, les séances vocales sur mesure.

07/et bien plus

…et bien plus

Dix-huit projets sur le moteur à ce jour : tableaux de bord, portails clients, un organiseur familial, un planificateur de raids, un gestionnaire d'abonnements, un arrière-guichet de loterie. Tout ce que le schéma décrit.

Partez de plus loin.

Un CRM, un module ERP, un portail ou un arrière-guichet sur mesure sur GoatCheese commence par une application fonctionnelle, documentée et prête pour l'IA dès la première semaine — et le budget va à ce qui la rend vôtre. Envoyez un brief ; recevez une ébauche et une soumission sous un jour ouvrable.