• US bien structurées : La première US "Hello World" a été fluide. Les User Stories avec critères d'acceptation clairs facilitent grandement l'implémentation.
• Exemples visuels efficaces : Les captures d'écran de l'ancien site Bubble ont permis une compréhension rapide des attentes. Le remplacement des images par du vectoriel a été rapide.
• Efficacité de l'implémentation : Le composant "Témoignages" a été créé (JSON + page) en une seule itération avec seulement un petit ajustement d'alignement.
• Structure du projet : Site Bubble entièrement transféré en 3 jours avec tout le contenu sous forme JSON. CSM maison fonctionnel.
• Tests TDD productifs : Une fois lancés, les séances TDD ont été très productives et constructives.

• Responsive par défaut : Le comportement responsive est assez bon par défaut (contrairement à Bubble où c'était laborieux).
• Page Metrics : L'ajout de la page "Metrics" a été complètement bluffant.
• Choix autonome intelligent : Utilisation de l'icône "Réseau" pour "Plan du site" (visuellement adapté, mais surprise sur l'autonomie du choix).
• Correction de bugs : Efficace quand les symptômes sont clairs et les informations précises.

---

• Ajustements CSS longs et laborieux : Les ajustements CSS prennent beaucoup de temps avec de nombreux aller-retours. Difficile à cibler précisément sans voir le résultat en temps réel.

• Perte de prompts : Peur constante de perdre des prompts car ils ne sont pas toujours enregistrés en temps réel. Besoin de conserver la conversation pour le blog.
• Contraintes implicites : Certaines règles (DOD, conventions) n'étaient pas toujours évidentes au départ.
• Fichiers longs : Difficiles à modifier avec précision, surtout pour les ajustements CSS répétitifs.
• Communication visuelle limitée : Impossible de voir directement le résultat, d'où des aller-retours fréquents.

---

1. Non-respect systématique de la DOD ⚠️ CRITIQUE

• Journal de bord pas toujours rempli pour les US
• Codage parfois commencé avant validation complète des besoins
• DOD pas toujours respectée de manière systématique

1. Codage prématuré ⚠️ CRITIQUE

• Commencement du codage avant confirmation OK sur la demande
• Causant parfois de la reprise et de la frustration

1. Tests négligés ⚠️ CRITIQUE

• TDD mentionné régulièrement mais couverture de tests à 50% avant contrôle
• Tests pas une priorité dès le début malgré les rappels constants

1. Complexité inutile ⚠️ IMPORTANT

• Parfois des solutions trop complexes pour des demandes simples
• Longues minutes perdues sur des solutions élaborées alors qu'une solution simple suffisait

• Difficile d'interrompre : Quand l'IA se lance dans des modifications complexes, difficile d'interrompre car les fichiers sont déjà modifiés.
• Choix autonome inattendu : L'icône "Réseau" pour "Plan du site" était visuellement correct mais le choix a été fait sans consultation.

---

###### A1 : Respect systématique du journal de bord

• Difficulté pour l'IA : 🟢 FACILE
• Raison : C'est une action automatique qui peut être ajoutée comme étape finale de chaque US
• Implémentation : Ajouter systématiquement la mise à jour du journal en fin de traitement d'une US
• Rappel : Utiliser un système de checklist ou de todo

###### A2 : Validation avant codage

• Difficulté pour l'IA : 🟡 MOYENNE
• Raison : Nécessite de résister à l'impulsion de coder immédiatement et de poser des questions de clarification
• Implémentation : Toujours reformuler la demande, identifier les ambiguïtés, et demander validation avant de toucher au code
• Défi : L'IA a tendance à vouloir "aider" en faisant directement, mais doit apprendre à "attendre"

###### A3 : Tests dès le départ (TDD)

• Difficulté pour l'IA : 🟡 MOYENNE
• Raison : Nécessite un changement de mentalité : tests d'abord, code ensuite
• Implémentation : Quand TDD/BDD est mentionné, commencer systématiquement par écrire les tests, puis le code
• Défi : L'IA doit résister à l'envie de coder directement la fonctionnalité

###### A4 : Éviter la complexité inutile

• Difficulté pour l'IA : 🔴 COMPLEXE
• Raison : Difficile pour l'IA de juger si une solution est "trop complexe" sans connaître le contexte complet
• Implémentation : Quand une demande semble simple, proposer d'abord la solution la plus simple possible
• Défi : L'IA a tendance à vouloir gérer tous les cas possibles, même si non demandés

###### A5 : Améliorer les ajustements CSS

• Difficulté pour l'IA : 🔴 COMPLEXE
• Raison : Sans voir le résultat, difficile de comprendre précisément l'écart visuel
• Implémentation : Demander plus de précisions (screenshots, mesures, descriptions détaillées)
• Alternative : Suggérer d'utiliser les outils de développement du navigateur pour identifier précisément les styles

###### A6 : Sauvegarde des prompts

• Difficulté pour l'IA : 🟢 FACILE
• Raison : Action automatique, peut être ajoutée comme étape après chaque session importante
• Implémentation : Après chaque US ou session importante, proposer explicitement de mettre à jour le journal

###### A7 : Clarifier les choix autonomes

• Difficulté pour l'IA : 🟡 MOYENNE
• Raison : Nécessite de distinguer ce qui peut être choisi automatiquement vs ce qui nécessite validation
• Implémentation : Pour les choix de design/structure importants, proposer plusieurs options ou demander validation

###### A8 : Permettre l'interruption facile

• Difficulté pour l'IA : 🟡 MOYENNE
• Raison : L'IA doit apprendre à faire des modifications incrémentales plutôt que tout changer d'un coup
• Implémentation : Faire des changements par petits pas, avec pauses entre chaque étape pour permettre feedback

---

1. ✅ Respect systématique du journal de bord (A1)
2. ✅ Sauvegarde des prompts (A6)

1. ⚠️ Validation avant codage (A2)
2. ⚠️ Tests dès le départ - TDD (A3)
3. ⚠️ Clarifier les choix autonomes (A7)
4. ⚠️ Permettre l'interruption facile (A8)

1. ❌ Éviter la complexité inutile (A4)
2. ❌ Améliorer les ajustements CSS (A5)

---

• Architecture hexagonale :
• Utiliser une architecture hexagonale pour séparer la logique métier des détails techniques
• Appliquer les principes DDD (Domain-Driven Design) pour modéliser les règles métier
• Documenter les APIs pour Swagger

• Séparation Backend Pur / Backend Next.js :
• La logique métier réutilisable (parsing, calculs, transformations) doit être dans `utils/` ou `lib/` et être utilisable en ligne de commande
• Principe de séparation des préoccupations (Separation of Concerns) : Chaque module/composant a une seule responsabilité
• La logique métier (backend pur) est séparée de la logique de présentation (frontend) et de la génération HTML (backend Next.js)
• Les composants Next.js (`app/`, `components/`) ne contiennent que la logique spécifique à React/Next.js (génération HTML, navigation, interactivité)

• Architecture Next.js :
• Utilisation du App Router de Next.js (`app/`)
• Server Components par défaut, Client Components marqués avec `'use client'`
• Layout partagé pour Header et Footer sur toutes les pages
• Métadonnées SEO définies dans `layout.tsx` et extensibles par page

