Démarrez votre application dès la première fonctionnalité.
Bones est un monorepo TypeScript où tout ce qui entoure votre produit est déjà construit, testé et assemblé : connexion, organisations, autorisations, console d’administration, journaux, e-mails, blog, documentation et quatre langues, sur une application web, une application de bureau et trois sites publics. Clonez-le : la première chose que vous écrivez, c’est ce qui fait vraiment votre produit.
| FONCTIONNALITÉ | owner | administrator | standard |
|---|---|---|---|
| page.admin.view | accordée | accordée | non accordée |
| admin.users.view | accordée | accordée | non accordée |
| admin.roles.create | accordée | non accordée | non accordée |
| admin.terms.update | accordée | non accordée | non accordée |
| application.organizations.create | accordée | accordée | accordée |
| chatbot | accordée | accordée | accordée |
- WORKSPACES
- 9
- COMPOSANTS PARTAGÉS
- 36
- ROUTEURS TRPC
- 18
- CLIENTS
- 5
Six mois de plomberie, déjà écrits.
Quinze briques dont chaque application a besoin, chacune construite, testée et documentée. Chaque carte mène à une page sur le problème qu’elle résout et sur ce qui la distingue des alternatives.
Une connexion qui fonctionne déjà
E-mail et mot de passe ou Google, avec better-auth. E-mails de vérification et de réinitialisation, gestion des sessions, jetons bearer pour la version bureau, et un interrupteur dans la console d’administration qui désactive une méthode de connexion sans redéploiement.
Deux niveaux de contrôle d’accès
Des fonctionnalités accordées aux rôles de la plateforme, et une grille distincte par organisation par-dessus. Les deux sont appliquées dans le middleware tRPC et résolues dans la session, pour que l’écran et le serveur lisent la même réponse.
De vraies organisations, avec leurs membres
Des membres, des avatars et un profil par organisation. Les rôles sont propres à chaque organisation, le dernier administrateur ne peut pas être retiré, et l’adhésion est désactivée plutôt que supprimée.
Une console d’administration incluse
Utilisateurs, organisations, rôles, autorisations, indicateurs de fonctionnalité, méthodes de connexion, paramètres du site et conditions versionnées avec acceptation par utilisateur — construits, pas esquissés.
Des journaux à confier à un auditeur
Chaque écriture en base et chaque requête, structurées et expurgées, tournées sur disque et archivées régulièrement dans S3. Des vérifications d’état et un compte propriétaire créé dès la première migration.
Un blog livré en fichiers statiques
Rédigez, modifiez et publiez depuis la console d’administration. Les métadonnées dans Postgres, le texte des articles et les médias dans S3, et une build statique séparée qui transforme chaque article en vrai fichier HTML — indexable sans exécuter une ligne de JavaScript.
Une documentation qui évolue avec le code
Le pourquoi, le quoi et le comment de chaque fonctionnalité, en MDX dans le dépôt, modifiés dans la même pull request que le code. Un site statique avec recherche intégrée, et chaque page disponible en Markdown pour les outils d’IA.
Des e-mails à l’image du produit
Des modèles écrits en React et rendus avec les tableaux et les styles en ligne qu’exigent les vrais clients de messagerie, avec des tokens générés depuis le design system. Mailpit intercepte chaque message en développement, et SES les envoie en production.
Un chatbot déjà relié à un modèle
Claude sur Bedrock en production et un modèle Ollama local en développement, derrière une seule interface de fournisseur. Les réponses arrivent jeton par jeton, les conversations sont conservées par organisation, et l’accès passe par la même grille d’autorisations que tout le reste.
Un backend, cinq clients
Une application web, une application de bureau avec ses propres routes, ce site, le blog et la documentation, qui appellent tous un seul backend. Les applications l’appellent via tRPC avec des types complets : un champ renommé casse la build, pas la production.
Cohérent jusqu’au bout
Un seul fichier de tokens derrière l’application web, l’application de bureau, ce site, le blog, la documentation et chaque e-mail. Les composants partagés sont spécifiés dans COMPONENTS.md et dessinés dans Storybook, et un contrôle écrit deux fois est mutualisé plutôt que copié.
Quatre langues, de droite à gauche comprise
Anglais, français, espagnol et hébreu sur chaque surface, des applications aux e-mails et aux messages d’erreur. L’hébreu inverse chaque mise en page, et la CI échoue sur tout texte d’interface qui échappe à la traduction.
Vérifié selon WCAG 2.2 AA
Le site marketing, le blog, la documentation et chaque story Storybook, en clair et en sombre, à chaque pull request. axe applique ses règles, et une seconde vérification confirme les repères, les titres et les libellés sur lesquels s’appuie un lecteur d’écran.
Des protections dans le code, analysées à chaque modification
Entrées bornées, requêtes paramétrées, limites de débit, fichiers envoyés vérifiés et une CSP sur chaque page. Semgrep, OWASP ZAP, une vérification de la CSP et une recherche de secrets tournent à chaque pull request.
Des tests en conditions réelles
Des tests backend sur un vrai Postgres dans un conteneur jetable, chaque story Storybook dans un vrai Chromium, et une build de chaque site. Chaque pull request ne lance que les jobs que sa modification concerne.
Trois étapes, et aucune ne consiste à « attendre une build ».
Opérationnel en un rien de temps
Un environnement de développement cohérent : quelques commandes suffisent pour se mettre au travail. L’une d’elles démarre ensemble le backend, l’application web, le site marketing, le blog et la documentation.
Faites-en votre SaaS
Quoi que vous construisiez, vous êtes déjà bien plus près du but. La connexion, les organisations, les autorisations, la console d’administration, les e-mails et quatre langues sont prêts, et chaque router et chaque page que vous ajoutez en profitent.
Déployez-le
Mettez-le en production et accueillez vos premiers utilisateurs. Tout est sur AWS, avec des paliers faciles à changer à mesure que votre application grandit : Starter, Growth et High availability, chacun en une ligne.
Un dépôt qu’un développeur serait content de reprendre. Un dépôt qu’une IA peut prendre en main.
Dans Bones, chaque autorisation est une ligne dans une table et un appel de middleware sur une procédure. Rien n’est appliqué seulement dans l’interface, et rien n’est caché derrière un service que vous ne pouvez pas lire.
Il en va de même pour ce qu’un modèle doit lire. Les règles, les spécifications et les raisons sont dans le dépôt : un agent part de ce que fait le code au lieu de le deviner.
- Des frameworks standard — Fastify, tRPC, Drizzle, React. Aucun runtime propriétaire à appeler.
- Des autorisations appliquées dans le middleware serveur, pas cachées dans l’interface.
- Des migrations que vous lancez vous-même, sur votre propre Postgres.
- Des tests exécutés sur une vraie base de données dans un conteneur jetable, pas sur un mock.
- Des conventions écrites plutôt que devinées : neuf règles strictes dans CLAUDE.md, trente-quatre spécifications de composants dans COMPONENTS.md.
- Les commentaires expliquent pourquoi une décision a été prise, jamais ce que fait la ligne suivante.
- Le travail terminé consigné dans NOTES.md, le travail en cours numéroté dans TODOS.md — le contexte est sur le disque, pas dans la tête de quelqu’un.
- Chaque composant et chaque page dans Storybook, pour qu’une modification se vérifie au lieu de se deviner.
- Chaque page de la documentation en Markdown, et tout le site sur /llms.txt, pour qu’un agent lise pourquoi une partie a été construite avant de la modifier.
export const rolesRouter = router({
list: protectedProcedure.query(() =>
db.select().from(roles)
),
create: requirePermission("admin.roles.create")
.input(z.object({ name: z.string().min(1) }))
.mutation(async ({ input }) => {
const [created] = await db
.insert(roles)
.values({ name: input.name })
.returning();
return created;
}),
});Des outils répandus et bien documentés. Les personnes que vous recrutez, comme l’IA que vous utilisez, les connaissent déjà.
- TypeScript
- Fastify
- tRPC
- Zod
- Drizzle
- Postgres
- Better Auth
- Pino
- React
- Vite
- Mantine
- Tauri
- Next.js
- Fumadocs
- React Email
- i18next
- Storybook
- Vitest
- Testcontainers
- Playwright
- oxlint
- Docker
- GitHub Actions
- AWS
Les fondations sont posées. Construisez le reste.
Connectez-vous et partez d’une stack qui fonctionne déjà — puis gardez-en chaque fichier.
Recevoir les nouveautés
Les nouvelles versions et les articles, par e-mail. Désabonnement possible depuis chaque message.