Cahier des charges (en anglais) : le guide détaillé + modèle Word

Un cahier des charges (Specification / Requirements Document) aligne toutes les parties prenantes sur ce qu’on construit, pour qui, dans quelles conditions et avec quels critères d’acceptation. L’objectif : réduire l’ambiguïté, accélérer les décisions et sécuriser la livraison. Ci-dessous, un guide pragmatique pour remplir et exploiter votre template en anglais, avec exemples prêts à copier.

1) À quoi sert le document — et quand l’utiliser ?

Alignement : une source unique de vérité pour le scope, les exigences (FR/NFR), les règles métiers, les intégrations, la sécurité et les SLO/SLA.
Achats/contrats : base opposable pour devis, planning, paiements/milestones.
Delivery : réduire les reworks en fixant tôt les critères d’acceptation.
Gouvernance : tracer les changements (change control) et les décisions.

À utiliser quand le périmètre est non trivial (multi-équipes, intégrations externes, exigences réglementaires, impacts sécurité/perf).
Plus léger (Project Brief 1 page) si : MVP exploratoire, équipe colocalisée, faible risque.

2) Document control & versioning (commencez ici)

Version (ex. v1.2), date ISO (2025-10-24), auteur, résumé des changements, approbateurs.
Règle pratique : une décision, une ligne dans l’historique.

Exemple (EN)

Version: v1.2 | Date: 2025-10-24
Change Summary: Updated payment schedule; clarified API rate limits.
Approved by: Jane Smith (Sponsor), Alex Lee (CTO)

3) Scope & objectives : délimiter sans ambiguïté

In scope : fonctions, parcours, systèmes, marchés inclus.
Out of scope : ce qui n’est pas livré (évite le scope creep).
Objectives : 2–4 objectifs mesurables (SMART).

Exemples (EN)

In scope: Online subscription flow (web), billing via Stripe, admin dashboard (roles: Admin, Support).
Out of scope: Mobile apps, offline payments, loyalty program.
Objectives: Reduce checkout drop-off from 41% to <25% within 90 days post-launch.

4) Stakeholders & RACI : dire qui décide

Listez rôles et noms RACI (Sponsor, Product Owner, PM, Tech Lead, QA Lead).
Marquez R (Responsible), A (Accountable), C (Consulted), I (Informed).

Exemple (EN)

Product Owner — R/A | Legal — C | Security — C | Sales — I

5) Hypothèses & contraintes

Assumptions : API disponibles, données sources, fenêtre de test, capacité équipe.
Constraints : budget, jalons contractuels, normes, choix technos imposés.

Astuce : toute hypothèse critique doit avoir un test d’atterrissage (date/owner).

6) Exigences fonctionnelles (FR) : claires, testables, priorisées

Rédigez par user story ou par fonctionnalité.
Priorisez MoSCoW (Must / Should / Could / Won’t for now).
Chaque exigence possède un Owner et des acceptance criteria.

Exemple (EN)

FR-01 (MUST): As a new user, I can sign up with email/password and verify my email within 5 minutes.
Acceptance: Verification link expires in 15 min; error messages localized (EN/FR).

7) Exigences non fonctionnelles (NFR) : performance, sécurité, qualité

Couvrez a minima : Security & Privacy, Performance, Availability/Resilience, Usability & Accessibility, Compliance/Legal, Observability.

Exemples (EN)

Security: SSO (SAML 2.0) and MFA for Admin; AES-256 at rest; TLS 1.2+ in transit.
Performance: P95 < 700 ms for /checkout under 200 RPS; CPU <70% avg.
Availability: 99.9% monthly uptime; RTO 2h / RPO 15 min.
Accessibility: WCAG 2.2 AA for public flows.
Observability: Trace IDs across services; error budget policy documented.

8) User stories & acceptance criteria : verrouiller la vérification

Forme As a / I want / So that + critères d’acceptation en Gherkin si possible.

Exemple (EN)

Story: As an Admin, I want to reset a user's password to help locked-out users regain access.
Acceptance (Gherkin):
Given an active Admin
When they request a password reset for a valid user
Then the user receives a time-limited link (15 min) and the action is audited

9) Règles métier (Business Rules)

Numérotez-les (BR-01, BR-02).
Basez-les sur lois, politiques internes ou calculs.

Exemples (EN)

