Comment créer et héberger de petites apps internes avec Custom App d'osFoundry

On est jeudi, deux heures avant une mise en production, et Dari est la seule personne à savoir quelles étapes du cutover sont déjà faites. La checklist est dans un onglet de tableur, le runbook sur un drive partagé et la discussion dans un fil de chat que personne ne retrouve. Ce dont l'équipe a vraiment besoin, c'est d'une toute petite app avec quatre cases à cocher et deux responsables, juste à côté des fichiers. L'écrire est facile. L'héberger, lui donner une base de données, protéger ses clés et lui obtenir une URL, c'est là que ça bloque d'habitude.

Ce qu'est la catégorie Custom App

osFoundry regroupe tout ce qu'il faut pour créer et faire tourner vos propres petites apps dans une seule catégorie de la barre latérale de l'app de bureau, appelée CUSTOM APP. Elle compte cinq écrans. Room est l'espace partagé où les apps vivent sous forme d'onglets. App Code est le dépôt qui se trouve derrière une app. Deployed Apps est la liste, à l'échelle du workspace, de ce qui est en ligne. Snippets rassemble les mini-apps qui n'ont jamais eu besoin de dépôt. Domains gère les adresses web depuis lesquelles ces apps sont servies. Si vous connaissez Notion, imaginez une page dont les onglets sont des apps qui fonctionnent plutôt que des documents, avec une petite couche d'hébergement façon Vercel en dessous : chaque app a sa propre base de données, ses secrets, ses tâches planifiées et un sous-domaine, comme décrit sur la page de la fonctionnalité apps internes.

Un coup d'œil à l'écran de construction

