celuga-html-bootstrap

Quand : Pages HTML5 / CSS / Bootstrap, grille container-row-col, CSS dans styles.css.

Portée : machine (~/.agents/skills) · Fichiers : 3

Tout installer

Copier le bloc et le coller dans un terminal. Il recrée tous les fichiers du skill.

dir="$HOME/.agents/skills/celuga-html-bootstrap"
mkdir -p "$dir"
cat > "$dir/SKILL.md" <<'CELUGA_SKILL_EOF'
---
name: celuga-html-bootstrap
description: Intègre et révise les projets Celuga en HTML5, CSS et Bootstrap avec une sémantique SEO, une hiérarchie de grille container-row-col, les classes Bootstrap en priorité et des modifications CSS exclusivement dans styles.css. Utiliser pour créer ou modifier des pages .html/.htm, des templates, des composants Bootstrap, leur responsive, leur accessibilité ou leur mise en forme dans un projet HTML/Bootstrap Celuga.
---

# Celuga HTML Bootstrap

Appliquer une discipline **HTML5 sémantique, Bootstrap-first, grille-first**. Conserver la version et les conventions du starter rencontré ; ne jamais migrer Bootstrap implicitement.

## 1. Inspecter avant de modifier

1. Localiser les fichiers HTML, `styles.css`, les feuilles Bootstrap, les scripts et les éventuelles consignes du dépôt.
2. Identifier la version réelle de Bootstrap dans les en-têtes, les dépendances ou le bundle JavaScript.
3. Inventorier dans le HTML et les CSS les composants, utilitaires, variables et classes déjà disponibles.
4. Lire les zones voisines de chaque modification pour respecter la hiérarchie des titres, la grille et les conventions de nommage.
5. Si le projet charge le starter Celuga v2 avec `bootstrap-reboot.css`, `bootstrap-grid.css` et `bootstrap-theme.css`, lire [references/celuga-starter-v2.md](references/celuga-starter-v2.md).

Terminer cette étape seulement après avoir identifié la version Bootstrap, la feuille `styles.css` modifiable et les classes réutilisables pour la demande.

## 2. Écrire du HTML5 sémantique pour le SEO

Pour chaque HTML créé ou touché :

- Employer les landmarks adaptés : `header`, `nav`, `main`, `section`, `article`, `aside` et `footer`. Garder un seul `main` visible par page.
- Utiliser un seul `h1` principal, puis une hiérarchie de `h2` à `h6` sans choisir un niveau pour son apparence. Utiliser les classes Bootstrap `.h1` à `.h6` si l'apparence doit différer du niveau sémantique.
- Donner à chaque `section` un titre explicite ; si le titre doit rester visuellement masqué, le conserver avec `.sr-only` ou l'utilitaire équivalent déjà présent.
- Employer `article` pour un contenu autonome, `aside` pour un complément, `figure`/`figcaption` pour un média légendé, `time` pour une date et `address` pour les coordonnées pertinentes.
- Employer `ul`/`ol` pour les ensembles de liens ou d'éléments répétés. Employer `a` pour une navigation et `button type="button"` pour une action.
- Rédiger des textes de liens descriptifs. Conserver des `id` uniques et des ancres valides.
- Fournir un `alt` informatif aux images porteuses de sens et `alt=""` aux images purement décoratives. Donner un `title` aux `iframe`.
- Associer chaque champ à un `label`. Maintenir `aria-label`, `aria-labelledby`, `aria-controls`, `aria-expanded` et les états de focus lorsque le composant l'exige.
- Préserver ou améliorer `lang`, `title`, meta description, canonical, Open Graph et données structurées lorsque la demande touche le `<head>` ; ne pas inventer d'URL ou de contenu métier.

Ne pas remplacer mécaniquement tous les `div` : choisir une balise sémantique uniquement quand son rôle est réel. Ne pas élargir la refonte à du HTML hors périmètre sauf si la modification rendrait le document invalide.

## 3. Construire la mise en page avec la grille Bootstrap

Utiliser cette structure par défaut pour chaque bloc de mise en page :

```html
<section aria-labelledby="section-title">
  <div class="container-xl">
    <div class="row">
      <article class="col-12 col-lg-8">
        <h2 id="section-title">Titre</h2>
      </article>
      <aside class="col-12 col-lg-4">...</aside>
    </div>
  </div>
</section>
```

Respecter les invariants suivants :