BR-03: VAT is applied based on customer's billing country; reverse charge for B2B EU with valid VAT ID.
BR-04: Trials are limited to one per billing account within 12 months.

10) Données & intégrations : dictionnaire et contrats d’API

Data model : entités, attributs, types, cardinalités, règles de rétention.
Intégrations : systèmes, méthodes, fréquence, auth, SLA, rate limits, gestion d’erreurs.

Exemple (EN)

Stripe — Webhooks (HTTPS, verified signature), events: invoice.payment_succeeded|failed.
Retries: exponential backoff up to 24h; idempotency keys required for POST /charges.

11) UX & accessibilité

Principes (clarté, hiérarchie, mobile-first), navigation modèle, copy.
Cibles d’accessibilité : contrastes, focus visibles, labels, raccourcis clavier.

12) Sécurité & conformité

Contrôles : SSO/MFA, RBAC, séparation des rôles, journaux d’audit.
Privacy : registres de traitements, DPA, base légale, DSR (Data Subject Requests).
Conformité selon périmètre (GDPR/CCPA/PCI/REACH/CPSIA, etc.).

13) Performance & SLO/SLA

Listez les transactions clés et les seuils (P95, P99, Throughput).
Définissez erreur budget et réaction (graceful degradation, feature flag off).

14) Environnements & DevOps

Envs : dev/test/stage/prod ; parité config ; données de test.
CI/CD : branches, revues, qualité (lint/tests), déploiements, rollbacks.
Observabilité : logs structurés, traces distribuées, alertes par SLO.

15) Jalons & livrables

Découpez en milestones (Design freeze, Alpha, Beta, GA).
Chaque jalon a : due date, deliverables, acceptance criteria, owner.

Exemple (EN)

Milestone: Beta (2026-01-15)
Deliverables: Payment flow, Admin reset, Reporting v1
Acceptance: 20 test cases passed; P95 < 900 ms; security review completed

16) UAT & acceptance

Entry/exit criteria, jeu de données, rôles (Business, QA, PO), procédure de sign-off.
Conservez un traceur d’anomalies UAT (ID, sévérité, statut).

17) Change control

Journal des CR (Change Requests) : ID, demandeur, description, impact, décision (Approved/Rejected/Deferred), date.
Pas de changement sans mise à jour de version + communication.

18) Risques & mitigations

Matrice Probabilité × Impact (H/M/L).
Plan de réponse (Avoid / Reduce / Transfer / Accept) + owner + trigger.

Top 8 fréquents

Dépendance API tierce non stable
Données de production non représentatives en test
Sous-estimations sécurité/PII
Échéances compliance ignorées
Capacité équipe surcrantée
Scope creep sans change control
Perf en charge réelle insuffisante
UAT tardif et incomplet

19) Budget & paiements

Lignes (item, qty, unit cost, total) + hypothèses.
Échéancier : acompte, milestones, rétention, pénalités SLA (si applicables).
Clair sur ce qui n’est pas inclus (licences tierces, infra, déplacement).

20) Annexes : glossaire, références, schémas

Glossaire bilingue (FR/EN) pour éviter les faux amis.
Références (politiques sécurité, normes), diagrammes (C4, séquences), MoU/SLAs.

21) Checklist qualité (avant diffusion)

Version/date/auteurs/approbateurs renseignés
Scope & Out-of-scope explicites
Objectifs mesurables (≤4)
FR priorisées (MoSCoW), acceptance criteria présents
NFR complets (sécurité, perf, disponibilité, accessibilité, observabilité)
Data & intégrations documentées (auth, erreurs, rate limits)
SLO/SLA chiffrés
UAT & sign-off décrits
Change log initialisé
Risques top-5 avec plans de réponse
Budget & termes de paiement clairs
Glossaire + annexes à jour

22) Extraits anglais prêts à copier

One-liner (objectifs)

This project aims to reduce checkout drop-off and enable compliant EU billing while maintaining a 99.9% availability target.

Clause d’acceptation générale

This deliverable is accepted when all defined acceptance criteria are met, no Severity-1 defects remain open, and the UAT sign-off is issued by the Product Owner.

Clause de performance

The /checkout endpoint must achieve P95 response time under 700 ms at 200 RPS sustained for 15 minutes, measured in the staging environment with production-like data.

Clause sécurité

Admin access requires SSO (SAML 2.0) and enforced MFA; all admin actions are recorded with user ID, timestamp and IP in an immutable audit log retained for 24 months.