Le moyen le plus rapide de voir comment une app démarre, c'est la vue de construction de l'app de bureau. Cette capture vient du constructeur Websites (projet d'exemple « Hearth Bakery »), qui utilise la même boucle « décrire puis construire » que propose une Room avec sa zone « Describe the app you want ».

• Pages, à gauche : les parties de l'app qui existent déjà, avec Add page en bas.
• L'aperçu, au centre : ce que vous êtes en train de construire, avec les tailles bureau, tablette et téléphone au-dessus. Le libellé « On this computer » indique que rien n'a encore été publié.
• La zone de description : vous écrivez ce que fait l'app, à qui elle s'adresse et l'impression qu'elle doit donner, puis vous cliquez sur Build my site. Maestro, l'assistant IA de l'app, écrit les fichiers.
• Le panneau Maestro, à droite : la conversation qui construit et modifie l'app. Use a folder lui donne votre propre matériel au lieu de le laisser deviner.
• Publish needs credits, en haut : la construction et l'aperçu se font sur votre ordinateur ; l'hébergement est l'étape qui consomme des crédits du workspace.

Dans une Room, c'est la même idée avec une autre disposition : une barre d'onglets d'apps en haut, l'app sélectionnée au centre et un panneau de droite avec deux onglets, Maestro et Details.

Cas d'usage 1 : une équipe de release garde sa checklist là où se fait le travail

Qui : une release manager et trois coéquipiers qui préparent un lancement.

La situation : les étapes du cutover, le runbook et le suivi de release sont répartis sur trois outils, et le jour J, personne ne fait confiance au tableur.

Ce qu'ils font dans osFoundry :

1. Créer une room appelée « Launch Ops » avec New Room, puis y ajouter le suivi de release et les fichiers du lancement sous forme d'onglets.
2. Cliquer sur le bouton + de la barre d'onglets. Le sélecteur New Tab liste les apps installées et un catalogue (Incident log, Retro board, On-call rota, Changelog builder), filtrable par All, Forked ou Snippets.
3. Dans « Describe the app you want », cliquer plutôt sur Build a snippet et demander une checklist de cutover avec un responsable par étape. Un snippet est une mini-app exécutable composée de quelques fichiers. Il n'a ni dépôt, ni version, ni déploiement, et il tourne directement dans l'onglet.
4. Continuer à échanger avec Maestro dans le panneau de droite pendant que la checklist est ouverte, et utiliser l'onglet Details pour voir ce qu'est la room et ce qui s'y est passé.

Résultat : une seule room où la checklist (dans la démo : Freeze the 2.4 branch, Run the order-index migration, Smoke-test the order desk, Post the release note) se trouve à côté du runbook et du suivi. Plus tard, l'écran Snippets liste tous les snippets de toutes les rooms. De là, on peut en exporter un en JSON avec Export pour un autre workspace, ou le transformer en vrai dépôt avec Promote quand il devient trop grand pour son onglet.

Cas d'usage 2 : un développeur donne un vrai backend à un outil interne

Qui : un développeur seul qui construit un outil d'inscriptions et de commandes pour l'équipe support.

La situation : la première version tournait sur un portable avec un fichier SQLite. Maintenant trois équipes en ont besoin, elle doit appeler une API de paiement et un nettoyage nocturne doit s'exécuter sans que personne ait à penser à cliquer sur un bouton.

Ce qu'il fait dans osFoundry :

1. Tant que l'app tourne encore en local, ouvrir le projet dans l'IDE et cliquer sur l'onglet Database. Il trouve les fichiers .db et .sqlite de l'app et ouvre une table en lecture seule, 200 lignes par page (données d'exemple ci-dessus), pour voir ce que l'app a réellement enregistré avant de déplacer quoi que ce soit.
2. Déplacer l'app dans une room partagée. La boîte de dialogue Move to cloud copie l'app dans une Cloud room pour que tous ses membres puissent l'utiliser, et indique quelles tables ont été copiées et lesquelles sont restées sur l'appareil. L'app et ses données restent aussi sur cet appareil.
3. Ouvrir les paramètres de l'onglet de l'app. Sous Secrets, App Runtime Secrets liste les clés que déclare l'app ; Add a custom secret en enregistre une nouvelle et Rotate remplace une valeur. L'app affiche alors « Secrets updated. Redeploy to apply changes. »
4. Déclarer le nettoyage sous container.cron dans le manifeste de l'app, puis ouvrir Scheduled jobs et cliquer sur Sync from manifest. Chaque tâche peut être mise en pause, reprise ou lancée une fois avec Run now.

Résultat : une app avec sa propre base Postgres. Sur osFoundry, chaque Room App en a une, avec pgvector et TimescaleDB installés, et la chaîne de connexion arrive sous forme de secret à l'exécution (Postgres par app). L'explorateur de base de données propose un éditeur de lignes avec filtres et une vue SQL limitée à SELECT, et Database snapshots offre New snapshot, Restore et un lien de téléchargement. Les modifications de code se font dans App Code, où le développeur peut travailler sur une version comme version/2.4 sans toucher à main, vérifier le Manifest (point d'entrée, visibilité, connecteurs requis) et suivre l'arbre Versions avant de livrer.

Cas d'usage 3 : une commerçante publie une page et garde un œil dessus

Qui : quelqu'un qui tient une petite boulangerie et ne code pas.

La situation : elle veut un site simple avec la carte et les horaires, sur sa propre adresse, et elle veut savoir combien coûte sa mise en ligne.

Ce qu'elle fait dans osFoundry :

1. Ouvrir Websites, cliquer sur New Website, décrire la boulangerie et cliquer sur Build my site. La première version (ci-dessus, exemple) utilise des textes provisoires, et Maestro le dit clairement.
2. Cliquer sur Use a folder, choisir le dossier avec la vraie carte et les photos, puis demander des changements avec des mots simples, comme « Make the headline bigger. »
3. Quand le résultat convient, publier. L'hébergement consomme des crédits du workspace. Who can open it propose Workspace members only, Anyone with the link ou la connexion propre à l'app ; un site de boulangerie public utilise Anyone with the link.
4. Dans Domains, enregistrer un domaine ou en ajouter un qu'elle possède déjà, puis modifier ses enregistrements DNS. Events montre qui a modifié quel enregistrement, et Settings regroupe le renouvellement, la confidentialité et le code de transfert.

Résultat : un site avec ses propres textes et photos, servi sur son propre domaine. Deployed Apps répond ensuite aux questions qu'une commerçante se pose vraiment. Apps montre chaque app et où elle est servie, Activity ce qui a changé, Usage le coût de build et de stockage par app, et Previews liste les versions d'aperçu encore actives.

Comment ça s'articule avec le reste d'osFoundry

Custom App fonctionne rarement seul. Maestro est l'assistant du panneau de droite de chaque Room et des vues de construction ; il écrit et modifie le code avec vous. L'IDE fournit l'onglet Database, le contrôle de version et l'éditeur pour les apps qui commencent comme un dossier sur votre ordinateur. Websites est un chemin plus rapide quand l'« app » est en réalité un site public. Les Snippets ne sont reliés à App Code que par Promote, si bien qu'un outil jetable peut devenir un dépôt maintenu sans être réécrit. Les tâches planifiées à l'intérieur d'une app sont prises en charge par les cron jobs d'app, décrits sur la page plateforme consacrée à app cron.

Les questions des nouveaux venus

Une Room, c'est un salon de discussion ?
Non. Le cœur d'une Room, ce sont ses onglets d'apps. Le chat Maestro se trouve dans le panneau compagnon à droite, à côté des Details de la room.

Quand faut-il créer un snippet plutôt qu'une app ?
Quand l'outil tient en quelques fichiers et n'a besoin de tourner que dans une seule room, comme un formateur de dates ou une vérification de webhook. Enregistrer un snippet n'installe rien et ne déploie rien. Si plus tard il lui faut des versions, des secrets ou une base de données, transformez-le en dépôt avec Promote.

Deux apps peuvent-elles partager une base de données ?
Chaque app a son propre Postgres. Le partage passe par des autorisations explicites : l'onglet Database de la room affiche Incoming Requests, Active Grants et Outgoing Access, et chaque demande peut être approuvée ou refusée.

Est-ce que l'essayer coûte quelque chose ?
Construire et prévisualiser sur votre ordinateur ne demande aucun crédit. Publier, déployer et enregistrer des domaines consomme des crédits du workspace. Vous pouvez télécharger l'app de bureau sur osfoundry.io/fr/download.