- Placer les `.row` dans un `.container`, `.container-fluid` ou conteneur responsive existant.
- Faire des colonnes `.col`, `.col-*` ou éléments portant ces classes les enfants directs d'une `.row`.
- Placer toute grille imbriquée dans une colonne, puis recommencer par `.row > .col-*`.
- Utiliser les breakpoints et largeurs réellement fournis par le projet ; ne pas supposer ceux d'une autre version de Bootstrap.
- Utiliser les colonnes responsives, `order-*`, `offset-*`, `row-cols-*`, les gouttières disponibles et les utilitaires d'espacement avant d'écrire du CSS de largeur, marge ou positionnement.
- Réserver `d-flex` et les utilitaires flex aux micro-layouts unidimensionnels : alignement d'icônes, groupe de boutons, ligne d'actions ou cas où la grille ajouterait une structure artificielle. Préférer les colonnes pour la mise en page principale.

## 4. Réutiliser Bootstrap avant de créer une classe

Chercher dans cet ordre :

1. composant Bootstrap déjà utilisé dans le projet ;
2. classes de grille et utilitaires Bootstrap disponibles dans cette version ;
3. classe personnalisée existante dans `styles.css` ;
4. nouvelle classe spécifique, seulement si les trois premières options ne couvrent pas le besoin.

Ne pas créer une classe spécifique uniquement pour une marge, un padding, un alignement, un ordre, une couleur, une largeur de colonne ou une visibilité responsive déjà fournis. Ne pas fabriquer une pseudo-classe Bootstrap absente de la version courante.

Lorsqu'une nouvelle classe est nécessaire :

- la nommer selon le rôle du composant, pas selon son apparence ou sa position ponctuelle ;
- la limiter au composant concerné et éviter les sélecteurs globaux fragiles ;
- la composer avec les utilitaires Bootstrap et classes projet existants ; ne déclarer que les propriétés encore manquantes ;
- expliquer dans le compte rendu final quel manque de Bootstrap ou du starter la justifie.

## 5. Modifier le CSS uniquement dans styles.css

Appliquer cette règle sans exception : **toute modification CSS va dans `styles.css`**.

- Ne jamais modifier `bootstrap.css`, `bootstrap.min.css`, `bootstrap-theme.css`, `bootstrap-grid.css`, `bootstrap-reboot.css`, leurs variantes, les fichiers `vendor`, `aos.css` ou toute autre feuille tierce.
- Ne pas ajouter de CSS inline avec `style="..."` et ne pas ajouter de bloc `<style>` pour contourner la règle.
- Si `styles.css` est absent ou n'est pas chargé, ne toucher aucune autre feuille ; signaler le blocage avant d'introduire une nouvelle convention.
- Réutiliser en priorité les variables `:root`, sélecteurs et composants déjà définis dans `styles.css`.
- Ranger la règle dans la section logique existante. Consolider le sélecteur propriétaire au lieu d'empiler en fin de fichier des « correctifs » ou des versions successives.
- Garder les media queries avec le composant ou dans la section responsive existante selon l'organisation du fichier.
- Éviter `!important`. Si l'héritage du starter l'impose réellement, limiter l'override au sélecteur le plus étroit et documenter sa raison dans le CSS.

## 6. Respecter la version Bootstrap et les interactions

- Réutiliser les composants Bootstrap (`collapse`, modal, navbar, dropdown, formulaires, boutons, etc.) avant d'écrire un moteur JavaScript personnalisé.
- Conserver la syntaxe de la version détectée : par exemple `data-toggle`/`data-target` pour Bootstrap 4 et `data-bs-toggle`/`data-bs-target` pour Bootstrap 5.
- Ne pas mélanger les API de deux versions et ne pas remplacer jQuery si le starter courant en dépend, sauf demande explicite de migration.
- Synchroniser les attributs ARIA, le focus, la touche Échap et les états ouverts/fermés pour toute interaction personnalisée.
- Respecter `prefers-reduced-motion` pour les animations ajoutées.

## 7. Vérifier avant de terminer

