Projet informatique : comment rédiger un bon cahier des charges

Dans tout projet informatique, le cahier des charges peut devenir votre meilleur allié… ou votre pire ennemi. Flou ou trop générique, il ouvre la porte aux dérives. Trop technique, il perd les métiers. Trop figé, il étouffe l’agilité. Découvrez comment écrire un cahier des charges structuré, lisible, et exploitable aussi bien par les équipes techniques que par les donneurs d’ordre métier.

Vous lancez un nouveau projet informatique. L’ambiance est bonne, les idées fusent : une appli interne qui fluidifie enfin les workflows, un site qui augmente le taux de conversion, un CRM qui parle le même langage que vos équipes commerciales et marketing, un hébergement cloud plus fiable…

Puis, arrive le moment du cahier des charges (CDC). Dans la sphère publique, on parle de CCTP (Cahier des Clauses Techniques Particulières). Dans beaucoup d’organisations privées, le document porte le nom de CCFT (Cahier des Clauses Fonctionnelles et Techniques).

Les sigles changent, mais la fonction reste la même : offrir un langage commun à la maîtrise d’ouvrage (MOA), qui exprime le besoin, et à la maîtrise d’œuvre (MOE), qui conçoit et réalise la solution.

Concrètement, le cahier des charges joue un triple rôle : 

• il traduit le besoin métier en exigences concrètes,
• il structure les engagements contractuels,
• il sert de référence juridique en cas de litige.

S’il manque de précision, il laisse la place aux surcoûts, aux retards et à des contrats IT fragiles. À l’inverse, s’il reste lisible, cohérent et solide juridiquement, il devient un outil de pilotage, protège la relation client-fournisseur et soutient vos décisions.

Bonne nouvelle : vous pouvez écrire un cahier des charges à la fois lisible, opérationnel et sécurisant, sans noyer tout le monde dans le jargon technique ou la langue administrative indigeste.

Mieux encore, vous pouvez le concevoir de manière à ce que vos équipes aient réellement envie de le lire… et de le respecter.

Avant de rédiger : cadrer le besoin et le marché

Du besoin flou au besoin formalisé

L’erreur fondamentale, commise même par des équipes expérimentées, est de plonger tête baissée dans la solution technique. Par exemple : « il nous faut un nouvel ERP », « on veut de l’IA générative » ou « on doit refaire tout le site ». Or, un bon cahier des charges agit au contraire comme un filtre stratégique.

D’abord, formulez un objectif clair, mesurable, daté. Avant de décrire une interface ou une fonctionnalité, le CDC fixe une ambition métier.

En pratique, une seule phrase doit résumer le besoin, avec un objectif clair, mesurable et daté.

Il ne s’agit donc plus d’annoncer : « nous voulons un nouveau système multilingue basé sur l’IA », mais plutôt de dire : « nous devons réduire de 40 % le temps de publication des contenus multilingues avant le T3, sans sacrifier la qualité ».

Cette nuance change tout. D’une part elle offre une boussole pour les futurs arbitrages. D’autre part, lorsque le budget sera sous tension, cette phrase permettra de trancher entre l’essentiel et le superflu.

Un périmètre précis, y compris ce que vous ne ferez pas

Une fois l’objectif clarifié, traduisez ce besoin en exigences fonctionnelles : ce que les utilisateurs doivent pouvoir faire, voir, décider. Surtout, résistez à la tentation d’imposer tout de suite la solution (« il nous faut absolument tel outil »).

D’abord l’intention, ensuite la technologie.

Puis, vous posez les frontières du projet. Définissez ce que le projet inclut… et surtout ce qu’il exclut. En réalité, la puissance d’une non-fonction bien formulée surprend souvent les chefs de projet.

En effet, définir ce que le projet ne fera pas est souvent plus puissant que de lister ce qu’il fera. Le fait de graver dans le marbre les exclusions (le « out-of-scope »), vous désamorcez par avance les dérives fonctionnelles, ce fameux « scope creep » qui, selon le PMI, affecte plus de la moitié des projets d’envergure.

