§ 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
état
v1.7 · 23 applications in production
licence
in-house · not sold, you get what it builds
platform
PHP 8 · Slim 4 · Propel
built with
itself
runtime
none; behaviours compile in at build
IA
MCP server in every build
§ 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é
In-house tooling, matured over 23 production applications and years of client back offices. You don't buy the engine; you get what it builds — and the next project starts further along.
§ 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.

page produit →
03/crm

CRM LL-TEQ

CRM de LL-TEQ, une entreprise canadienne de technologie routière : contacts, entreprises, soumissions, factures, paiements, campagnes courriel et stockage de documents, bâtis avec GoatCheese — avec une intégration IA par son propre serveur MCP, qui donne à un assistant un accès complet au CRM avec les mêmes permissions que l'équipe.

ll-teq.com →
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

Lumio

Un tuteur vocal de langues 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.

page produit →
07/et bien plus

…et bien plus

Twenty-three projects on the engine so far: dashboards, client portals, a family organiser, a raid planner, a subscription manager, a lottery back office. Whatever the schema describes.

§ 05 / under a switch

Everything under a switch.

GoatCheese doesn't carry a big runtime. A behaviour is compiled into the application only when the schema asks for it — nothing you didn't switch on ships. The code stays lean, the app stays fast.

01 with_api

API REST

Every table as documented endpoints, with per-route access rules and an audit log.

02 with_mcp

Serveur MCP

An assistant like Claude works in the application as a named user, with that user's rights — through business operations, not raw tables.

03 with_ai

AI fields and tools

Model-backed columns and actions — a summary, a classification, a draft — declared next to the data they read.

04 with_pdf

Generated documents

Quotes, invoices, reports: templates rendered from the record, previewed and e-mailed from the admin.

05 with_stripe

Payments

Plans, checkout and webhooks wired to the entities that own them.

06 with_mailbox

Mail in and out

Templated outbound mail and an inbox the application can read and act on.

07 with_job_queue

Background jobs

A queue and workers for the slow parts — imports, scans, batch mail — off the request path.

08 with_multi_tenant

Multi-tenant

Tenant isolation enforced in the model, the API and the admin, not remembered by each screen.

09 with_mobile

Mobile app

OAuth 2.1 server storage and the token flow an Expo app needs to talk to the same API.

Twenty-one switches today; each one is a build parameter in the HJSON schema.

§ 06 / next step

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.