Cahier des charges fonctionnel logiciel : modèle et exemple

Cahier des charges fonctionnel d'un logiciel : modèle et exemple

Rédiger le cahier des charges fonctionnel d'un logiciel, c'est définir ce qu'un projet logiciel doit apporter avant que le premier prestataire ne remette une offre. Le cahier des charges fonctionnel est le document du donneur d'ordre. Il décrit les objectifs, les processus et les exigences du point de vue métier et laisse volontairement ouverte la manière dont la solution sera construite techniquement. Plus il est rigoureux, plus les offres sont comparables et moins le périmètre fait débat par la suite.

En bref

Le cahier des charges fonctionnel d'un logiciel décrit, du point de vue du donneur d'ordre, ce que le logiciel doit faire, et non comment il est construit. Une structure éprouvée le divise en huit chapitres: contexte et objectif, situation actuelle, situation cible, exigences fonctionnelles, exigences de qualité, contraintes et interfaces, exclusions, ainsi que livrables et réception. Sur cette base, le prestataire rédige le cahier des charges technique. Voir notre modèle : Cahier des charges technique.

Qu'est-ce qu'un cahier des charges fonctionnel logiciel ?

La norme DIN 69901-5 définit le cahier des charges fonctionnel (Lastenheft) comme « l'ensemble des exigences fixées par le donneur d'ordre concernant les fournitures et prestations d'un prestataire dans le cadre d'une commande » (cité d'après LMU de Munich, travail de séminaire, 01/2017). L'ancienne norme DIN 69905, qui est encore souvent citée, a été intégrée depuis 2009 à la série de normes DIN 69901 (DIN Media).

Pour un projet logiciel, cela signifie que le cahier des charges fonctionnel répond aux questions « quoi » et « pour quoi » : quel problème métier doit être résolu, qui travaille avec le système, quels processus il doit couvrir, quelles conditions s'appliquent en exploitation. La question du « comment », c'est-à-dire l'architecture, les technologies et le modèle de données, est traitée par le prestataire dans le cahier des charges technique. Les différences détaillées entre les deux documents sont présentées dans notre article sur le modèle de cahier des charges technique.

Ce qui a sa place dans le cahier des charges fonctionnel, et ce qui ne l'a pas
Dans le cahier des charges fonctionnel Dans le cahier des charges technique
Objectif commercial et critère de réussite Architecture et composants
Les groupes d'utilisateurs et leurs processus Langage de programmation, frameworks, base de données
Exigences fonctionnelles avec priorité Mise en œuvre technique de chaque exigence
Systèmes existants devant être connectés Les protocoles d'interface et les formats de données en détail
Budget et calendrier Estimation de la charge de travail et plan de projet

Le modèle de cahier des charges fonctionnel logiciel : huit chapitres

Le plan suivant passe en revue les éléments dont un prestataire a besoin pour établir une offre solide. Il s'applique aussi bien à un outil interne qu'à une plateforme multi-sites ; seule la profondeur varie.



Télécharger le modèle de cahier des charges fonctionnel (en allemand)

Les huit chapitres en modèle à compléter, en allemand, avec conseils et un exemple fictif par chapitre : Word (.docx) · OpenOffice/LibreOffice (.odt). Gratuit, sans inscription.

  1. Contexte et objectif du projet. Quel problème métier doit être résolu, pourquoi maintenant, et sur quels critères le donneur d'ordre mesurera le succès après la mise en œuvre.
  2. Situation actuelle. Comment le processus fonctionne-t-il aujourd'hui, avec quels outils, quels volumes et quels points faibles connus ? Les chiffres, tels que le nombre d'utilisateurs, le nombre d'opérations par jour ou le nombre de sites, aident davantage le prestataire que n'importe quelle description.
  3. État souhaité. Qui utilisera ce système à l'avenir et comment le processus devra-t-il se dérouler par la suite ? Ces points sont décrits du point de vue des utilisateurs, et non d'un point de vue technique.
  4. Exigences fonctionnelles. Chaque exigence séparément, numérotée et avec une priorité, par exemple OBLIGATOIRE, SOUHAITÉ et OPTIONNEL. Des exigences numérotées rendent les offres comparables (wiki.induux.de).
  5. Exigences de qualité. Disponibilité, délais de réponse, protection des données, accessibilité, multilinguisme. Si possible, avec des chiffres, afin qu'ils puissent être vérifiés.
  6. Contexte et interfaces. Les systèmes existants tels que les progiciels de gestion intégrée (ERP) ou Active Directory, les directives informatiques relatives à l'exploitation dans le cloud ou au sein du centre de données interne, ainsi que les exigences légales.
  7. Exclusions. Ce qui n'est expressément pas inclus dans la mission. Ce chapitre permet d'éviter davantage de malentendus que tout autre.
  8. Contenu de la livraison, réception et cadre. Ce qui est fourni (logiciels, documentation, formation, exploitation), comment se déroule la réception, quels sont les délais et le budget prévus.

Exemple de cahier des charges fonctionnel : un portail de maintenance

Exemple fictifL'exemple suivant est purement fictif et n'a qu'un but illustratif. Il ne fait référence à aucun client ni à aucun projet réel.

Un constructeur de machines disposant de trois usines consigne aujourd'hui les opérations de maintenance dans des tableaux Excel et sur papier. L'objectif est de mettre en place un portail de maintenance dans lequel les techniciens traitent les ordres de travail sur tablette et où la direction de l'usine peut visualiser les interventions en attente pour chaque installation. Un extrait du chapitre 4 pourrait se présenter comme suit :

Extrait fictif : exigences fonctionnelles d'un portail de maintenance
N°. Priorité Exigence Vérifiable par
A-01 OBLIGATOIRE Les techniciens peuvent consulter sur leur tablette toutes les interventions de maintenance qui leur ont été attribuées pour la journée. Test avec trois comptes de techniciens
A-02 OBLIGATOIRE Une commande peut être validée sans connexion Internet et sera transmise ultérieurement. Test en mode avion
A-03 SOUHAITÉ Les photos et les valeurs mesurées sont directement associées à la commande. Réception sur une installation type
A-04 OPTIONNEL La direction de l'usine reçoit chaque semaine par e-mail un récapitulatif des opérations de maintenance en retard. Échantillon prélevé sur deux semaines

Ce qui manque est révélateur : pas de base de données, pas de technologie d'application, pas d'architecture. L'exigence A-02 dit que le technicien doit pouvoir travailler hors ligne, pas comment la synchronisation est construite. C'est le prestataire qui en décide dans le cahier des charges technique.

Qui rédige le cahier des charges fonctionnel

Le cahier des charges fonctionnel est rédigé par le donneur d'ordre. En pratique, c'est le plus souvent une personne du service métier ou de la gestion de projet, qui connaît le processus et peut obtenir les décisions. L'informatique fournit les contraintes, les futurs utilisateurs fournissent les processus. Un partenaire externe peut aider à structurer le document, mais ne doit pas en imposer le contenu. Confier la rédaction au futur prestataire donne souvent des exigences qui correspondent comme par hasard à sa propre solution.

Erreurs fréquentes dans le cahier des charges fonctionnel

  • La technologie plutôt que les besoins. « Le logiciel doit être développé avec React » n'est pas une exigence fonctionnelle. Ce type de prescription n'y a sa place que si votre propre service informatique l'exige réellement, et alors dans le chapitre des contraintes.
  • Un texte continu plutôt qu'une liste. Les exigences dissimulées dans les paragraphes ne peuvent être ni classées par ordre de priorité ni validées.
  • Aucune priorité. Si tout est « obligatoire », chaque prestataire évalue l'ensemble des prestations et l'offre devient plus chère que nécessaire.
  • Pas de volumétrie. Que l'on compte dix ou dix mille utilisateurs, un seul site ou douze, cela modifie fondamentalement l'architecture et le prix.
  • Pas d'exclusions. Ce qui n'est pas exclu est rapidement considéré par la suite comme ayant été commandé. Il en résulte Dérive du périmètre.

Comment le cahier des charges fonctionnel structure la comparaison des offres

Un cahier des charges fonctionnel est généralement envoyé à plusieurs prestataires. Chacun répond par une offre ou une première ébauche de solution. Ces réponses ne deviennent comparables que si toutes se réfèrent aux mêmes exigences numérotées. On peut alors vérifier, exigence par exigence, qui couvre quoi, où un prestataire formule des hypothèses et où il omet des points sans le dire.

Un simple tableau comparatif suffit : les numéros d'exigence en lignes, les prestataires en colonnes et, dans chaque cellule, « couvert », « partiel » ou « non inclus ». Les grands écarts de prix s'expliquent souvent moins par les taux horaires que par des hypothèses différentes sur le périmètre. Les autres facteurs qui déterminent le prix sont décrits dans notre article Coût des logiciels sur mesure.

Faire relire votre cahier des charges fonctionnel avant l'envoiNous le lisons comme le ferait un prestataire et nous soulignons les points sur lesquels les offres divergeront.

Demander un rendez-vous

Foire aux questions

Que doit contenir un cahier des charges fonctionnel logiciel ?

Contexte et objectif, situation actuelle et situation cible, exigences fonctionnelles numérotées avec priorité, exigences de qualité, contraintes et interfaces, exclusions, ainsi que livrables, réception et cadre de délais et de budget. Les solutions techniques n'y ont pas leur place.

Qui établit le cahier des charges fonctionnel ?

Le donneur d'ordre. Selon la norme DIN 69901-5, il contient les exigences fixées par le donneur d'ordre concernant les prestations du prestataire. Le service métier, l'informatique et les futurs utilisateurs en fournissent le contenu ; un partenaire externe peut aider à le structurer.

Le cahier des charges fonctionnel fait-il partie du contrat ?

En règle générale, oui. Le cahier des charges fonctionnel est établi par le donneur d'ordre et fait habituellement partie du contrat ou de l'appel d'offres (LMU Munich, 01/2017 ; wiki.induux.de). Les exigences doivent donc être formulées de façon à pouvoir être vérifiées sans ambiguïté lors de la réception.

Un projet logiciel agile a-t-il besoin d'un cahier des charges fonctionnel ?

Oui, mais plus léger. L'objectif, les groupes d'utilisateurs, les contraintes, les exclusions et les principales exigences obligatoires doivent être fixés avant le démarrage, même dans un projet agile. Les détails se construisent ensuite dans le backlog. Comment découper un premier périmètre pertinent, c'est ce que montre notre article sur le MVP.

La prochaine étape

torck lit les cahiers des charges fonctionnels du point de vue du développement et pose les questions avant qu'elles ne deviennent des hypothèses dans l'offre. Nos équipes de Maxhütte-Haidhof, Vienne et Rabat développent des logiciels et des solutions de données et d'IA pour l'industrie et le commerce, avec torck GmbH comme partenaire contractuel allemand. Lors d'un Premier entretien , nous passons ensemble en revue votre cahier des charges fonctionnel ou vos premières exigences.

Une question sur cet article ?

Deux phrases suffisent pour décrire votre situation. La réponse vous sera donnée par quelqu'un qui conçoit lui-même ce genre de systèmes.

Réponse dans un délai d'un jour ouvrable.torck · code with torque
Florian Blischke
Directeur général de torck GmbH · plus de 20 ans d'expérience dans le développement de logiciels
Florian Blischke est directeur général de torck GmbH et travaille depuis plus de 20 ans dans le développement de logiciels. Il est responsable de logiciels individuels destinés à l'industrie et au commerce, allant de l'intégration des processus physiques à l'architecture cloud, en passant par l'IoT et les systèmes basés sur les données et l'IA. Chez torck, il supervise notamment la plateforme énergétique Jouvoli et le produit de gestion de flotte KVM Fleet. torck développe ses solutions sur ses sites de Maxhütte-Haidhof, Vienne et Rabat, et accorde une grande importance à la mise au point de logiciels qui fonctionnent réellement en conditions réelles d'exploitation.

Vous vous posez la même question ?

Depuis 2017, nous développons des logiciels pour l'industrie et le commerce depuis Maxhütte-Haidhof, avec des équipes à Vienne et à Rabat. Un premier entretien dure 30 minutes et est gratuit. À l'issue de celui-ci, vous saurez si le projet en vaut la peine, même si la réponse est négative.

Autres articles