Par exemple : « Le système ne gère pas la traduction automatique des PDF complexes en phase 1. »

Cette simple phrase peut épargner des semaines de débats avec la DSI ou la direction métier.

Le triangle des contraintes : budget, délais, périmètre

Ensuite, dessinez ensuite votre triangle de contraintes :

• le budget : définissez une fourchette budgétaire
• les délais : créez un macro-planning (grandes phases, quelques jalons)
• le périmètre : précisez tout ce qui doit être réalisé (livrables, tâches, fonctionnalités….)

Inutile, ici, de viser la précision absolue dès le départ. Un ordre de grandeur suffit pour éviter les illusions.

Puis, seulement après, descendez vers les contraintes techniques : choix cloud ou on-premise, interopérabilité avec votre SI existant, sécurité, volumétrie, réversibilité des données, etc.

Quel cahier des charges selon votre projet ?

Tous les cahiers des charges ne racontent pas la même histoire. Autrement dit, vous n’insistez pas sur les mêmes chapitres selon que vous commandez un développement spécifique, que vous choisissez un progiciel ou que vous demandez une prestation d’AMOA.

▶ Pour un développement sur mesure

Attardez-vous sur le diagnostic de l’existant, les processus métier, les données manipulées, les workflows, les besoins de qualité.

▶ Vous voulez choisir un logiciel du marché ou un ERP

Vous décrivez surtout vos besoins métier, vos priorités, vos contraintes d’intégration et vos critères de choix. Le cahier des charges devient alors la base d’un questionnaire détaillé que chaque éditeur remplit. Ensuite, vous pouvez ensuite comparer les offres, les pondérer et construire une short list sur des critères objectifs plutôt que sur la plus belle démonstration commerciale.

▶ Vous devez connecter plusieurs outils

Vous mettez davantage l’accent sur les interfaces et les flux. Les formats d’échange, la fréquence, la volumétrie, la reprise des données et la gestion des erreurs deviennent des éléments centraux du document.

▶ Pour un site ou une plateforme web

Vous faites davantage ressortir l’expérience utilisateur, la performance perçue, la sécurité des comptes, l’accessibilité, le référencement, la montée en charge et les exigences d’hébergement.

▶ Vous cherchez un partenaire d’assistance à la maîtrise d’ouvrage (AMOA)

Votre objectif est de trouver un partenaire pour vous aider à cadrer et à piloter. Vous décrivez le périmètre d’intervention de votre partenaire : contribution à l’expression des besoins, organisation des ateliers, rédaction du cahier des charges, dépouillement des offres, animation de la recette, conduite du changement.

À noter : pour les projets complexes (ERP, refonte SI), attendez-vous à rédiger plusieurs cahiers des charges : fourniture du logiciel, intégration, développements spécifiques, migration, infogérance, TMA…

Les acteurs : MOA, MOE, sponsor, comité de pilotage

Un bon cahier des charges ne décrit pas seulement un système, il décrit aussi un jeu d’acteurs.

Côté client, la maîtrise d’ouvrage (MOA) formule le besoin, vérifie l’adéquation des solutions proposées, organise les ateliers, valide les livrables, pilote le projet et la recette, conduit le changement. Souvent, la MOA se décline en deux niveaux : une MOA stratégique, proche de la direction, qui donne le mandat et les grandes orientations, et une MOA opérationnelle, qui tient la plume et anime le travail au quotidien.

Côté fournisseur, la maîtrise d’œuvre (MOE) conçoit les solutions, réalise la solution retenue, conseille techniquement la MOA et s’engage sur des moyens et des délais.

Au-dessus de ce duo, le sponsor joue le rôle de parrain du projet. Il porte le projet au plus haut niveau de l’organisation, légitime les objectifs, arbitre les dossiers sensibles et protège le budget.

Enfin, le comité de pilotage (Copil) réunit sponsor, représentants métiers, DSI, parfois achats, et prend les décisions structurantes aux jalons clés.

