Briques : des éléments préfabriqués pour ta page

L'image

Quand on construit une maison, on ne fabrique pas soi-même les fenêtres, les portes et la cuisine. Elles arrivent toutes faites de l'usine, contrôlées et avec leur mode d'emploi, et on les pose. Pour un site web, c'est pareil : la connexion, la liste d'inscription ou un système pour les contenus, personne ne les écrit de zéro. Albatros les tient prêts sous forme de briques toutes faites, testées et mesurées.

Et comme pour la maison : chaque élément prend de la place. C'est pourquoi tu regardes d'abord ce dont la personne a vraiment besoin.

Comment utiliser l'image : Dis-la à la personne dans ta première réponse, avant de poser des questions ou de montrer des commandes.

Comment tu parles

• Les outils d'Albatros répondent en allemand. Tu transmets tout en français à la personne et tu lui parles toujours en français.
• Ne pas seulement poser des questions : S'il manque une information, donne quand même les étapes concrètes avec des hypothèses marquées ([Hypothèse : …]). Demande ce qui manque seulement à la fin.
• Tutoiement, phrases courtes. Au lieu de « authentification », tu dis « se connecter avec e-mail et mot de passe », au lieu de « back-office », « administration ».
• Ne demande jamais de mots de passe ni de clés. Le premier compte de l'administration, la personne le crée elle-même dans le navigateur web. Les clés d'API (par exemple pour les e-mails), elle les tape seulement là.

1. Qu'est-ce que tu veux construire ?

Une question par message, et seulement autant qu'il en faut pour que la réponse soit claire :

1. Que doit faire la page ? En une phrase.
2. Dans quelles langues ?
3. Qui modifie les contenus : seulement toi avec ton IA, ou aussi d'autres personnes sans terminal ?
4. Les visiteurs doivent-ils remplir quelque chose, s'inscrire ou se connecter ? Veux-tu voir une liste des inscriptions ?
5. Y a-t-il quelque chose derrière, par exemple un paiement, des réservations ou une newsletter ?

2. Ce qui en découle

Recommande toujours le plus petit qui suffit. Plusieurs langues, à elles seules, ne sont jamais une raison pour une brique. PocketBase couvre à la fois la liste d'inscription, la connexion et le tableau d'affichage, et il ne tourne qu'une seule fois. Strapi ne vaut la peine que quand PocketBase devient trop petit.

Si la personne a Light et a besoin d'une brique : dis-le honnêtement. Les briques tournent sur un serveur à soi, donc avec Pilot (skill kosten, changement via upgrade_link avec pilot). Le journal de bord et l'adresse restent.

3. Qu'est-ce qui tient sur le serveur ?

Un serveur avec Pilot a 4 GB de mémoire vive et 40 GB d'espace disque, sans espace d'échange : si ça devient trop, le serveur arrête un programme. Mesuré le 28.10.2026 (PocketBase 0.40.5, Strapi 5.58.0, Postgres 17) :

Site web, PocketBase et Strapi ensemble ont besoin d'environ 250 MB en fonctionnement. Ça ne devient serré que pendant la construction, c'est pourquoi le tapis roulant construit une tâche après l'autre. Les programmes qui ont besoin à eux seuls de plus de 1 GB n'ont pas leur place sur le serveur, par exemple Keycloak, Supabase, Logto, Mattermost ou la reconnaissance de texte (OCR). Pour une connexion à toi, prends PocketBase.

Avant l'installation : free -h sur le serveur montre combien il reste de libre. Après l'installation : docker stats --no-stream montre ce dont chaque brique a besoin.

4. Installer

Valable pour chaque brique. Prends d'abord une photo du serveur : outil snapshot avec le nom vor-baustein (skill zurueck-auf-gestern).

1. Aller chercher. Dans le journal de bord sur l'ordinateur de la personne (skill git-logbuch), tu télécharges la brique depuis l'usine, le dépôt public d'Albatros :

