Cahier des charges logiciel sur mesure : une trame utile pour PME

Un cahier des charges logiciel sur mesure doit permettre à deux personnes de comprendre le même travail à réaliser — puis de vérifier que le logiciel le fait correctement. Une liste comme « gestion clients, planning, statistiques » ne suffit pas : elle laisse ouvertes les règles, les exceptions et les responsabilités qui influencent le devis.

Voici une trame pour les dirigeants de PME et responsables métier qui préparent une consultation. L’objectif n’est pas de devenir développeur, ni de tout figer avant le premier échange. Il est de rendre les besoins, les décisions prises et les incertitudes assez explicites pour construire un premier périmètre cohérent.

Le repère Pixel Info : pour chaque demande importante, écrivez qui agit, dans quelle situation, avec quelles règles et quel résultat observable. Si vous ne savez pas encore répondre, indiquez la question à résoudre plutôt que d’inventer une précision.

Sommaire

• Définir le problème et les limites du projet
• Décrire le travail, pas seulement les écrans
• Rendre une exigence vérifiable
• Préciser données, accès et connexions
• Utiliser la trame de cahier des charges
• Comparer les propositions et gérer les changements
• Questions fréquentes

Cahier des charges logiciel sur mesure : partir d’un problème délimité

Commencez par décrire ce qui ne fonctionne pas aujourd’hui. « Nous voulons une application » est une solution envisagée. « Le responsable ne sait pas quelles interventions attendent une validation » décrit une difficulté que l’on peut examiner avec l’équipe. Joignez un exemple anonymisé du processus actuel : étapes, documents utilisés, personnes impliquées et points de blocage.

Précisez ensuite ce qui doit être différent après la mise en service. Un objectif utile peut être de retrouver le statut d’un dossier sans appeler plusieurs collègues. Si vous espérez réduire un délai ou des ressaisies, mesurez d’abord la situation de départ. Notez « à mesurer » lorsque les données manquent ; aucun pourcentage arbitraire ne rendra le dossier plus solide.

Écrivez aussi les limites : équipe concernée au lancement, opérations exclues, logiciel qui reste la référence pour la facturation, matériel déjà disponible, période d’activité à préserver. Cette délimitation protège le projet contre les attentes implicites. Elle ne prouve pas qu’un développement spécifique est nécessaire : notre guide pour décider s’il faut remplacer Excel par un outil métier aide à examiner cette question en amont.

Décrire un parcours complet avec ses exceptions

Choisissez une opération représentative et racontez-la du déclenchement à sa clôture. Qui reçoit l’information ? Qui la complète ? Qui décide ? Qu’est-ce qui peut empêcher de poursuivre ? Une maquette aide à discuter, mais elle ne remplace pas ces règles.

Le Service Manual de GOV.UK propose de décrire l’utilisateur, son besoin et son objectif, puis les résultats permettant de vérifier que le besoin est satisfait. Ce principe se transpose à un outil métier sans imposer une méthode de projet particulière : le texte doit rester compréhensible par les utilisateurs qui valideront le logiciel.

Exemple fictif : clôturer une intervention

Dans une entreprise fictive, un technicien prépare un compte rendu, puis un responsable le valide. Le besoin n’est pas simplement « ajouter un bouton Valider ». Il faut préciser les états autorisés, les informations nécessaires, la personne habilitée et ce qu’il se passe en cas de refus.

• Cas normal : le compte rendu complet passe de « à vérifier » à « validé », avec la date et l’identité du valideur.
• Cas incomplet : une information indispensable manque ; le dossier reste à corriger et l’utilisateur comprend ce qui est attendu.
• Cas de refus : le responsable renvoie le compte rendu au technicien avec un motif, sans effacer les informations déjà saisies.
• Cas de concurrence : deux personnes ouvrent le même dossier ; le comportement attendu doit éviter qu’une modification récente soit écrasée sans avertissement.

Ces règles sont un exemple à discuter, pas un fonctionnement universel. Dans votre entreprise, le technicien peut être autorisé à valider lui-même, ou une autre étape peut être indispensable. Faites arbitrer la règle par le responsable métier avant de demander au développeur de la deviner.

