Cahier des charges informatique : méthode, exemple et modèle

Pour rédiger un cahier des charges informatique, partez du problème métier, décrivez les usages attendus et associez chaque exigence à un critère de validation. Complétez avec le périmètre, les contraintes techniques, le budget, le calendrier et les responsabilités. Ce document doit permettre à un prestataire de chiffrer le projet et à vos équipes de vérifier la livraison.

Ce guide propose une méthode en huit étapes, un exemple de gestion des demandes d’intervention et une trame à adapter à votre logiciel ou application métier. Le fil conducteur : prendre les décisions utiles assez tôt pour éviter de réécrire le document à chaque réunion.

Télécharger le modèle Word gratuit de cahier des charges informatique — document modifiable, avec trame vierge et exemple rempli, sans inscription. Vous pouvez aussi consulter l’exemple directement dans l’article.

Mis à jour le 3 octobre 2026.

Qu’est-ce qu’un cahier des charges informatique ?

Un cahier des charges informatique est le document de référence qui formalise les objectifs, les besoins, les contraintes et les conditions d’acceptation d’un projet numérique. Il peut concerner un logiciel métier, une application web ou mobile, un ERP, un portail ou une évolution du système d’information.

Il sert à partager une compréhension du besoin, comparer des propositions sur une même base et préparer la recette, c’est-à-dire la vérification de la solution livrée. Il précise aussi ce qui reste à décider : une hypothèse visible peut être discutée ; une hypothèse implicite risque de devenir un désaccord.

Trois niveaux d’information se complètent :

Le cahier des charges fonctionnel approfondit les usages et les règles métier. Les choix de conception détaillés peuvent ensuite être proposés par l’équipe technique. Imposez une technologie lorsqu’une contrainte le justifie, en expliquant cette contrainte.

Qui rédige et qui valide le document ?

Le responsable métier porte le besoin ; le chef de projet ou l’assistance à maîtrise d’ouvrage coordonne la rédaction. Les utilisateurs décrivent le travail réel, tandis que la DSI examine les intégrations, la sécurité et l’exploitation. La direction ou le sponsor arbitre les priorités et les moyens.

Répartissez les validations : le métier approuve les scénarios et les résultats attendus, la DSI les contraintes techniques, le responsable budgétaire l’enveloppe et le sponsor le périmètre. Associez les achats et, selon les données traitées, le responsable sécurité ou le délégué à la protection des données.

Un consultant peut faciliter les entretiens et structurer le dossier. Il a néanmoins besoin d’interlocuteurs disponibles pour décider. Prévoyez des ateliers de cadrage métier et IT avec des exemples de dossiers, des formulaires et des cas d’exception à examiner ensemble.

Comment rédiger un cahier des charges informatique en 8 étapes

1. Décrire le contexte et les résultats attendus

Présentez l’activité, les utilisateurs concernés et le fonctionnement actuel. Décrivez les difficultés observables : doubles saisies, manque de visibilité, erreurs de transmission ou délais difficiles à suivre. Indiquez les outils utilisés et les volumes connus, en distinguant les mesures des estimations.

Remplacez « améliorer la productivité » par un résultat observable : chaque demande doit avoir un responsable identifié et un statut consultable. Si vous fixez un objectif chiffré, précisez la valeur de départ, la cible, la période et la méthode de mesure. Sans mesure initiale, prévoyez de l’établir pendant le cadrage.

2. Décrire les utilisateurs et le processus réel

Partez d’un scénario complet, du déclencheur au résultat. Qui crée la demande ? Qui la contrôle ? Qui décide ? Qui intervient ? Qui constate que le travail est terminé ? Pour chaque rôle, décrivez les informations nécessaires et les actions autorisées.

Ajoutez les exceptions : dossier incomplet, refus, absence du responsable, doublon, annulation et réouverture. Un schéma du processus et quelques cas réels anonymisés permettent de vérifier que toutes les équipes parlent du même fonctionnement. Ils deviennent ensuite une base pour concevoir le workflow de l’application.

3. Fixer le périmètre et les priorités

Écrivez ce qui entre dans la première livraison et ce qui en est exclu. Définissez les sites, populations, langues et données concernés. Identifiez les dépendances : accès à une API, disponibilité d’un expert, nettoyage des données ou décision d’architecture.

Classez les besoins en indispensables, importants et optionnels. Une exigence indispensable bloque la mise en service si elle manque. Une option doit pouvoir être chiffrée séparément. Évitez de qualifier chaque demande d’urgente : le prestataire a besoin de connaître les arbitrages possibles.

4. Rédiger des exigences fonctionnelles testables