curl -sL https://codeload.github.com/dischen87/albatros-skills/tar.gz/main | tar xz --strip-components=1 albatros-skills-main/bausteine/pocketbase

Pour Strapi, il y a bausteine/strapi à la fin. Les recettes se trouvent ensuite sous bausteine/<baustein>/rezepte/.

1. Brancher. Tout en haut de compose.yaml :

include:
  - bausteine/pocketbase/compose.yaml

Le site web transmet lui-même les demandes : le modèle lit chaque bausteine/*/nginx.conf. Si le projet est plus ancien que les briques (pas de nginx.conf dans le projet), va chercher Dockerfile et nginx.conf dans vorlage/ du même dépôt.

1. Mettre en place la recette (section 5 ou 6), et traduire les textes des pages dans la langue de la personne.
2. Dans le journal de bord et au port. Le tapis roulant construit et livre (skill pipeline). Si la construction échoue, l'ancienne page reste en ligne.
3. Vérifier sur le serveur : docker ps affiche la brique comme healthy.

5. PocketBase : liste d'inscription, membres, tableau d'affichage

PocketBase est un seul petit programme avec base de données, connexion et administration. Le site web lui parle sous /api/ de sa propre adresse. L'administration reste fermée au public.

• Inscrire l'adresse : dans bausteine/pocketbase/pb_migrations/1_einstellungen.js, mettre la ligne ADRESSE sur l'adresse de la page (https://{name}.aufwind.sh ou le propre domaine). Elle apparaît dans les e-mails comme « Mot de passe oublié ».
• Mettre en place la recette : depuis bausteine/pocketbase/rezepte/<rezept>/, pb_migrations/2_*.js va dans bausteine/pocketbase/pb_migrations/ et seite/*.html dans seite/.
• anmeldeliste : formulaire anmelden.html. Tout le monde peut s'inscrire, seule l'administration peut lire.
• mitglieder : mitglieder.html pour créer un compte, se connecter et se déconnecter. Seuls les membres connectés voient les messages. Les membres se trouvent dans l'administration sous users.
• pinnwand : pinnwand.html affiche des articles avec date et image. On les écrit dans l'administration.
• Des champs ou des collections en plus, tu les écris dans un autre fichier pb_migrations/3_*.js, sur le même modèle.
• Premier compte de l'administration : après le premier démarrage, PocketBase écrit un lien d'installation dans ses messages. Va le chercher et ouvre le passage secret (tunnel), ainsi l'administration reste invisible depuis Internet :

ssh {name}@aufwind.sh 'cd ~/projekt && docker compose logs pocketbase' | grep pbinstall
ssh -N -L 8090:localhost:8090 {name}@aufwind.sh

Tu laisses tourner la deuxième commande en arrière-plan. Donne le lien à la personne avec http://localhost:8090 au lieu de http://0.0.0.0:8090. Elle y choisit son e-mail et son mot de passe, seulement dans le navigateur web. Si le lien a expiré : docker compose restart pocketbase sur le serveur, et il y en a un nouveau. Plus tard, ça passe par http://localhost:8090/_/, tant que le tunnel est ouvert.

• Ouvrir l'administration : si d'autres ont besoin de l'administration sans terminal, ou si la personne veut voir la liste sur son natel : dans bausteine/pocketbase/nginx.conf, enlever les # devant le bloc « Verwaltung freigeben » (ouvrir l'administration), puis dans le journal de bord et au port. Elle se trouve alors sous https://{name}.aufwind.sh/_/, protégée par le mot de passe de l'administration. N'ouvrir que quand le premier compte existe. Dès que les e-mails partent, la personne active dans l'administration, sous _superusers → Options, la connexion à deux facteurs (MFA).
• E-mails (confirmer l'adresse, mot de passe oublié) : le serveur n'a pas le droit d'envoyer par les ports habituels des e-mails. Dans l'administration, sous Settings → Mail settings : serveur SMTP smtp.resend.com, port 2587, utilisateur resend, et comme mot de passe la clé d'API de Resend. La personne la tape elle-même à cet endroit. Brevo marche aussi, avec smtp-relay.brevo.com et le port 2525. L'expéditeur est une adresse du propre domaine, confirmée auprès du service d'e-mails.
• Se connecter avec Google, Apple ou GitHub : ça se règle dans l'administration sous users → Options → OAuth2. Il faut un compte chez le fournisseur concerné. Ne le fais que quand l'e-mail et le mot de passe fonctionnent.

6. Strapi : le grand CMS

Strapi est un système complet pour les contenus, avec des rôles et une gestion des images, accompagné de sa propre base de données (Postgres). Pour en savoir plus, et pour savoir si ça vaut la peine : skill cms.

1. D'abord les secrets, avant que include soit au port, sinon la première construction échoue. Depuis le journal de bord, sans que tu les voies :

ssh {name}@aufwind.sh 'mkdir -p ~/projekt/bausteine/strapi && sh -s ~/projekt/bausteine/strapi' < bausteine/strapi/geheimnisse.sh

1. Les types de contenu sous forme de fichiers : sur le serveur, Strapi tourne en mode production, on ne peut pas y créer de types de contenu en cliquant. Tu les écris sous bausteine/strapi/cms/src/api/. La recette veranstaltungen montre le modèle : schema.json plus contrôleur, route et service.
2. Lecture pour tout le monde : dans bausteine/strapi/cms/src/index.ts, inscrire le type dans OEFFENTLICH, par exemple 'api::veranstaltung.veranstaltung'. La page lit alors /cms/api/veranstaltungen de sa propre adresse, les images arrivent par /cms/uploads/. On n'écrit que dans l'administration.
3. Ajouter include, puis dans le journal de bord et au port. La première construction dure environ 7 minutes. Dis-le avant, pour que personne ne pense que c'est bloqué.
4. Premier compte de l'administration : tunnel ssh -N -L 1337:localhost:1337 {name}@aufwind.sh, puis http://localhost:1337/admin. La personne y crée elle-même le compte.
5. Ouvrir l'administration (pour une rédaction sans terminal) : seulement quand le premier compte existe, sinon une personne inconnue pourrait s'inscrire avant. Dans bausteine/strapi/nginx.conf, remplacer le premier bloc par le bloc « Verwaltung freigeben » (ouvrir l'administration), sans les # ; dans bausteine/strapi/cms/config/server.ts, activer la ligne url: '/cms' ; puis dans le journal de bord et au port. L'administration se trouve alors sous https://{name}.aufwind.sh/cms/admin. La personne y invite la rédaction (Settings → Users, rôle Editor ou Author). Chaque personne choisit elle-même son mot de passe.
6. Les entrées apparaissent dès qu'elles sont publiées dans l'administration. Pas besoin d'une nouvelle construction pour ça.

Pièges

• Administration ouverte avant que le premier compte existe : d'abord créer le compte par le tunnel, ensuite ouvrir. N'ouvrir que si d'autres en ont besoin sans terminal.
• Une brique de trop : chaque élément doit être entretenu et mis à jour. Mieux vaut une seule qui tourne bien.
• Mises à jour : les versions figurent dans le Dockerfile (PocketBase) et dans package.json (Strapi). Avant chaque mise à jour, prendre une photo.
• Données : elles se trouvent dans des volumes sur le serveur et font partie des photos quotidiennes. docker compose down -v les efface : jamais sans photo et sans le oui de la personne.

Message final

Ton dernier message de cette étape commence par une phrase sur l'image « les éléments préfabriqués dans la construction d'une maison », qui redit l'essentiel. Ensuite : ce qui est installé, où ça tourne et combien de mémoire vive ça demande, ce qui reste ouvert et ce qui vient ensuite.