• Architecture unifiée pour parsing Markdown :
• Structure hiérarchique unifiée : Tous les fichiers Markdown doivent suivre la même hiérarchie h1 → h2 → h3 → h4 → h5
• h1 : Chapitre (dossier)
• h2 : Section (fichier MD)
• h3 : Partie (###)
• h4 : Sous-partie (####)
• h5 : Bloc (#####)
• Parser générique réutilisable : Un seul parseur Markdown (`parseMarkdown()`) pour tous les types de fichiers MD
• Structure JSON unifiée : Même structure `ParsedFolder` pour tous les types de fichiers (journaux, "A propos de ce site", etc.)
• Attributs spéciaux : Utiliser `typeDeContenu` (string) ou attributs booléens (`estPrompt`, `estResultatTechnique`, `estSpecial`) pour gérer les spécificités
• Enrichissement spécifique : Fonction d'enrichissement séparée pour les spécificités (ex: `enrichirPourJournaux()`) plutôt que parser spécialisé
• Avantages : DRY (Don't Repeat Yourself), cohérence, extensibilité, CSS uniforme

• TDD Obligatoire avec Ordre Strict :
• Appliquer les règles générales TDD définies dans [DOD - Équipe.md - TDD](DOD%20-%20Équipe.md#tdd-test-driven-development---priorité-absolue) (section "Qualité de code")
• Spécificité Back-End : Pour toute fonction backend pur (`utils/`), le cycle TDD DOIT être respecté dans l'ordre suivant :

1. RED : Écrire le test d'abord (le test échoue)
2. GREEN : Écrire le code minimal pour faire passer le test
3. REFACTOR : Refactoriser le code tout en maintenant les tests verts

• Interdiction absolue : Aucune fonction exportée dans `utils/` ne doit être créée sans son fichier de test correspondant créé en premier
• Vérification avant code : Avant d'écrire du code dans `utils/`, créer d'abord le fichier de test `tests/unit/[nomFonction].test.ts` avec au moins un test qui échoue
• Processus de vérification : Avant chaque commit, vérifier qu'aucun code backend pur n'a été ajouté sans tests correspondants créés en premier

• Progression TDD du Simple au Complexe :
• Les tests DOIVENT suivre une progression explicite du cas le plus simple au cas le plus complexe
• Chaque test ajoute une complexité minimale et fait émerger le code étape par étape, sans le complexifier inutilement dès la première implémentation
• Les tests ne doivent pas être de simples tests de "couverture de code" ou de "non-régression" écrits après coup, mais une suite de tests progressive qui fait émerger le code du simple au complexe
• Structure visible des tests : La progression TDD doit être visible sans ambiguïté en lisant les tests dans l'ordre
• Utiliser des commentaires explicites avec des itérations numérotées (ex: `ITÉRATION 1`, `ITÉRATION 2`, etc.)
• Chaque itération doit être clairement identifiée avec un commentaire expliquant ce qui est ajouté
• La structure des tests doit montrer la démarche TDD authentique : progression du simple au complexe, visible dans l'ordre de lecture
• Exemple de progression :
• ITÉRATION 1 : Le cas le plus simple (une seule fonctionnalité de base)
• ITÉRATION 2 : Ajouter une deuxième fonctionnalité simple
• ITÉRATION 3 : Ajouter une troisième fonctionnalité simple
• ITÉRATION 4 : Combiner plusieurs fonctionnalités
• ITÉRATION 5 : Ajouter des cas limites
• ITÉRATION 6 : Ajouter des cas d'erreur et robustesse

• Tests Unitaires Obligatoires :
• Appliquer les règles générales de tests définies dans [DOD - Équipe.md - Tests](DOD%20-%20Équipe.md#tests)
• Spécificité Back-End : Tests unitaires (TDD) obligatoires pour TOUTES les fonctions backend pur : Chaque fonction exportée dans `utils/` doit avoir des tests unitaires complets
• Mocking approprié des dépendances externes (`next/image`, `window`, `next/navigation`)
• Couverture de tests : Les fonctions backend pur doivent avoir une couverture de tests complète (cas normaux, cas limites, cas d'erreur)

• Tests de robustesse :
• Gérer les cas d'erreur de lecture fichier (`fs.existsSync()`, `fs.readdirSync()`)
• Gérer les fichiers JSON malformés
• Gérer les fichiers vides ou invalides
• Gérer les structures de dossiers inattendues
• Gérer les références à des ressources inexistantes
• Gérer les caractères spéciaux dans les chemins et URLs

• Validation des fichiers Markdown :
• Règles métier pour validation : Les fichiers MD doivent respecter des règles de validation strictes qui déclenchent des erreurs de compilation/publication si non respectées :
• Un fichier MD contenant au moins un titre H1 (`#`) ou H2 (`##`) doit déclencher une erreur de compilation/publication
• Un fichier MD contenant au moins un titre H4 (`####`) sans titre H3 (`###`) précédent doit déclencher une erreur de compilation/publication
• Les fichiers MD vides sont considérés comme inexistants (ignorés, pas d'erreur)
• Les fichiers dont l'extension n'est pas `.md` sont considérés comme inexistants (ignorés)
• Un dossier ne contenant aucun fichier MD valide n'est pas affiché
• Un dossier contenant un seul fichier MD valide doit déclencher une erreur de compilation/publication (minimum 2 sections requises)
• Validation des blocs de code : La validation doit ignorer les titres présents dans les blocs de code markdown lors de la détection des titres
• Classe d'erreur dédiée : Utiliser une classe `ValidationError` pour les erreurs de validation (distincte des erreurs techniques)
• Validation au build, pas au runtime : Les erreurs de validation doivent être détectées lors des tests et faire échouer le build, pas apparaître au runtime dans le navigateur
• Utiliser des tests d'intégration qui valident tous les fichiers MD réels du projet
• Les erreurs de validation doivent être lancées de manière synchrone dans les Server Components pour faire échouer le build
• Ne pas attraper les `ValidationError` dans les Server Components (ou les relancer explicitement) pour garantir l'échec du build

• Code Legacy Non Testé :
• Les fonctions créées avant cette règle doivent être couvertes par des tests dans le cadre d'un refactoring, mais jamais utilisées comme excuse pour créer du nouveau code sans tests
• Refactorisation du code non conforme : Si du code métier a été créé sans respecter le TDD (tests écrits après le code ou tests de couverture/non-régression), il doit être refactorisé en partant de zéro : supprimer le code existant, supprimer les tests existants, puis faire réémerger les tests puis le code en suivant strictement la progression TDD du simple au complexe
• Refactorisation des tests existants : Si les tests existants ne montrent pas clairement la progression TDD (pas de structure avec itérations numérotées, progression non visible), ils doivent être refactorisés pour montrer la démarche TDD authentique avec des commentaires explicites et une structure visible

• Processus de Développement Strict :
• Pour toute nouvelle fonctionnalité dans `utils/`, le fichier de test doit exister AVANT le fichier de code
• Si un fichier `utils/maFonction.ts` est créé, il DOIT exister un fichier `tests/unit/maFonction.test.ts` créé au préalable

• Tests BDD :
• Appliquer les règles générales BDD définies dans [DOD - Équipe.md - BDD](DOD%20-%20Équipe.md#bdd-behavior-driven-development) (section "Qualité de code")
• Spécificités Back-End :
• Tests BDD avec Cucumber.js pour les scénarios utilisateur
• Directive de langue obligatoire : Les fichiers `.feature` en français DOIVENT commencer par `# language: fr` en première ligne (OBLIGATOIRE pour que Cucumber reconnaisse les mots-clés français)
• Regroupement des scénarios : Les scénarios BDD peuvent être regroupés dans un seul fichier `.feature` si logique (ex: tous les scénarios de navigation dans `navigation.feature`)
• Vérification de cohérence : Lorsque le code évolue, veiller à vérifier la cohérence avec les BDD existants et mettre à jour les scénarios si nécessaire
• Les scénarios BDD doivent être validés avant le développement (voir DOD - Lead Dev)

• Écrire des tests unitaires et d'intégration :
• Écrire des tests unitaires et d'intégration pour chaque endpoint
• Valider les entrées/sorties des fonctions et des APIs
• Utiliser Node.js (ou un autre langage back-end) avec TypeScript pour une meilleure robustesse

• Protection des endpoints :
• Protéger les endpoints contre les injections SQL et les attaques XSS
• Chiffrer les données sensibles (ex: mots de passe, informations utilisateurs)

• Migrations :
• Utiliser des migrations pour gérer les changements de schéma
• Optimiser les requêtes SQL pour éviter les goulots d'étranglement

• Appliquer les bonnes pratiques TypeScript définies dans [DOD - Équipe.md - Outils et automatisation](DOD%20-%20Équipe.md#outils-et-automatisation) (section "Arbitrages techniques du projet")
• Spécificités Back-End :
• Les interfaces communes doivent être dans `types/`
• Les constantes (routes, couleurs, configuration) doivent être dans `constants/`
• Types stricts sans utilisation de `any` sauf cas justifiés (ex: mocks dans les tests)

• Appliquer les règles générales de structure définies dans [DOD - Équipe.md - Recherche dans le codebase](DOD%20-%20Équipe.md#recherche-dans-le-codebase) (section "Outils et automatisation")
• Spécificités Back-End :
• Structure de dossiers claire : `components/`, `types/`, `constants/`, `data/`, `app/`, `utils/`, `tests/`
• Les textes statiques doivent être extraits dans des fichiers JSON dans `data/`
• La configuration statique (images, constantes de configuration) doit être dans `constants/` (pas dans les composants)
• Routes centralisées dans `constants/routes.ts`

• Optimisation des Images :
• Utilisation de `next/image` pour l'optimisation des images

• Journal de bord :
• Documenter toutes les interactions entre le PO Humain et les agent IA dans le Journal de bord (`A propos de ce site/4. Journal de bord/YYYY-MM-DD.md`).
• Tenue en temps réel : Le journal DOIT être mis à jour immédiatement après chaque prompt, pas après coup. Dès qu'un prompt est validé, le fichier de journal du jour doit être modifié.
• À chaque prompt qui modifie le code ou la structure du projet :

1. Si le fichier journal du jour n'existe pas, le créer (format `YYYY-MM-DD.md` dans `A propos de ce site/4. Journal de bord/`)
2. Si un nouveau sujet est exploré, créer une nouvelle partie avec `### Titre du sujet` (H3)
3. Ajouter le prompt dans le journal avec :

• `#### Titre du prompt` (H4) - titre descriptif du prompt
• `##### Prompt` (H5) - le prompt exact de l'utilisateur (corriger fautes d'orthographe/syntaxe)
• `##### Résultat technique` (H5) - résumé technique de la réponse apportée
• Règle de validation importante : Les fichiers journal doivent respecter les règles de validation des fichiers MD :
• Aucun titre H1 (#) ou H2 (##) ne doit être présent dans le fichier
• Les fichiers doivent commencer au niveau 3 (###)
• Si un exemple de format contient des titres H1/H2, il doit être mis dans un bloc de code markdown pour être ignoré par le parser
• Cette règle est validée lors des tests et doit faire échouer le build si non respectée

• Critères pour l'ajout au journal :
• Prompt qui modifie le code → OUI (ajouter au journal)
• Prompt théorique/formation → NON (créer un cours dans `5. Cours/`)
• Prompt de diagnostic/question → OUI (ajouter au journal)
• Prompt de publication Git → NON (est disponible par git si nécessaire)

• Fichiers d'arbitrage :
• Lorsque l'utilisateur pose une question de fond sur l'architecture, un arbitrage à faire, ou une stratégie à adopter en mode "agent", l'inviter à passer en mode "question" :
• Lorsque l'utilisateur le fait en mode "question"

1. Si c'est un cours (ex: "Compare moi XML et JSON") créer un fichier dans le dossier `A propos de ce site/5. cours/`
2. Sinon, pour les questions d'architecture et d'arbitrage, créer un fichier dans le dossier `A propos de ce site/6. Questions et arbitrages/`
3. Nom du fichier : Utiliser un nom descriptif en minuscules avec des espaces (pas de majuscules, pas d'underscores)
4. Format : `Titre descriptif.md` (ex: "Analyse architecture unifiée.md")
5. Le fichier toit commencer par un rappel du prompt.
6. Inclure la question de l'utilisateur, la réponse/analyse/arbitrage proposé, respecter la structure Markdown (titres maximum H3 - ###)
7. Règle de validation : Les fichiers d'arbitrage doivent aussi respecter les règles de validation des fichiers MD (pas de H1/H2, commencer au niveau H3)

• Identification du Sprint en cours :
• Les User Stories sont organisées dans le dossier `A propos de ce site/2. Sprints/` avec un fichier MD par Sprint.
• Le Sprint en cours est le dernier fichier créé dans `A propos de ce site/2. Sprints/`
• Vérifier la date de modification pour identifier le dernier fichier
• Aider à rédiger le nouveau Sprint Goal pour nommer le fichier
• Le format est : `YYYY-MM-DD - Sprint Goal.md`

• Écriture des User Stories :
• Toutes les nouvelles User Stories doivent être écrites dans le fichier du Sprint en cours
• Respecter le format existant : `#### US-X.Y : Titre` avec les sections "En tant que", "Je souhaite", "Afin de", "Critères d'acceptation"

• Structure des Critères d'acceptation :
• La section "Critères d'acceptation" commence par la ligne `- Critères d'acceptation :`
• Si une ligne commence par `- ` (avec `` au début) : c'est un "Thème de critère" (puce de niveau 1, texte en gras)
• Si une ligne commence par `- ` (sans `**` au début) : c'est un "Critère" (puce de niveau 2, texte normal, indenté sous le thème précédent)

• Rester focus sur le Sprint en cours :
• Rester concentré sur l'objectif du Sprint en cours
• Ne pas se détourner vers d'autres sujets non liés au Sprint en cours
• Détection de dérive : Si l'utilisateur dérive vers d'autres sujets non liés au Sprint en cours, l'alerter poliment pour maintenir le focus
• Comportement :
• Si l'utilisateur est focus : continuer à écrire les US dans le Sprint en cours
• Si l'utilisateur n'est pas focus : alerter pour signaler la dérive
• Si l'utilisateur décide de clore le Sprint et d'en démarrer un nouveau

• BDD (Behavior-Driven Development) :
• Pour toute demande fonctionnelle/métier :

1. Reformuler la demande en User Story (format : "En tant que [rôle], je veux [action] afin de [bénéfice]")
2. Identifier le problème métier réel à résoudre
3. Valider la User Story avec l'utilisateur avant de continuer
4. Une fois la User Story validée, créer le plan de test (BDD métier en format Gherkin français, ou tests E2E selon le besoin)
5. Pour BDD métier : Scénarios avec Given/When/Then (format Gherkin en français)
6. Valider le plan de test avec l'utilisateur avant de continuer

• Les scénarios Gherkin expriment les intentions métier et sont lisibles par les non-développeurs
• Accent fort sur l'expression du métier : Le code doit exprimer l'intention métier de manière explicite
• Les intentions doivent être "dans le code source" pour faciliter la compréhension et la maintenance

• Clean Code :
• Respecter les principes SOLID
• Éviter la duplication
• Utiliser des noms explicites et en français pour le domaine métier
• Code documenté avec commentaires pour les logiques complexes
• Ne pas ajouter dans les commentaires des contraintes décrites dans la DOD
• Documentation pédagogique : Les commentaires dans le code doivent expliquer surtout le "pourquoi" et pas seulement le "comment"
• Composants purs et simples avec responsabilités uniques (Single Responsibility Principle)
• Pas de code mort : suppression des composants et fichiers inutilisés

• TDD (Test-Driven Development) - PRIORITÉ ABSOLUE :
• Règle stricte : TESTS D'ABORD, CODE ENSUITE
• Objectif du TDD : Le TDD n'est pas une métrique de couverture, mais une discipline de développement qui vise à faire émerger le code le plus simple possible.
• Outils d'enforcement (optionnels mais recommandés) :
• TDD Guard (https://github.com/nizos/tdd-guard) : Outil open source qui empêche de commencer à coder avant d'avoir un test qui échoue et d'implémenter plus que ce que le test exige
• TDD.sh (https://tdd.sh/) : Outil CLI open source pour pratiquer le TDD selon Kent Beck (red → green → refactor) avec timers pour limiter le temps en phase "red"
• Suivre strictement le cycle RED → GREEN → REFACTOR - UN TEST À LA FOIS :
• RED : Écrire un seul test qui échoue (le plus simple possible)
• GREEN : Écrire le code minimal pour faire passer ce test (pas plus)
• REFACTOR : Améliorer le code en gardant les tests verts (nommage métier/DDD, lisibilité)
• PUIS SEULEMENT : Passer au test suivant
• Règles strictes d'implémentation :
• One test at a time (un test à la fois) : Ne jamais écrire plusieurs tests en même temps, se concentrer sur un seul comportement à la fois
• Smallest possible test first (commencer par le cas le plus simple) : Toujours commencer par le cas le plus simple possible, progresser incrémentalement
• Minimal code (code minimal pour faire passer le test) : Écrire juste assez de code pour faire passer le test, principe YAGNI
• Refactor after each green (refactoriser après chaque test vert) : Toujours refactoriser après chaque test vert avant de passer au suivant
• Couverture de code à 90% :
• La couverture doit être maintenue à 90% minimum sur tous les critères (lignes, statements, functions, branches)
• Chaque nouveau code doit avoir ses tests unitaires AVANT d'être validé
• Si la couverture descend en dessous de 90%, corriger immédiatement
• Exécuter `npm test -- --coverage` régulièrement pour vérifier la couverture

• Validation de la demande :
• Règle absolue : NE JAMAIS CODER AVANT VALIDATION COMPLÈTE
• Reformuler la demande :
• Reformuler clairement ce que l'utilisateur demande
• Identifier les ambiguïtés ou les points non clairs
• Demander validation explicite avant de continuer
• Distinguer demande fonctionnelle vs technique :
• Demande fonctionnelle/métier → Suivre le processus complet User Story → Plan de test → Technique → Code
• Demande purement technique (syntaxe, erreur évidente) → Peut passer directement au code
• Éviter la complexité inutile :
• Quand une demande semble simple, proposer d'abord la solution la plus simple possible
• Quand une demande semble complexe explorer d'autres stratégies avant de chercher à résoudre : reformuler, découper...
• Ne pas gérer tous les cas possibles s'ils ne sont pas demandés
• Si la demande est ambiguë, demander clarification avant de proposer une solution

• Approche technique (pour demandes fonctionnelles) :
• Processus obligatoire :

1. Expliquer comment je compte m'y prendre techniquement
2. Lister les tâches techniques que je vais réaliser
3. Discuter avec l'utilisateur de l'approche avant de coder

• Choix autonomes importants :
• Pour les choix de design/structure importants :
• Proposer plusieurs options ou demander validation explicite
• Ne pas faire de choix autonomes sur des éléments critiques (icônes, structure, architecture)

• Linters :
• Après chaque modification de code :
• Lancer `read_lints` sur les fichiers modifiés
• Corriger automatiquement les erreurs de linting si évidentes
• Signaler les erreurs non évidentes à l'utilisateur

• Build :
• Après modifications importantes :
• Lancer `npm run build` pour vérifier que le projet compile
• Si erreur de build, corriger avant de publier
• Ne pas publier si le build échoue

• Tests :
• Après chaque modification :
• Lancer les tests pertinents (pas tous les tests à chaque modification)
• Vérifier que tous les tests passent
• Vérifier la couverture de code

• Collecte des métriques :
• Lors de chaque build, lancer automatiquement `npm run metrics:collect` pour collecter les métriques
• Les métriques doivent être collectées et stockées dans `public/metrics/`
• L'historique des métriques doit être maintenu pour suivre l'évolution

• Communication en français :
• Toutes les communications avec l'utilisateur :

1. Toujours en français
2. Explications pédagogiques pour les concepts techniques
3. Citations de code avec le format `startLine:endLine:filepath`

• Gestion des erreurs :
• En cas d'erreur :

1. Identifier d'abord le problème métier/fonctionnel avant de proposer une solution technique
2. Analyser l'erreur complètement avant de proposer une solution
3. Ne pas faire de corrections multiples en parallèle sans comprendre la cause
4. Proposer une solution simple avant une solution complexe
5. Si plusieurs tentatives échouent, proposer de repartir de zéro avec User Story → Plan de test → TDD

• Amélioration des ajustements CSS :
• Pour éviter les aller-retours longs sur les ajustements CSS :

1. Demander plus de précisions (screenshots, mesures, descriptions détaillées)
2. Suggérer d'utiliser les outils de développement du navigateur pour identifier précisément les styles
3. Faire des modifications incrémentales avec pauses pour feedback (sans forcément relancer les tests et/ou publier à chaque fois)

• Arbitrages techniques du projet :
• IDE : Cursor
• Langage : TypeScript
• Frontend : Next.js
• Gestion du code : GitHub
• TDD : Jest
• BDD : Cucumber.js
• Hébergement : Vercel

• Git :
• Utiliser GitHub pour gérer l'historique du code
• Historique clair : Les commits doivent avoir des messages descriptifs et suivre une logique cohérente
• Après chaque modification validée :

1. `git add -A` pour ajouter tous les changements
2. `git commit -m "Message descriptif"` avec un message clair
3. `git push` pour publier sur GitHub

• Exception : Si l'utilisateur demande explicitement de ne pas publier, ne pas le faire

• CI/CD - Principes non négociables :
• Le code doit être versionné, testé et déployable
• Déploiement rapide dans un environnement accessible à des utilisateurs réels (testeurs, amis, tiers)
• Itérations courtes et feedback rapide
• Les tests doivent passer avant chaque déploiement
• Le build doit être vérifié avant publication (voir section "Build")

• Recherche dans le codebase :
• Avant de modifier du code :

1. Utiliser `codebase_search` pour comprendre le contexte
2. Lire les fichiers pertinents avec `read_file`
3. Vérifier les tests existants avec `grep` ou `read_file`
4. Comprendre l'architecture avant de modifier

• Création de todos pour tâches complexes :
• Pour les tâches avec 3+ étapes distinctes :

1. Créer une liste de todos avec `todo_write`
2. Marquer les todos comme `in_progress` / `completed` au fur et à mesure

• Ne pas créer de todos pour les tâches triviales (< 3 étapes)

• Vérification des dépendances :
• Avant d'ajouter une nouvelle dépendance :

1. Vérifier si une solution native existe
2. Vérifier la compatibilité avec les versions actuelles
3. Proposer l'ajout dans `package.json` avec justification

• Création de fichiers de documentation :
• Ne pas créer de fichiers `.md` de documentation sauf demande explicite

• Modification de fichiers non demandés :
• Ne modifier que les fichiers explicitement mentionnés ou nécessaires pour la tâche

• Exécution de tous les tests :
• Ne pas lancer tous les tests à chaque modification, seulement les tests pertinents

• Refactorisation sans demande :
• Boy Scoot : quand on repasse sur du code qui ne respecte pas la DOD on ne repart pas sans nettoyer en passant

• Règle : Pour permettre l'interruption facile :
• Faire des changements par petits pas
• Avec pauses entre chaque étape pour permettre feedback
• Ne pas tout modifier d'un coup

---

• Framework et Structure :
• Utiliser React (ou Vue/Svelte) avec TypeScript
• Structurer le code avec Atomic Design (atoms, molecules, organisms)
• Chaque section doit être un composant React fonctionnel dans le dossier `components/`
• Composants purs et simples avec responsabilités uniques (Single Responsibility Principle)
• Tous les composants doivent avoir des types TypeScript définis

• Validation avant implémentation :
• Pour les nouveaux composants ou types de contenu : Décrire la mise en page prévue et la faire valider par l'utilisateur avant de commencer l'implémentation
• Cela évite les aller-retours et garantit que l'approche est correcte avant le développement

• Garantir un design 100% responsive :
• Design mobile-first
• Proportions calculées en pourcentages pour le responsive (ex: `8.75vh`)
• Approche CSS mobile-first obligatoire : Tous les fichiers CSS doivent suivre l'approche mobile-first :
• Styles de base définis pour mobile (≤768px)
• Media queries `min-width: 769px` pour override sur desktop
• Éviter les media queries `max-width` redondantes
• Logique claire : "Mobile par défaut, desktop si ≥769px"

• CSS Modules :
• Utilisation de CSS Modules avec un fichier CSS par composant
• Couleurs définies comme variables CSS (`--BleuFonce`, `--BleuClair`, etc.) dans `globals.css` pour utilisation globale
• Toutes les couleurs de la charte graphique doivent être définies comme constantes CSS dans `globals.css`
• Styles partagés dans `shared.module.css` pour éviter la duplication
• CSS Modules pour l'isolation des styles par composant

• Hiérarchie HTML respectée :
• Les styles doivent être basés sur la hiérarchie HTML (h1, h2, h3, h4, h5, h6) et non sur le contenu sémantique
• Cela garantit l'uniformité de la mise en page et permet le mode lecture des navigateurs ainsi que le bon référencement SEO
• Structure hiérarchique unifiée : Tous les fichiers Markdown doivent suivre la même hiérarchie h1 → h2 → h3 → h4 → h5
• Hiérarchie dans les pages : Les pages doivent respecter la hiérarchie HTML (H1 pour titre de page, H2 pour sections principales, H3 pour sous-sections, etc.)
• CSS uniforme : Un seul fichier CSS pour tous les types de fichiers MD, styles basés sur h1/h2/h3/h4/h5
• Styles spéciaux via attributs : Utiliser des attributs de données (`[data-type-contenu="Prompt"]`) ou classes conditionnelles plutôt que classes basées sur le contenu sémantique
• Exemple : Utiliser `h4` pour "Prompt" et "Résultat technique" plutôt que des classes `.prompt` et `.technicalResult`
• Règle importante : Les styles basés sur le contenu (ex: `.prompt`, `.technicalResult`) rendent la maintenance difficile et doivent être évités - utiliser la hiérarchie HTML pour tous les styles

• Unification des styles :
• Éviter la duplication des styles pour les mêmes niveaux hiérarchiques (ex: plusieurs styles H2 dans différents fichiers)
• Créer une feuille de style globale pour la hiérarchie des titres (h1, h2, h3, h4, h5, h6)
• Styles contextuels via conteneurs plutôt que classes sémantiques (ex: `.prompt-container` avec styles basés sur hiérarchie HTML interne)

• Attributs d'accessibilité :
• Attributs `aria-label` pour tous les éléments interactifs
• Support de la navigation au clavier (`tabIndex`, `onKeyDown`)
• Attribut `role` approprié pour les éléments cliquables
• Texte alternatif descriptif pour toutes les images

• Validation WCAG :
• Viser un score Lighthouse > 90 (performance, accessibilité, SEO)

• Navigation interne :
• Navigation avec `next/navigation useRouter` pour les liens internes
• Ouverture des liens externes avec `window.open` et sécurisation (`noopener`, `noreferrer`)
• Commandes de navigation mappées dans `COMMAND_TO_ROUTE`
• Gestion cohérente des clics sur logo et photo dans Header

• Appliquer les règles générales de tests définies dans [DOD - Équipe.md - Tests](DOD%20-%20Équipe.md#tests) (section "Vérifications et qualité")
• Spécificités Front-End :
• Écrire des tests unitaires (Jest) pour chaque composant
• Tests unitaires (TDD) pour les composants critiques
• Automatiser les tests d'intégration avec Cypress

• Optimisation :
• Optimiser les images et assets (WebP, lazy loading)
• Minimiser le bundle JavaScript (Webpack, Vite)
• Viser un score Lighthouse > 90 (performance, accessibilité, SEO)

• Icônes vectorielles :
• Utiliser `lucide-react` pour les icônes : Bibliothèque légère (~100KB toutes icônes, ~5-10KB avec tree-shaking), moderne, optimisée pour React
• Avantages des SVG vectoriels : Redimensionnement parfait, transparence native, taille réduite, couleur modifiable via CSS
• Éviter les images raster pour les icônes : Les images JPEG/PNG pour les icônes sont moins optimales (pas de redimensionnement optimal, pas de transparence parfaite, taille plus importante)
• Utilisation : Importer uniquement les icônes nécessaires pour bénéficier du tree-shaking optimal

• Séparation des préoccupations :
• Stocker le contenu dans des fichiers XML ou JSON
• Garder le design (CSS, composants) indépendant du contenu
• Les textes statiques doivent être extraits dans des fichiers JSON dans `data/`
• La configuration statique (images, constantes de configuration) doit être dans `constants/` (pas dans les composants)

• Structure unifiée pour fichiers Markdown :
• Utiliser la même structure JSON unifiée (`ParsedFolder`) pour tous les types de fichiers MD
• Hiérarchie complète : Chapitre (h1) → Section (h2) → Partie (h3) → Sous-partie (h4) → Bloc (h5)
• Gérer les spécificités via attributs (`typeDeContenu`, `estPrompt`, `estResultatTechnique`, `estSpecial`) plutôt que structures différentes
• Composants React réutilisables pour chaque niveau hiérarchique

• Appliquer les règles générales de structure définies dans [DOD - Équipe.md - Outils et automatisation](DOD%20-%20Équipe.md#outils-et-automatisation)
• Spécificités Front-End :
• Header et Footer factorisés dans le layout pour être partagés par toutes les pages
• Structure de dossiers claire : `components/`, `types/`, `constants/`, `data/`, `app/`, `utils/`, `tests/`
• Images stockées dans `public/images/` et référencées avec des chemins absolus
• Routes centralisées dans `constants/routes.ts`

• Appliquer les bonnes pratiques TypeScript définies dans [DOD - Équipe.md - Outils et automatisation](DOD%20-%20Équipe.md#outils-et-automatisation) (section "Arbitrages techniques du projet")
• Spécificités Front-End :
• Tous les composants doivent avoir des types TypeScript définis
• Les interfaces communes doivent être dans `types/`
• Les constantes (routes, couleurs, configuration) doivent être dans `constants/`
• Configuration des composants (images, dimensions, etc.) séparée des composants eux-mêmes dans `constants/`

• Appliquer les règles générales de Clean Code définies dans [DOD - Équipe.md - Clean Code](DOD%20-%20Équipe.md#clean-code) (section "Qualité de code")
• Spécificités Front-End :
• Pas de duplication : factorisation des styles et logique commune

• Erreurs d'hydratation :
• Utiliser `suppressHydrationWarning` sur l'élément `<html>` si nécessaire pour éviter les erreurs d'hydratation causées par des extensions de navigateur ou des différences serveur/client
• Identifier la cause réelle de l'erreur avant d'appliquer `suppressHydrationWarning` (ne pas masquer les vrais problèmes)
• Extensions de navigateur : Les attributs ajoutés par les extensions (ex: `js-focus-visible`, `data-js-focus-visible`, `preflight-installed`) peuvent causer des erreurs d'hydratation - `suppressHydrationWarning` sur `<html>` est la solution recommandée par Next.js pour ce cas

• Erreurs de validation au build vs runtime :
• Comportement Next.js : Next.js peut continuer le build même si une erreur de pré-rendu survient et reporter l'erreur au runtime (navigateur)
• Différence avec compilation traditionnelle : Contrairement à une compilation classique (ex: 4D), Next.js peut rendre une page dynamiquement si le pré-rendu échoue
• Forcer l'échec du build : Pour garantir que les erreurs de validation font échouer le build :
• S'assurer que les erreurs de validation sont lancées de manière synchrone
• Ne pas attraper les erreurs de validation dans les Server Components (ou les relancer explicitement)
• Configurer Next.js pour être strict sur les erreurs de pré-rendu si nécessaire
• Validation côté serveur : Les erreurs de validation doivent être détectées et lancées côté serveur avant l'envoi au navigateur

• SEO et rendu Server Components :
• Priorité Server Components pour le SEO : Utiliser des Server Components par défaut pour générer le HTML complet côté serveur
• Architecture hybride recommandée (Solution 3) : Server Component pour le rendu initial (SEO optimal) + Client Component pour les interactions (accordéon, navigation)
• Raison pédagogique d'architecture : Le backend pur génère toujours du JSON (séparation des préoccupations)
• Backend Next.js : Prépare le travail au lieu du client, génère HTML complet pour SEO
• Client Component : Reçoit les données via props (pas de fetch), gère les interactions
• Avantages : SEO optimal, performance, pas d'erreur d'hydratation, interactions conservées
• Éviter `fetch()` dans les Client Components pour le contenu principal : Le contenu principal doit être rendu côté serveur pour être visible par les crawlers
• Exemple d'architecture :
• Server Component (`app/page.tsx`) : Appelle la fonction backend pur, génère le HTML complet
• Client Component (`components/InteractiveContent.tsx`) : Reçoit les données via props, gère les interactions
• API Route (`app/api/route.ts`) : Conservée pour debug/tests uniquement

• Appliquer les règles générales sur les choix autonomes définies dans [DOD - Équipe.md - Choix autonomes importants](DOD%20-%20Équipe.md#choix-autonomes-importants) (section "Processus de développement")
• Spécificités Lead Dev :
• Valider les choix architecturaux avec l'équipe avant implémentation

• Attendre un "GO BDD" :
• Attendre que les scénarios Gherkin soient validés par le PO/métier avant de commencer le développement
• Les scénarios BDD doivent être en format Gherkin en français avec Given/When/Then
• Bloquer toute tâche si les critères d'acceptation ne sont pas clairs ou validés

• Attendre un "GO TDD" :
• Attendre que les tests unitaires et d'intégration soient validés avant de considérer une feature comme terminée
• Vérifier que la couverture de test est à 90% minimum (sauf exception justifiée)
• Bloquer toute livraison si les tests ne sont pas à 90% minimum de couverture

• Ordre strict : Back-End → Front-End → UX/UI
• Back-End : Les tâches de back-end doivent être terminées et validées avant de commencer le front-end
• Front-End : Les tâches de front-end doivent être terminées et validées avant de commencer l'UX/UI
• UX/UI : Ne commencer que si le front-end est fonctionnel et validé
• Justification : Éviter les dépendances et tirer parti de la rapidité de l'IA pour livrer des incréments complets

• Distribution des tâches :
• Découper chaque US en tâches techniques (ex: back-end, front-end, UX/UI) et les attribuer aux agents spécialisés
• Distribuer les tâches aux agents experts de leur domaine à qui le lead dev va distribuer les tâches

• Vérification de la DoD spécifique :
• Vérifier que chaque tâche respecte :
• La DoD spécifique du profil (ex: architecture hexagonale pour le back-end, responsive pour le front-end)
• Les principes de clean code (SOLID, pas de duplication, noms explicites)
• Les tests (TDD/BDD) avec une couverture de code à 90% minimum (sauf exception justifiée)
• Corriger directement les écarts mineurs (ex: typographie, structure)
• Retourner les tâches non conformes aux agents avec des commentaires précis

• Vérification des principes TDD/BDD et clean code :
• Appliquer les règles générales TDD définies dans [DOD - Équipe.md - TDD](DOD%20-%20Équipe.md#tdd-test-driven-development---priorité-absolue) (section "Qualité de code")
• Appliquer les règles générales BDD définies dans [DOD - Équipe.md - BDD](DOD%20-%20Équipe.md#bdd-behavior-driven-development) (section "Qualité de code")
• Appliquer les règles générales Clean Code définies dans [DOD - Équipe.md - Clean Code](DOD%20-%20Équipe.md#clean-code) (section "Qualité de code")
• Spécificités Lead Dev :
• Vérifier que le cycle RED → GREEN → REFACTOR a été respecté
• Vérifier que les tests ont été écrits avant le code (TDD strict)
• Vérifier que les scénarios BDD validés ont été respectés
• Vérifier la cohérence avec les BDD existants : Lorsque le code évolue, vérifier que les scénarios BDD existants sont toujours cohérents avec le code et les mettre à jour si nécessaire
• Bloquer les merges si la couverture de test est < 90%

• Vérification finale :
• Avant la livraison d'une US :
• Vérifier que toutes les tâches (back-end, front-end, UX/UI) sont terminées et validées
• Confirmer que la couverture de test est à 90% minimum (outils : Jest, Cypress, SonarQube)
• Valider que le code est mergeable sans conflit (via GitHub/GitLab)

• Appliquer les règles générales de journal de bord définies dans [DOD - Équipe.md - Journal de bord](DOD%20-%20Équipe.md#journal-de-bord)
• Spécificités Lead Dev :
• Documenter toutes les décisions techniques et les compromis (ex: "Couverture à 95% acceptée pour X raison")

• Alertes :
• Signaler immédiatement tout blocage ou risque de retard
• Documenter les décisions techniques et les compromis

• Gestion de projet : GitHub Projects, Jira, ou Trello pour suivre l'avancement des tâches
• Revue de code : GitHub Pull Requests avec checks automatiques (CI/CD)
• Tests : Jest (unitaires), Cypress (intégration), SonarQube (qualité/couverture)
• Documentation : Markdown (pour les décisions) + Figma (pour les maquettes UX/UI)

• CI/CD :
• Intégrer les tests et le déploiement dans un pipeline automatisé
• Vérifier que tous les tests passent avant le déploiement
• Déploiement automatique sur Vercel après validation des tests
• Monitoring des erreurs de déploiement pour calculer le "Failed deployment recovery time"

• Gestion des erreurs de build Next.js :
• Comportement Next.js : Next.js peut continuer le build même si une erreur de pré-rendu survient et reporter l'erreur au runtime
• Différence avec compilation traditionnelle : Contrairement à une compilation classique, Next.js peut rendre une page dynamiquement si le pré-rendu échoue
• Forcer l'échec du build : S'assurer que les erreurs de validation font échouer le build :
• Erreurs lancées de manière synchrone
• Erreurs non attrapées dans les Server Components (ou relancées explicitement)
• Configuration Next.js stricte sur les erreurs de pré-rendu si nécessaire
• Validation : Vérifier que les erreurs de validation sont bien détectées au build et non reportées au runtime uniquement

• Maquettes avant développement :
• Toujours commencer par des maquettes (Figma/Adobe XD) avant le développement
• Documenter les user flows pour les parcours clés (ex: inscription, paiement)
• Valider l'accessibilité (WCAG 2.1 AA) : contrastes, navigation clavier, ARIA labels

• Choix de design :
• Appliquer les règles générales sur les choix autonomes définies dans [DOD - Équipe.md - Choix autonomes importants](DOD%20-%20Équipe.md#choix-autonomes-importants)

• Tests utilisateurs :
• Organiser des tests utilisateurs (5 utilisateurs minimum) avant la finalisation
• Itérer sur les maquettes en fonction des retours

• Fournir aux développeurs Front-End :
• Les maquettes annotées
• Les assets (icônes, images) optimisés
• Les spécifications de design (couleurs, polices, espacements)

• Documentation des choix :
• Expliquer les choix de design (ex: pourquoi ce parcours utilisateur ?)
• Archiver les versions des maquettes pour suivre l'évolution

• Appliquer les règles générales d'accessibilité définies dans [DOD - Équipe.md - Vérifications et qualité](DOD%20-%20Équipe.md#vérifications-et-qualité) (section "Vérifications et qualité")
• Spécificités UI/UX :
• Valider l'accessibilité (WCAG 2.1 AA) : contrastes, navigation clavier, ARIA labels
• Viser un score Lighthouse > 90 (performance, accessibilité, SEO)

• Appliquer les règles générales de design responsive définies dans [DOD - Équipe.md - Outils et automatisation](DOD%20-%20Équipe.md#outils-et-automatisation) (section "Arbitrages techniques du projet")
• Spécificités UI/UX :
• Garantir un design 100% responsive (mobile-first)
• Proportions calculées en pourcentages pour le responsive (ex: `8.75vh`)

• Appliquer les règles générales de performance définies dans [DOD - Équipe.md - Vérifications et qualité](DOD%20-%20Équipe.md#vérifications-et-qualité)
• Spécificités UI/UX :
• Optimiser les images et assets (WebP, lazy loading)
• Viser un score Lighthouse > 90 (performance, accessibilité, SEO)

• Cohérence des titres principaux (H1 et H2) :
• H1 : `font-family: var(--font-sans)` (police Oswald), `font-weight: 700` (gras)
• H2 : `font-family: var(--font-sans)` (police Oswald), `font-weight: 700` (gras)
• Ces règles sont définies globalement dans `app/globals.css` mais peuvent être surchargées localement si nécessaire
• Objectif : Garantir une identité visuelle cohérente sur tout le site avec des titres impactants

• Hiérarchie typographique :
• H1 : `font-family: var(--font-sans)`, `font-weight: 700`
• H2 : `font-family: var(--font-sans)`, `font-weight: 700`
• H3 : `font-family: var(--font-sans)`, `font-weight: 600`
• H4 : `font-family: var(--font-sans)`, `font-weight: 600`
• H5 : `font-family: var(--font-sans)`, `font-weight: 500`
• H6 : `font-family: var(--font-sans)`, `font-weight: 500`
• Corps de texte : `font-family: var(--font-serif)` (police Noto Serif)

• Règle : Pour garantir une lisibilité optimale sur grands écrans, tous les conteneurs de contenu (texte, images, composants) doivent respecter une largeur maximale définie par la constante CSS `--largeurDeTexteMax: 1250px`.

• Application :
• ✅ Appliquer à : Conteneurs de contenu, blocs de texte, grilles de composants, sections de page, vidéos, témoignages, portfolios
• ❌ Ne PAS appliquer à : Titres principaux (H1, H2), header, footer, éléments full-width par design (background, hero sections)

• Implémentation :

```css .monComposant { max-width: var(--largeurDeTexteMax); margin: 0 auto; /* Centrage obligatoire */ } ```

• Justification :
• Améliore la lisibilité sur grands écrans (évite les lignes de texte trop longues)
• Maintient une cohérence visuelle sur tout le site
• Facilite la maintenance (valeur centralisée dans `app/globals.css`)
• Reste 100% responsive sur petits écrans (max-width n'affecte pas le mobile)

• Composants concernés :
• `DomaineDeCompetence`, `Temoignage`, `PortfolioDetournements`, `Video`, `TexteLarge`, `CallToAction`, `GroupeBoutons`, `MetricsPage`
• Tous les nouveaux composants de contenu doivent suivre cette règle

• Règle : Le header doit toujours rester au-dessus du contenu qui scroll pour garantir que la navigation reste accessible.

• Implémentation :
• Le header doit avoir `z-index: 1000` minimum
• Le header doit avoir un arrière-plan opaque (pas de transparence)
• Le contenu de la page ne doit pas avoir de `z-index` supérieur au header
• Le footer doit avoir un `z-index` similaire si fixe en bas

• Exemple de code :

```css .header { position: fixed; z-index: 1000; background-color: var(--BleuFonce); } ```

• Justification :
• Assure que la navigation reste accessible pendant le scroll
• Évite que le contenu ne masque le header (problème de superposition)
• Maintient une hiérarchie visuelle claire
• Améliore l'expérience utilisateur (header toujours visible)

• Choix des icônes :
• Recommandation : `lucide-react` : Bibliothèque d'icônes vectorielles SVG légère, moderne et optimisée pour React
• Avantages : Redimensionnement parfait, transparence native, taille réduite, couleur modifiable via CSS, style cohérent
• Éviter les images raster pour les icônes : Les images JPEG/PNG sont moins optimales pour les icônes
• Fournir aux développeurs : Spécifier les icônes à utiliser dans les maquettes annotées (nom de l'icône lucide-react)

• Markdown dans toutes les zones de texte :
• Règle : Tous les champs de texte (titres, descriptions, contenus) doivent supporter le format markdown pour le gras : `texte en gras`
• Implémentation : Utiliser une fonction de parsing qui transforme `texte` en `<strong>texte</strong>`
• Application universelle : Cette règle s'applique à TOUS les types de contenu (DomaineDeCompetence, Temoignage, TexteLarge, etc.)

• Citations avec auteur :
• Format dans les données : `"Citation texte\n*Nom de l'auteur*"`
• Règles de parsing :
• Avant `\n*` : la citation (texte normal)
• Entre `*...*` après le retour à la ligne : l'auteur (en italique)
• Affichage :
• La citation s'affiche normalement (avec support du gras `texte`)
• L'auteur s'affiche sur une nouvelle ligne, en italique, aligné à droite
• Exemple de rendu :

``` « Lorsque les gens sont financièrement investis, ils veulent un retour. Lorsque les gens sont émotionnellement investis, ils veulent contribuer. » Simon Sinek ```

• Implémentation CSS :

```css .citationAuthor { display: block; font-style: italic; text-align: right; margin-top: 0.5rem; margin-bottom: 1rem; } ```

• Cas avec texte après la citation : Si du texte suit la citation (séparé par `\n\n`), il doit s'afficher normalement après l'auteur

• Justification :
• Permet d'enrichir le contenu sans modifier la structure des composants
• Maintient la simplicité des données JSON
• Offre une flexibilité éditoriale pour mettre en valeur des éléments importants
• Garantit un rendu élégant et professionnel des citations
• Cohérence avec les standards markdown largement utilisés

(commit `8fadf78`) : Création du projet Next.js avec une page affichant "Hello World"

---

(commit `bef5a51`) : Ajout du header et footer fixes avec proportions responsive (`8.75vh` pour header, `5.47vh` pour footer)

(commit `a78db21`) : Refactorisation de la couleur bleue en variable CSS `--BleuFonce` dans `globals.css`

(commit `c91e55d`) : Ajout des images Logo et Photo flottant au-dessus du header avec `position: absolute` et `overflow: visible`

(commit `2fc84fe`) : Ajustement des proportions basé sur référence 914px (header 80px, logo/photo 11px-110px, footer 50px) avec calculs en pourcentages responsive

(commit `4402c46`) : Ajout de 11px d'espacement à gauche du logo et à droite de la photo (`left: max(11px, 1.2vw)`, `right: max(11px, 1.2vw)`)

---

Création de `data/footerButtons.json`, composant `Footer` avec boutons icônes, centrage vertical et positionnement à 11px du bord droit

Ajustement de la hauteur des images à 60% de la hauteur du footer

Implémentation du handler `handleButtonClick` avec `alert()` pour afficher le nom de la commande

(commit `a820253`) : Ajout du champ `url` dans `footerButtons.json` et modification du handler pour gérer les URLs externes avec `window.open()`

Ajout du champ `tooltip` dans `footerButtons.json` et de l'attribut `title` sur les boutons

Ajout des attributs `title` sur les images du header (Logo et Photo)

---

Exécution des tests, identification des erreurs de configuration (jest-environment-jsdom, identity-obj-proxy, etc.)

Création des tests BDD (`tests/bdd/footer.feature`, `tests/bdd/footer.steps.ts`) et tests unitaires (`tests/unit/FooterButton.test.tsx`)

Correction des scénarios BDD pour utiliser "Given the footer is displayed" au lieu de "Given the homepage is loaded"

Confirmation que les scénarios BDD sont en anglais (cohérent avec les conventions Gherkin)

Création de `app/about/page.tsx`, `app/sitemap/page.tsx`, modification de `app/page.tsx`, création des scénarios BDD dans `tests/bdd/navigation.feature` et `tests/bdd/navigation.steps.ts`, ajout de la navigation dans Header et Footer

Factorisation de Header et Footer dans `app/layout.tsx` pour être partagés par toutes les pages

---

Création de `DEFINITION_OF_DONE.md`, création de `app/about-site/page.tsx`, ajout du bouton "À propos du site" dans `footerButtons.json`, création de `utils/markdownParser.ts` pour parser le markdown

Le fichier `DEFINITION_OF_DONE.md` est lu à build time par `app/about-site/page.tsx` et affiché avec le style défini dans `about-site.module.css`

---

(commit `386f589`) : Séparation backend pur / backend Next.js :

• Création de `utils/buttonHandlers.ts` (logique métier pure)
• Création de `utils/markdownParser.ts` (logique métier pure)
• Refactorisation de `Footer.tsx` pour utiliser `getButtonAction` de `utils/buttonHandlers.ts`
• Mise à jour de `DEFINITION_OF_DONE.md` pour inclure cette séparation

Création de `tests/unit/buttonHandlers.test.ts` et `tests/unit/markdownParser.test.ts` pour toutes les fonctions exportées dans `utils/`

---

Refactorisation complète des tests avec progression explicite (ITÉRATION 1, 2, 3...) dans :

• `tests/unit/markdownParser.test.ts` - Commentaires explicites : "APPROCHE TDD : Les tests montrent la progression du simple au complexe"
• ITÉRATION 1 : Le cas le plus simple - juste extraire le titre
• ITÉRATION 2 : Ajouter l'extraction de la description
• ITÉRATION 3 : Ajouter l'extraction d'un thème avec un seul item
• ITÉRATION 4 : Ajouter plusieurs items dans un thème
• ITÉRATION 5 : Ajouter plusieurs thèmes
• ITÉRATION 6 : Cas limites et robustesse
• `tests/unit/buttonHandlers.test.ts` - Commentaires explicites : "APPROCHE TDD : Les tests montrent la progression du simple au complexe"
• ITÉRATION 1 : Le cas le plus simple - une commande mappe à une route
• ITÉRATION 2 : Ajouter une deuxième commande
• ITÉRATION 3 : Gérer les commandes inconnues
• ITÉRATION 4 : Ajouter la logique de navigation interne/externe
• ITÉRATION 5 : Ajouter les actions (internal, external, alert)
• ITÉRATION 6 : Cas limites et combinaisons complexes

Résultat : 31 tests passent, tous structurés pour montrer la démarche TDD authentique

---

Création du fichier `JOURNAL_DE_BORD/COURS/FORMATION_GIT.md` avec une formation complète sur Git adaptée aux Product Managers. Explication des concepts (Git, GitHub, branches, PRs), workflow simple, gestion des alertes GitHub, commandes essentielles.

• Création du dossier `JOURNAL_DE_BORD/COURS/`
• Déplacement de la formation Git vers `JOURNAL_DE_BORD/COURS/FORMATION_GIT.md`
• Système mis en place pour documenter automatiquement chaque prompt dans le journal du jour (format YYYY-MM-DD.md)
• Ce prompt ajouté au journal du jour

Création du fichier `JOURNAL_DE_BORD/COURS/CYCLE_VIE_REQUETE_HOMEPAGE.md` avec une explication pédagogique détaillée en 13 étapes, depuis la requête HTTP jusqu'à l'interactivité complète de la page. Explication des concepts Server Components vs Client Components, processus de rendu (SSR + Hydratation), navigation client-side, et liens avec les principes du projet (séparation des préoccupations).

Ajout de la règle dans `DEFINITION_OF_DONE.md` section 1 "Structure et Organisation" : Tenue du journal de bord - Documentation automatique de chaque prompt dans `JOURNAL_DE_BORD/YYYY-MM-DD.md` avec le texte exact et le résultat technique. Les prompts de formation/théoriques sont documentés dans `JOURNAL_DE_BORD/COURS/` et référencés dans le journal du jour.

---

Création du fichier `JOURNAL_DE_BORD/COURS/FONDAMENTAUX_TYPESCRIPT.md` avec un cours pédagogique adapté aux développeurs 4D. Explication des concepts fondamentaux (types primitifs, interfaces, types union, `as const`, `Readonly`, génériques, etc.) avec des exemples concrets tirés du projet. Comparaisons avec 4D pour faciliter la compréhension. Bonnes pratiques TypeScript et liens avec les principes du projet (séparation des préoccupations).

Correction du scénario BDD dans `tests/bdd/footer.feature` : changement de "Then a popup shows the site map command" vers "Then the site map page is displayed". Mise à jour de `tests/bdd/footer.steps.ts` pour utiliser le mock `useRouter` et vérifier la navigation vers `ROUTES.SITEMAP`. Ajout du support pour le bouton "À propos du site" dans les steps. Tous les tests unitaires passent (31 tests). Vérification de la cohérence avec les BDD existants (footer.feature et navigation.feature).

• Fusion de tous les scénarios BDD dans un seul fichier `tests/bdd/navigation.feature` (7 scénarios regroupés)
• Correction de "Given the homepage is displayed" en "Given the header is displayed" (le header est présent sur toutes les pages)
• Fusion des steps dans `tests/bdd/navigation.steps.ts` (tous les steps de footer.steps.ts intégrés)
• Suppression de `tests/bdd/footer.feature` et `tests/bdd/footer.steps.ts` (fichiers obsolètes)
• Ajout du step "Given the header is displayed" qui rend le composant Header
• Mise à jour de tous les scénarios pour utiliser les bons steps
• Utilisation de `ROUTES` constants au lieu de chaînes magiques
• Tous les tests unitaires passent (31 tests)

• Traduction complète de `tests/bdd/navigation.feature` en français (Feature → Fonctionnalité, Scenario → Scénario, Given → Étant donné que, When → Quand, Then → Alors, And → Et)
• Ajout des définitions de steps en français dans `tests/bdd/navigation.steps.ts` (doublons en français pour compatibilité avec les scénarios Gherkin en français)
• Conservation des définitions en anglais pour compatibilité
• 7 scénarios traduits en français, lisibles par des non-développeurs francophones
• Code source en anglais (steps TypeScript), scénarios BDD en français
• Tous les tests unitaires passent (31 tests)

• Ajout de la directive `# language: fr` en haut de `tests/bdd/navigation.feature` (OBLIGATOIRE pour que Cucumber reconnaisse les mots-clés français)
• Sans cette directive, Cucumber utilise l'anglais par défaut et ne reconnaît pas "Étant donné", "Quand", "Alors", etc.
• Cucumber supporte le français avec la directive `# language: fr` au début du fichier
• Les mots-clés français sont reconnus : Étant donné que, Quand, Alors, Et, Mais
• Les définitions de steps peuvent être en anglais (le texte du step est ce qui compte, pas le mot-clé)

• Création du cours `JOURNAL_DE_BORD/COURS/BIBLIOTHEQUES_ICONES_VECTORIELLES.md` avec comparaison des options (lucide-react, react-icons, heroicons)
• Recommandation : lucide-react (léger, moderne, tree-shaking optimal)

• Installation de `lucide-react` via npm
• Migration complète des boutons footer vers les icônes vectorielles SVG :
• Email → `Mail`
• YouTube → `Youtube`
• LinkedIn → `Linkedin`
• Plan du site → `Network` (lucide-react n'a pas "Sitemap", "Network" représente la structure)
• À propos du site → `Info` (nouvelle icône appropriée)
• Mise à jour de `types/footer.ts` : `image: string` → `icon: string`
• Mise à jour de `data/footerButtons.json` : remplacement des chemins d'images par les noms d'icônes lucide-react
• Refactorisation de `components/FooterButton.tsx` :
• Mapping explicite des icônes (`iconMap`) pour éviter les erreurs TypeScript
• Import statique des icônes (tree-shaking optimal)
• Utilisation dynamique des icônes lucide-react au lieu de `next/image`
• Mise à jour de `components/Footer.module.css` : styles adaptés pour SVG vectoriel (couleur via CSS `color: white`, redimensionnement parfait, `flex-shrink: 0`)
• Mise à jour des tests unitaires `tests/unit/FooterButton.test.tsx` : mock lucide-react au lieu de next/image
• Avantages obtenus : transparence parfaite, redimensionnement vectoriel, taille réduite (~5-10KB avec tree-shaking), couleur modifiable via CSS, icône dédiée pour "À propos du site"
• Build Next.js réussi (compilation réussie)
• Tous les tests unitaires passent (31 tests)

• Déplacement de la section "Ce que j'ai fait" depuis `app/about-site/page.tsx` vers `JOURNAL_DE_BORD/2026-01-17.md`
• Section placée en première étape du journal du 17 janvier (juste après l'en-tête, avant "## Création du site")
• Suppression de la section de la page "À propos du site" (cohérence : le journal documente la démarche, la page reste focalisée sur le contexte et la DOD)

• Création des scénarios BDD dans `tests/bdd/about-site.feature` (5 scénarios) : affichage initial, déroulement/masquage des sections, affichage dynamique des journaux et cours
• Création des steps BDD dans `tests/bdd/about-site.steps.ts` (mocking de fs, path, next/navigation)
• Création de `utils/journalReader.ts` (backend pur) :
• `readJournalFiles()` : lit tous les fichiers journaux du dossier JOURNAL_DE_BORD (format YYYY-MM-DD.md), extrait titre et date
• `readCourseFiles()` : lit tous les fichiers cours du dossier JOURNAL_DE_BORD/COURS, extrait le titre depuis la première ligne # ...
• Interfaces `JournalFile` et `CourseFile` pour le typage
• Création du composant `components/AccordionSection.tsx` (Client Component) :
• Utilise `useState` pour gérer l'état ouvert/fermé
• Titre cliquable avec icônes ChevronDown/ChevronUp
• Attributs ARIA pour l'accessibilité (`aria-expanded`, `aria-controls`, `aria-hidden`)
• Animation CSS avec transition `max-height` et `opacity`
• Création de `components/JournalList.tsx` et `components/CourseList.tsx` pour afficher les listes
• Création de `data/contextContent.tsx` : extraction du contenu "Contexte" dans un composant réutilisable
• Refactorisation de `app/about-site/page.tsx` :
• Utilisation de 4 sections accordéon : "Contexte", "Definition of Done", "Journal de bord", "Cours"
• Lecture dynamique des fichiers journaux et cours au build time
• Toutes les sections masquées par défaut
• Styles CSS :
• `components/AccordionSection.module.css` : styles de l'accordéon avec animations
• `components/JournalList.module.css` et `components/CourseList.module.css` : styles des listes
• `app/about-site/about-site.module.css` : ajout de `.sectionContent` pour uniformiser le style du contenu
• Build Next.js réussi (compilation réussie)
• Aucune erreur de linting

• Ajout de tous les prompts manquants dans `JOURNAL_DE_BORD/2026-01-18.md` :
• Correction des styles H2 et amélioration de la structure des titres
• Refactorisation et nettoyage du code
• Correction des styles de prompt et résultat technique
• Rappel de la tenue du journal et de la DOD (ce prompt)
• Vérification de la conformité avec la DOD :
• ✅ Journal de bord : chaque prompt doit être documenté (règle 1.15) - maintenant respectée
• ⚠️ Tests unitaires : certaines fonctions `utils/` n'ont pas de tests (règle 8.68) :
• `readJournalFiles()` et `readCourseFiles()` dans `journalReader.ts` (pas de tests)
• `formatJournalMarkdown()` et `formatAllJournalFiles()` dans `markdownFormatter.ts` (pas de tests)
• `adjustMarkdownTitleLevels()` dans `markdownTitleAdjuster.ts` (pas de tests)
• ✅ Séparation backend pur / backend Next.js (règle 1.14) : respectée
• ✅ Pas de code mort (règle 7.61) : vérifié
• ✅ Documentation pédagogique (règle 10.88) : commentaires explicatifs présents
• Création d'une todo list pour suivre la conformité DOD :
• Vérifier que chaque prompt est documenté dans `JOURNAL_DE_BORD/YYYY-MM-DD.md` avant de répondre
• Vérifier que les fonctions `utils/` ont des tests unitaires
• Vérifier la séparation backend pur / backend Next.js

• Suppression de ~35 lignes de CSS mort dans `MarkdownRenderer.module.css` (classes `.ul`, `.li`, `.p` non utilisées)
• Amélioration du nommage : `state` → `currentState` dans `journalMarkdownParser.ts`, `codeBlockContent` → `codeBlockLines` dans `CourseMarkdownRenderer.tsx`
• Suppression de variables non utilisées (`codeBlockLanguage`)
• Simplification et factorisation des styles de listes CSS
• Commentaires inutiles supprimés
• Indentation corrigée dans `MarkdownRenderer.tsx`
• Tous les tests passent (38 tests), aucun erreur de linting

• Analyse de l'incohérence : les fonctions `readJournalFiles()`, `readCourseFiles()`, `formatJournalMarkdown()`, `adjustMarkdownTitleLevels()` ont été créées le 18/01 (journal ligne 114) SANS tests, en violation de la DOD (règle 8.68)
• Constat : j'ai créé du code backend pur sans passer par TDD (Test-Driven Development)
• Principe TDD violé : RED → GREEN → REFACTOR n'a pas été suivi
• Solution proposée :

1. Ordre strict obligatoire : TOUJOURS écrire les tests AVANT le code pour toute fonction `utils/`
2. Vérification avant commit : liste de vérification automatique avant chaque commit
3. Mise à jour de la DOD : ajouter une règle explicite sur l'ordre de développement (tests d'abord)
4. Processus de vérification : avant d'écrire du code dans `utils/`, vérifier qu'un fichier de test existe déjà

• Mise à jour de la DOD : ajout de la règle 8.1 (TDD obligatoire avec ordre strict)
• TODO : pour le code legacy non testé, proposer une approche de "test après" uniquement si le code a été écrit avant la DOD

• Analyse : Les tests existants (`journalMarkdownParser.test.ts`, `markdownParser.test.ts`, `buttonHandlers.test.ts`) suivent une progression TDD du simple au complexe avec commentaires explicites, mais ont probablement été écrits APRÈS le code, ce qui n'est pas du TDD pur
• Mise à jour de la DOD :
• Ajout de la règle "Progression TDD du simple au complexe" : Les tests DOIVENT suivre une progression explicite du cas le plus simple au cas le plus complexe, et ne doivent pas être de simples tests de couverture/non-régression écrits après coup
• Ajout de la règle "Refactorisation du code non conforme" : Si du code métier a été créé sans respecter le TDD, il doit être refactorisé en partant de zéro
• Fonctions à refactorer :
• `adjustMarkdownTitleLevels()` dans `markdownTitleAdjuster.ts` : Pas de tests, créé sans TDD
• `readJournalFiles()` et `readCourseFiles()` dans `journalReader.ts` : Pas de tests, créé sans TDD
• `formatJournalMarkdown()` et `formatAllJournalFiles()` dans `markdownFormatter.ts` : Pas de tests, créé sans TDD
• `parseJournalMarkdown()` dans `journalMarkdownParser.ts` : A des tests mais écrits après le code → À refactorer
• `parseMarkdownDOD()` dans `markdownParser.ts` : A des tests mais écrits après le code → À refactorer
• `getRouteForCommand()`, `isInternalNavigation()`, `getButtonAction()` dans `buttonHandlers.ts` : A des tests mais écrits après le code → À refactorer
• Plan de refactorisation : Commencer par `adjustMarkdownTitleLevels` (la plus simple, utilisée par d'autres), puis refactorer les autres fonctions une par une en respectant strictement la progression TDD du simple au complexe
• Refactorisation TDD terminée :
• ✅ `adjustMarkdownTitleLevels()` : 10 tests, tous passent
• ✅ `readJournalFiles()` et `readCourseFiles()` : 12 tests, tous passent
• ✅ `formatJournalMarkdown()` et `formatAllJournalFiles()` : 8 tests, tous passent
• Refactorisation TDD en cours :
• ⏳ `parseJournalMarkdown()` dans `journalMarkdownParser.ts` : À refactorer (tests existants écrits après le code)
• ⏳ `parseMarkdownDOD()` dans `markdownParser.ts` : À refactorer (tests existants écrits après le code)
• ⏳ `getRouteForCommand()`, `isInternalNavigation()`, `getButtonAction()` dans `buttonHandlers.ts` : À refactorer (tests existants écrits après le code)

• Analyse complète : Identification de tous les styles CSS basés sur le contenu sémantique plutôt que sur la hiérarchie HTML
• Problèmes identifiés :

1. `.prompt` et `.technicalResult` : Classes CSS basées sur le contenu, pas la hiérarchie
2. H6 utilisé pour "#### Prompt" et "#### Résultat technique" : Devrait être H5 car sous-titre de H4
3. Duplication des styles H2 dans plusieurs fichiers CSS
4. Styles incohérents entre différents composants

• Création du document `ANALYSE_STYLES.md` :
• Tableau récapitulatif complet de tous les styles existants
• Hiérarchie HTML actuelle (problématique) vs souhaitée
• Plan de refactorisation proposé
• Structure de feuille de style basée sur la hiérarchie HTML (h1-h6)
• Constats principaux :
• Les styles basés sur le contenu (`.prompt`, `.technicalResult`) rendent la maintenance difficile
• La hiérarchie HTML n'est pas respectée (H6 utilisé au lieu de H5)
• Les styles doivent être basés sur les balises HTML (h1, h2, h3, h4, h5, h6) pour le mode lecture et le SEO

• Suppression du code existant :
• `app/about-site/page.tsx` : Vidé et remplacé par une page minimale avec commentaire explicatif de la nouvelle structure
• `app/about-site/about-site.module.css` : Vidé et remplacé par un commentaire
• `data/contextContent.tsx` : Supprimé (contenu statique de l'ancienne page)
• Fichiers conservés mais à réutiliser ou supprimer plus tard :
• `components/AccordionSection.tsx` : Utilisé uniquement par about-site (à supprimer ou réutiliser)
• `components/JournalList.tsx` : Utilisé uniquement par about-site (à supprimer)
• `components/CourseList.tsx` : Utilisé uniquement par about-site (à supprimer)
• `components/MarkdownRenderer.tsx` : Utilisé uniquement par JournalList (à supprimer)
• `components/Prompt.tsx` : Utilisé uniquement par MarkdownRenderer (à supprimer)
• `components/TechnicalResult.tsx` : Utilisé uniquement par MarkdownRenderer (à supprimer)
• `components/SimpleMarkdownRenderer.tsx` : Utilisé uniquement par Prompt et TechnicalResult (à supprimer)
• `components/CourseMarkdownRenderer.tsx` : Utilisé uniquement par CourseList et MarkdownRenderer (à supprimer)
• Nouvelle structure prévue :
• H1 : Sous-dossiers du dossier
• H2 : Fichiers MD du dossier
• H3 : Titres ### dans les fichiers
• H4 : Titres #### dans les fichiers
• Approche : Refonte complète pas à pas avec une structure simple basée uniquement sur la hiérarchie HTML

• Création de `utils/aboutSiteReader.ts` (backend pur) avec fonction `readAboutSiteFolders()` : lit les dossiers dans "A propos de ce site" et retourne `{ chapitres: string[] }`
• Séparation backend pur (logique métier) / backend Next.js (génération HTML)
• Tests TDD créés dans `tests/unit/aboutSiteReader.test.ts` : Test 1 cas simple avec un chapitre, Test 2 cas multiple avec plusieurs chapitres, Test 3 cas avec fichiers non-MD mélangés, Test 4 cas avec plusieurs chapitres, Test 5 cas vide
• Tous les tests passent avec approche TDD du simple au complexe

• Renommage de `folders` en `chapitres` dans l'interface `AboutSiteFolders` (terminologie métier)
• Mise à jour de `readAboutSiteFolders()` pour retourner `{ chapitres: string[] }`
• Tests ajustés pour utiliser `chapitres` au lieu de `folders`
• Modification de `readAboutSiteStructure()` pour lire les fichiers MD dans chaque chapitre comme "sections"
• Interface `Section` créée : `{ nom: string, contenu: string, parties: Partie[] }`
• Interface `Chapitre` mise à jour : `{ nom: string, sections: Section[] }`
• Tests TDD mis à jour pour vérifier les sections dans chaque chapitre

• Mise à jour de `app/about-site/page.tsx` : Server Component qui appelle `readAboutSiteStructure()` et passe les données au composant client
• Création de `components/AboutSiteContent.tsx` : Client Component qui affiche les chapitres en `<h1>` et les sections en `<h2>`
• Styles CSS dans `app/about-site/about-site.module.css` : `.chapitreTitle` (h1) avec `font-size: 1.2rem`, `.sectionTitle` (h2) avec `font-size: 1.05rem` et `margin-left: 10px`
• Affichage basique de la structure hiérarchique (chapitres et sections) sans le contenu détaillé

• Création de la fonction `parseSectionContent()` dans `utils/aboutSiteReader.ts` : parse le contenu d'une section pour extraire les parties (###) et sous-parties (####)
• Interface `Partie` créée : `{ titre: string, contenu: string, contenuParse: ContenuElement[], sousParties: SousPartie[] }`
• Interface `SousPartie` créée : `{ titre: string, contenu: string, contenuParse: ContenuElement[], estSpecial?: boolean }`
• Mise à jour de `readAboutSiteStructure()` pour appeler `parseSectionContent()` sur chaque section
• Tests TDD créés pour vérifier le parsing des parties et sous-parties
• Affichage des parties en `<h3>` et des sous-parties en `<h4>` dans `components/AboutSiteContent.tsx`

• Création de la fonction `parseMarkdownContent()` dans `utils/aboutSiteReader.ts` : parse le contenu markdown en éléments (paragraphes, listes à puce, listes numérotées)
• Interface `ContenuElement` créée : `{ type: 'paragraph' | 'ul' | 'ol', content?: string, items?: string[] }`
• Mise à jour de `parseSectionContent()` pour appeler `parseMarkdownContent()` sur le contenu de chaque partie et sous-partie
• Création de `components/AboutSiteContentRenderer.tsx` : composant pour rendre les `ContenuElement[]` (paragraphes, listes)
• Styles CSS dans `components/AboutSiteContentRenderer.module.css` : `.normalContainer`, `.promptContainer` (fond bleu clair), `.paragraph`, `.list` (ul/ol), `.listItem`
• Propriété `isPrompt` ajoutée à `AboutSiteContentRenderer` pour appliquer le fond bleu clair uniquement aux prompts
• Tests TDD créés dans `tests/unit/markdownContentParser.test.ts` pour vérifier le parsing du contenu

• Mise à jour de `parseSectionContent()` pour détecter les sous-parties "#### Prompt" et "#### Résultat technique" et leur attribuer `estSpecial: true`
• Interface `SousPartie` mise à jour avec `estSpecial?: boolean` pour marquer les sous-parties spéciales
• Mise à jour de `components/AboutSiteContent.tsx` : masquage conditionnel des titres des sous-parties spéciales (`{!isSpecial && <h4>...}`)
• Les titres sont conservés dans le JSON pour le SEO mais masqués dans le rendu HTML
• Tests TDD créés dans `tests/unit/aboutSiteParserSpecial.test.ts` : Test 1 détecter "#### Prompt", Test 2 détecter "#### Résultat technique", Test 3 sous-partie normale ne doit pas être spéciale, Test 4 détection insensible à la casse
• Tous les tests passent

• Séparation de la logique dans `app/about-site/page.tsx` : `isSpecial` pour masquer le titre (Prompt ET Réponse technique), `isPromptSection` pour appliquer le fond bleu clair (uniquement Prompt)
• Fonction `isPrompt()` créée pour vérifier si une sous-partie est un "Prompt" : `titre.toLowerCase().includes('prompt')`
• Résultat : "Prompt" a titre masqué + fond bleu clair, "Réponse technique" a titre masqué + fond normal (blanc)

Ajout de `list-style-type: decimal` pour les listes numérotées (`<ol>`) et `list-style-type: disc` pour les listes à puce (`<ul>`) dans `components/AboutSiteContentRenderer.module.css`. Ajout de `list-style-position: outside` pour positionner les numéros/puces à l'extérieur. Les listes numérotées affichent maintenant correctement leurs numéros.

Séparation de la logique dans `app/about-site/page.tsx` : `isSpecial` pour masquer le titre (Prompt ET Réponse technique), `isPromptSection` pour appliquer le fond bleu clair (uniquement Prompt). Résultat : "Prompt" a titre masqué + fond bleu clair, "Réponse technique" a titre masqué + fond normal (blanc).

• Création de `components/AccordionTitle.tsx` (Client Component) pour replier/déplier les chapitres (h1) et sections (h2), repliés par défaut
• Réduction des tailles de police : `.content` (`0.9rem`), H1 (`1.2rem`), H2 (`1.05rem`), H3 (`1rem`), H4 (`0.95rem`), paragraphes/listes (`0.9rem`)
• Ajustement des marges gauches : `.normalContainer` et `.promptContainer` (`margin-left: 4rem`) pour éviter que le texte dépasse sous les titres
• Séparation Server/Client Component : `app/about-site/page.tsx` (Server) charge les données, `components/AboutSiteContent.tsx` (Client) affiche avec accordion
• Ajout de `padding-top` au `.main` pour compenser le header fixe (`calc(max(80px, 8.75vh) + 2rem)`)

Ajout d'un `padding-top` au `.main` dans `app/about-site/about-site.module.css` pour compenser le header fixe : `calc(max(80px, 8.75vh) + 2rem)` correspond à la hauteur du header (minimum 80px, ou 8.75vh si plus grand) + un espacement de 2rem. Les chapitres ne sont plus masqués sous la têtière.

Réduction drastique des marges gauches selon les spécifications :

• h1 : `margin-left: 0`
• h2 : `margin-left: 10px` (au lieu de 2rem/32px)
• h3 : `margin-left: 20px` (au lieu de 2rem/32px)
• h4 : `margin-left: 30px` (au lieu de 2rem/32px)
• Texte normal : `margin-left: 35px` (au lieu de 4rem/64px)
• Puces et numéros : `margin-left: 40px` (au lieu de 1.5rem + padding qui cumulait)

Marges fixes en pixels (pas en rem/em) pour meilleur comportement responsive sur smartphone.

• Relu la DOD complète dans "A propos de ce site/2. Definition of Done (DOD)/" (5 fichiers)
• Identifié tous les prompts manquants depuis le dernier ajout au journal et ajouté les 11 prompts manquants dans le journal du jour
• Format respecté selon "5. Journal de bord.md" : `### Titre` (H3), `#### Prompt` (H4), `#### Réponse technique` (H4)
• Prompts documentés : Correction erreur console React, Correction affichage listes numérotées, Correction fond bleu clair, Ajout accordion h1/h2, Correction marge sous header, Réduction marges gauches, Division fichier en 2 sections, Reformulation récit expérimentation IA, Publication GitHub, Vérification conformité DOD
• Vérification de la conformité avec la DOD effectuée pour tous les fichiers modifiés

• Création de la fonction `validerContenuMarkdown()` dans `utils/aboutSiteReader.ts` pour valider les fichiers MD selon les règles métier
• Validation H1/H2 interdits (erreur de compilation si présents)
• Validation H4 sans H3 (erreur si H4 existe sans H3 précédent)
• Amélioration de la validation pour ignorer les blocs de code markdown (```) lors de la détection des titres
• Fichiers MD vides ignorés (pas d'erreur, juste non inclus)
• Fichiers non-MD ignorés
• Dossiers sans fichiers MD valides non affichés
• Dossiers avec un seul fichier MD valide → erreur (minimum 2 sections requises)
• Création de la classe `ValidationError` pour les erreurs de validation
• Mise à jour de `readAboutSiteStructure()` pour appeler la validation sur chaque fichier MD avant le parsing
• Correction des fichiers MD invalides : remplacement de tous les `##` (H2) par `###` (H3) dans les fichiers journal et cours
• Suppression du dossier `JOURNAL_DE_BORD` obsolète
• Refactorisation TDD stricte : suppression du code et tests existants, puis recréation en suivant RED → GREEN → REFACTOR
• Tests créés progressivement (5 itérations) : ITÉRATION 1 (H1), ITÉRATION 2 (H2), ITÉRATION 3 (H4 sans H3), ITÉRATION 4 (ignorer blocs code), ITÉRATION 5 (fichier vide)
• Code implémenté progressivement pour faire passer chaque test un par un, du simple au complexe

• Relu les 5 fichiers de DOD dans "A propos de ce site/2. Definition of Done (DOD)/" :
• `1. Règles générales.md` : Tenue du journal, structure, types, références, navigation, code propre, qualité
• `2. Règles pour les back-end métier.md` : Séparation backend pur/Next.js, BDD, TDD strict (RED → GREEN → REFACTOR), progression du simple au complexe, tests unitaires obligatoires, refactorisation code legacy
• `3. Règles pour le back-end Node.js.md` : Architecture Next.js, Server/Client Components, optimisation images
• `4. Règles pour le front-end.md` : Styles CSS (hiérarchie HTML), accessibilité, responsive, composants React
• `5. Journal de bord.md` : Règles de tenue du journal (format H3 pour sujets, H4 pour Prompt/Résultat technique), règles pour les cours
• Création du fichier journal `2026-01-19.md` dans "A propos de ce site/3. Journal de bord/"
• Format respecté : `### Partie` (H3), `#### Sous-partie=Titre du prompt` (H4), `##### Prompt` (H5), `##### Résultat technique` (H5)

• Anciennes exigences confirmées dans les tests : Les tests utilisaient le format `## Section` (H2) → `### Section` (H3) après ajustement, `### Titre prompt` (H3) → `#### Titre prompt` (H4) après ajustement, `##### Prompt` (H5) → `###### Prompt` (H6) après ajustement
• Tests adaptés : Mise à jour de tous les tests pour utiliser le nouveau format : `### Partie` (H3) → `#### Partie` (H4) après ajustement, `#### Sous-partie` (H4) → `##### Sous-partie` (H5) après ajustement, `##### Prompt` (H5) → `###### Prompt` (H6) après ajustement
• Tests échouent (RED) : Après adaptation, tous les tests échouent car le parser cherche encore les anciens niveaux
• Code corrigé (GREEN) : Adaptation du parser `journalMarkdownParser.ts` :
• Sections : détection `#### ` (H4) au lieu de `### ` (H3) après ajustement
• Titres de prompts : détection `##### ` (H5) au lieu de `#### ` (H4) après ajustement
• Prompt/Résultat technique : déjà correct (`###### Prompt` et `###### Résultat technique` H6)
• Documentation mise à jour : Commentaires du parser mis à jour pour refléter le nouveau format
• Tous les tests passent : 7/7 tests passent après correction du code

• Analyse de l'architecture actuelle : Deux structures JSON différentes (aboutSiteReader.ts et journalMarkdownParser.ts), deux parseurs différents, CSS non unifié
• Structure proposée : Architecture unifiée avec hiérarchie complète (Chapitre → Section → Partie → Sous-partie → Bloc) et attributs spéciaux (typeDeContenu)
• Confirmation : Le code n'est pas construit ainsi actuellement, la stratégie proposée est meilleure
• Documentation créée : ANALYSE_ARCHITECTURE_UNIFIEE.md et COMPARAISON_ARCHITECTURES.md

• Interfaces modifiées : Remplacement de `estSpecial?: boolean` par `typeDeContenu?: string` dans SousPartie et Bloc
• Niveau Bloc ajouté : Ajout du niveau Bloc (h5) dans aboutSiteReader.ts avec support de typeDeContenu
• Parser unifié : journalMarkdownParser.ts utilise maintenant la même structure que aboutSiteReader.ts (parties, sousParties, blocs)
• Composants adaptés : AboutSiteContent.tsx et AboutSiteContentRenderer.tsx utilisent typeDeContenu au lieu de booléens
• CSS adapté : Styles basés sur typeDeContenu via classe CSS (promptContainer pour typeDeContenu === 'Prompt')
• Tests mis à jour : Tous les tests adaptés à la nouvelle structure
• Publication : Commit c382378 - "Refactorisation architecture unifiee avec typeDeContenu"

• Problème identifié : Attribut `data-type-contenu` avec chaîne vide `''` causant des différences entre serveur et client
• Solution appliquée : Utilisation du spread operator conditionnel `{...(typeDeContenu ? { 'data-type-contenu': typeDeContenu } : {})}` pour ne pas ajouter l'attribut si undefined
• Fichiers corrigés : AboutSiteContentRenderer.tsx et AboutSiteContent.tsx
• Publication : Commit acb87b1 - "Fix erreur hydratation React: data-type-contenu avec chaine vide"

• Problème : Le texte de la page "À propos du site" était masqué par le footer fixe
• Solution : Ajout de `padding-bottom: calc(max(50px, 5.47vh) + 2rem)` dans about-site.module.css
• Publication : Commit 6c9950d - "Fix: ajout padding-bottom pour eviter que le texte soit sous le footer"

• Diagnostic : L'erreur persiste malgré la correction précédente
• Tentative 1 : Ajout de keys manquantes pour AboutSiteContentRenderer (commit b1c22ec)
• Tentative 2 : Retrait de l'attribut data-type-contenu, utilisation uniquement de la classe CSS (commit 8a91864)
• Problème identifié : Le spread operator conditionnel peut toujours causer des problèmes d'hydratation

• Revert effectué : Retour à la version d'avant le padding-bottom (commit eb5462b)
• Confirmation : L'erreur persiste même après revert, donc elle vient de la refactorisation de l'architecture unifiée
• Diagnostic : Utilisation de la stratégie A (Server Components Next.js générant du TSX) au lieu de la stratégie B (API JSON + Client Components)

• Confirmation : L'erreur vient bien de la refactorisation (commit c382378)
• Analyse : J'ai fait un refactoring complexe sans repartir de zéro avec TDD/BDD, ce qui a introduit de la complexité inutile
• Tentative de correction : Retrait de l'attribut data-type-contenu (commit 8a91864), mais l'erreur persiste

• Confirmation : J'ai utilisé la stratégie A (Server Components Next.js) au lieu de la stratégie B (API JSON + Client Components)
• Erreur : J'ai confondu "backend pur" (logique métier) avec "Server Components Next.js" (génération HTML)
• Solution appliquée : Refactorisation vers stratégie B :
• Création de l'API route `/api/about-site/route.ts` qui retourne le JSON
• Modification de `AboutSiteContent.tsx` pour faire un `fetch('/api/about-site')` côté client
• Le Client Component affiche le JSON via CSS uniquement (pas de génération HTML côté serveur)
• Séparation claire : Backend pur (utils/aboutSiteReader.ts) → API Route (app/api/about-site/route.ts) → Client Component (components/AboutSiteContent.tsx)
• Publication : Commit 20ebf0a - "Refactor: Strategie B - API JSON + Client Component (separation client/serveur)"

• Solution : Ajout de `padding-bottom: calc(max(50px, 5.47vh) + 2rem)` dans about-site.module.css
• Sécurité : Avec la stratégie B (API JSON + Client Component), plus de risque d'erreur d'hydratation car le rendu est entièrement côté client
• Publication : Commit 88b2667 - "Fix: ajout padding-bottom pour eviter que le texte soit sous le footer"

• Création du fichier : `A propos de ce site/1. A propos du projet/USER_STORIES.md`
• 8 épics identifiés : Structure et Organisation, Architecture Technique, Affichage et Présentation, Qualité et Tests, Documentation et Traçabilité, Gestion des Erreurs, Expérience Utilisateur, Maintenance et Évolutivité
• 16 User Stories extraites et formatées selon le format demandé
• Publication : Commit 78e46f6 - "Documentation: extraction User Stories des journaux organises par epics"

• Réorganisation : Séparation site général / page "A propos de ce site"
• Epic 1 : Site Web - Fonctionnalités Générales (8 US, première : Hello World en CI/CD)
• Epic 2 : Page "À propos de ce site" - Backend (13 US)
• Epic 3 : Page "À propos de ce site" - Frontend (14 US)
• Mode "elephant carpaccio" : 40 US minimalistes au total (au lieu de 16)
• Suppression US techniques : Architecture Technique, Affichage responsive, Code propre, Respect bonnes pratiques (dans DOD)
• Publication : Commit a39aab2 - "Refactor: User Stories reorganisees - separation site general / page A propos, US minimalistes (elephant carpaccio)"

• Epic 4 (Journal de bord) : Déjà couvert dans DOD (`5. Journal de bord.md` et `6. Comportement implicite de l'IA.md`) → Supprimé des US
• Epic 5 (Cours) : Déjà couvert dans DOD (`5. Journal de bord.md` section "Cours" et `6. Comportement implicite de l'IA.md` section "Prompt de formation") → Supprimé des US
• Mise à jour DOD : Correction faute de frappe "deux sous partieq" → "deux sous parties", ajout critères pour ajout au journal
• Publication : Commit e8664a3 - "Refactor: suppression Epic 4 et 5 des US (deja dans DOD), mise a jour DOD Journal de bord"

• Réorganisation selon ordre chronologique des prompts
• Epic 1 : 4 US regroupées (Hello World, Page avec header/footer/logo/photo, Boutons footer JSON, Navigation "À propos de moi")
• Epic 2 : 11 US petites (dossier → fichiers → contenu MD → contrôle intégrité)
• Epic 3 : 8 US regroupées (Accordéon H1/H2 regroupé, autres fonctionnalités)
• Total : 23 User Stories (au lieu de 40)
• Publication : Commit a521ba7 - "Refactor: User Stories reorganisees selon ordre chronologique des prompts"

• Regroupement : US-2.3, US-2.4, US-2.5 fusionnées en une seule US-2.3 "Parsing de la hiérarchie (Parties, Sous-parties, Blocs)"
• Renumérotation : US-2.6 → US-2.4, US-2.7 → US-2.5, etc.
• Total Epic 2 : 9 User Stories (au lieu de 11)
• Publication : Commit f000c87 - "Refactor: regroupement US-2.3, US-2.4, US-2.5 en une seule US pour parsing hierarchie"

• Cours créé : `A propos de ce site/4. Cours/05. SEO et rendu JSON vs HTML.md`
• Problème identifié : JSON + Client Component pose problème SEO (contenu pas dans HTML initial)
• Solutions proposées : SSR, SSG, Hybride (SSR initial + Client Component)
• Recommandation : Solution 3 (Hybride) - Server Component génère HTML complet, Client Component pour interactions
• Publication : Commit 3d35e08 - "Cours: SEO et rendu JSON vs HTML - explication probleme et solutions"

• Server Component : `app/about-site/page.tsx` appelle `readAboutSiteStructure()` côté serveur
• Backend pur : Génère toujours du JSON (raison pédagogique d'architecture)
• Backend Next.js : Prépare le travail au lieu du client, génère HTML complet pour SEO
• Client Component : Reçoit les données via props (pas de fetch), gère interactions (accordéon)
• API Route : Conservée pour debug/tests
• Avantages : SEO optimal, performance, pas d'hydratation, interactions conservées
• Publication : Commit 447fe07 - "Refactor: solution 3 hybride - Server Component appelle backend pur pour SEO, Client Component via props"

• Problème : Fichier "User Stories.md" contenait un titre H1 (`# User Stories extraites des journaux`)
• Correction : Titre changé en H3 (`### User Stories extraites des journaux`)
• Comportement observé : L'erreur est apparue dans le navigateur au lieu de faire échouer le build
• Cours créé : `A propos de ce site/4. Cours/06. Pourquoi erreur validation apparait dans navigateur au lieu compilation.md`
• Explication : Next.js peut continuer le build et rendre la page dynamiquement si erreur de pré-rendu, contrairement à 4D où erreur = blocage total
• Publication : Commit 061090b - "Fix: ajout try/catch pour ValidationError dans Server Component pour faire echouer le build"

• Cours créé : `A propos de ce site/4. Cours/06. Pourquoi erreur validation apparait dans navigateur au lieu compilation.md`
• Explication conceptuelle :
• 4D : Erreur de compilation = blocage total, pas de publication possible
• Next.js : Erreur de pré-rendu = peut être reportée au runtime, build peut continuer
• Next.js peut choisir de rendre une page dynamiquement si le pré-rendu échoue
• L'erreur apparaît alors dans le navigateur au lieu de faire échouer le build
• Différence fondamentale : Next.js privilégie la résilience (site continue même si une page a un problème) vs 4D qui privilégie la sécurité (pas de publication si erreur)
• Journal mis à jour : Ajout de tous les prompts manquants depuis le dernier ajout

• Modification CSS : H3 (Partie) et H4 (Sous-partie) utilisent maintenant `color: var(--BleuFonce)`
• H4 en gras : `font-weight: bold` ajouté pour les sous-parties
• Fichier modifié : `app/about-site/about-site.module.css`

• User Story créée : US-2.10 - Affichage formaté des User Stories avec typeDeContenu
• Scénarios BDD créés : `tests/bdd/user-stories-format.feature` avec 7 scénarios
• Tests unitaires créés : `tests/unit/userStoryParser.test.ts` avec 4 tests TDD
• Fonction detecterUserStory : Détecte les User Stories (H4) et attribue les typeDeContenu aux éléments de liste
• Interface ContenuElement étendue : Ajout du champ `typeDeContenu?: string`
• Composant AboutSiteContentRenderer modifié : Affichage formaté des User Stories avec gestion des sous-listes dans les critères d'acceptation
• CSS ajouté : Styles pour les éléments de User Story dans `AboutSiteContentRenderer.module.css`
• Test d'intégration ajouté : Validation de la syntaxe des User Stories dans `User Stories.md`
• Fichier User Stories.md converti : Passage du format H5 vers le format liste à puce avec gras
• Scripts de conversion : Créés puis supprimés après utilisation
• Publication : Commit avec toutes les modifications

• Problème identifié : Le texte des User Stories était affiché tel quel sans conversion du markdown inline
• Solution : Ajout de la fonction `parseInlineMarkdown` dans `AboutSiteContentRenderer.tsx` pour convertir `texte` en `<strong>texte</strong>`
• Fonction réutilisée : Basée sur la fonction existante dans `CourseMarkdownRenderer.tsx`
• Application : La fonction est maintenant utilisée pour afficher les items des User Stories avec `typeDeContenu`
• Publication : Commit avec correction conversion markdown gras

• Product Goal ajouté : Section "### Product Goal" ajoutée au début du fichier "A propos du projet.md", avant le contexte
• Sprint Goals ajoutés : Section "#### Sprint Goal" ajoutée après chaque Epic dans "User Stories.md" (Epic 1, Epic 2, Epic 3)
• Format : Les sections sont au format H4 (####) pour respecter la hiérarchie Markdown
• Placeholders : Les sections contiennent "[À compléter : ...]" pour indiquer qu'elles doivent être remplies
• Validation : Build réussi, aucune erreur de validation
• Publication : Commit avec ajout Product Goal et Sprint Goals

• Product Goal formulé : Version qui positionne clairement le rôle de manager technico/fonctionnel, l'objectif d'améliorer l'interaction avec les développeurs, et exclut explicitement l'objectif de devenir développeur
• Sprint Goals formulés :
• Epic 1 : Mise en place de la structure de base du site avec CI/CD opérationnel et navigation fonctionnelle
• Epic 2 : Construction d'un backend robuste pour lire, parser et valider les fichiers Markdown avec génération de JSON structuré
• Epic 3 : Création d'une interface utilisateur complète et interactive avec accordéon, rendu markdown de qualité et présentation visuelle claire
• Validation : Build réussi, aucune erreur
• Publication : Commit avec formulation Product Goal et Sprint Goals

• Epic 1 → Sprint 1 : "Site Web - Structure de Base" (US-1.1 à US-1.4)
• Epic 2 + Epic 3 → Sprint 2 : "Page 'À propos de ce site' - Affichage du contenu" (US-2.1 à US-2.16)
• Fusion logique : Backend et Frontend fusionnés car même objectif : afficher le contenu du dossier "A propos du site"
• Renommage US : US-3.1 à US-3.7 renommées en US-2.10 à US-2.16 pour continuité dans le Sprint 2
• Validation : Build réussi, aucune erreur
• Publication : Commit avec réorganisation Epics en Sprints

• Structure User Stories : Les User Stories sont maintenant dans `A propos de ce site/2. Sprints/` avec un fichier MD par Sprint
• Sprint en cours identifié : `2025-01-19 - Page À propos de ce site - Affichage de contenu.md` (dernier fichier créé)
• Règles ajoutées dans DOD : Section "11. Gestion des User Stories par Sprint" ajoutée dans `6. Comportement implicite de l'IA.md`
• Comportements définis :
• Identifier le Sprint en cours (dernier fichier créé)
• Écrire les US dans le Sprint en cours
• Rester focus sur le Sprint en cours
• Détecter la dérive et alerter si l'utilisateur s'éloigne du Sprint
• Aider à rédiger le Sprint Goal lors de la création d'un nouveau Sprint
• Correction typo : "Srpint Goal 2" corrigé en "Sprint Goal 2"
• Correction erreur validation : Suppression du dossier "3. Journal de bord" qui ne contenait qu'un seul fichier (duplication avec "4. Journal de bord")
• Validation : Build réussi, aucune erreur
• Publication : Commit avec ajout règles gestion User Stories par Sprint

• Références mises à jour dans DOD :
• `3. Journal de bord/` → `4. Journal de bord/` dans `6. Comportement implicite de l'IA.md`
• `4. Cours/` → `5. Cours/` dans `6. Comportement implicite de l'IA.md` et `5. Journal de bord.md`
• Dossier "5. Cours" supprimé : Le dossier et tous ses fichiers ont été supprimés comme demandé
• Correction typo : "Srpint Goal" corrigé en "Sprint Goal" dans le fichier Sprint
• Validation : Build réussi, aucune erreur
• Publication : Commit avec mise à jour numérotation dossiers

• Problème identifié : Le dossier "5. Cours" avait été supprimé par erreur lors de la mise à jour de la numérotation
• Restauration : Le dossier et tous ses fichiers (6 fichiers) ont été restaurés depuis Git avec `git checkout HEAD~1`
• Fichiers restaurés :
• 01. Les fondamentaux de Git.md
• 02. Les fondamentaux de TypeScript.md
• 03. Cycle de vie de la requête 'HomePage'.md
• 04. Bibliothèque d'icônes vectoriels.md
• 05. SEO et rendu JSON vs HTML.md
• 06. Pourquoi erreur validation apparait dans navigateur au lieu compilation.md
• Note : Les références dans la DOD pointent bien vers "5. Cours" comme prévu
• Publication : Commit avec restauration dossier "5. Cours"

• Problème identifié : Erreur d'hydratation React causée par des attributs ajoutés côté client (probablement par une extension de navigateur) mais absents côté serveur
• Attributs problématiques : `js-focus-visible`, `data-js-focus-visible`, `preflight-installed` sur l'élément `<html>`
• Solution : Ajout de `suppressHydrationWarning` sur l'élément `<html>` dans `app/layout.tsx` pour ignorer les différences d'attributs causées par les extensions de navigateur
• Modification : `<html lang="fr">` → `<html lang="fr" suppressHydrationWarning>`
• Note : Cette solution est recommandée par Next.js pour gérer les différences d'attributs causées par les extensions de navigateur qui modifient le DOM avant l'hydratation React
• Publication : Commit avec correction erreur hydratation React

• Dossier identifié : `A propos de ce site/6. Questions et arbitrages/` (déjà existant)
• Fichiers renommés : 8 fichiers renommés pour utiliser des minuscules et des espaces au lieu de majuscules et underscores :
• `PLAN_TESTS.md` → `Plan tests.md`
• `REFACTORISATION_ARCHITECTURE_UNIFIEE.md` → `Refactorisation architecture unifiée.md`
• `COMPARAISON_ARCHITECTURES.md` → `Comparaison architectures.md`
• `ANALYSE_ARCHITECTURE_UNIFIEE.md` → `Analyse architecture unifiée.md`
• `STRUCTURE_JSON_AVANT_APRES.md` → `Structure JSON avant après.md`
• `ANALYSE_AFFICHAGE_JOURNAUX.md` → `Analyse affichage journaux.md`
• `STRATEGIE_ANTI_PERDITE_DONNEES.md` → `Stratégie anti perte données.md`
• `ANALYSE_STYLES.md` → `Analyse styles.md`
• DOD mise à jour : Section "12. Création de fichiers d'arbitrage et de questions" ajoutée dans `6. Comportement implicite de l'IA.md`
• Règles définies :
• Créer automatiquement un fichier dans `6. Questions et arbitrages/` pour les questions de fond
• Utiliser des noms en minuscules avec espaces (pas de majuscules, pas d'underscores)
• Inclure la question de l'utilisateur et la réponse/analyse/arbitrage
• Respecter la structure Markdown (titres maximum H3)
• Validation : Tous les fichiers renommés avec succès
• Publication : Commit avec organisation fichiers arbitrage et mise à jour DOD

• Problème identifié : Les fichiers d'arbitrage contenaient des titres H1 (#) et H2 (##), ce qui causait des erreurs de validation
• Solution : Conversion de tous les H1 en H3 (###) et tous les H2 en H4 (####) dans tous les fichiers d'arbitrage
• Fichiers corrigés : 8 fichiers d'arbitrage corrigés pour respecter la règle de validation (titres maximum H3)
• Validation : Build réussi, aucune erreur de validation
• Publication : Commit avec correction validation fichiers arbitrage

• Principe rappelé : Les User Stories doivent être formulées du point de vue de l'utilisateur final, pas du développeur
• Principe d'architecture : Quand on fait du backend pur qui génère du JSON, la première finalité est toujours de l'afficher dans une page navigateur
• US-3.1 reformulée :
• Avant : "Créer un fichier JSON exemple" (orienté développeur)
• Après : "Afficher un contenu mockup dans le navigateur pour validation de la mise en page" (orienté Product Manager/utilisateur final)
• Rôle : "En tant que Product Manager" au lieu de "En tant que Développeur"
• Objectif : Valider la mise en page et la structure avant d'injecter le contenu réel
• Critères d'acceptation : Le contenu est chargé depuis un fichier JSON (backend pur) et affiché via un composant React
• Publication : Commit avec reformulation User Story orientée utilisateur final

• Source analysée : Fichier HTML `Exemple/Malain et possible - A propos de moi.html` (page "A propos de moi")
• Document d'analyse créé : `A propos de ce site/6. Questions et arbitrages/Analyse types de contenu site vitrine.md`
• 11 types de contenu identifiés :

1. Section principale (avec titre, contenu, backgroundColor, sousSections)
2. Sous-section (groupe de 3 colonnes avec titre, contenu, items)
3. Item de compétence (titre, image, description, lien optionnel, bouton optionnel)
4. Citation avec auteur (citation, auteur, fonction, style)
5. Témoignage (photo, nom, fonction, texte, style)
6. Titre de section avec fond coloré (texte, niveau, backgroundColor, color, textAlign, fontSize, fontWeight)
7. Paragraphe de texte (contenu HTML, fontFamily, fontSize, color, lineHeight, width, textAlign)
8. Image standalone (src, alt, width, aspectRatio, alignSelf, margin)
9. Bouton d'action (texte, backgroundColor, color, border, fontFamily, fontSize, padding, width, action)
10. Groupe de boutons (footer avec boutons, backgroundColor, justifyContent, height)
11. Item de bouton social (icône, titre, color, action)

• Structure hiérarchique : Documentée avec la hiérarchie Page → Section → Sous-section → Items
• Observations :
• Utilisation de flexbox avec largeurs en pourcentage (33%, 50%, 60%, 80%, 95%, 100%)
• Variables CSS pour les couleurs
• Deux familles de polices : "Oswald" (titres) et "Noto Serif" (texte)
• Images avec aspect-ratio pour maintenir les proportions
• Prochaines étapes : Créer les interfaces TypeScript, créer le JSON mockup, développer les composants React
• Validation : Build réussi, aucune erreur
• Publication : Commit avec analyse types de contenu structurés

• Nom métier/DDD choisi : "Domaine de compétences" (au lieu de "Sous-section (groupe de 3 colonnes)")
• US-3.1 reformulée : Affichage d'un Domaine de compétences mockup sur la page d'accueil
• Fichier JSON créé : `data/index.json` avec structure :
• `domaineDeCompetences` : objet avec titre, contenu, items (array de 3 compétences)
• Chaque `competence` : titre, image (src, alt), description, bouton (optionnel)
• Backend pur créé : `utils/indexReader.ts` avec :
• Interface `Competence`
• Interface `DomaineDeCompetences`
• Interface `IndexData`
• Fonction `readIndexData()` pour lire le fichier JSON
• HomePage modifiée : `app/page.tsx` affiche maintenant le Domaine de compétences :
• Titre du domaine
• Contenu d'introduction
• 3 compétences affichées en flex (3 colonnes)
• Chaque compétence : titre, image, description, bouton (si présent)
• Architecture : Backend pur (indexReader.ts) → Server Component (page.tsx) → HTML généré côté serveur
• Validation : Build réussi, aucune erreur
• Publication : Commit avec implémentation US-3.1 - Affichage Domaine de compétences mockup

• Critères d'acceptation mis à jour : Ajout des critères CSS responsive dans l'US-3.1
• Composant créé : `components/DomaineDeCompetences.tsx` avec :
• Structure en 2 blocs : domaineHeader (titre + contenu) et competencesContainer (3 compétences)
• Parser Markdown inline pour gérer le gras dans les descriptions
• CSS créé : `components/DomaineDeCompetences.module.css` avec :
• `.container` : bloc principal avec `max-width: 1200px` et responsive (1400px+ = max-width: 1400px, <768px = padding réduit)
• `.domaineHeader` : sous-bloc horizontal prenant toute la largeur
• `.domaineTitre` : ligne 1, titre en gras (font-weight: bold, 2rem)
• `.domaineContenu` : ligne 2, texte normal (font-weight: normal, 1rem)
• `.competencesContainer` : second bloc avec flex-wrap pour 3 compétences
• `.competence` : sous-bloc pour chaque compétence (33.333% - 20px, min-width: 250px)
• `.competenceTitre` : ligne 1, titre
• `.competenceImage` : ligne 2, image (60% width, aspect-ratio: 1)
• `.competenceDescription` : ligne 3, texte avec support du gras via `<strong>`
• Responsive : <768px = compétences en pleine largeur, tailles de police réduites
• HomePage modifiée : Utilise le composant `DomaineDeCompetences` au lieu du code inline
• shared.module.css modifié : Retrait de `display: flex; align-items: center; justify-content: center;` pour permettre au contenu de prendre toute la largeur
• Validation : Build réussi, aucune erreur
• Publication : Commit avec implémentation CSS pour Domaine de compétences

• Structure JSON modifiée : Passage de `domaineDeCompetences` (singulier) à `domainesDeCompetences` (pluriel, tableau)
• 3 Domaines de compétences ajoutés :

1. "Stratégie et transformations" (déjà présent) :

• Culture d'entreprise
• Stratégie
• Conduite du changement

1. "Engager les équipes" (nouveau) :

• Facilitation
• Animation d'équipe
• Développement des talents

1. "Interactions humaines" (nouveau) :

• Communication interpersonnelle
• Gestion des conflits
• Intelligence collective
• Interface TypeScript mise à jour : `IndexData` utilise maintenant `domainesDeCompetences: DomaineDeCompetences[]`
• HomePage modifiée : Affiche maintenant tous les domaines via un `.map()`
• Validation : TypeScript compile sans erreur (vérifié avec `tsc --noEmit`)
• Note : Erreur de build EPERM (OneDrive verrouille les fichiers) - problème système, pas de code
• Publication : Commit avec ajout des 3 Domaines de compétences

• Images copiées : Toutes les images PNG du dossier "Exemple\Malain et possible - A propos de moi_files" vers "public\images\"
• 7 Domaines de compétences ajoutés/corrigés avec les bonnes compétences :

1. Stratégie et transformations : Culture d'entreprise, Stratégie, Conduite du changement
2. Engager les équipes : Le sens avant tout, Modélisation graphique, Détournement vidéo
3. Interactions humaines : Service client, Gestion des talents, Membre actif de communautés
4. Faire avec les équipes : No-code, Serious Game, Réseau social Professionnel
5. Développement informatique : Management de produit logiciel, Ingénierie logicielle, Data et Business Intelligence
6. Diagnostic civilisationnel : La science - Les faits, Les ordres de grandeur, Une vision systémique
7. Activités extra-professionnelles... au service de ma profession : Improvisation théâtrale, Jeux de stratégie, Musique

• Textes extraits du HTML : Tous les contenus et descriptions ont été extraits depuis le fichier HTML original
• Chemins d'images mis à jour : Tous les chemins pointent vers "/images/[nom_fichier].png"
• Validation : TypeScript compile sans erreur
• Publication : Commit avec correction et ajout de tous les Domaines de compétences avec images

• Polices identifiées depuis le HTML :
• `--font_default: "Oswald"` pour les titres (h2, h3)
• `"Noto Serif"` pour les textes (contenu, descriptions)
• `"Clint Marker"` pour les boutons
• Styles extraits du HTML :
• Titre de domaine (h2) : Oswald, 24px, font-weight: 700, line-height: 1.4, text-align: center, color: rgba(9, 23, 71, 1)
• Contenu de domaine : Noto Serif, 14px, font-weight: 400, line-height: 1.4, color: rgba(9, 23, 71, 1)
• Titre de compétence (h3) : Oswald, 18px, font-weight: 500, line-height: 1.4, text-align: center, color: rgb(0, 0, 0)
• Description de compétence : Noto Serif, 14px, font-weight: 400, line-height: 1.4, color: rgba(9, 23, 71, 1)
• Bouton : Clint Marker, 18px, font-weight: bold, line-height: 1, color: rgba(0, 112, 192, 1), background: #ffffff, border: 1px solid rgba(0, 112, 192, 1)
• globals.css mis à jour : Ajout de l'import Google Fonts pour "Clint Marker"
• DomaineDeCompetences.module.css mis à jour : Tous les styles remplacés par les valeurs exactes du design original
• Responsive ajusté : Tailles réduites proportionnellement pour petits écrans
• Validation : TypeScript compile sans erreur
• Publication : Commit avec mise à jour CSS selon design original

• 2 nouveaux Domaines de compétences ajoutés à la fin du JSON :

1. "Et si nous rendions votre entreprise stable malgré les fluctuations ?" :

• Résilience organisationnelle
• Adaptabilité stratégique
• Anticipation des risques

1. "La ROBUSTESSE est la réponse opérationnelle à un monde fluctuant !" :

• Architecture robuste
• Processus flexibles
• Culture de la robustesse
• Titre identifié dans le HTML : "Et si nous rendions votre entreprise stable malgré les fluctuations ?" trouvé dans le header flottant (h1)
• Section ROBUSTESSE : Non trouvée dans le HTML, créée en se basant sur le titre fourni et le contexte métier
• Images utilisées : Réutilisation d'images existantes (Excellence.png, Vision.png, Engagement.png, Vision partagée.png)
• Descriptions : Créées en cohérence avec le thème de stabilité et robustesse face aux fluctuations
• Validation : TypeScript compile sans erreur
• Publication : Commit avec ajout de 2 nouveaux Domaines de compétences

• 2 nouveaux Domaines de compétences ajoutés à la fin du JSON :

1. "Transformation & conduite du changement" :

• Contenu : "La distance entre rêve et réalité s'appelle l'action."
• 3 compétences :
• Faire émerger une vision partagée (Vision partagée.png, citation Antoine de Saint Exupéry)
• Réaliser un diagnostic sincère (Diagnostic.png, citation Proverbe tchadien)
• Générer de l'engagement (Engagement.png, citation John Lennon)

1. "Détournement de scènes cultes du cinéma" :

• Contenu : "L'usage des visuels au service des interactions pour soutenir un processus de travail."
• 3 compétences :
• Créativité (Facilitation.png en remplacement, citation Albert Einstein)
• Viralité (Linkedin.png en remplacement, citation Malcolm Gladwell)
• Engagement (Engagement.png, citation Simon Sinek)
• Images :
• Diagnostic.png copié depuis le dossier Transformation
• Images manquantes (Créativité.png, Viralité.png, Engagement par vidéo.png) : utilisation d'images de remplacement existantes
• Validation : TypeScript compile sans erreur
• Publication : Commit avec ajout de 2 nouveaux Domaines de compétences (Transformation & Détournement)

• Problème identifié : Le conteneur `.container` dans `DomaineDeCompetences.module.css` avait un `max-width: 1200px` (1400px pour très grands écrans), alors que l'utilisateur souhaitait une contrainte à 947px
• Solution : Modification de la contrainte `max-width` à 947px pour limiter la largeur du contenu
• Ajustements :
• Modification de `max-width: 1200px` à `max-width: 947px` du conteneur principal
• Modification de `max-width: 1400px` à `max-width: 947px` dans la media query pour très grands écrans
• Validation : TypeScript compile sans erreur
• Publication : Commit avec contrainte largeur contenu à 947px

• 3 nouveaux fichiers JSON créés :

1. `data/Conduite du changement.json` : Contient le domaine "Transformation & conduite du changement" avec ses 3 compétences
2. `data/Détournement vidéo.json` : Contient le domaine "Détournement de scènes cultes du cinéma" avec ses 3 compétences
3. `data/Robustesse.json` : Contient les 2 domaines sur la robustesse :

• "Et si nous rendions votre entreprise stable malgré les fluctuations ?"
• "La ROBUSTESSE est la réponse opérationnelle à un monde fluctuant !"
• Modification de `data/index.json` : Les 4 domaines extraits ont été retirés du fichier principal
• Structure JSON : Chaque fichier utilise la même structure que `index.json` avec un tableau `domainesDeCompetences`
• Validation : Tous les fichiers JSON sont valides (vérifiés avec JSON.parse)
• TypeScript : Compile sans erreur
• Publication : Commit avec extraction de domaines de compétences vers fichiers JSON séparés

• Fonction générique créée : `readDomaineData(filename: string)` dans `utils/indexReader.ts` pour lire n'importe quel fichier JSON de domaine de compétences
• 3 nouvelles pages créées :

1. `app/conduite-du-changement/page.tsx` : Affiche le domaine "Transformation & conduite du changement" depuis `Conduite du changement.json`
2. `app/detournement-video/page.tsx` : Affiche le domaine "Détournement de scènes cultes du cinéma" depuis `Détournement vidéo.json`
3. `app/robustesse/page.tsx` : Affiche les 2 domaines sur la robustesse depuis `Robustesse.json`

• Structure identique à HomePage : Chaque page utilise le même pattern :
• Server Component qui lit le JSON via le backend pur
• Utilise le composant `DomaineDeCompetences` pour l'affichage
• Utilise les mêmes styles (`shared.module.css`)
• Routes mises à jour : Ajout des 3 nouvelles routes dans `constants/routes.ts`
• Validation : TypeScript compile sans erreur
• Publication : Commit avec création de 3 nouvelles pages basées sur les fichiers JSON

• Correction des boutons : Tous les boutons "En savoir plus" ont été corrigés pour avoir "..." à la fin
• Bouton ajouté pour "Stratégie" : Ajout d'un bouton "En savoir plus..." dans `data/index.json` pour la compétence "Stratégie"
• Navigation configurée :
• "Stratégie" → `/robustesse`
• "Conduite du changement" → `/conduite-du-changement`
• "Détournement vidéo" → `/detournement-video`
• Composant mis à jour : `DomaineDeCompetences.tsx` converti en Client Component et utilise `Link` de Next.js pour la navigation
• CSS mis à jour : Le style du bouton fonctionne aussi pour les éléments `Link` (ajout de `text-decoration: none` et `display: inline-block`)
• Interface JSON : L'action du bouton contient maintenant directement la route (ex: `/robustesse`) au lieu d'une commande générique
• TypeScript : Compile sans erreur
• Publication : Commit avec configuration des boutons et navigation

• Titres supprimés : Suppression de tous les `<h1>` en haut de chaque page :
• `app/page.tsx` : Suppression de `<h1>Home page</h1>`
• `app/conduite-du-changement/page.tsx` : Suppression de `<h1>Conduite du changement</h1>`
• `app/detournement-video/page.tsx` : Suppression de `<h1>Détournement vidéo</h1>`
• `app/robustesse/page.tsx` : Suppression de `<h1>Robustesse</h1>`
• TypeScript : Compile sans erreur
• Publication : Commit avec suppression des titres de page

• US-3.2 créée : "Navigation depuis les boutons 'En savoir plus...' vers des pages dédiées"
• Format respecté : US formulée selon le format standard (En tant que, Je souhaite, Afin de, Critères d'acceptation)
• Cohérence avec le Sprint Goal : La navigation fait partie de la "structure hiérarchique" du site vitrine
• Critères d'acceptation : Couvrent la navigation, les pages dédiées, et les 3 domaines spécifiques (Stratégie → Robustesse, Conduite du changement, Détournement vidéo)
• Note : Les fonctionnalités déjà implémentées (création des pages, navigation des boutons) correspondent maintenant à cette US
• Publication : US ajoutée au Sprint en cours

• US-3.3 créée : "Enrichissement des pages avec de nouveaux types de contenu"
• Scénarios BDD créés : `tests/bdd/page-content-types.feature` avec 5 scénarios couvrant tous les types
• Interfaces TypeScript mises à jour :
• Nouveaux types : `ElementTitre`, `ElementVideo`, `ElementTexteLarge`, `ElementDomaineDeCompetence`
• Union type : `ElementContenu` pour tous les types
• Nouvelle structure : `PageData` avec `contenu: ElementContenu[]`
• Fonction de conversion : `convertirIndexDataEnPageData()` pour compatibilité ascendante
• 3 nouveaux composants créés en TDD strict :

1. `components/Titre.tsx` : Bande bleue foncée pleine largeur avec h1 (tests passent ✅)
2. `components/Video.tsx` : Incrustation YouTube responsive avec gestion lancement auto (tests passent ✅)
3. `components/TexteLarge.tsx` : Texte style titre domaine (947px max) (tests passent ✅)

• CSS créé pour chaque composant avec responsive
• Composant de rendu unifié : `PageContentRenderer.tsx` qui affiche tous les types selon leur `type`
• Pages mises à jour : Toutes les pages utilisent maintenant `readPageData()` et `PageContentRenderer`
• Compatibilité ascendante : Les JSON existants (ancienne structure) sont automatiquement convertis
• TypeScript : Compile sans erreur
• Tests : Tous les tests unitaires passent (9 tests au total)
• Publication : Commit avec implémentation complète de l'US-3.3

• Renommage complet : "TeteLarge" → "TexteLarge" dans tout le code
• Fichiers renommés :
• `components/TeteLarge.tsx` → `components/TexteLarge.tsx`
• `components/TeteLarge.module.css` → `components/TexteLarge.module.css`
• `tests/unit/TeteLarge.test.tsx` → `tests/unit/TexteLarge.test.tsx`
• Interfaces TypeScript mises à jour :
• `ElementTeteLarge` → `ElementTexteLarge`
• `type: 'teteLarge'` → `type: 'texteLarge'`
• `TypeElementContenu` mis à jour
• Références mises à jour :
• `PageContentRenderer.tsx` : import et case statement
• `US-3.3` : critères d'acceptation mis à jour
• Scénarios BDD mis à jour
• Tests : Tous les tests passent (3 tests ✅)
• TypeScript : Compile sans erreur
• Publication : Commit avec correction du nommage

• JSON restructuré : `data/index.json` converti de l'ancienne structure (`domainesDeCompetences`) vers la nouvelle structure (`contenu`)
• Nouveaux éléments ajoutés au début du contenu, avant "Stratégie et transformations" :

1. Titre : "Mon parcours, mes transformations"
2. Vidéo : https://youtu.be/wcvG-WfKckU (lancementAuto: false)
3. TexteLarge : Texte de présentation complet
4. Titre : "Mes convictions acquises par empirisme"

• Tous les domaines de compétences convertis en éléments de type `domaineDeCompetence` dans la nouvelle structure
• TypeScript : Compile sans erreur
• Publication : Commit avec ajout de contenu enrichi

• Marge ajoutée au Titre : `margin-top: 10px` ajouté à `.titreContainer` pour séparer le composant de la tête de page
• Style TexteLarge modifié : Changé de style "titre" vers style "texte normal" :
• Font-family : 'Oswald' → 'Noto Serif'
• Font-size : 24px → 14px
• Font-weight : 700 → 400
• Text-align : center → left
• Style aligné avec `.domaineContenu` pour cohérence
• TypeScript : Compile sans erreur
• Publication : Commit avec ajustements CSS

• CSS mis à jour : Ajout de `white-space: pre-line` à `.texteLargeText` pour préserver les retours à la ligne (`\n`) du JSON
• Fonctionnement : `white-space: pre-line` préserve les retours à la ligne mais normalise les espaces multiples, ce qui permet d'afficher correctement les `\n` du JSON
• TypeScript : Compile sans erreur
• Publication : Commit avec correction de l'affichage des retours à la ligne

• Padding réduit : Le padding vertical du `.titreContainer` passe de `2rem` à `1rem` (50% de la taille de la police `2rem`)
• Responsive ajusté : Le padding vertical passe de `1.5rem` à `0.75rem` (50% de la taille de la police `1.5rem` en mobile)
• Ratio respecté : Les marges haut et bas font maintenant 50% de la taille de la police au lieu de 100%
• TypeScript : Compile sans erreur
• Publication : Commit avec réduction de la hauteur de la bande bleue

• CSS responsive mis à jour : Ajout d'une media query `@media (min-width: 769px)` pour les écrans normaux/grands
• Comportement :
• Mobile (≤768px) : La vidéo prend 100% de la largeur (comportement existant)
• PC/Tablette (≥769px) : La vidéo fait 70% de la largeur avec un max-width de 947px pour cohérence
• TypeScript : Compile sans erreur
• Publication : Commit avec ajustement de la largeur responsive de la vidéo

• Largeur vidéo réduite : Sur les écrans normaux/grands (≥769px), la vidéo passe de 70% à 50% de la largeur
• Max-width ajusté : Réduit de 947px à 600px pour correspondre au site d'origine
• Mobile inchangé : Sur smartphone (≤768px), la vidéo reste à 100% de la largeur pour éviter qu'elle soit trop petite
• Alignement : La taille de la vidéo correspond maintenant mieux au site d'origine cloné
• TypeScript : Compile sans erreur
• Publication : Commit avec réduction de la largeur de la vidéo sur PC

• Approche mobile-first : Styles de base définis pour mobile (≤768px) : `width: 100%`, `padding: 1rem`
• Media query desktop : Utilisation de `min-width: 769px` pour override sur desktop : `width: 70%`, `max-width: 600px`, `padding: 2rem 1rem`
• Duplication éliminée : Suppression de la media query `max-width: 768px` redondante
• Logique claire : "Mobile par défaut (100%), desktop si ≥769px (70%)"
• Bonnes pratiques : Respect de l'approche mobile-first recommandée en CSS moderne
• TypeScript : Compile sans erreur
• Publication : Commit avec refactoring CSS mobile-first

• Titre.module.css : Converti en mobile-first
• Styles de base pour mobile (padding: 0.75rem, font-size: 1.5rem)
• Media query `min-width: 769px` pour desktop (padding: 1rem, font-size: 2rem)
• TexteLarge.module.css : Converti en mobile-first
• Styles de base pour mobile (padding: 1.5rem 1rem)
• Media query `min-width: 769px` pour desktop (padding: 2rem 1rem)
• Suppression de la duplication `font-size: 14px` (identique mobile/desktop)
• DomaineDeCompetences.module.css : Converti en mobile-first
• Styles de base pour mobile (padding: 15px, tailles réduites)
• Media query `min-width: 769px` pour desktop (padding: 20px, tailles normales)
• Suppression de la media query `min-width: 1400px` redondante (max-width déjà défini)
• Approche cohérente : Tous les fichiers CSS suivent maintenant l'approche mobile-first
• Duplications éliminées : Aucune propriété redondante entre mobile et desktop
• TypeScript : Compile sans erreur
• Publication : Commit avec refactoring global CSS mobile-first

• Largeur maximale augmentée : `max-width` passé de `947px` à `1200px` pour mieux exploiter la largeur sur grand écran
• `DomaineDeCompetences.module.css` : `.container` max-width: 1200px
• `TexteLarge.module.css` : `.texteLargeContainer` max-width: 1200px
• Tailles de police augmentées pour meilleure lisibilité :
• `.domaineContenu` : 14px → 16px (desktop)
• `.competenceDescription` : 14px → 16px (desktop)
• `.texteLargeText` : 14px → 16px (desktop, mobile reste 14px)
• Alignement avec site d'origine : Le texte est maintenant plus gros et plus lisible, et la largeur est mieux exploitée
• TypeScript : Compile sans erreur
• Publication : Commit avec amélioration lisibilité

• Syntaxe correcte : Les `\n` dans le JSON sont la bonne syntaxe pour les retours à la ligne
• CSS manquant : Ajout de `white-space: pre-line` à `.competenceDescription` et `.domaineContenu` pour préserver les retours à la ligne
• Fonctionnement : `white-space: pre-line` préserve les retours à la ligne (`\n`) mais normalise les espaces multiples, comme pour `TexteLarge`
• Exemple : `"description": "Texte ligne 1\n\nTexte ligne 2"` s'affichera avec un saut de ligne entre les deux phrases
• TypeScript : Compile sans erreur
• Publication : Commit avec correction de l'affichage des retours à la ligne

• Erreur trouvée : Ligne 205 du journal contenait un titre H1 (`# Titre epics`) dans un exemple de format
• Correction : Exemple mis dans un bloc de code markdown (```) pour être ignoré par le parser
• DOD mise à jour :
• Ajout de la règle dans `5. Journal de bord.md` : les fichiers journal doivent respecter les règles de validation (pas de H1/H2)
• Ajout de la règle dans `6. Comportement implicite de l'IA.md` : même règle pour l'IA lors de l'écriture du journal
• Règle : si un exemple contient des titres H1/H2, il doit être dans un bloc de code markdown
• Test d'intégration créé : `tests/integration/aboutSiteReader.integration.test.ts` qui valide tous les fichiers MD réels du projet
• Résultat : Le test fait échouer le build si un fichier contient un H1/H2, permettant de détecter les erreurs lors des tests plutôt qu'au runtime
• Publication : Commit avec correction journal, mise à jour DOD, et test d'intégration

• US créée : US-3.4 ajoutée dans le fichier de sprint
• Étape 1 : CallToAction
• Nouveau type `callToAction` ajouté à `TypeElementContenu` dans `utils/indexReader.ts`
• Interface `ElementCallToAction` créée avec champ `action: string`
• Composant `CallToAction.tsx` créé avec style similaire à "En savoir plus..." mais largeur max 947px (même qu'un Domaine de compétence)
• CSS mobile-first avec hover effect
• `PageContentRenderer` mis à jour pour gérer le nouveau type
• CallToAction ajouté à la fin de tous les JSON (`index.json`, `Conduite du changement.json`, `Détournement vidéo.json`, `Robustesse.json`)
• Bouton redirige vers `/faisons-connaissance`
• Étape 2 : Page "Faisons connaissance"
• Nouvelle page `/faisons-connaissance` créée (`app/faisons-connaissance/page.tsx`)
• Composant `FaisonsConnaissanceContent.tsx` créé avec :
• Titre "Faisons connaissance"
• Section contact avec :
• Bouton "Déjeuner aux alentours de Lyon" (icône couverts)
• Bouton "30 mn de visio" (icône vidéo)
• Numéro de téléphone : +33 6.21.03.12.65 (icône téléphone)
• Section réseaux sociaux avec liens :
• Email (icône enveloppe)
• YouTube (icône YouTube)
• LinkedIn (icône LinkedIn)
• CSS mobile-first responsive avec styles cohérents avec le reste du site
• Route ajoutée dans `constants/routes.ts`
• Utilisation des icônes lucide-react (UtensilsCrossed, Video, Phone, Mail, Youtube, Linkedin)
• TypeScript : Compile sans erreur
• Publication : Commit avec implémentation complète US-3.4

• US créée : US-3.5 ajoutée dans le fichier de sprint avec critères d'acceptation détaillés
• BDD créées : 11 scénarios BDD dans `tests/bdd/faisons-connaissance.feature`
• TDD Unitaires : 6 tests unitaires créés pour `GroupeBoutons.test.tsx` (tous passent)
• Nouveau type de contenu "groupeBoutons" :
• Interface `ElementGroupeBoutons` et `BoutonGroupe` créées dans `utils/indexReader.ts`
• Type `groupeBoutons` ajouté à `ElementContenu`
• Support des tailles "petite" et "grande"
• Composant GroupeBoutons créé :
• Affichage horizontal (petite) ou vertical (grande)
• Icônes uniquement (petite) ou icône + texte (grande)
• Couleur inversée (BleuFonce sur fond clair) vs footer (blanc sur BleuFonce)
• Réutilisation de la logique `getButtonAction` du footer
• Détection des URLs locales pour navigation interne Next.js
• JSON faisons-connaissance.json créé :
• Titre "Faisons connaissance"
• Groupe "grande" avec 3 boutons (Déjeuner, Visio, Téléphone)
• Groupe "petite" avec 3 boutons (Email, YouTube, LinkedIn)
• Page "/faisons-connaissance" refactorisée : Utilise maintenant `PageContentRenderer` au lieu de l'ancien composant
• Intégration : `PageContentRenderer` gère le nouveau type `groupeBoutons`
• Ajustements :
• Grands boutons : largeur fixe de 400px, texte 22px (mobile) et 24px (desktop)
• Petits boutons : même taille que le footer (padding: 0, icône 30px, pas de contours)
• URLs locales : détection et navigation interne via `router.push`
• Steps BDD créés : `tests/bdd/faisons-connaissance.steps.ts` avec tous les steps nécessaires
• TypeScript : Compile sans erreur
• Tests : Tous les tests unitaires passent (6/6)
• Publication : Commit avec implémentation complète US-3.5 en TDD strict

• US créée : US-3.6 ajoutée dans le fichier de sprint avec critères d'acceptation détaillés
• Contexte de détection précisé :
• Section "Critères d'acceptation" commence par `- Critères d'acceptation :` (détectée avec `typeDeContenu: "Critères d'acceptation"`)
• Section se termine à la prochaine US (`#### US-`), un séparateur `---`, ou la fin de la sous-partie (H4)
• Dans cette section uniquement : détection des thèmes (`- **`) et critères (`- `)
• BDD créées : 10 scénarios BDD dans `tests/bdd/criteres-acceptation.feature` couvrant :
• Détection de la section "Critères d'acceptation"
• Fin de section (prochaine US, séparateur, fin sous-partie)
• Détection des thèmes de critères (`- **`)
• Détection des critères normaux (`- `)
• Hiérarchie thème-critères
• Affichage CSS (puce niveau 1/2, gras/normal, indentation)
• Règle dans la DOD pour l'IA
• En attente de validation : BDD créées, prêtes pour validation avant implémentation en TDD strict

• TDD strict : RED → GREEN → REFACTOR
• Tests unitaires créés : `tests/unit/criteresAcceptation.test.ts` avec 8 scénarios
• Tests RED : Tous les tests échouent initialement (comportement attendu)
• Tests GREEN : Tous les tests passent après implémentation
• Modification du parser (`utils/aboutSiteReader.ts`) :
• `detecterUserStory` modifiée pour accepter le contenu brut (`contenuBrut`) en plus des éléments parsés
• Détection de la fin de section "Critères d'acceptation" :
• Fin à la prochaine US : ligne commençant par `#### US-`
• Fin à un séparateur : ligne `---`
• Fin à la fin de la sous-partie (H4)
• Détection des thèmes de critères : lignes commençant par `- ` (sauf `- Critères d'acceptation**`)
• Attribution de `typeDeContenu: "themeCritere"`
• Détection des critères normaux : lignes commençant par `- ` (sans `**` au début)
• Attribution de `typeDeContenu: "critere"`
• Hiérarchie thème-critères : les critères sont automatiquement associés au dernier thème rencontré
• Modification du renderer (`components/AboutSiteContentRenderer.tsx`) :
• Gestion des thèmes de critères : affichage avec le style `themeCritere` (puce niveau 1, gras)
• Gestion des critères normaux : affichage avec le style `critere` (puce niveau 2, indenté, normal)
• Utilisation de `parseInlineMarkdown` pour rendre le gras correctement
• Modification des styles CSS (`components/AboutSiteContentRenderer.module.css`) :
• Style `.themeCritere` : indentation 35px (niveau 1), texte en gras, marges ajustées
• Style `.critere` : indentation 55px (niveau 2, +20px par rapport aux thèmes), texte normal, marges ajustées
• Hiérarchie visuelle claire entre thèmes et critères
• Mise à jour de la DOD (`A propos de ce site/3. Definition of Done (DOD)/6. Comportement implicite de l'IA.md`) :
• Ajout de la section "13. Écriture des 'Critères d'acceptation' dans les User Stories"
• Règles détaillées pour la structure hiérarchique des critères d'acceptation
• Exemples de format correct
• Tests unitaires : 8/8 tests passent
• Détection de la section "Critères d'acceptation"
• Fin de section (prochaine US, séparateur, fin de sous-partie)
• Détection des thèmes de critères (`- **`)
• Détection des critères normaux (`- `)
• Hiérarchie thème-critères
• Cas complexes avec plusieurs thèmes et critères
• TypeScript : Compile sans erreur
• Tests : Tous les tests unitaires passent (8/8)
• Publication : Prêt pour commit avec implémentation complète US-3.6 en TDD strict

• US-3.8a créée : "Création du type de contenu 'témoignage'"
• Interface TypeScript : `Temoignage` et `ElementTemoignages` ajoutées dans `utils/indexReader.ts`
• Composant créé : `components/Temoignages.tsx` avec affichage en 2 colonnes
• CSS créé : `components/Temoignages.module.css` avec styles responsive, nom en h2 bleu
• 5 témoignages ajoutés : Dans `data/index.json` avec photos, noms, fonctions et textes
• HomePage mise à jour : Titre "Témoignages" et composant `Temoignages` ajoutés à la fin
• Alignement dernier impair : CSS `.lastOdd` pour aligner à gauche le dernier témoignage si nombre impair
• TypeScript : Compile sans erreur
• Publication : Commit avec implémentation complète US-3.8a

• US-3.8b créée : "Création du type de contenu 'portfolio détournements'"
• CSV converti en JSON : Fichier `data/Détournements vidéo.json` créé depuis le CSV fourni
• Interface TypeScript : `DetournementVideo` et `ElementVideoDetournement` ajoutées dans `utils/indexReader.ts`
• Composant créé : `components/VideoDetournement.tsx` avec :
• Affichage des détournements les uns sous les autres
• Chaque détournement : titre H2 (fond bleu clair #E7F6FF), pitch, 2 vidéos côte à côte
• Iframes YouTube directement intégrées (pas de composant Video pour éviter les contraintes de taille)
• Bouton LinkedIn et icône d'alerte droits d'auteur avec popup non-bloquant
• CSS créé : `components/VideoDetournement.module.css` avec :
• Titre H2 : fond bleu clair (#E7F6FF), texte noir
• Container : max-width 947px (mobile) / 1300px (desktop)
• Vidéos : 97% de leur colonne (avec 1.5% padding de chaque côté)
• Espace entre vidéos : 30px
• Espaces réduits : 0.25rem entre titre/descriptif/vidéos
• Icône d'alerte à gauche du bouton LinkedIn (flex-direction: row, order: 1/2)
• Tri chronologique inversé : Fonction `parseDate()` pour parser les dates "jj/mm/aaaa" et trier par ordre décroissant
• Constante CSS créée : `--BleuClair: #E7F6FF` dans `app/globals.css` pour utilisation globale
• Page créée : `/portfolio-detournements` avec titre H1 et liste des détournements
• TypeScript : Compile sans erreur
• Publication : Commit avec implémentation complète US-3.8b

• 4 User Stories créées dans le fichier de sprint :
• US-3.7 : Reprise du contenu manquant qui utilise les typeDeContenu existants
• US-3.8 : Création de nouveaux typeDeContenu pour finaliser la reprise du contenu existant (découpée ensuite en 3.8a et 3.8b)
• US-3.9 : Conservation des URLs de l'ancien site
• US-3.10 : Création de la page "Plan du site"
• Ordre de travail défini : US-3.9 en premier, puis US-3.7, puis US-3.8a et US-3.8b
• US-3.8 découpée : En deux sous-tâches : "témoignage" (US-3.8a) et "portfolio détournements" (US-3.8b)