Co-rédaction de documents

Présentation

Workflow structuré pour rédiger en collaboration des documents, propositions, spécifications et documents de décision. Trois phases : collecte de contexte, raffinement itératif et test lecteur.

Pour commencer

Ajoutez vos sources dans l’espace du projet et activez la compétence Co-rédaction de documents. L’agent vous guidera étape par étape.

Exemple de conversation

Vous : Je veux rédiger un document de décision d’une page pour migrer notre auth vers OAuth2. On peut faire le workflow structuré ?
Agent : Oui. Trois phases : (1) Collecte de contexte — j’interroge sur l’audience, l’impact et un éventuel modèle ; (2) Raffinement — on construit chaque section par brainstorming et éditions ; (3) Test lecteur — on vérifie si un lecteur neuf peut répondre aux questions clés. Pour commencer : qui est l’audience principale ? Que doivent-ils faire après lecture ? Un modèle existant ?
Vous : Audience : responsables ingénierie et sécurité. Objectif : go/no-go. Pas de modèle, des sections claires.
Agent : Je propose : Contexte et problème, Options envisagées, Recommandation, Risques et mitigation, Prochaines étapes. On commence par « Options » et « Recommandation ». Dumpez tout le contexte (contraintes, discussions passées, pourquoi pas d’autres options) ; ensuite brainstorming et rédaction section par section. Prêt pour le contexte ?
Vous : [Fournit le contexte.]
Agent : J’ai créé decision-doc-auth-oauth2.md avec des placeholders. Pour la section Recommandation : voici 8 points possibles d’après ce que vous avez partagé. Lesquels garder, retirer ou fusionner ? [Liste les options.] Une fois choisi, je rédige la section et on itère.

Extrait de sortie type

Extrait représentatif d’un document de décision produit avec le workflow de co-rédaction.

Décision : Migrer l’authentification vers OAuth2

Contexte et problème

L’auth actuelle basée sur cookies ne supporte pas le mobile ni les intégrations tierces. Nous avons besoin d’une couche d’auth standard et maintenable pour web, mobile et API.

Options envisagées

Option	Avantages	Inconvénients
Rester sur le système actuel	Aucun coût de migration	Ne répond pas aux exigences mobile/API
OAuth2 + OIDC	Standard, support de librairies, s’intègre à notre stack	Effort de migration et gestion des clés
Couche de tokens custom	Contrôle total	Non standard, coût long terme plus élevé

Recommandation

Adopter OAuth2 avec OpenID Connect pour l’identité. Utiliser [Fournisseur X] pour l’émission et notre user store existant. Phase 1 : web et API ; Phase 2 : mobile. Délai : 8 semaines jusqu’au pilote, 12 jusqu’au déploiement complet.

Risques et mitigation

Risque : Révocation des tokens et invalidation de session. Mitigation : Tokens d’accès à courte durée, rotation du refresh et endpoint de révocation en Phase 2.
Risque : Rotation des clés. Mitigation : Rotation automatisée et support double clé pendant la transition.

Prochaines étapes

Validation sécurité du fournisseur et du flow (Semaine 1).
Implémenter l’émetteur et intégrer à l’app web (Semaines 2–6).
Pilote avec les consommateurs internes de l’API (Semaines 7–8).