Conclusion logique : plus le cahier des charges décrit clairement cette gouvernance, plus le projet garde une trajectoire maîtrisée.

La structure d’un cahier des charges qui inspire confiance

Un cahier des charges efficace suit une logique simple : il explique d’abord pourquoi vous agissez, ensuite ce que vous attendez, puis comment vous prévoyez d’y aller, avec qui et dans quelles conditions.

Voici une structure que vous pouvez reprendre telle quelle et adapter à votre contexte.

1. Contexte et objectifs : posez le décor

Pour commencer, décrivez le système actuel : ses forces, ses limites, ses irritants. Décrivez ce qui se passe si rien ne change : retards, risques de conformité (RGPD…), perte d’opportunités, dépendance excessive à un fournisseur, etc.

Ensuite, vous expliquez les objectifs business et utilisateurs. Idéalement, rendez-les mesurables et priorisés selon la logique Must / Should / Could / Won’t (obligatoire / souhaitable / nice-to-have / hors scope).

Enfin, ajoutez vos indicateurs de succès : les KPI (indicateurs clés de performance) et les critères d’acceptation.

Exemple : « 95 % des contenus traduits doivent être alignés avec le glossaire en moins de 48 h. »

Vos KPI aident-ils réellement à trancher quand les demandes s’accumulent ? Si la réponse reste floue, simplifiez. Trois indicateurs clairs valent mieux qu’un tableau de bord illisible.

 « Le jour où on a mis sur la table un KPI unique : le temps moyen entre demande et mise en ligne. Depuis, les arbitrages sont devenus beaucoup plus simples », Damien, chef de projet digital dans l’industrie.

2. Périmètre et livrables : dire ce qui sort de la boîte

D’abord, décrivez le périmètre fonctionnel : ce que les utilisateurs pourront faire et ce qu’ils ne feront pas. Utilisez des verbes d’action et inspirez-vous du quotidien : « créer un contenu », « demander une traduction », « valider une campagne », etc.

Puis, détaillez les contraintes techniques majeures : architecture cible, intégrations clés (API, SSO, DAM, PIM, CRM), et les normes de sécurité à respecter.

Ensuite, listez enfin les livrables attendus : logiciels, documentation, jeux de tests, supports de formation, maquettes, plan de déploiement, prestations complémentaires (TMA, infogérance, recette, migration, etc.).…

Enfin, écrivez noir sur blanc ce qui figure dans le marché et ce qui restera hors périmètre (ou fera l’objet d’un autre marché).

Pour résumer, expliquez clairement ce que le CDC doit décrire :

• les services attendus (hébergement, TMA, infogérance, développement, intégration SaaS…)
• les livrables (logiciels, documentation, plans de tests, supports de formation)
• les obligations du prestataire (réactivité, continuité de service, sécurité, reporting, assistance)

En résumé, le lecteur doit comprendre en quelques pages où s’arrête la promesse marketing et où commence l’engagement contractuel.

Le cadre se précise. Vous avez posé le décor et les règles du jeu. À présent, regardons ce que vivent les utilisateurs.

3. Parcours utilisateurs et exigences fonctionnelles : raconter l’usage avant la technologie

Votre CDC doit s’adresser à des chefs de projet, des équipes techniques, des acheteurs et parfois des juristes. La seule façon de parler à tout le monde est de raconter les usages.

Servez-vous des parcours utilisateurs et des user stories pour éviter les zones grises.

Commencez par vos personas :

• l’éditeur qui publie,
• le traducteur qui traite une file de contenus,
• le chef de projet qui orchestre,
• la DSI qui sécurise.

Décrivez une journée type avec leurs irritants et leurs attentes.

Ensuite, basculez en user stories. Une user story décrit un besoin fonctionnel vu par l’utilisateur, au format : « En tant que… je veux… afin de… ».  Associez à chaque story des critères d’acceptation.

Par exemple :