1. Relire tous les fichiers modifiés et le diff lorsqu'un VCS est disponible.
2. Confirmer qu'aucune feuille CSS autre que `styles.css` n'a changé et qu'aucun style inline n'a été ajouté.
3. Contrôler chaque grille touchée : conteneur > ligne > colonnes, sommes et empilement responsives cohérents, grilles imbriquées valides.
4. Contrôler les landmarks, l'unique `h1`, l'ordre des titres, les noms accessibles des sections, les `alt`, labels, liens et boutons.
5. Vérifier que chaque nouvelle classe et chaque propriété qu'elle déclare sont indispensables et qu'aucune classe Bootstrap ou classe projet existante ne peut les remplacer.
6. Vérifier les composants interactifs au clavier et aux largeurs mobile, tablette et desktop lorsque le rendu change.
7. Vérifier la console et l'absence de régression Bootstrap lorsque du JavaScript ou des attributs `data-*` changent.

Terminer seulement lorsque chaque point applicable est vérifié. Dans le compte rendu, lister les fichiers touchés, les validations effectuées et toute nouvelle classe spécifique avec sa justification.
CELUGA_SKILL_EOF
mkdir -p "$dir/agents"
cat > "$dir/agents/openai.yaml" <<'CELUGA_SKILL_EOF'
interface:
  display_name: "Celuga HTML + Bootstrap"
  short_description: "Intégration HTML5 et Bootstrap Celuga"
  default_prompt: "Utilise $celuga-html-bootstrap pour intégrer cette modification en HTML5 sémantique, avec Bootstrap en priorité et uniquement styles.css pour le CSS."
CELUGA_SKILL_EOF
mkdir -p "$dir/references"
cat > "$dir/references/celuga-starter-v2.md" <<'CELUGA_SKILL_EOF'
# Starter Standard Celuga v2 — observations TAE2026

Lire cette référence uniquement lorsque le projet utilise le starter Celuga v2 ou la combinaison de feuilles `bootstrap-reboot.css`, `bootstrap-grid.css` et `bootstrap-theme.css`.

## Empilement technique observé

- Bootstrap 4.5.2, réparti entre `bootstrap-reboot.css`, `bootstrap-grid.css`, `bootstrap-theme.css` et `bootstrap.bundle.min.js`.
- jQuery chargé avant le bundle Bootstrap.
- `styles.css` chargé après toutes les feuilles du starter : c'est l'unique emplacement des adaptations projet.
- API Bootstrap 4 dans le HTML : `data-toggle`, `data-target`, `data-dismiss`, `data-parent`.
- AOS et PureCounter présents dans TAE2026. Les réutiliser seulement s'ils existent déjà dans le projet concerné ; ce ne sont pas des dépendances obligatoires du skill.

## Grille Celuga observée

Ne pas remplacer ces valeurs par les valeurs Bootstrap standards sans demande explicite :

| Palier | Début | Conteneur observé |
|---|---:|---:|
| `sm` | 320 px | 540 px |
| `md` | 768 px | 720 px |
| `lg` | 992 px | 1 140 px |
| `xl` | 1 200 px pour les classes ; 1 366 px pour `.container-xl` | 1 440 px |

La grille utilise des gouttières de 15 px. Les classes `row-cols-*`, `order-*`, `offset-*`, affichage, flex, espacement et texte sont disponibles dans les feuilles du starter ; vérifier leur présence exacte avant usage.

## Conventions réutilisables observées

- Conteneur éditorial principal : `.container-xl`.
- Mise en page : `.row` avec `.col-*`, notamment `col-12`, `col-md-*`, `col-lg-*`, `order-*`.
- Accessibilité : `.sr-only`, `.sr-only-focusable`, lien d'évitement, `aria-labelledby`, labels de formulaires et boutons typés.
- Médias : `.img-fluid`, `.img-fit-cover-center`, `.img-fit-cover-left`, `.img-fit-cover-right`.
- Composants : `.btn` et ses variantes, navbar/collapse, modal, formulaires, `input-group`.
- Variables projet dans `styles.css` : couleurs `--primary`, `--secondary`, `--warning`, leurs variantes RVB, familles de polices, rayon et courbe d'animation.

Réutiliser ces conventions lorsqu'elles existent dans le projet courant. Ne pas les recopier automatiquement vers un autre starter.

## Leçons de maintenance tirées de TAE2026

