Règles de l’agent IA - Publications FO Matmut

Ce document définit les directives, conventions et règles que l’agent IA doit respecter sur le projet publications-fo-matmut.

1. Contexte du projet

• Nature du projet : Site de publications syndicales (FO Matmut), géré avec le générateur de site statique Hugo et l’extension FrontMatter CMS.
• Langue principale : Français (orthographe et grammaire soignées).
• Environnement local et Hugo : Le moteur Hugo n’est pas installé sur ce poste local (la génération du site est effectuée à distance via la CI/CD). L’agent ne doit JAMAIS tenter d’exécuter la commande hugo en ligne de commande.

2. Structure des contenus

Les articles et documents sont organisés par catégories dans les répertoires suivants :

• actu/ : Actualités juridiques, déclarations CSE, brèves et informations d’actualité.
• tracts/ : Tracts et communications syndicales.
• dossiers/ : Dossiers thématiques de fond (causes nationales, temps de travail, etc.).
• editos/ : Éditoriaux.
• accords/ : Accords d’entreprise et documents juridiques associés.
• gazettes/ : Publications périodiques / gazettes.
• media/ : Fichiers médias (images, visuels, PDF).

3. Conventions de nommage et d’emplacement des fichiers

Pour les publications périodiques et chronologiques (tracts/, actu/, editos/) :

• Format strict horodaté : YYYY-MM-DD_titre_court_en_minuscules.md
• Date : Le tiret - doit impérativement être utilisé comme séparateur dans la date (YYYY-MM-DD).
• Espaces : Le tiret bas _ (underscore) doit être utilisé pour remplacer les espaces.
• Casse : Aucune majuscule (tout en minuscules exclusivement).
• Interdictions strictes : Aucun espace, aucun caractère accentué ni caractère spécial.
• Exemple : 2026-08-14_declaration_fo_matmut_au_cse_sur_la_politique_sociale.md

Pour les dossiers thématiques (dossiers/) :

• Format du fichier : <sujet_court_en_minuscules>.md (tout en minuscules, sans espaces, sans accents, mots séparés par _).
• Pas d’horodatage YYYY-MM-DD_ par défaut dans le nom de fichier (sauf s’il s’agit d’une déclaration ou d’un document spécifiquement daté au sein d’un dossier).
• Arborescence & Emplacement :
  • Dossier de fond / guide permanent : directement sous le thème, ex. dossiers/<theme>/<sujet_court>.md (ex. dossiers/rupture_du_contrat_de_travail/mettre_fin_au_contrat.md).
  • Dossier annuel / événementiel : sous le millésime de l’année, ex. dossiers/<theme>/<annee>/<sujet_court>.md (ex. dossiers/rps/2024/pgis.md).
  • Index de section : Chaque sous-dossier doit comporter son fichier _index.md.

Détermination interactive du nom et de l’emplacement :

• Lorsque le rédacteur sollicite l’agent pour créer ou nommer un nouvel article, l’agent doit être capable de déterminer le nom et l’emplacement exacts en lui posant au préalable les questions nécessaires :
  1. Le type de publication (tract, actu, édito, dossier, etc.).
  2. La date de publication envisagée.
  3. Pour un dossier : le thème (existant ou nouveau) et son caractère intemporel/guide permanent ou rattaché à une année spécifique.
  4. Le sujet court pour formater correctement le nom de fichier en minuscules et snake_case.

4. Format et conventions du Frontmatter

Chaque article Markdown doit comporter un en-tête Frontmatter au format TOML (+++) conforme à la configuration frontmatter.json :

+++
title = "Titre explicite de la publication"
date = "YYYY-MM-DDTHH:MM:SS.000Z"
lastmod = "YYYY-MM-DDTHH:MM:SS.000Z" # si modification substantielle
draft = false
tags = [ "Actu_juridique" ] # ou autres tags existants
summary = "Résumé concis de l'article." # réservé aux tracts et actus
une = false # true si l'article doit être mis en avant
description = ""
+++

Champs importants :

