# Cahier des charges

| | |
| --- | --- |
| **Projet** | *à compléter* |
| **Version** | *à compléter* |
| **Date** | *à compléter* |
| **Auteur** | *à compléter* |
| **Rédigé par** | MOA / direction métier |
| **Destinataires** | Fournisseurs consultés, MOE, juridique, achats |
| **Statut** | Brouillon / En relecture / Validé |

---

## 1. Présentation du demandeur

<!-- Le contexte de l'organisation, ce qui aide un tiers à dimensionner sa réponse. -->

<!-- Points à couvrir :
     - Activité, taille, organisation, implantations
     - Paysage applicatif existant et systèmes concernés
     - Historique du sujet : ce qui a déjà été tenté
-->

*à compléter*

## 2. Objet de la consultation

<!-- Ce qui est demandé, en un paragraphe compréhensible hors contexte. -->

<!-- Points à couvrir :
     - Nature de la prestation attendue (projet, TMA, licence, forfait, assistance)
     - Résultat attendu et échéance cible
-->

*à compléter*

## 3. Périmètre

<!-- La délimitation fonctionnelle et technique, dans les deux sens. -->

<!-- Points à couvrir :
     - Processus, entités, flux et applications inclus
     - Exclusions explicites
     - Volumétries : nombre de flux, de sources, de lignes, fréquences
-->

*à compléter*

## 4. Exigences fonctionnelles

<!-- Ce que le système doit faire. Une exigence par ligne, numérotée, vérifiable. -->

<!-- Points à couvrir :
     - Identifiant unique et stable (EF-001), repris ensuite dans la recette
     - Formulation vérifiable : on doit pouvoir écrire le test qui prouve qu'elle est tenue
     - Priorité affectée (obligatoire, souhaitée, optionnelle)
     - Règles de gestion associées
-->

*à compléter*

## 5. Exigences non fonctionnelles

<!-- Les qualités attendues du système, chiffrées, pas qualitatives. -->

<!-- Points à couvrir :
     - Performance : temps de traitement, débit, fenêtre de traitement disponible
     - Disponibilité et engagements de service attendus
     - Sécurité : authentification, habilitations, chiffrement, traçabilité
     - Conformité RGPD : données personnelles traitées, durées de conservation, sous-traitance
     - Exploitabilité, supervision, reprise sur incident
     - Scalabilité : volumétrie à horizon trois ans
-->

*à compléter*

## 6. Contraintes

<!-- Ce que le fournisseur doit prendre comme donné, même s'il ferait autrement. -->

<!-- Points à couvrir :
     - Techniques : socle imposé, hébergement, environnements, référentiels internes
     - Organisationnelles : lieux d'intervention, langue, plages de disponibilité
     - Réglementaires et sectorielles
-->

*à compléter*

## 7. Prestations attendues

<!-- Le travail demandé au-delà du logiciel lui-même. -->

<!-- Points à couvrir :
     - Conception, développement, reprise de données, intégration
     - Documentation attendue et formats
     - Formation, transfert de compétences, accompagnement au démarrage
     - Garantie et maintenance : durée, périmètre, engagements
-->

*à compléter*

## 8. Modalités de réponse

<!-- Le cadre imposé aux réponses pour pouvoir les comparer. -->

<!-- Points à couvrir :
     - Plan de réponse imposé et pièces attendues
     - Grille de chiffrage à remplir (structure identique pour tous)
     - Critères de sélection et pondération
     - Calendrier de la consultation et date limite
-->

*à compléter*

## 9. Annexes

<!-- Ce qui alourdirait le corps du document mais reste nécessaire. -->

<!-- Points à couvrir :
     - Cartographie applicative et schémas de flux
     - Dictionnaire de données et formats de fichiers
     - Modèles de documents internes à respecter
-->

*à compléter*

---

## Notes de rédaction

**Quand produire ce document**

- Pour toute consultation de fournisseurs ou appel d'offres.
- Quand la réalisation est confiée à une équipe qui n'a pas participé au cadrage.
- Pour un projet à enjeu contractuel, où le périmètre livré devra être opposable.
- Quand le besoin implique plusieurs directions et doit être arbitré avant consultation.

**Erreurs les plus fréquentes**

- Décrire la solution au lieu du besoin. « Un job Talend qui lit un CSV » ferme la porte à toute autre approche ; « intégrer quotidiennement les commandes du portail fournisseur » laisse le fournisseur proposer.
- Écrire des exigences invérifiables. « Le système doit être rapide » ne se recette pas ; « le traitement quotidien s'exécute en moins de 30 minutes pour 2 millions de lignes » se recette.
- Oublier les volumétries. C'est le premier facteur de dérive de chiffrage, et le premier reproche des fournisseurs après coup.
- Ne pas prioriser les exigences. Sans priorité, tout est obligatoire, tout est chiffré au maximum, et le budget explose avant la première ligne de code.
- Numéroter les exigences après coup. Les identifiants doivent être posés dès la rédaction : ils servent de fil conducteur jusqu'au PV de recette.

**Référentiel de rattachement**

ISO/IEC/IEEE 29148 (ingénierie des exigences). La norme définit les caractéristiques d'une exigence exploitable : non ambiguë, vérifiable, traçable, réaliste, et énoncée une seule fois. Le plan ci-dessous applique ces critères à un cahier des charges SI classique.

---

Modèle « CdC - Cahier des charges » (Cadrage), publié par DataALC.
Version en ligne, commentée : https://www.dataalc.com/boite-a-outils/templates/cahier-des-charges/

Ce modèle est fourni comme base de travail : adaptez-le à votre contexte, supprimez les rubriques sans objet plutôt que de les laisser vides.