# Vue d'ensemble plateforme

Le modele technique des projets, workers, orchestration et frontieres.

BernOps est une plateforme d'automatisation limitee par projet. Un projet represente une application ou une surface operationnelle, et chaque job, execution, trigger, file, cle API, variable et job externe appartient a ce perimetre projet.

## Modele mental

Le produit a trois plans :

| Plan | Role | Code principal |
| --- | --- | --- |
| Plan de controle | Interface navigateur pour espaces de travail, projets, jobs, files, variables, executions et cles. | `frontend` |
| Plan d'orchestration | API REST Go, controles d'auth, dispatch des executions, gateway WebSocket worker, ecritures base. | `backend` |
| Plan d'execution | Worker Node qui recoit les payloads d'execution et lance Playwright. | `worker` |

Le frontend est une application Next statique. Il ne possede pas de routes API. Le code navigateur appelle le backend Go via `lib/api-client.ts`, et l'authentification est geree par Supabase PKCE dans le navigateur.

## Hierarchie des ressources

La hierarchie est volontairement stricte :

1. Les espaces de travail contiennent des projets.
2. Les projets contiennent jobs, variables, files, triggers, executions, jobs et cles API.
3. Les cles API sont limitees a un projet et ne traversent pas vers un autre projet.
4. L'execution worker est assignee par execution, pas par projet.

La plupart des automatisations n'ont donc besoin que de trois valeurs : un ID projet, l'ID de la ressource a manipuler et un bearer token avec le scope requis.

## Chemin d'execution

Consultez le schéma ou le tableau sur la page de documentation liée.

Quand une execution demarre, le backend cree une ligne `test_executions`, resout les variables runtime du projet, choisit un worker disponible et envoie un message WebSocket `run_tests`. Le worker ecrit les fichiers Playwright dans un dossier temporaire, genere une configuration Playwright, puis lance `npx playwright test`.

Les resultats reviennent sous forme de logs et d'etapes structures. Le backend les persiste pour que la page de detail affiche timeline, console, reseau, captures, pieces jointes et statut final.

## Principaux d'authentification

BernOps reconnait deux types d'appelants :

| Principal | Cas ideal | Notes |
| --- | --- | --- |
| JWT utilisateur | Actions de gestion authentifiees dans le navigateur. | Herite du role espace de travail/projet de l'utilisateur connecte. |
| Cle API projet | CI, runners externes, workers de file, execution de jobs enregistres, ingestion. | Limitee a un projet et a une liste de scopes. |

Utilisez un JWT utilisateur pour les actions admin comme creer des projets ou gerer les cles. Utilisez une cle API projet quand une machine ou un systeme externe a besoin d'un acces repetable.

## Frontieres techniques

**Contrat de frontend statique**

Le frontend est deployee en export statique. Il ne faut pas attendre des routes frontend qu'elles executent du code serveur, lisent des cookies cote serveur ou exposent des handlers `app/api`. Le runtime doit passer par le backend Go.


La source de verite des routes backend est `backend/main.go`. Les payloads du protocole worker sont miroirs entre `backend/protocol` et `worker/src/protocol/types.ts`; quand les champs changent, les deux cotes doivent rester synchronises.

## Suite conseillee

- Lisez [Jobs Playwright](/fr/docs/playwright-jobs) pour comprendre comment ecrire les jobs.
- Lisez [Variables runtime](/fr/docs/runtime-variables) pour passer des valeurs projet aux executions.
- Lisez [Cles API et scopes](/fr/docs/api-keys-scopes) avant de donner acces a des systemes externes.
- Consultez [Utilisation efficace des outils agent](/fr/docs/agent-tools) pour la découverte selon la version, la sélection compacte, les lots sûrs et la vérification de préparation.
- Utilisez la [Reference API](/fr/docs/api) separee pour les chemins, schemas de requete et outils try-it.