Donnez un identifiant stable à chaque exigence, puis précisez l’acteur, le déclencheur, la règle métier et le résultat attendu. Une phrase doit porter une règle que l’on peut vérifier. Reliez-la à sa priorité et à un test de recette.

« L’outil doit gérer les interventions » laisse trop d’interprétations. Préférez : « Un responsable peut affecter une demande de son site à un technicien actif. Après validation, le technicien voit cette demande dans sa liste de travail. » Ajoutez ensuite la règle de refus lorsqu’une affectation n’est pas autorisée.

Pour les formulaires, indiquez les champs obligatoires, les formats et les contrôles. Pour les notifications, précisez l’événement, le destinataire et le canal. Pour un tableau de bord, donnez la définition de chaque indicateur et les droits de consultation.

5. Préciser les données, les intégrations et la sécurité

Cette partie doit rendre les contraintes vérifiables. Décrivez notamment :

• Données et reprise : sources, formats, qualité attendue, volumes et contrôles après import.
• Intégrations : systèmes concernés, sens des échanges, fréquence, responsable de chaque interface et comportement en cas d’échec.
• Accès : authentification, rôles, séparation des périmètres et retrait des droits lorsqu’un utilisateur change de fonction.
• Performance et disponibilité : opérations mesurées, charge, conditions réseau, plages de service et protocole de test.
• Exploitation : sauvegardes, restauration, journalisation, supervision et responsabilités de support.
• Accessibilité et mobilité : parcours au clavier, lisibilité, terminaux visés et éventuel fonctionnement hors connexion.

« Rapide » ou « sécurisé » ne suffit pas. Une cible de temps de réponse doit préciser le scénario et les conditions de mesure. Une exigence de sécurité doit préciser le contrôle attendu et la preuve qui permettra de le vérifier.

Si le projet traite des données personnelles, faites préciser les données nécessaires, leurs finalités, les habilitations et les durées de conservation avec les responsables concernés. Le guide de sécurité de la CNIL fournit des repères pour cadrer l’authentification, les accès, la traçabilité, les sauvegardes et la reprise d’activité.

6. Encadrer le budget, le planning et les livrables

Demandez un chiffrage qui distingue cadrage, réalisation, interfaces, reprise de données, tests, formation et mise en service. Ajoutez les coûts récurrents : licences, hébergement, support et maintenance. Précisez la période de comparaison retenue pour éviter de comparer un coût initial avec un coût sur plusieurs années.

Organisez le calendrier autour de livrables acceptables : périmètre validé, prototype examiné, interfaces testées, recette terminée et équipe formée. Associez à chaque jalon un responsable, une date cible et ses dépendances. La date de livraison dépend aussi du délai de réponse de vos équipes.

Prévoyez la documentation, le transfert de connaissances et les conditions de récupération des données à la sortie de la solution. Les engagements à formaliser avec le prestataire doivent être examinés par les interlocuteurs contractuels du projet.

7. Préparer la recette avant le développement

La recette vérifie que la livraison répond aux exigences approuvées. Pour chaque test, indiquez la référence de l’exigence, le profil utilisateur, les données de départ, les actions et le résultat attendu. Désignez la personne qui constate le résultat et celle qui prononce l’acceptation.

Testez le cas nominal, les refus attendus et les erreurs d’intégration. Définissez les anomalies qui bloquent la mise en service, la façon de documenter les réserves et le délai de correction convenu. Une démonstration générale ne remplace pas ces vérifications.

8. Valider une version et organiser les évolutions

Donnez au document une version, une date, un responsable et un statut : en rédaction, en revue ou validé. Centralisez les commentaires et consignez les décisions. Les questions ouvertes doivent avoir un propriétaire et une échéance.

Après validation, toute évolution reçoit une description, une justification et une analyse d’impact sur le coût, le délai et la recette. L’arbitrage peut être simple : intégrer au lot courant, reporter ou abandonner. Ce suivi permet de faire évoluer le besoin tout en gardant une référence commune.

Exemple rempli : une application de demandes d’intervention

Exemple fictif à adapter. Une entreprise souhaite centraliser les demandes d’intervention de trois sites. Les volumes, délais et règles ci-dessous sont des hypothèses pédagogiques, pas des résultats clients ni des engagements de Softyflow.

Objectif : rendre chaque demande traçable, de sa création à sa clôture. Périmètre du premier lot : saisie, qualification, affectation, suivi et historique. Hors périmètre : gestion des stocks de pièces, facturation et maintenance prédictive. Les utilisateurs sont les demandeurs, les responsables de site et les techniciens.

