Rédaction pilotée par la spec : pourquoi elle surpasse le ChatGPT brut

Rédiger des documents complexes et réglementés — politiques, récits de contrôles, rapports CAPA, dossiers d’autorisation — avec une interface de chat générique est tentant : on colle un prompt et on obtient un brouillon. Le problème, c’est la cohérence, la structure et la conformité. Les prompts ponctuels n’imposent pas de workflow, ne lancent pas de vérifications et ne donnent pas au modèle le moyen de se corriger. La rédaction pilotée par la spec dans Rakenne inverse la logique : les skills définissent des workflows, chargent des références et utilisent des extensions pour que l’agent puisse valider, corriger et maintenir la qualité. Cet article explique pourquoi cette approche est nettement meilleure que le « simple prompting sur ChatGPT » et donne des exemples concrets et des comparaisons de sorties.

Pourquoi la spec bat le prompting ad hoc

En bref : la rédaction pilotée par la spec donne au LLM une spec (workflow + références + structure) et des outils (extensions) pour se vérifier et se corriger. Le prompting brut, non.

Comment les skills Rakenne mettent en œuvre la rédaction pilotée par la spec

Dans Rakenne, chaque skill est un petit paquet que l’agent pi peut déclencher. Il contient en général :

1. SKILL.md — Nom, description (quand l’utiliser) et un workflow : étapes ordonnées (ex. définir le périmètre → charger la référence → rédiger → valider).
2. Références — Fichiers Markdown (standards, listes de critères, schémas) que l’agent charge quand le skill est actif, pour garder le brouillon aligné sur les référentiels.
3. Extensions (optionnel) — Outils TypeScript enregistrés auprès de l’agent (extension.ts) qui exécutent des contrôles déterministes sur le document (couverture, gates logiques, exhaustivité). L’agent les appelle, lit le résultat et révise jusqu’à ce que les contrôles passent.

Le contexte projet (type de document, domaine, glossaire) vit dans AGENTS.md dans l’espace de travail, donc chaque conversation du projet reste dans le même cadre.

Ci-dessous nous utilisons de vrais skills Rakenne pour illustrer workflows, contrôles et auto-correction, puis nous comparons les sorties.

Exemple 1 : Politique médicaments HIQA (workflow + référence)

Skill : HIQA Designated Centre Medication . Rédige une politique médicaments pour les centres désignés irlandais alignée sur les standards HIQA.

Workflow dans le skill :

1. Définir le périmètre — Type de centre, auto-administration vs médicaments administrés, procédures existantes.
2. Charger la référence — Lire references/hiqa-nssbh.md pour le thème 3 NSSBH (soins sûrs, sécurité des médicaments).
3. Rédiger — Produire une politique couvrant : commande, stockage, prescription, administration, auto-administration, fiches MAR, erreurs/incidents, élimination, formation, revue.
4. Référence croisée — Aligner avec le signalement d’incidents et la planification des soins/soutien.

Le fichier de référence détaille les huit thèmes HIQA et les attentes de gouvernance pour que l’agent ne devine pas.

Rakenne (avec le skill) : L’agent suit le workflow, intègre le thème 3 NSSBH et les textes de gouvernance associés depuis la référence, et produit une politique avec des sections nommées (commande, stockage, administration, erreurs, formation, etc.) et un alignement explicite sur « NSSBH Theme 3 » et le contexte « designated centre ».

ChatGPT brut : Vous pourriez demander : « Rédigez une politique médicaments pour un EHPAD en Irlande. » Le modèle renvoie souvent une « politique médicaments » générique applicable partout : « revue périodique », « personnel approprié » vagues, sans lien avec HIQA ou NSSBH. Aucune garantie que le thème 3 (ou stockage, MAR, erreurs, élimination) soit couvert de façon systématique, et aucune étape intégrée « charger la référence puis rédiger ».

Exemple 2 : Récits de contrôles SOC 2 (workflow + outils de validation)

Skill : SOC 2 Control Narrative Author . Construit la documentation SOC 2 avec récits de contrôles, mapping TSC et emplacements pour les preuves.

Workflow :

1. Périmètre — Quelles catégories TSC (Security toujours ; optionnellement Availability, PI, Confidentiality, Privacy).
2. Récits de contrôles — Pour chaque critère dans le périmètre (CC1–CC9, A1, PI1, C1, P1–P8) : récit + référence de preuve.
3. Preuves — Ajouter des emplacements de preuve par récit.
4. Valider — Lancer les extensions et corriger jusqu’à ce qu’elles passent.

Outils d’extension :

• check_trust_services_criteria_coverage — Vérifie que chaque critère TSC dans le périmètre a un récit et une référence de preuve ; signale les critères non mappés.
• soc2_narrative_reliability_check — Applique le rubrique SOC 2 Reliability : signale les formulations vagues (« revu périodiquement », « la direction assure la sécurité ») et pousse à la précision (qui, comment, quand, où, technologie nommée).

Rakenne (avec le skill) : L’agent rédige les récits puis lance les deux outils. Si CC4 n’a pas de référence de preuve ou si le récit dit « l’accès est revu périodiquement », les outils renvoient FAIL avec des constats précis. L’agent révise (ajoute la preuve, précise « trimestriellement par l’équipe sécurité via le rapport d’accès IdP ») et relance jusqu’à PASS.