- `styles.css` contient des sections par composant suivies d'une section responsive : placer les nouvelles règles avec leur propriétaire logique.
- Éviter d'ajouter en fin de fichier des couches nommées « correctif V… ». Fusionner la règle dans la définition ou la media query existante lorsque le périmètre le permet.
- Le starter surcharge déjà de nombreux composants Bootstrap. Lire la définition existante avant d'ajouter un sélecteur plus spécifique ou `!important`.
- Des interactions Bootstrap coexistent avec du JavaScript spécifique. Préserver Bootstrap pour collapse/modal/navbar et réserver le code spécifique aux comportements absents du framework.
CELUGA_SKILL_EOF
mkdir -p "$HOME/.claude/skills" "$HOME/.codex/skills"
[ -e "$HOME/.claude/skills/celuga-html-bootstrap" ] || ln -s "$dir" "$HOME/.claude/skills/celuga-html-bootstrap"
[ -e "$HOME/.codex/skills/celuga-html-bootstrap" ] || ln -s "$dir" "$HOME/.codex/skills/celuga-html-bootstrap"

SKILL.md

SKILL.md

---
name: celuga-html-bootstrap
description: Intègre et révise les projets Celuga en HTML5, CSS et Bootstrap avec une sémantique SEO, une hiérarchie de grille container-row-col, les classes Bootstrap en priorité et des modifications CSS exclusivement dans styles.css. Utiliser pour créer ou modifier des pages .html/.htm, des templates, des composants Bootstrap, leur responsive, leur accessibilité ou leur mise en forme dans un projet HTML/Bootstrap Celuga.
---

# Celuga HTML Bootstrap

Appliquer une discipline **HTML5 sémantique, Bootstrap-first, grille-first**. Conserver la version et les conventions du starter rencontré ; ne jamais migrer Bootstrap implicitement.

## 1. Inspecter avant de modifier

1. Localiser les fichiers HTML, `styles.css`, les feuilles Bootstrap, les scripts et les éventuelles consignes du dépôt.
2. Identifier la version réelle de Bootstrap dans les en-têtes, les dépendances ou le bundle JavaScript.
3. Inventorier dans le HTML et les CSS les composants, utilitaires, variables et classes déjà disponibles.
4. Lire les zones voisines de chaque modification pour respecter la hiérarchie des titres, la grille et les conventions de nommage.
5. Si le projet charge le starter Celuga v2 avec `bootstrap-reboot.css`, `bootstrap-grid.css` et `bootstrap-theme.css`, lire [references/celuga-starter-v2.md](references/celuga-starter-v2.md).

Terminer cette étape seulement après avoir identifié la version Bootstrap, la feuille `styles.css` modifiable et les classes réutilisables pour la demande.

## 2. Écrire du HTML5 sémantique pour le SEO

Pour chaque HTML créé ou touché :

- Employer les landmarks adaptés : `header`, `nav`, `main`, `section`, `article`, `aside` et `footer`. Garder un seul `main` visible par page.
- Utiliser un seul `h1` principal, puis une hiérarchie de `h2` à `h6` sans choisir un niveau pour son apparence. Utiliser les classes Bootstrap `.h1` à `.h6` si l'apparence doit différer du niveau sémantique.
- Donner à chaque `section` un titre explicite ; si le titre doit rester visuellement masqué, le conserver avec `.sr-only` ou l'utilitaire équivalent déjà présent.
- Employer `article` pour un contenu autonome, `aside` pour un complément, `figure`/`figcaption` pour un média légendé, `time` pour une date et `address` pour les coordonnées pertinentes.
- Employer `ul`/`ol` pour les ensembles de liens ou d'éléments répétés. Employer `a` pour une navigation et `button type="button"` pour une action.
- Rédiger des textes de liens descriptifs. Conserver des `id` uniques et des ancres valides.
- Fournir un `alt` informatif aux images porteuses de sens et `alt=""` aux images purement décoratives. Donner un `title` aux `iframe`.
- Associer chaque champ à un `label`. Maintenir `aria-label`, `aria-labelledby`, `aria-controls`, `aria-expanded` et les états de focus lorsque le composant l'exige.
- Préserver ou améliorer `lang`, `title`, meta description, canonical, Open Graph et données structurées lorsque la demande touche le `<head>` ; ne pas inventer d'URL ou de contenu métier.

Ne pas remplacer mécaniquement tous les `div` : choisir une balise sémantique uniquement quand son rôle est réel. Ne pas élargir la refonte à du HTML hors périmètre sauf si la modification rendrait le document invalide.

## 3. Construire la mise en page avec la grille Bootstrap

Utiliser cette structure par défaut pour chaque bloc de mise en page :

```html
<section aria-labelledby="section-title">
  <div class="container-xl">
    <div class="row">
      <article class="col-12 col-lg-8">
        <h2 id="section-title">Titre</h2>
      </article>
      <aside class="col-12 col-lg-4">...</aside>
    </div>
  </div>
</section>
```