Transformer une attente vague en exigence testable

Attribuez un identifiant aux exigences importantes. Cela permet de relier une question, une estimation, un test et une anomalie au même besoin, même si son intitulé évolue. Une fiche peut tenir en quelques lignes, à condition de ne pas mélanger plusieurs comportements indépendants.

Une fiche de cahier des charges logiciel sur mesure, avec preuve attendue

Appliquez la même précision aux attentes non fonctionnelles. « Rapide » doit devenir une opération à tester, avec un volume de données, un environnement, un nombre d’utilisateurs simultanés et un seuil à convenir. « Simple » mérite un essai avec les personnes concernées sur une tâche définie. Évitez de fixer un chiffre sans lien avec l’usage et les moyens disponibles.

La recette désigne ici la vérification du logiciel livré par rapport aux attentes convenues. Préparez-la pendant le cadrage : qui teste, sur quel environnement, avec quels exemples, et comment classe-t-on les anomalies ? Distinguez ce qui empêche l’usage d’un point d’amélioration qui peut être planifié. Les modalités de validation et de correction doivent être clarifiées avec le prestataire.

Ne pas laisser les données et les accès dans les angles morts

Recensez les informations que le logiciel utilisera : dossiers, contacts, pièces jointes, statuts, historiques. Pour chacune, identifiez la source de référence, la personne qui peut la modifier, les formats disponibles et les problèmes connus. Un export existant ne garantit pas que ses données sont complètes, cohérentes ou directement réutilisables.

Décrivez les droits par rôle et par opération : consulter, créer, modifier, valider, exporter, administrer. La CNIL recommande de limiter les habilitations aux données nécessaires aux missions. Une case « administrateur / utilisateur » peut être trop grossière : un accès à un dossier ne doit pas automatiquement donner le droit de le supprimer ou d’en exporter toutes les données.

Une connexion à un autre logiciel doit être décrite dans les deux sens

Pour chaque liaison, notez ce qui est envoyé, ce qui revient, le système qui fait autorité, la fréquence et la personne à prévenir en cas d’échec. Demandez à vérifier l’existence de la documentation, d’un accès de test et des autorisations nécessaires. Écrire « compatible avec notre CRM » ne dit pas si l’on attend un export manuel ou une synchronisation avec gestion des erreurs.

Ces questions relèvent du cadrage d’une automatisation ou intégration API. Elles permettent de distinguer ce que le nouveau logiciel maîtrise de ce qui dépend d’un fournisseur externe, de ses limites techniques ou de ses conditions d’accès.

Prévoyez des données d’essai adaptées, sans copier par défaut les fichiers réels des clients dans un environnement de développement. La documentation de la CNIL pour les développeurs aide à examiner les flux, la minimisation, les tests et la conservation. Les exigences de confidentialité et les obligations propres à votre activité doivent être validées avec les responsables concernés ; ce guide n’est pas un audit de conformité.

La trame à compléter avant de demander un devis

Copiez les rubriques ci-dessous dans un document partagé. Gardez une version datée, un responsable du document et un emplacement unique. Les annexes peuvent contenir les parcours, les règles et les exemples anonymisés ; le résumé doit rester lisible par la direction.

1. Contexte et objectif : difficulté observée, personnes concernées, situation de départ et résultat recherché.
2. Périmètre : opérations incluses dans le premier lot, exclusions explicites et évolutions envisagées séparément.
3. Utilisateurs et responsabilités : rôles, droits, responsable des arbitrages et personnes qui participeront aux tests.
4. Parcours et règles : déclencheur, étapes, résultat, exceptions et exigences identifiées.
5. Données et connexions : sources, qualité connue, reprise attendue, systèmes conservés et dépendances externes.
6. Conditions d’usage : appareils, réseau, accessibilité, volumes, disponibilité attendue et contraintes de sécurité.
7. Livraison et exploitation : recette, formation, documentation, support, sauvegarde, restauration et procédure de sortie à préciser.
8. Consultation : calendrier souhaité et ses raisons, budget à discuter, hypothèses ouvertes et réponse attendue du prestataire.