• title : Titre clair, percutant et informatif.
• date : Date de création / publication (obligatoire dès la création de l’article, au format ISO YYYY-MM-DDTHH:MM:SS.000Z).
• lastmod : Date de modification (doit être impérativement renseignée lors de toute modification substantielle du contenu, au format ISO YYYY-MM-DDTHH:MM:SS.000Z).
• summary : Utilisé pour les tracts (tracts/) et les actualités (actu/). Pour les autres types de contenus (éditos, accords, dossiers, etc.), ce champ n’est pas renseigné. Synthèse en 1 à 3 phrases qui doit donner le contexte de la publication et susciter l’envie d’en savoir plus.
• tags : Utiliser en priorité les tags existants dans le projet.
• draft : true pour un brouillon en cours de rédaction, false une fois finalisé.

Règle de vérification obligatoire :

• Validation systématique : La validité syntaxique du frontmatter en TOML doit impérativement être vérifiée après chaque modification ou création (respect strict des délimiteurs +++, types de valeurs : chaînes entre guillemets, booléens true/false, tableaux de tags [ "..." ], format de date ISO).

5. Ligne éditoriale, typographie et style de rédaction

• Ton : Professionnel, factuel, engagé, rigoureux juridiquement (droit du travail, accords collectifs, prérogatives CSE).
• Positionnement : Défense des intérêts, des conditions de travail et des droits des salariés de la Matmut (organisation syndicale Force Ouvrière).
• Structure des articles :
  • Titre accrocheur et informatif.
  • Chapeau / introduction synthétisant les faits majeurs.
  • Corps de texte structuré avec des intertitres (##, ###), des listes à puces et du gras pour faciliter la lecture.
  • Conclusion / revendications claires de FO Matmut.

Typographie française & Ponctuation :

• Espaces insécables : Insérer obligatoirement un espace insécable avant les signes de ponctuation double ( :,  ;,  ?,  !).
• Guillemets :
  • Utiliser les guillemets à la française (« et ») pour les citations ainsi que pour les expressions employées par l’auteur, avec un espace insécable à l’intérieur (« texte »).
  • Utiliser les guillemets droits/normaux ("...") pour les autres cas d’utilisation (termes techniques, valeurs de configuration, etc.).
• Éléments strictement proscrits :
  • Emojis : Ne JAMAIS utiliser d’emojis.
  • Tirets quadratins : Ne JAMAIS utiliser de tiret quadratin (—).

Gestion du Markdown et mise en évidence :

• Conformité CommonMark : Tous les fichiers Markdown doivent impérativement respecter la spécification CommonMark (syntaxe standard pour les listes, paragraphes, intertitres, liens et blocs de texte).
• Format des liens internes : Lors de la création d’un lien Markdown vers un article ou document interne, le lien doit obligatoirement pointer vers le fichier Markdown avec son extension .md (ex. [texte](/dossiers/rgpd/declaration_sirh/) ou [texte](mon_fichier.md)). Il ne faut JAMAIS supposer que le fichier sera transformé en répertoire sans extension par le générateur de site.
• Hiérarchie de mise en valeur : La mise en valeur des éléments dans le texte se fait selon l’ordre hiérarchique suivant :
  1. Italique (*texte*) : premier niveau de mise en valeur.
  2. Gras (**texte**) : deuxième niveau de mise en valeur.
  3. Gras et italique (***texte***) : niveau d’accentuation maximale (Note : le rendu sur le site correspond à un texte en gras/italique blanc sur fond surligné en rouge).

Règle générale d’alerte au rédacteur :

• Alerte systématique : Lors de la création ou de la modification d’une publication (article, tract, actu, édito, etc.) dont la date de publication date de moins de 2 jours ou est ultérieure, si l’une des règles de rédaction, de typographie, de nommage, de structure ou de frontmatter n’est pas respectée, l’agent doit impérativement le signaler au rédacteur.

6. Règles spécifiques aux tracts (tracts/)

Pour toute publication dans le répertoire tracts/ :

• Titre (title) : Le terme “Matmut” doit obligatoirement être présent dans le titre.
• Titre ou Résumé (summary) : Les termes “FO” et “Matmut” doivent impérativement être présents dans le titre ou dans le summary.

Un tract possède toujours un fichier PDF (qui contient le contenu du tract en version PDF) et qui porte le même nom que le fichier markdown, seule l’extension étant différente. Le fichier marckdown et le fichiers PDF sont enregistrés dans le même répertoire tracts.

Exemple :

• tracts/tract-n-1-titre-du-tract.md
• tracts/tract-n-1-titre-du-tract.pdf

7. Articulation et mise à jour des dossiers thématiques (dossiers/)

• Proposition proactive lors d’un commit : Lorsque le rédacteur demande un commit concernant une nouvelle actualité (actu/) ou un nouveau tract (tracts/), l’agent doit systématiquement lui proposer de mettre à jour le dossier thématique correspondant dans dossiers/.
• Procédure de mise à jour d’un dossier :
  1. Identification du dossier lié : Déterminer le dossier thématique approprié (existant ou nouveau thème à créer).
  2. Intégration du contenu : Reprendre les points principaux et éléments clés de la publication pour enrichir le dossier de fond.
  3. Lien de référence : Insérer si nécessaire un lien Markdown dans le dossier pointant vers la nouvelle publication.
  4. Suggestions et accord préalable : L’agent doit obligatoirement soumettre ses suggestions de modifications au rédacteur et ne mettre à jour le dossier qu’après avoir reçu son accord explicite.

8. Gestion de Git, synchronisations et accompagnement pédagogique

• Posture bienveillante et pédagogique : Le rédacteur n’étant pas un professionnel de l’informatique et n’étant pas à l’aise avec Git, l’agent doit toujours faire preuve de pédagogie, expliquer simplement le but de chaque commande (sans jargon technique complexe) et guider le rédacteur étape par étape en toute sécurité.
• Branche de travail : TOUJOURS travailler sur la branche main, sauf demande explicite contraire du rédacteur.
• Synchronisation initiale (git pull) : Au début de chaque nouvelle discussion, avant d’effectuer la moindre modification de fichier, l’agent doit systématiquement proposer de synchroniser le projet local avec le serveur distant (git pull) pour être certain de travailler sur la version la plus récente.
• Interdiction formelle de commit direct ou automatique : EN AUCUN CAS l’agent ne doit commiter directement ou de façon autonome, même si le rédacteur lui demande de commiter (ex. « fais un commit », « commite »). Les commits automatiques ou directs sont STRICTEMENT ET FORMELLEMENT INTERDITS, afin de garantir une revue préalable systématique.
• Principe d’autorisation explicite : Tous les commits doivent être effectués directement par le rédacteur, ou EXPLICITEMENT et UN PAR UN autorisés par celui-ci.
• Protocole obligatoire pour tout commit (proposé par l’agent ou demandé par l’utilisateur) :
  1. L’agent doit PROPOSER un message de commit précis et clair en français.
  2. L’agent doit LISTER l’ensemble exhaustif des fichiers concernés.
  3. L’agent doit DEMANDER EXPLICITEMENT LA CONFIRMATION au rédacteur en posant une question exigeant une réponse par OUI ou NON.
  4. Sans confirmation explicite (« OUI ») reçue en réponse, aucun commit ne doit être déclenché.
• Synchronisation finale (git push) : Après chaque commit validé et exécuté, l’agent doit systématiquement proposer au rédacteur de publier/sauvegarder les modifications sur le serveur distant (git push).

9. Précautions et sécurité

• Intégrité des contenus existants : Ne jamais supprimer ou écraser d’articles existants sans demande explicite.
• Renommage ou déplacement d’articles : Lors de toute modification du nom de fichier ou de l’emplacement d’un article, vérifier impérativement que les liens Markdown (internes ou externes pointant vers cet article) fonctionnent toujours et ne sont pas brisés (mettre à jour les liens ou ajouter un aliases dans le frontmatter si nécessaire).
• Vérification des liens et médias : S’assurer que les liens vers les PDF ou images dans media/ sont valides.
• Préservation du balisage : Conserver la compatibilité Hugo (shortcodes éventuels, format TOML/Markdown).
• Interdiction des commandes Hugo locales : Ne jamais exécuter la binaire hugo sur le poste.