Story
« En tant que chef de projet éditorial, je veux lancer une demande de traduction en un clic depuis l’éditeur, afin de suivre l’état et valider les retours sans quitter mon flux. »

Critères d’acceptation

• Le bouton « Demander une traduction » s’affiche pour les rôles autorisés.
• Le système préremplit la langue source et les langues cibles selon un modèle.
• Le statut de la demande se met à jour en temps réel et garde l’historique.
• L’utilisateur clôture la tâche avec un commentaire obligatoire.

Une bonne user story remplace souvent un long paragraphe de spécifications illisibles. Ce type de formulation clarifie rapidement ce que la solution doit permettre de faire, sans figer le choix technique.

 « Nous avons réécrit 40 pages de spécifications sous forme de 80 user stories. Les débats ont diminué, les développeurs ont posé moins de questions », résume Claire, cheffe de projet dans les médias.

4. Exigences techniques et architecture : tracer les rails

Dans cette partie, vous donnez aux équipes techniques la profondeur dont elles ont besoin, sans perdre les autres lecteurs.

D’abord, décrivez un schéma d’architecture cible : modules, flux, API, stockages, outils tiers. Même un croquis simplifié rend le propos plus concret.

Puis, détaillez :

• les intégrations (REST ou GraphQL, authentification via OAuth2 ou OpenID Connect, mapping des données),
• la sécurité (chiffrement au repos et en transit, journalisation, conservation, RGPD, gestion des droits par rôle),
• la performance (temps de réponse, charge, pics, stratégie de cache, tolérance aux pannes),
• la qualité et l’observabilité (logs, métriques, alertes, SLO/SLA, traçabilité).

Appuyez-vous sur la modélisation UML quand c’est utile : diagrammes de cas d’utilisation, d’activité, de séquence, de classes. Vous représentez ainsi les données, les acteurs, les échanges, et pas seulement une liste de fonctionnalités.

Un système vit, change, s’améliore. Vous avez posé les premières briques. Il faut maintenant définir qui pilote tout cela.

5. Gouvernance, rôles et responsabilités : savoir qui décide quoi

Un projet qui avance garde une gouvernance lisible.

Présentez votre comité projet : sponsor, responsable produit, référent technique, sécurité, métier éditorial… Chacun tient un rôle clair.

Introduisez ensuite la matrice RACI (Responsible, Accountable, Consulted, Informed) :

• qui réalise (R),
• qui porte la responsabilité finale (A),
• qui vous consulte (C),
• qui vous informez (I).

Exemple de matrice RACI simplifiée pour un projet SI (à adapter selon vos besoins)

Légende :

• R = Responsible (réalise)
• A = Accountable (décideur final)
• C = Consulted (consulté)
• I = Informed (informé)

Ajoutez le rythme des points clés : revues de sprint, démonstrations produit, comités de pilotage, arbitrages.

Enfin, terminez par une cartographie des risques avec leur probabilité, leur impact et un plan B.

Avez-vous désigné un owner (responsable identifié) pour chaque exigence critique ? Si non, faites-le et inscrivez son nom dans le CCFT.

6. Planning et méthodes : transformer l’intention en trajectoire

À ce stade, il ne s’agit plus seulement de définir ce que le projet doit produire, mais comment il va avancer, être contrôlé et livré dans les délais et le niveau de qualité attendus.

Méthode de conduite de projet

Tout d’abord, choisissez et expliquez votre approche de delivery :

• Agile (Scrum ou Kanban) avec sprints, backlog priorisé, démonstrations régulières, feedback continu
• Approche itérative ou cycle en V, si votre contexte l’impose : V : jalons formalisés, phases séquentielles, validations intermédiaires

Puis, montrez une roadmap lisible qui enchaîne les phases clés : exploration, design, build, intégration, la recette utilisateur, formation, go-live, hypercare (période de soutien renforcé après la mise en production).

Ajoutez également des phases gestion du changement : communication, supports, formation, boucles de feedback.