Pour un premier lot, retenez un travail complet utilisable, pas seulement une collection d’écrans. Classez les éléments en « indispensable au lancement », « utile ensuite » et « hors périmètre ». Une fonction dite secondaire peut pourtant être indispensable si elle permet de récupérer les données ou de corriger une erreur bloquante.

Ajoutez un registre des questions ouvertes : question, personne chargée de répondre, conséquence possible et date d’arbitrage. Par exemple, une incertitude sur la disponibilité d’une API peut empêcher un chiffrage ferme de l’intégration. Un prestataire peut proposer une phase d’exploration limitée avant de s’engager sur cette partie.

Comparer des réponses sur le même périmètre

Transmettez la même version du document à chaque prestataire consulté et partagez les précisions apportées pendant les échanges. Demandez une réponse qui distingue ce qui est compris, exclu, proposé en option ou encore soumis à vérification. Un prix global n’est comparable que si les services et les limites le sont aussi.

Faites apparaître séparément les travaux de cadrage, de développement, de reprise des données, d’intégration, de tests et d’accompagnement, puis les frais récurrents et prestations de maintenance. Clarifiez également les livrables remis, les accès, les possibilités d’export et les conditions d’une reprise par un autre intervenant. Ne supposez pas que toutes ces dispositions sont identiques d’une proposition à l’autre.

Une fois le projet engagé, gardez la trace des changements : besoin modifié, raison, effet sur le périmètre, coût ou délai à évaluer, et décision. Le cahier des charges n’a pas vocation à empêcher d’apprendre pendant le développement ; il sert à ne pas confondre une nouvelle demande avec une règle déjà convenue.

Avant d’envoyer votre document : demandez à un utilisateur de raconter un parcours à partir du texte, puis à une autre personne d’expliquer comment elle vérifierait le résultat. Les désaccords révèlent les précisions les plus utiles à ajouter.

FAQ : préparer un cahier des charges logiciel

Faut-il un cahier des charges complet avant de contacter un développeur ?

Non. Un résumé du problème, un parcours représentatif et les contraintes connues permettent de commencer. Le cadrage sert ensuite à préciser les règles et les incertitudes avec les utilisateurs et le prestataire.

Combien de pages doit contenir un cahier des charges logiciel sur mesure ?

Il n’existe pas de longueur idéale. Le document doit permettre de comprendre les parcours, les limites et les résultats à vérifier. Placez les détails utiles en annexe plutôt que de multiplier les pages sans décision nouvelle.

Faut-il choisir la technologie dans le cahier des charges ?

Décrivez les contraintes techniques réellement imposées, comme un système à conserver ou un environnement existant. Laissez le prestataire expliquer les options lorsque le choix n’est pas encore justifié.

Qui doit valider les exigences et la recette ?

Désignez un responsable métier capable d’arbitrer, et associez les futurs utilisateurs aux vérifications. Le prestataire apporte l’expertise technique ; les règles de travail et les priorités doivent être confirmées par l’entreprise.

Peut-on modifier le cahier des charges pendant le projet ?

Oui, en consignant la modification et son impact à évaluer sur le périmètre, le budget et le calendrier. Une version datée et une décision explicite évitent de confondre une évolution avec une attente déjà convenue.

Préparer un échange utile avec Pixel Info

Un bon cadrage relie le besoin, les règles et la preuve attendue. Il donne au prestataire de quoi poser les bonnes questions, tout en vous laissant la maîtrise des priorités. Mieux vaut un dossier clair avec des incertitudes signalées qu’une longue liste de fonctions dont personne ne partage la définition.

Pixel Info développe des logiciels et applications web sur mesure. Pour préparer votre projet d’outil métier, réunissez un parcours représentatif, les contraintes connues et les questions qui restent ouvertes. Décrivez votre besoin à Pixel Info : un résumé anonymisé suffit pour commencer, sans transmettre de mots de passe ni de fichiers clients confidentiels.

Sources consultées le 28 septembre 2026 : Service Manual GOV.UK et recommandations CNIL liées dans le texte. Trame et exemples rédigés pour ce guide ; ils ne décrivent pas une réalisation client.