La matrice des droits complète ces règles : le demandeur consulte ses demandes, le responsable celles de son site et le technicien celles qui lui sont affectées. Les contrôles d’autorisation doivent aussi s’appliquer à un accès direct à une fiche ou à une API.

Pour F-02, le test peut s’écrire ainsi : « Étant donné une demande du site A et un responsable du site B, lorsqu’il tente une affectation, l’opération est refusée et la demande reste inchangée. » Cette précision rend une règle métier directement exploitable par les personnes qui développent et testent.

Modèle Word gratuit : la trame à remplir

Le fichier contient une trame vierge en huit rubriques, une fiche d’exigence, un scénario de recette, un registre des changements et l’exemple d’intervention rempli. Les zones entre crochets sont à compléter ; les hypothèses de l’exemple sont à remplacer par vos décisions.

1. Contexte, problème et objectifs mesurables.
2. Utilisateurs, rôles et processus existant.
3. Périmètre, exclusions et priorités.
4. Exigences fonctionnelles et règles de gestion.
5. Données, interfaces et exigences non fonctionnelles.
6. Budget, calendrier, livrables et exploitation.
7. Recette, critères d’acceptation et responsables.
8. Validation, versions, décisions et demandes de changement.

Télécharger le modèle de cahier des charges informatique au format Word (.docx)

Pour un ERP, développez les référentiels, la reprise des historiques et les interfaces. Pour un portail, détaillez les profils externes et la séparation des données. Pour une application mobile, précisez les appareils, les usages terrain, les permissions et la synchronisation si un mode hors connexion est nécessaire.

Comment éviter de réécrire le cahier des charges à chaque réunion ?

Le problème vient souvent de décisions restées implicites. Rendez visibles les limites du projet, les désaccords et les hypothèses avant de chercher à finaliser chaque paragraphe.

• Besoin encore flou : examinez un dossier concret avec un utilisateur et reformulez le résultat attendu.
• Demandes contradictoires : nommez l’arbitre et consignez sa décision avec sa justification.
• Nouvelles idées permanentes : enregistrez-les dans une liste priorisée, avec leur impact sur le lot courant.
• Solution difficile à imaginer : utilisez un prototype pour tester les parcours et relever les règles manquantes.
• Plusieurs versions concurrentes : désignez une référence partagée et conservez un historique des changements approuvés.

En méthode agile, le cadrage donne une direction et des limites. La liste priorisée des travaux, souvent appelée backlog, détaille progressivement les fonctionnalités. Conservez les identifiants d’exigences dans les tâches, les tests et les décisions : vous pourrez suivre l’effet d’un changement sans repartir de zéro.

Checklist avant d’envoyer le document à un prestataire

Le dossier est prêt à être consulté lorsque vous pouvez répondre à ces questions :

• Le problème à résoudre et les utilisateurs concernés sont-ils compréhensibles sans explication orale ?
• Le périmètre, les exclusions et les priorités sont-ils explicites ?
• Les règles métier et les principaux cas d’exception sont-ils décrits ?
• Les accès, données et interfaces ont-ils un responsable identifié ?
• Chaque exigence indispensable dispose-t-elle d’un résultat testable ?
• Le chiffrage demandé inclut-il la reprise des données et les coûts d’exploitation ?
• Les livrables, les dépendances et les validateurs sont-ils nommés ?
• Les questions ouvertes et la procédure de changement sont-elles visibles ?

Pour comparer les réponses, demandez au prestataire de préciser, pour chaque exigence : couvert en standard, à configurer, à développer ou non couvert. Faites expliciter les hypothèses, exclusions, dépendances et options. Un prix global seul ne permet pas de comprendre ce qui sera livré.

Du cahier des charges au prototype avec Softyflow

Lorsque le projet repose sur des formulaires, des validations et des échanges avec le système d’information, un prototype aide à confronter les règles aux usages. La plateforme low code Softyflow réunit la création d’interfaces, la modélisation de workflows et la connexion aux systèmes existants.

Choisissez un parcours représentatif : soumettre une demande, l’affecter, la traiter et la clôturer. Faites-le essayer aux utilisateurs, relevez les écarts et mettez à jour les exigences. La DSI doit ensuite vérifier les droits, les intégrations, les performances et les conditions d’exploitation prévues au cahier des charges.

Pour préparer cette étape, découvrez notre approche du développement d’applications métier ou demandez un essai de Softyflow à partir d’un processus que vous souhaitez digitaliser.

Pour compléter le cadrage de votre projet, le dossier IT et technologie réunit d’autres repères sur les applications et le système d’information.

Préparez aussi la vérification des exigences : téléchargez le modèle Excel de cahier de recette informatique, puis adaptez les scénarios et les résultats attendus à votre projet.