Un projet informatique mal cadré, c'est un budget qui dérape et des délais qui s'allongent. J'ai vu ça des dizaines de fois en couvrant des projets IT pour DjVuZone : la cause numéro un, c'est l'absence d'un cahier des charges technique solide dès le départ. Ce document est le fondement de tout développement sérieux, que vous construisiez une application mobile, un site web ou un système industriel.
Dans ce guide, on va voir exactement ce qu'est un cahier des charges technique, comment le structurer, comment l'écrire sans tomber dans les pièges classiques, et en quoi il diffère du cahier des charges fonctionnel.
Qu'est-ce qu'un cahier des charges technique ?
Un cahier des charges technique est un document contractuel qui décrit les spécifications d'un projet : les contraintes, les exigences de performance et les normes à respecter. Il précise comment un système doit être construit, dans le sens de la norme ISO 21500 de management de projet. C'est le référentiel commun entre le maître d'ouvrage et les équipes de réalisation.
Contrairement à une simple liste de souhaits, le CDC technique engage les deux parties. Il sert de base à l'évaluation des offres et au suivi du développement. Sans lui, chaque prestataire interprète les besoins à sa façon, avec des résultats souvent incompatibles avec les attentes initiales.
Le périmètre varie selon la nature du projet. Pour un développement logiciel, il détaillera les architectures serveur, les langages, les API et les contraintes de sécurité. Pour un chantier de construction, il précisera les matériaux, les normes parasismiques ou thermiques, les procédés d'assemblage.
CDC fonctionnel vs CDC technique : quelle différence ?
La confusion entre les deux types de cahiers des charges est l'une des sources d'erreurs les plus fréquentes en gestion de projet. Le cahier des charges fonctionnel (CDCF) décrit le quoi : ce que le système doit faire, les besoins utilisateurs, les cas d'usage. Le cahier des charges technique décrit le comment : avec quelles technologies, selon quelles contraintes, dans quel environnement.
En pratique, le CDC fonctionnel précède toujours le CDC technique. On part des besoins métier pour dériver les exigences techniques. Un CDCF dit "l'utilisateur doit pouvoir se connecter via son compte Google". Le CDC technique précise ensuite "l'authentification OAuth 2.0 sera intégrée via l'API Google Identity Platform, avec un token JWT de durée de vie 3600 secondes".
Tableau comparatif : CDC fonctionnel vs CDC technique
| Critère | CDC fonctionnel | CDC technique |
|---|---|---|
| Réponse à la question | Quoi faire ? | Comment le faire ? |
| Public cible | Maîtrise d'ouvrage, métier | Développeurs, architectes, prestataires |
| Langage utilisé | Fonctionnel, orienté utilisateur | Technique, précis, chiffré |
| Contenu principal | Cas d'usage, parcours, interfaces | Architecture, performances, sécurité |
| Moment de rédaction | Phase de cadrage | Phase de spécification technique |
| Valeur contractuelle | Souvent annexe au contrat | Document contractuel central |
| Évolution en cours de projet | Peut évoluer avec les besoins | Contrôlé, toute modification = avenant |
Un CDC technique rédigé sans CDCF en amont est bâti sur du sable, ce qui complique d'autant la tâche de trouver le bon freelance ou le prestataire adapté : les choix techniques ne s'ancrent pas dans des besoins réels validés.
Quelle est la structure d'un cahier des charges technique ?
Un cahier des charges technique suit une structure standard, même si elle s'adapte à chaque secteur. On retrouve cinq grandes sections dans la quasi-totalité des CDC sérieux : la présentation du projet et du contexte, les spécifications techniques détaillées, les contraintes et exigences non fonctionnelles, les modalités de développement et de livraison, et les critères de réception.
1. Présentation du projet et contexte
Cette section pose le décor. On y trouve l'objet du projet, les objectifs mesurables, les parties prenantes, le périmètre fonctionnel de référence et les grandes contraintes connues. C'est court, mais indispensable pour que tout lecteur comprenne immédiatement de quoi il s'agit.
On précise aussi les documents de référence : CDCF, études préalables, normes applicables. Cette traçabilité évite les malentendus lors des litiges.
2. Spécifications techniques détaillées
C'est le cœur du document. Pour un projet numérique, on y détaille l'architecture système (front-end, back-end, bases de données, hébergement), les langages et frameworks retenus ou imposés, les API tierces et les protocoles de communication. Pour un projet industriel, on y trouve les plans, les matériaux, les tolérances et les procédés de fabrication.
Chaque spécification doit être mesurable et vérifiable. "Le site doit être rapide" ne vaut rien. "Le temps de réponse serveur doit être inférieur à 200 ms pour 95 % des requêtes" : ça, c'est une exigence.
3. Exigences non fonctionnelles
Performances, disponibilité, sécurité, accessibilité, maintenabilité : ces contraintes transversales sont souvent sous-estimées. Pourtant, elles conditionnent les choix d'architecture autant que les fonctionnalités. Un SLA de 99,9 % de disponibilité n'a pas les mêmes implications techniques qu'un SLA de 99 %.
4. Modalités de réalisation
Cette section précise le planning prévisionnel, les jalons de livraison, les environnements de développement, de recette et de production, ainsi que les outils et cadres de référence imposés, que ceux-ci suivent la méthode PRINCE2 de gestion de projet ou une approche agile. Elle fixe aussi les règles de versioning du code et les obligations de documentation technique.
5. Critères de réception et de validation
Comment saura-t-on que le projet est terminé et conforme ? Cette section définit les tests d'acceptation, les indicateurs de performance à atteindre, les procédures de recette et les conditions de garantie, à l'image de ce qu'impose un cahier des charges en marché public pour la réception des travaux. Un projet sans critères de réception clairs finit rarement bien.
Comment rédiger un cahier des charges technique efficace ?
La rédaction d'un CDC technique est un exercice collectif. J'ai participé à plusieurs d'entre eux lors de refontes de sites médias : le document le plus solide que j'aie vu émerger l'a été en réunissant dès le départ le chef de projet, un architecte technique, un développeur senior et un représentant des futurs utilisateurs. Chacun apporte un angle que les autres n'ont pas.
Partir des besoins validés, pas des solutions
L'erreur classique est d'écrire directement "le site sera développé sous WordPress avec WooCommerce" sans avoir vérifié si c'est la solution adaptée aux contraintes réelles. Le CDC technique doit s'appuyer sur une analyse des besoins fonctionnels préalablement validés, en intégrant dès l'amont les contraintes du processus d'achat en entreprise quand plusieurs services sont impliqués dans le choix du prestataire. Les choix technologiques viennent ensuite, justifiés par des critères objectifs.
Si le client impose une technologie spécifique, cela doit être explicitement documenté comme une contrainte imposée, pas comme un choix technique rationnel. La nuance est importante pour la gestion des risques.
Formuler des exigences SMART
Chaque exigence technique doit être Spécifique, Mesurable, Atteignable, Réaliste et Temporellement définie. "Assurer la sécurité des données" est une intention, pas une exigence au sens des spécifications techniques publiées par les organismes de normalisation, qui exigent une formulation précise et vérifiable. "Les données personnelles seront chiffrées en AES-256 au repos et en TLS 1.3 en transit, conformément au RGPD" : ça, c'est une exigence technique valide.
Prioriser et hiérarchiser
Toutes les exigences ne sont pas égales. Un système de priorités (indispensable, important, souhaitable) permet au prestataire de faire des arbitrages en cas de contrainte budgétaire ou temporelle, sans trahir l'essentiel. Sans cette hiérarchisation, tout devient prioritaire, ce qui revient à dire que rien ne l'est vraiment.
Faire relire par un expert technique avant diffusion
Avant de diffuser le document, une relecture par un expert indépendant vaut de l'or. Il identifiera les incohérences et les spécifications irréalistes que l'équipe projet ne voit plus à force de relire le même texte. Ce temps investi en amont évite des allers-retours coûteux en phase de développement.
Quelles sont les erreurs courantes dans un CDC technique ?
Après avoir suivi des dizaines de projets digitaux en tant que journaliste tech, j'ai observé les mêmes écueils revenir régulièrement. Les voici dans l'ordre de fréquence.
Confondre exigences fonctionnelles et techniques
Mélanger les deux niveaux dans un seul document crée de la confusion. Le prestataire ne sait plus si une règle relève du besoin métier (modifiable) ou de la contrainte technique (non négociable), ce qui nuit directement à la cohérence technique du projet et à la qualité des livrables. Garder les deux documents séparés et bien articulés simplifie considérablement les échanges.
Écrire dans le vague pour "rester flexible"
La flexibilité mal comprise produit des CDC inutilisables. Laisser des zones de flou avec l'idée de "s'adapter en cours de route" génère des interprétations divergentes et des surcoûts. Un bon CDC anticipe les ambiguïtés et les lève dès la rédaction.
Négliger les exigences non fonctionnelles
Les performances, la sécurité, l'accessibilité et la maintenabilité sont souvent traitées en dernière minute ou oubliées. Ce sont pourtant ces exigences, décrites dans les normes en management de projet, qui vont peser sur les choix d'architecture les plus structurants. Elles doivent figurer dès la première version du document.
Rédiger seul, sans itérations
Un CDC technique rédigé par une seule personne, sans relecture croisée, accumule les angles morts. Les développeurs voient des risques que les chefs de projet n'identifient pas. Les utilisateurs finaux perçoivent des besoins que les architectes ont oubliés. La rédaction collaborative avec des cycles de révision formels est non négociable.
Ne pas prévoir de procédure de modification
Tout CDC évolue. Si le document ne prévoit pas de procédure formelle de gestion des modifications (avenant signé, numérotation de versions, traçabilité des changements), il devient rapidement obsolète sans que personne ne le sache vraiment. Chaque modification non documentée est un risque contractuel.
CDC technique par secteur : web, mobile, BTP et industrie
La structure de base reste la même, mais le contenu varie considérablement selon le domaine. Voici les spécificités à connaître pour les secteurs les plus courants.
Projets web et e-commerce
Le CDC technique d'un site web aborde systématiquement l'hébergement (cloud, serveur dédié, CDN), le CMS ou le framework, les performances (Core Web Vitals, temps de chargement), la compatibilité navigateurs, la sécurité (HTTPS, protection contre les injections SQL, RGPD) et l'accessibilité (normes WCAG). Pour un e-commerce, s'y ajoutent les contraintes PCI-DSS pour les paiements, l'intégration des ERP et la gestion des stocks en temps réel.
Les métriques de performance comptent énormément dans ce secteur. Un LCP supérieur à 2,5 secondes sur mobile fait perdre des visiteurs avant même que la page soit chargée, et Google le sanctionne dans son classement.
Applications mobiles
Un CDC technique mobile doit préciser les plateformes cibles (iOS, Android, les deux) et les versions OS minimales supportées. Le choix entre natif, hybride ou cross-platform (React Native, Flutter) doit être justifié, pas juste posé. Idem pour les contraintes des stores, la gestion offline et les permissions requises : chaque choix a des conséquences sur le délai de mise en ligne.
Projets BTP et construction
Dans le bâtiment, le CDC technique se double souvent d'un CCTP (Cahier des Clauses Techniques Particulières), document réglementé dans les marchés publics. Il précise les matériaux et leurs normes (NF, CE), les méthodes d'exécution, les tolérances, les essais à réaliser et les conditions de réception. La conformité aux réglementations thermiques (RE2020) et aux DTU y est centrale.
Industrie et systèmes embarqués
Les CDC techniques industriels sont souvent les plus exhaustifs. Ils couvrent les spécifications électriques et mécaniques, les contraintes environnementales et les protocoles de communication industriels (Modbus, CAN bus, OPC-UA), domaines où le regard d'un consultant informatique externe peut aider à valider les choix d'intégration. Les normes de sécurité fonctionnelle (IEC 61508, ISO 26262 pour l'automobile) et les exigences de traçabilité s'y ajoutent.
CDC technique et appel d'offres : quel lien ?
Dans un appel d'offres, le cahier des charges technique est le document sur lequel les prestataires construisent leurs propositions. C'est lui qui leur permet de chiffrer correctement, de proposer une architecture cohérente et d'évaluer la charge réelle. Un CDC flou produit des offres incomparables, avec des écarts de prix que personne ne sait expliquer.
Un CDC technique bien rédigé produit des offres comparables entre elles, ce qui simplifie considérablement l'évaluation. J'ai vu des projets où trois prestataires avaient présenté des budgets allant du simple au quadruple, uniquement parce que les spécifications laissaient trop de place à l'interprétation.
Dans les marchés publics, le CDC technique fait partie du Dossier de Consultation des Entreprises (DCE). Sa valeur contractuelle est pleine et entière, et les bonnes pratiques pour rédiger un cahier des charges informatique le soulignent : tout ce qui y figure engage le prestataire retenu. Cette dimension juridique impose une rigueur particulière dans la formulation des exigences, surtout pour les clauses de pénalités et les critères de réception.
Mettre à jour le CDC après choix du prestataire
Une pratique souvent négligée : mettre à jour le CDC technique après la phase de négociation avec le prestataire retenu. Les échanges de l'appel d'offres, qui impliquent l'ensemble des parties prenantes côté client et prestataire, font souvent émerger des précisions, des ajustements ou des options retenues. Intégrer ces éléments dans une version finale garantit que tout le monde travaille sur la même base.
Un document vivant, pas un carcan
Après douze ans à suivre des projets numériques, je retiens une chose : les meilleurs cahiers des charges techniques que j'ai vus n'étaient pas les plus épais. C'étaient ceux dont chaque ligne avait été écrite pour être utile. Un CDC technique bien construit n'est pas une contrainte bureaucratique, c'est le meilleur investissement qu'un chef de projet puisse faire avant de lancer la moindre ligne de code ou le premier coup de pelleteuse.
La clé est de le traiter comme un document versionné et relu à chaque jalon important. Pour cela, l'associer à un outil de suivi des activités du projet permet de maintenir la traçabilité tout au long du développement. Pas comme une archive poussiéreuse signée une fois et oubliée dans un tiroir.
Questions fréquentes
Quelle est la différence entre un cahier des charges fonctionnel et un cahier des charges technique ?
Le cahier des charges fonctionnel décrit ce que le système doit faire (besoins utilisateurs, cas d'usage, parcours). Le cahier des charges technique décrit comment le construire : technologies, architecture, performances, sécurité, contraintes d'intégration. Le premier précède toujours le second et lui sert de base.
Qui rédige un cahier des charges technique ?
La rédaction est généralement menée par le maître d'ouvrage ou son représentant (chef de projet, DSI), avec l'appui d'un architecte technique quand le projet le justifie. Elle implique aussi les futurs utilisateurs et, dans certains cas, un conseil en maîtrise d'ouvrage externe. Les prestataires ne rédigent pas le CDC : ils y répondent.
Un cahier des charges technique est-il obligatoire ?
Il n'est pas légalement obligatoire pour tous les projets privés, mais il est fortement recommandé dès qu'un prestataire externe est impliqué. Dans les marchés publics, il est en revanche obligatoire et fait partie intégrante du Dossier de Consultation des Entreprises (DCE).
Quelle longueur doit avoir un cahier des charges technique ?
Il n'existe pas de longueur standard. Un CDC technique pour un site vitrine peut tenir en 10 pages. Celui d'un système industriel critique peut en faire plusieurs centaines. Ce qui compte, c'est la précision des exigences, pas le volume. Mieux vaut 15 pages de spécifications mesurables que 50 pages de généralités.
Comment gérer les modifications d'un CDC technique en cours de projet ?
Chaque modification doit faire l'objet d'un avenant formalisé, signé par les deux parties. Le document doit être versionné (v1.0, v1.1, v2.0) et chaque version archivée. Toute exigence modifiée doit mentionner la raison du changement et son impact sur le planning et le budget.
Peut-on utiliser un modèle de CDC technique existant ?
Oui, les modèles sont un bon point de départ pour ne rien oublier. Mais un modèle ne remplace pas l'analyse des besoins spécifiques du projet. Copier-coller un CDC sans l'adapter produit des documents inutilisables, remplis de clauses génériques qui ne correspondent pas à la réalité du projet.
Quelle est la durée de validité d'un cahier des charges technique ?
Un CDC technique est valide pour la durée du projet auquel il se rapporte. Il peut être prolongé pour couvrir des phases ultérieures (maintenance, évolutions) sous forme d'avenants. Le réviser formellement à chaque jalon majeur garantit qu'il reflète toujours la réalité du projet.