Respecter les invariants suivants :

- Placer les `.row` dans un `.container`, `.container-fluid` ou conteneur responsive existant.
- Faire des colonnes `.col`, `.col-*` ou éléments portant ces classes les enfants directs d'une `.row`.
- Placer toute grille imbriquée dans une colonne, puis recommencer par `.row > .col-*`.
- Utiliser les breakpoints et largeurs réellement fournis par le projet ; ne pas supposer ceux d'une autre version de Bootstrap.
- Utiliser les colonnes responsives, `order-*`, `offset-*`, `row-cols-*`, les gouttières disponibles et les utilitaires d'espacement avant d'écrire du CSS de largeur, marge ou positionnement.
- Réserver `d-flex` et les utilitaires flex aux micro-layouts unidimensionnels : alignement d'icônes, groupe de boutons, ligne d'actions ou cas où la grille ajouterait une structure artificielle. Préférer les colonnes pour la mise en page principale.

## 4. Réutiliser Bootstrap avant de créer une classe

Chercher dans cet ordre :

1. composant Bootstrap déjà utilisé dans le projet ;
2. classes de grille et utilitaires Bootstrap disponibles dans cette version ;
3. classe personnalisée existante dans `styles.css` ;
4. nouvelle classe spécifique, seulement si les trois premières options ne couvrent pas le besoin.

Ne pas créer une classe spécifique uniquement pour une marge, un padding, un alignement, un ordre, une couleur, une largeur de colonne ou une visibilité responsive déjà fournis. Ne pas fabriquer une pseudo-classe Bootstrap absente de la version courante.

Lorsqu'une nouvelle classe est nécessaire :

- la nommer selon le rôle du composant, pas selon son apparence ou sa position ponctuelle ;
- la limiter au composant concerné et éviter les sélecteurs globaux fragiles ;
- la composer avec les utilitaires Bootstrap et classes projet existants ; ne déclarer que les propriétés encore manquantes ;
- expliquer dans le compte rendu final quel manque de Bootstrap ou du starter la justifie.

## 5. Modifier le CSS uniquement dans styles.css

Appliquer cette règle sans exception : **toute modification CSS va dans `styles.css`**.

- Ne jamais modifier `bootstrap.css`, `bootstrap.min.css`, `bootstrap-theme.css`, `bootstrap-grid.css`, `bootstrap-reboot.css`, leurs variantes, les fichiers `vendor`, `aos.css` ou toute autre feuille tierce.
- Ne pas ajouter de CSS inline avec `style="..."` et ne pas ajouter de bloc `<style>` pour contourner la règle.
- Si `styles.css` est absent ou n'est pas chargé, ne toucher aucune autre feuille ; signaler le blocage avant d'introduire une nouvelle convention.
- Réutiliser en priorité les variables `:root`, sélecteurs et composants déjà définis dans `styles.css`.
- Ranger la règle dans la section logique existante. Consolider le sélecteur propriétaire au lieu d'empiler en fin de fichier des « correctifs » ou des versions successives.
- Garder les media queries avec le composant ou dans la section responsive existante selon l'organisation du fichier.
- Éviter `!important`. Si l'héritage du starter l'impose réellement, limiter l'override au sélecteur le plus étroit et documenter sa raison dans le CSS.

## 6. Respecter la version Bootstrap et les interactions

- Réutiliser les composants Bootstrap (`collapse`, modal, navbar, dropdown, formulaires, boutons, etc.) avant d'écrire un moteur JavaScript personnalisé.
- Conserver la syntaxe de la version détectée : par exemple `data-toggle`/`data-target` pour Bootstrap 4 et `data-bs-toggle`/`data-bs-target` pour Bootstrap 5.
- Ne pas mélanger les API de deux versions et ne pas remplacer jQuery si le starter courant en dépend, sauf demande explicite de migration.
- Synchroniser les attributs ARIA, le focus, la touche Échap et les états ouverts/fermés pour toute interaction personnalisée.
- Respecter `prefers-reduced-motion` pour les animations ajoutées.

## 7. Vérifier avant de terminer