ChatGPT brut : Vous demandez « récits de contrôles SOC 2 pour Security ». Vous obtenez souvent un texte qui parle de « contrôles » et « politiques » mais ne couvre pas systématiquement CC1–CC9, ne mappe pas chaque critère à un récit + preuve, et utilise exactement le genre de formulations vagues que le rubrique rejette (« revu périodiquement », « contrôles appropriés »). Aucun contrôle automatisé : les trous et le flou n’apparaissent qu’à la préparation d’audit.

Exemple 3 : Rapport CAPA (workflow + gates logiques)

Skill : CAPA Report . Rapports d’actions correctives et préventives pour non-conformités (ISO 9001 / ISO 13485).

Workflow :

1. Non-conformité — Constat, périmètre, confinement.
2. Cause racine — Compléter une section 5 Whys (Why 1 … Why 5). Ne pas proposer d’actions avant que ce soit fait.
3. Gate — Lancer root_cause_logic_gate sur le document. Ne continuer que lorsqu’il passe.
4. Actions correctives / préventives — Actions, responsables, échéances.
5. Mise en œuvre — Consigner la réalisation.
6. Vérification d’efficacité — Fixer une date future pour la vérification. Lancer verification_of_effectiveness_timer avant de clôturer ; ne pas clôturer tant qu’il ne passe pas.

Outils d’extension :

• root_cause_logic_gate — Vérifie la présence d’une section Cause racine / 5 Whys et d’au moins cinq niveaux why distincts. Échoue si le document passe aux « solutions » avant un 5 Whys correct.
• verification_of_effectiveness_timer — S’assure qu’une date de vérification d’efficacité existe et est dans le futur. Évite de clôturer la CAPA avant que la vérification soit planifiée.

Rakenne (avec le skill) : L’agent rédige la non-conformité et la cause racine. S’il n’a que trois niveaux why ou enchaîne sur « nous formerons le personnel », le gate renvoie FAIL avec « Niveaux why détectés : 3/5. Complétez une analyse 5 Whys avant de proposer des solutions. » L’agent ajoute Why 4 et Why 5, relance le gate, puis enchaîne sur les actions. Avant de clôturer, il doit fixer une date d’efficacité future ; s’il met « 2025-01-15 » et qu’on est au-delà, le timer échoue et l’agent doit fixer une date future.

ChatGPT brut : Vous demandez « une CAPA pour un constat d’audit sur la maîtrise documentaire ». Vous obtenez souvent un paragraphe de cause et une liste d’actions d’un coup — pas de 5 Whys imposé, pas de gate, pas de vérification que la vérification d’efficacité est planifiée dans le futur. Le résultat semble plausible mais ne passerait pas une revue ISO 9001/13485 stricte.

Exemple 4 : Dossier d’autorisation FedRAMP (workflow + contrôle d’exhaustivité)

Skill : FedRAMP Authorization Package . SSP, pièces jointes, SAP, SAR, POA&M.

Workflow (simplifié) : Catégoriser le système → description du système → périmètre d’autorisation → flux de données → implémentations des contrôles (avec référence de baseline) → pièces jointes SSP → Valider avec fedramp_package_completeness_check. Corriger et relancer jusqu’à PASS. Sous-workflows distincts pour SAP/SAR et POA&M, le même outil servant à signaler contrôles manquants, sections de pièces jointes manquantes ou éléments POA&M sans plan de remédiation ou en retard sans justification.

Rakenne (avec le skill) : L’agent suit le workflow, charge les références de baseline et de pièces jointes, rédige les sections et lance le contrôle d’exhaustivité. Les manques (ex. contrôles non implémentés sans justification, section PIA manquante) sont remontés ; l’agent les comble et revalide.

ChatGPT brut : Vous demandez « un SSP FedRAMP pour un produit SaaS ». Vous obtenez un long récit qui peut ressembler à un SSP mais ne suit pas la structure FedRAMP réelle, l’implémentation contrôle par contrôle ni la checklist des pièces jointes. Aucun moyen de vérifier la couverture de la baseline ou l’exhaustivité des pièces jointes ; vous découvrez les manques plus tard à la main.

Résumé : même modèle, résultats différents

Le LLM sous-jacent peut être le même. La différence est comment on l’utilise :

• Prompting brut : Une fois ou en va-et-vient sans workflow fixe, sans références chargées par le skill, sans outils de validation. La sortie est générique, la structure dérive et le modèle ne peut pas se « vérifier et corriger » de façon fiable.
• Piloté par la spec dans Rakenne : Les skills définissent workflow, références et extensions. L’agent suit le workflow, charge les bonnes références, rédige puis lance des outils qui renvoient PASS/FAIL et des constats précis. Il corrige jusqu’à ce que les contrôles passent et maintient la structure et la qualité voulues.

Pour les documents complexes et réglementés — politiques, récits de contrôles, CAPA, dossiers d’autorisation — la rédaction pilotée par la spec avec workflows et outils de validation n’est pas une petite amélioration ; c’est la différence entre « peut-être suffisant » et « prêt pour l’audit et reproductible ».

Pour essayer : choisissez un skill Rakenne pour votre domaine, créez un projet avec ce workflow et comparez la sortie structurée et validée à ce que donne un seul prompt ChatGPT.