# Constructions

La construction transforme un commit en image prête à servir. Cette page décrit comment elle est isolée, ce que le cache fait gagner, ce qu'elle consomme de votre palier, et la chaîne d'approvisionnement qui analyse, inventorie et signe chaque image avant qu'elle n'atteigne la production. Elle dit aussi quoi faire quand une image est refusée pour une vulnérabilité.

## Ce qui se passe pendant une construction

1. **Récupération** du commit, avec un jeton limité au dépôt et à la lecture pour un dépôt raccordé (voir [Git](git.md)).
2. **Détection** du cadriciel et choix de l'étage : votre `Dockerfile`, l'image composée ou le repli (voir [Cadriciels](frameworks.md)).
3. **Contrôle des variables requises** : les noms déclarés par `.env.example` doivent exister sur l'environnement.
4. **Installation** des dépendances puis **construction** de l'image.
5. **Porte d'approvisionnement** : analyse, inventaire, signature, puis passage à `built`.

Chaque étape est horodatée dans le journal de construction, que l'écran **Déploiement** montre en direct et que `deployment_log_read` rend page par page. Le journal est conservé jusqu'à 64 Mio sans troncature.

## Isolation

- La détection lit des fichiers et n'exécute aucun script du dépôt.
- L'image composée par la plateforme n'interpole aucune valeur venue du dépôt dans ses instructions : les commandes viennent d'un catalogue fermé.
- La construction s'exécute sans privilège ; un `Dockerfile` qui en demande est refusé.
- Le cache n'est jamais partagé entre deux locataires, même à dépendances identiques : un voisin ne peut pas glisser un artefact dans votre image.
- Une construction est arrêtée au-delà de 30 minutes. Les ouvriers de construction la bornent aussi à 4 vCPU, 8 Go de mémoire et 20 Go de disque ; le message d'arrêt nomme la limite atteinte et la valeur observée.

## Le cache de construction

### Le cache des couches

Les couches d'image d'un projet sont gardées d'une construction à l'autre : une construction dont les dépendances n'ont pas changé repart de là. Ce cache est plafonné à 2 Go par projet et conservé 30 jours.

Pour construire sans aucun cache : `ignoreCache: true` dans `deployment_create`, ou **Reconstruire quand même** sur l'écran **Déploiement** d'un échec survenu après la construction.

### Le cache distant Turborepo

Un monorepo Turborepo peut déposer et relire ses artefacts dans le cache distant du projet. Dans votre intégration continue ou vos scripts, posez :

- `TURBO_API` à l'adresse de l'API, `https://api.bastide.app` ;
- `TURBO_TEAM` à l'identifiant du projet (`prj_…`) ;
- `TURBO_TOKEN` à un jeton du projet.

Un artefact qui contient un secret est refusé, et le refus nomme le fichier.

Dans la console, ouvrez **Réglages** du projet, section « Crochets et cache », carte « Cache distant Turborepo » : vous y réglez la rétention (de 1 à 30 jours, 7 par défaut) et purgez tout le cache. Un agent fait de même avec `build_cache_manage`, et peut aussi purger des empreintes précises :

```json
{
  "projectId": "prj_01JQ8ZK4M7NP2RSTVWXYZ34567",
  "purge": ["a1b2c3d4e5f60718"],
  "retentionDays": 14
}
```

Sans `purge`, seule la rétention change ; une liste `purge` vide purge tout le cache. Un artefact purgé n'est plus servi dès l'appel. La nouvelle rétention vaut pour les dépôts suivants.

> **Note.** Le panneau « Cache de l'edge et images » de l'écran **Domaines** concerne le cache qui sert votre site et la transformation d'images, pas la construction : voir [Cache](cache.md).

## Ce que la construction consomme

| Palier | Minutes de construction par mois | Constructions simultanées | Registre d'images |
| --- | --- | --- | --- |
| Découverte | 100 | 1 | 10 Go |
| Standard | 500 | 2 | 10 Go |
| Pro | 2 000 | 5 | 40 Go |
| Souverain | 10 000 | négocié | négocié |

- **Minutes** : le quota est un plafond dur, sans facturation de dépassement. Une construction annulée ou sautée ne compte rien ; un échec compte ses secondes. Le mois est celui de la fin de la construction, en UTC. Atteint, il refuse les constructions suivantes jusqu'au premier jour du mois suivant ; les sites en ligne continuent d'être servis. Une construction en cours compte à sa fin.
- **Constructions simultanées** : au-delà du plafond du palier, une construction attend son tour, sans rien perdre. La plateforme a aussi un plafond global.
- **Registre** : chaque construction le dit au-delà de 80 % du quota ; à 100 %, la construction est refusée. Les releases anciennes sont purgées chaque jour (les dix dernières de chaque environnement et celles qui ont servi la production depuis 30 jours sont gardées).
- **Taille d'image** : au-delà de 5 Go, la construction est refusée ; au-delà de 1 Go, le fait est rapporté.