1. Relire tous les fichiers modifiés et le diff lorsqu'un VCS est disponible.
2. Confirmer qu'aucune feuille CSS autre que `styles.css` n'a changé et qu'aucun style inline n'a été ajouté.
3. Contrôler chaque grille touchée : conteneur > ligne > colonnes, sommes et empilement responsives cohérents, grilles imbriquées valides.
4. Contrôler les landmarks, l'unique `h1`, l'ordre des titres, les noms accessibles des sections, les `alt`, labels, liens et boutons.
5. Vérifier que chaque nouvelle classe et chaque propriété qu'elle déclare sont indispensables et qu'aucune classe Bootstrap ou classe projet existante ne peut les remplacer.
6. Vérifier les composants interactifs au clavier et aux largeurs mobile, tablette et desktop lorsque le rendu change.
7. Vérifier la console et l'absence de régression Bootstrap lorsque du JavaScript ou des attributs `data-*` changent.

Terminer seulement lorsque chaque point applicable est vérifié. Dans le compte rendu, lister les fichiers touchés, les validations effectuées et toute nouvelle classe spécifique avec sa justification.

Fichiers annexes

agents/openai.yaml

agents/openai.yaml

interface:
  display_name: "Celuga HTML + Bootstrap"
  short_description: "Intégration HTML5 et Bootstrap Celuga"
  default_prompt: "Utilise $celuga-html-bootstrap pour intégrer cette modification en HTML5 sémantique, avec Bootstrap en priorité et uniquement styles.css pour le CSS."

references/celuga-starter-v2.md

references/celuga-starter-v2.md

# Starter Standard Celuga v2 — observations TAE2026

Lire cette référence uniquement lorsque le projet utilise le starter Celuga v2 ou la combinaison de feuilles `bootstrap-reboot.css`, `bootstrap-grid.css` et `bootstrap-theme.css`.

## Empilement technique observé

- Bootstrap 4.5.2, réparti entre `bootstrap-reboot.css`, `bootstrap-grid.css`, `bootstrap-theme.css` et `bootstrap.bundle.min.js`.
- jQuery chargé avant le bundle Bootstrap.
- `styles.css` chargé après toutes les feuilles du starter : c'est l'unique emplacement des adaptations projet.
- API Bootstrap 4 dans le HTML : `data-toggle`, `data-target`, `data-dismiss`, `data-parent`.
- AOS et PureCounter présents dans TAE2026. Les réutiliser seulement s'ils existent déjà dans le projet concerné ; ce ne sont pas des dépendances obligatoires du skill.

## Grille Celuga observée

Ne pas remplacer ces valeurs par les valeurs Bootstrap standards sans demande explicite :

| Palier | Début | Conteneur observé |
|---|---:|---:|
| `sm` | 320 px | 540 px |
| `md` | 768 px | 720 px |
| `lg` | 992 px | 1 140 px |
| `xl` | 1 200 px pour les classes ; 1 366 px pour `.container-xl` | 1 440 px |

La grille utilise des gouttières de 15 px. Les classes `row-cols-*`, `order-*`, `offset-*`, affichage, flex, espacement et texte sont disponibles dans les feuilles du starter ; vérifier leur présence exacte avant usage.

## Conventions réutilisables observées

- Conteneur éditorial principal : `.container-xl`.
- Mise en page : `.row` avec `.col-*`, notamment `col-12`, `col-md-*`, `col-lg-*`, `order-*`.
- Accessibilité : `.sr-only`, `.sr-only-focusable`, lien d'évitement, `aria-labelledby`, labels de formulaires et boutons typés.
- Médias : `.img-fluid`, `.img-fit-cover-center`, `.img-fit-cover-left`, `.img-fit-cover-right`.
- Composants : `.btn` et ses variantes, navbar/collapse, modal, formulaires, `input-group`.
- Variables projet dans `styles.css` : couleurs `--primary`, `--secondary`, `--warning`, leurs variantes RVB, familles de polices, rayon et courbe d'animation.

Réutiliser ces conventions lorsqu'elles existent dans le projet courant. Ne pas les recopier automatiquement vers un autre starter.

## Leçons de maintenance tirées de TAE2026

- `styles.css` contient des sections par composant suivies d'une section responsive : placer les nouvelles règles avec leur propriétaire logique.
- Éviter d'ajouter en fin de fichier des couches nommées « correctif V… ». Fusionner la règle dans la définition ou la media query existante lorsque le périmètre le permet.
- Le starter surcharge déjà de nombreux composants Bootstrap. Lire la définition existante avant d'ajouter un sélecteur plus spécifique ou `!important`.
- Des interactions Bootstrap coexistent avec du JavaScript spécifique. Préserver Bootstrap pour collapse/modal/navbar et réserver le code spécifique aux comportements absents du framework.