CdC - Cahier des charges

À quoi sert ce document

Le cahier des charges expose un besoin à des tiers capables d'y répondre. Sa qualité se juge à une seule chose : deux fournisseurs différents doivent en tirer la même compréhension du besoin, et leurs propositions doivent être comparables. Il décrit ce que le système doit faire et les contraintes à respecter, pas comment le construire. Un cahier des charges qui impose déjà une architecture prive l'acheteur des solutions qu'il ne connaissait pas, et transfère au client la responsabilité technique du résultat.

Quand le produire

• 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.

Le plan, rubrique par rubrique

1. Présentation du demandeur

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

   • Activité, taille, organisation, implantations
   • Paysage applicatif existant et systèmes concernés
   • Historique du sujet : ce qui a déjà été tenté

2. Objet de la consultation

   Ce qui est demandé, en un paragraphe compréhensible hors contexte.

   • Nature de la prestation attendue (projet, TMA, licence, forfait, assistance)
   • Résultat attendu et échéance cible

3. Périmètre

   La délimitation fonctionnelle et technique, dans les deux sens.

   • Processus, entités, flux et applications inclus
   • Exclusions explicites
   • Volumétries : nombre de flux, de sources, de lignes, fréquences

4. Exigences fonctionnelles

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

   • 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

5. Exigences non fonctionnelles

   Les qualités attendues du système, chiffrées, pas qualitatives.

   • 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

6. Contraintes

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

   • Techniques : socle imposé, hébergement, environnements, référentiels internes
   • Organisationnelles : lieux d'intervention, langue, plages de disponibilité
   • Réglementaires et sectorielles

7. Prestations attendues

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

   • 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

8. Modalités de réponse

   Le cadre imposé aux réponses pour pouvoir les comparer.

   • 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

9. Annexes

   Ce qui alourdirait le corps du document mais reste nécessaire.

   • Cartographie applicative et schémas de flux
   • Dictionnaire de données et formats de fichiers
   • Modèles de documents internes à respecter

Les erreurs qui coûtent cher

• 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.