Plan d’assurance qualité (PAQ)

Ensuite, le projet devra être encadré par un Plan d’assurance qualité (PAQ), formalisé par le prestataire et validé par la maîtrise d’ouvrage en début de mission.

Le PAQ définit le cadre de la qualité :

• l’organisation et les responsabilités,
• les processus de contrôle et de validation,
• les critères de conformité et de passage des jalons clés.

Il conditionne notamment la recette utilisateur, la décision de mise en production et le Go / No-Go. Le PAQ constitue ainsi un référentiel commun entre MOA et MOE pour sécuriser les livraisons tout au long du projet.

Qualité opérationnelle : tests et outillage

Enfin, côté qualité opérationnelle, décrivez les moyens concrets mis en œuvre pour appliquer ce cadre :

• les pipelines CI/CD (intégration et déploiement continus),
• les revues de code et contrôles techniques,
• la stratégie de tests : unitaires, d’intégration, End-to-End (E2E) et sécurité.

Précisez les environnements (dev, test, recette, production), les critères d’acceptation, ainsi que les modalités de correction des anomalies.

L’objectif est simple : garantir que chaque livraison est testée, validée et conforme aux exigences fonctionnelles, techniques et de sécurité avant son déploiement.

Vous avez décrit comment l’équipe avance au quotidien. Reste à cadrer la relation contractuelle.

7. Clauses sensibles et clauses contractuelles

Ici, certaines clauses portent une part importante du risque. Donc, rédigez-les avec soin. Parmi elles :

• Sécurité et continuité de service : exigences de chiffrement, gestion des incidents, plan de reprise d’activité (PRA), journalisation, habilitations.
• Interopérabilité et compatibilité : formats d’échange, API, standards ouverts, contraintes d’intégration avec votre SI (SSO, annuaire, PIM, CRM, etc.).
• Réversibilité et restitution des données : formats d’export, délais, responsabilités, coûts, support du prestataire sortant.
• Protection des données personnelles (RGPD) : catégories de données, localisation, sous-traitants, accord de traitement des données, rôle du DPO.
• SLA / SLO (Service Level Agreement / Objectives) : temps de réponse, taux de disponibilité, délais de prise en compte et de résolution, pénalités éventuelles.

Pour chaque clause, posez-vous la question : “Que se passe-t-il si… ?”. Si la réponse est floue, la clause manque de précision.

Définissez ensuite la propriété intellectuelle : code, livrables, templates, documentation, modèles IA éventuels.

Abordez également la confidentialité et le RGPD : données, sous-traitants, accord de traitement des données, rôle du DPO (Data Protection Officer).

Terminez avec la facturation et les avenants (comment vous gérez les demandes hors périmètre), puis la réversibilité : plan de sortie, backups, export des données, transfert de compétences.

Prévoyez un tour de table juridique avec le DPO et le service juridique avant la signature, pas après le premier incident.

Les projets les plus sereins se préparent… en réfléchissant dès le début à la sortie. Paradoxal, mais terriblement efficace.

8. Annexes utiles : le coffre à outils

Enfin, n’oubliez pas les annexes. Elles transforment un bon CDC en outil de référence.

Glissez-y :

• un glossaire qui traduit le jargon (API, SSO, PRA, TMA, etc.)
• des modèles (user stories, cas de test, checklists de sécurité, exemple de RACI)
• des schémas (architecture, flux de données, responsabilités)

Les lecteurs pressés y trouveront rapidement l’information essentielle.

Écrire sans lasser : 10 astuces pour être lu

Un cahier des charges doit être opérationnel. Autrement dit, l’enjeu n’est pas de produire un document exhaustif, mais un outil de travail vivant. Il ne faut pas oublier non plus que cela reste un texte. Et un texte se lit mieux quand il respecte quelques règles simples.

1. Adoptez une structure modulaire : chaque grande section se lit séparément
2. Adoptez un ton neutre et factuel, orienté résultats
3. Parlez aux utilisateurs, pas aux systèmes
   Préférez « L’éditeur déclenche la traduction » à « Le module de traduction est déclenché ».