La consommation du dernier mois clos se lit dans **Réglages** du projet, section « Consommation », ou par `usage_read`. Voir [Limites](limits.md) et [Facturation](billing.md).

## La chaîne d'approvisionnement

Entre la construction de l'image et son passage à `built`, la plateforme :

1. **analyse** l'image avec Trivy ;
2. **juge** ses vulnérabilités contre le catalogue des vulnérabilités activement exploitées (recopié de celui de la CISA) et le registre des dérogations ;
3. **attache** à l'image, dans le registre, l'inventaire logiciel (SBOM) au format CycloneDX et le rapport d'analyse ;
4. **inscrit** l'analyse au journal d'audit ;
5. **refuse la production** si le verdict l'exige ;
6. **signe** l'image et celles de ses services. Les nœuds n'exécutent que des images signées.

Le résumé de l'analyse accompagne le passage du déploiement à « Construit » : le nombre de vulnérabilités élevées et moyennes, et ce que la production refuserait.

### Ce qui bloque la production

| Vulnérabilité | Effet |
| --- | --- |
| Activement exploitée (au catalogue) | Production refusée, sans dérogation possible. |
| Critique (CVSS 9,0 ou plus), avec ou sans correctif | Production refusée, sauf dérogation en vigueur. |
| Élevée | Non bloquante, à corriger sous 7 jours. |
| Moyenne | Non bloquante, à corriger sous 30 jours. |
| Basse | Non bloquante, à corriger sous 90 jours. |

La criticité se lit au plus haut score CVSS v3 rapporté ; la sévérité du fournisseur ne sert que faute de score. En prévisualisation, l'analyse informe et ne bloque pas : c'est là que vous découvrez ce que la production refuserait. Une image que la plateforme n'a pas pu analyser, juger ou signer n'est pas promue en production (`chaine_d_approvisionnement_indisponible`) : relancez le déploiement, la cause est de son côté.

### Corriger une image refusée

Le refus (`image_vulnerabilite_critique` ou `image_vulnerabilite_exploitee`) nomme jusqu'à cinq vulnérabilités, avec le paquet, sa version et la version qui corrige. La carte « Pourquoi il a échoué » de l'écran **Déploiement** le montre.

1. **Mettez à jour le paquet** nommé à la version qui corrige, dans votre fichier de verrou, puis redéployez. Si le paquet vient de l'image de base, reconstruisez sur une image de base plus récente.
2. **Retirez de l'image finale ce qui n'y sert pas.** Une faille portée par un outil de construction (npm et ses dépendances, un compilateur) disparaît si l'image finale ne le contient pas. Avec votre `Dockerfile`, construisez en plusieurs étages et terminez sur une image d'exécution sans gestionnaire de paquets.
3. **Demandez une dérogation** si aucun correctif n'existe encore, ou s'il ne peut pas être appliqué tout de suite. Une dérogation ne couvre qu'une vulnérabilité critique, jamais une vulnérabilité exploitée. Elle est datée, motivée, signée par le responsable technique de la plateforme chez Glowsoft, et dure sept jours au plus ; elle ne se prolonge pas. Adressez la demande au support, avec l'identifiant de la vulnérabilité, le projet et votre mesure de contournement.

À l'échéance d'une dérogation, la construction suivante est de nouveau bloquée, et le refus nomme la dérogation échue et sa date.

### Licences contaminantes et secrets

- L'option « Bloquer les licences AGPL, SSPL et BUSL » (**Réglages** du projet, « Source et construction ») fait échouer la construction, dans tout environnement, quand un paquet sous l'une de ces licences est dans l'image. Sans elle, le paquet est seulement signalé.
- Une variable d'image dont la valeur a la forme d'un secret connu refuse la production (`image_variable_de_secret`). Révoquez d'abord la valeur chez son émetteur : elle est dans une couche d'image, donc publiée.

## Erreurs fréquentes

| Code | Remède |
| --- | --- |
| `quota_de_construction_atteint` | Attendre le premier du mois (UTC) ou changer de palier. |
| `quota_gratuit_construction` | Le projet gratuit a consommé ses 100 minutes : attendre le mois suivant ou passer au palier payant depuis **Facturation**. |
| `build_quota_registre` | Réduire les images ou détruire les prévisualisations inutiles ; sinon changer de palier. |
| `build_limite_duree` | La construction a dépassé 30 minutes : alléger l'installation, profiter du cache. |
| `build_limite_taille` | Image trop grande : plusieurs étages, un `.dockerignore`, moins de dépendances dans l'image finale. |
| `image_vulnerabilite_critique` | Voir « Corriger une image refusée ». |
| `image_licence_contaminante` | Remplacer le paquet, ou retirer l'option si la licence est acceptée. |

Voir aussi : [Cadriciels](frameworks.md), [Déployer](deploy.md), [Sécurité](security.md), [Limites](limits.md), [Facturation](billing.md).