Standards de Gouvernance & Templates

Référentiel de rigueur documentaire et automatisation

STD

Introduction

Ce référentiel définit les normes de rigueur applicables à l’ensemble de l’écosystème documentaire de l’organisation edpi-org. Le respect de ces standards est une condition sine qua non pour la validation et le déploiement des livrables via le pipeline CI/CD.

Note d’application (Double Standard) : Les règles définies dans ce document s’appliquent de manièresuivante : 1. Dossier /docs : Soumis au standard EDPI-STD complet. Le non-respect du YAML ou de la nomenclature bloque le pipeline. 2. Dossier /notes : Soumis à un linter allégé. Le YAML est simplifié (uniquement title et categories) et la nomenclature est libre pour faciliter l’indexation sémantique et le partage social.

1. Nomenclature et Formats

Tout livrable intégré au dépôt doit suivre l’un des deux formats suivants : - Documents Racine (.md) : Uniquement pour README, CONTRIBUTING, LICENSE. - Documents Techniques (.qmd) : Pour tous les livrables du dossier /docs.

Règle de nommage : EDPI-[TYPE]-[ETAT]-v[X.Y].qmd

Identificateurs de TYPE

CHARTE / STD : Gouvernance, vision et normes.
STB : Spécifications Techniques et Besoins (Métiers & Fonctionnels).
DAL : Dossier d’Architecture Logicielle (Conception Technique).
PVA : Plan de Validation et d’Assurance Qualité (Tests).
DEX : Dossier d’Exploitation (Maintenance, CI/CD, Monitoring).

Indicateurs d’ÉTAT

DRAFT : Document en cours de rédaction (Soumis à modification).
FINAL : Document validé, stable et versionné.

2. Encodage et Fins de Ligne

Pour garantir la compatibilité avec les scripts de validation (Ubuntu) : - Encodage : UTF-8 strict. - Fin de ligne (EOL) : LF (Unix style). Impératif pour éviter les erreurs de linter sur GitHub Actions.

3. Standard de Qualité : Markdownlint

Pour assurer une lisibilité universelle sur PC et Mobile (Android/iOS), chaque fichier doit satisfaire les règles du linter. Toute violation bloque automatiquement le déploiement.

Règles Critiques à respecter

MD001 (Header Levels) : La hiérarchie des titres doit être progressive (H1 > H2 > H3). Ne sautez jamais de niveau.
MD022 (Headers Margins) : Les titres doivent être entourés de lignes vides.
MD032 (Lists Margins) : Les listes doivent être séparées du texte par des lignes vides pour un rendu correct sur les lecteurs mobiles.

Template Officiel (Structure YAML)

Tout document doit obligatoirement débuter par ce bloc de métadonnées pour permettre au moteur Quarto de générer les rendus HTML/PDF de façon cohérente.

---
# --- MÉTADONNÉES OBLIGATOIRES (EDPI-STD-v1.0) ---
title: "NOM_DU_DOCUMENT"
subtitle: "DESCRIPTION_COURTE"
author: "Lorein Du Perron"
date: last-modified
categories: [CODE_TYPE] # Ex: STB, DAL, DEX

# Bloc de Gouvernance EDPI
Projet: "EDPI-Docs"
Organisation: "edpi-org"
Responsable: "Lorein Du Perron"
Formalisme: "SDLC-Standard-v1.0"
Code: "EDPI-XXX"
Version: "DRAFT" # Ou FINAL

# Configuration du rendu
format:
  html:
    toc: true
    number-sections: true
    code-fold: true
---

comme exemple, pour ce document ci meme, sa Structure YAML est la suivante :

---
# --- MÉTADONNÉES OBLIGATOIRES (EDPI-STD-v1.0) ---
title: "Standards de Gouvernance & Templates"
subtitle: "Référentiel de rigueur documentaire et automatisation"
author: "Lorein Du Perron"
date: last-modified
lang: fr-FR
categories: [STD] # Ex: STB, DAL, DEX

# Bloc de Gouvernance EDPI
Projet: "EDPI-Docs"
Organisation: "edpi-org"
Responsable: "Lorein Du Perron"
Formalisme: "SDLC-Standard-v1.0"
Code: "EDPI-STD"
Version: "FINAL" # Ou DRAFT

# Configuration du rendu
format:
  html:
    toc: true
    number-sections: true
    code-fold: true
---

Processus de Validation (Workflow)

Le passage d’un document à l’état FINAL est subordonné au succès du pipeline Qualité :

Zéro Erreur Linter : Validation locale via markdownlint.
Success Build : Rendu Quarto sans avertissement (Warning) sur la branche develop.
Peer-Review : Validation finale par le responsable du projet avant fusion sur main.

Dernière mise à jour : r Sys.Date()