4. Utilisez des titres concrets et accrocheurs
   « Ce que l’éditeur fait en 3 clics » parle mieux que « Fonctionnalités éditeur ».
5. Raccourcissez les phrases
   Deux phrases claires informent mieux qu’une seule qui s’étire sur 5 lignes.
6. Montrez la progression avec des mots de liaison en début de phrase (D’abord, Ensuite, Par ailleurs, Enfin…)
7. Évitez la voix passive
   « L’équipe sécurité valide la conception » rythme davantage que « La conception est validée ».
8. Favorisez la lisibilité : illustrez avec des images, tableaux, diagrammes et mini-scénarios
   Un parcours simple en 5 étapes, avec captures ou maquette, convainc plus vite qu’une page de texte.
9. Rangez les détails techniques dans des encadrés ou annexes. Vous gardez une narration fluide tout en donnant de la précision à ceux qui la recherchent.
10. Mettez à jour le document à chaque évolution majeure.

Un bon test : si un prestataire externe peut comprendre sans explication orale la finalité du projet, celui-ci est réussi.

La partie technique : aligner les attentes et la qualité

Posez des exigences chiffrées. Les chiffres réduisent les malentendus.

• Performance : « 95 % des requêtes en moins de 300 ms pour 500 utilisateurs simultanés (hors pics planifiés). »
• Sécurité : « Chiffrement AES-256 au repos, TLS 1.2+ en transit, rotation mensuelle des secrets. »
• Interopérabilité : « API REST paginée, JSON, versionnée, documentation OpenAPI, limites de consommation publiées. »
• Qualité : « 80 % de couverture de tests unitaires sur les modules critiques », « zéro incident de sévérité P1 en production. »

Les chiffres protègent la discussion : chacun sait ce que “rapide”, “fiable” ou “sécurisé” signifie dans ce projet précis.

Gouvernance et communication : la mécanique qui évite les emballements

Une bonne gouvernance repose sur des routines simples plutôt que sur des comités exceptionnels.

Par exemple, mettez en place:

• une démo toutes les deux semaines : chaque sprint se conclut par une mise en visibilité
• un comité de pilotage mensuel : décisions, arbitrages, risques, finances
• un canal unique pour les demandes de changement (un formulaire court avec impact, coût, délai)
• un registre des décisions partagé en 24 heures

Qui tient ce registre des décisions ? Nommez une personne, donnez-lui l’autorité pour dire : « Ceci n’entre pas dans le périmètre défini. »

Budget, délais, risques : jouer cartes sur table

Parlez argent et calendrier tôt, clairement. Pour le budget, structurez par grandes rubriques : Build, Intégrations, Sécurité, Tests, Formation, Run. Ajoutez une réserve pour les aléas (10-15 %).

Côté délais, utilisez un Gantt léger ou une roadmap visuelle : jalons datés, principales dépendances.

Côté risques, listez-les avec un plan de mitigation.

Exemple : « Retard d’intégration SSO » → « POC en amont + interlocuteur DSI dédié ».

Un prototype simple, réalisé tôt, efface parfois la moitié des incertitudes : n’hésitez pas à négocier un sprint spike pour les points techniques délicats.

Un cahier des charges ne se contente pas de cadrer un projet. Il raconte pourquoi l’organisation change, comment elle s’organise pour le faire, avec quels partenaires et sous quelles conditions. Il relie l’opportunité au contrat, les ambitions métier aux tests de recette, le quotidien des utilisateurs aux modèles UML, les promesses commerciales aux SLA.

Bien conçu, il devient une boussole partagée par toutes les parties prenantes. Il réduit les frictions, accélère les décisions, sécurise la relation avec les prestataires.

Et surtout, il cesse de ressembler à un pavé bureaucratique. Il devient un document que l’on ouvre en réunion non par obligation, mais parce qu’il aide vraiment à travailler.