Préparer un projet numérique : cahier des charges et recette

Les questions à se poser avant de commencer

Avant de préparer un projet numérique, clarifiez la difficulté à traiter et les personnes concernées. Ces réponses permettent de vérifier qu’un outil ou un développement répondra à un besoin réel, plutôt qu’à une idée de solution encore imprécise. Recensez aussi les données mobilisées et les contraintes qui peuvent influencer le calendrier. Vous pourrez ensuite cadrer le travail sur des éléments observables et désigner les personnes nécessaires aux décisions.

Le problème à résoudre

Commencez par décrire la difficulté telle qu’elle se manifeste dans le travail quotidien, sans proposer d’emblée un logiciel ou une fonctionnalité. Une description précise aide à distinguer un problème récurrent d’un incident ponctuel.

Vérifiez qui est touché et dans quelle tâche : par exemple, une personne ressaisit-elle les mêmes informations entre un tableur et un outil de facturation ? Repérez l’endroit où le blocage survient, comme une validation, une recherche de dossier ou une transmission entre deux équipes. Notez sa fréquence — chaque jour, à chaque clôture mensuelle ou seulement lors d’un pic d’activité — et le temps perdu à chaque occurrence. Ces observations rendent le besoin vérifiable, même sans mesurer immédiatement chaque minute.

Reliez enfin le constat à un objectif concret : réduire les doubles saisies, retrouver un dossier en moins d’étapes ou limiter les retards de traitement. Vous pourrez comparer cet objectif à la situation actuelle et vérifier si le problème mérite un projet.

Les utilisateurs et les données

Cartographiez les personnes qui utiliseront la solution, leurs tâches et les informations nécessaires à chacune. Cette vérification fait ressortir les besoins des utilisateurs d’un projet numérique et les dépendances parfois invisibles entre équipes.

Listez les profils concernés, comme la personne qui saisit les commandes et celle qui les valide, afin de ne pas concevoir pour un seul rôle.
Associez chaque profil à ses tâches et à leur fréquence, par exemple consulter les stocks chaque matin ou traiter les demandes clients en continu.
Inventoriez les données requises et leur emplacement actuel : fichiers partagés, logiciel de gestion, courriels ou dossiers papier, pour repérer les sources à mobiliser.
Identifiez le propriétaire de chaque jeu de données, car cette personne peut confirmer sa définition, son accès et les règles de mise à jour.
Signalez si les données comprennent des noms, coordonnées ou autres informations personnelles, afin de prévoir leur traitement avec les personnes responsables.

Nommez un responsable du projet, chargé de coordonner les échanges et de réunir les décisions. Un projet qui ne peut nommer ni son responsable ni ses utilisateurs risque de stagner, car personne ne peut confirmer les besoins ou trancher les questions pratiques.

Les contraintes de temps, de budget et de personnes

Vérifiez que le projet peut s’appuyer sur une enveloppe budgétaire identifiée et une échéance compréhensible, même si ces éléments restent à préciser. Leur existence permet de juger si le périmètre envisagé est compatible avec les moyens disponibles.

Repérez les étapes qui conditionnent le calendrier : collecte des besoins, validation des choix, préparation des données et disponibilité d’un environnement de test. Une échéance liée à une période d’activité intense peut réduire le temps disponible pour les essais ; prévoyez donc qui pourra y consacrer des créneaux. Vérifiez également la présence des personnes qui décident, contribuent au contenu ou aux opérations, et testeront les usages. Par exemple, une personne absente lors des validations peut retarder l’arbitrage d’un parcours de commande.

Désignez explicitement la personne qui arbitre lorsque le délai, le budget ou les demandes des équipes entrent en conflit. L’erreur la plus fréquente consiste à retenir une date sans vérifier la disponibilité des décideurs et des utilisateurs qui devront valider le travail.

Rédiger un cahier des charges lisible

Un cahier des charges numérique transforme une intention en consignes compréhensibles par l’équipe et le prestataire. Il rassemble les objectifs, les fonctionnalités attendues, les contraintes à examiner et les conditions qui permettront de vérifier le résultat. Pour rédiger un cahier des charges utile, associez chaque besoin à un exemple concret plutôt qu’à une formule générale comme « le site doit être intuitif ». Distinguez ce qui est décidé de ce qui reste à confirmer afin que les échanges et les arbitrages s’appuient sur les mêmes informations.

Contexte et objectifs

Présentez l’activité concernée et la situation de départ : par exemple, une équipe de quatre personnes reçoit les demandes clients par courriel et les reporte manuellement dans un tableur. Décrivez le problème précis — doublons, délais de traitement ou informations manquantes — sans présumer de la solution technique.

Formulez ensuite le résultat attendu de façon observable. Phrase modèle : « D’ici septembre 2026, permettre à l’équipe commerciale d’enregistrer chaque demande dans un formulaire partagé et de retrouver son statut sans ressaisie. » La date et le résultat peuvent être adaptés à votre calendrier et à votre activité.

Pour relier l’objectif aux besoins utilisateurs, écrivez les demandes sous forme de récits courts : « En tant que…, je veux… afin de… ». Par exemple : « En tant que responsable commercial, je veux filtrer les demandes par statut afin de repérer celles qui attendent une réponse. »

À vérifier : • Qui utilise ou administre la solution ? Cette précision aide à décrire les rôles concernés. • Quelle tâche pose problème aujourd’hui ? Un exemple réel évite de confondre symptôme et besoin. • Quel changement pourra être constaté après le projet ? Un indicateur observable permet de juger si l’objectif est atteint.

Périmètre et priorités des fonctionnalités

Délimitez ce que le projet doit livrer et ce qui restera hors périmètre : par exemple, inclure la création et le suivi des demandes, mais exclure une application mobile si elle n’est pas prévue. Classez ensuite les fonctionnalités avec MoSCoW pour rendre les arbitrages visibles.

Must : fonctions indispensables à la première mise en service, comme enregistrer une demande avec ses coordonnées et son statut.
Should : fonctions importantes, mais dont l’absence temporaire ne bloque pas l’usage principal, comme l’export périodique des demandes.
Could : améliorations souhaitables si le budget et le calendrier le permettent, comme un tableau de bord personnalisable.
Won’t have : éléments écartés du périmètre actuel, par exemple une application mobile, à réexaminer lors d’une évolution ultérieure.

Inscrivez chaque fonctionnalité dans une seule catégorie et ajoutez une raison : dépendance métier, obligation de lancement ou confort d’utilisation. Précisez aussi les exclusions pour éviter qu’une demande nouvelle soit interprétée comme un oubli.

À vérifier : relisez le classement avec les personnes qui utiliseront la solution, car une fonction jugée secondaire par le commanditaire peut être indispensable à une tâche quotidienne. Indiquez qui valide tout changement de priorité.

Contraintes techniques et juridiques

Recensez les outils déjà utilisés et les contraintes susceptibles de modifier la conception : logiciel de gestion, messagerie, formats de fichiers ou règles applicables aux données. Le tableau aide à associer chaque sujet à une vérification précise avant de figer les spécifications fonctionnelles.

Points de contrainte à examiner avant de valider le périmètre
Sujet	Éléments à préciser	Vérification concrète
Systèmes existants	Logiciels, versions, formats et échanges nécessaires	Confirmer avec l’administrateur si les données peuvent être exportées et dans quels formats, par exemple CSV ou PDF.
RGPD	Données personnelles collectées, usage et durée de conservation envisagée	Vérifier les rôles des intervenants et les traitements concernés au regard du règlement (UE) 2016/679.
Mentions légales	Informations requises selon l’activité et le service proposé	Faire contrôler les mentions applicables au regard des textes officiels, notamment ceux encadrant les services en ligne.
Lieu d’hébergement	Pays où sont hébergées les données et conditions de transfert éventuel	Demander au prestataire le lieu d’hébergement et vérifier les garanties en cas de transfert hors de l’Espace économique européen.
Accessibilité	Public concerné et exigences applicables au service	Vérifier si le RGAA et les obligations françaises d’accessibilité s’appliquent au projet, puis préciser les contrôles attendus.

Les obligations dépendent notamment de l’activité, du public et de l’organisation : vérifiez les textes officiels applicables avant de contractualiser une exigence. Faites confirmer les points juridiques incertains par la personne compétente.

Critères d’acceptation

Associez à chaque besoin des critères qui décrivent un résultat observable, les conditions de réussite et les erreurs utiles à tester. Un critère comme « la recherche fonctionne bien » ne permet pas de décider si la fonction est conforme.

Phrase modèle vérifiable : « Lorsque l’utilisateur saisit un numéro de demande existant et valide la recherche, la fiche correspondante s’affiche avec son statut ; si le numéro est inconnu, un message indique qu’aucun résultat n’a été trouvé. » Cet exemple précise l’action, le résultat attendu et un cas d’erreur.

À vérifier : • Le scénario commence-t-il par une action précise et un état identifiable ? Cela rend le contrôle reproductible. • Le résultat attendu peut-il être constaté à l’écran ou dans un document ? Cela évite une validation fondée sur une impression. • Les données manquantes, invalides ou inconnues sont-elles décrites ? Ces cas révèlent les comportements à prévoir.

Pour chaque critère, indiquez les conditions de test, le résultat observé et la décision prise. L’erreur la plus fréquente consiste à accepter des formulations vagues comme « simple à utiliser » sans définir ce qui permettra de constater la réussite.

Les points à vérifier dans le contrat

Le contrat encadre la relation avec le prestataire au-delà du devis et fixe les obligations de chacun pendant le projet. Pour préparer un projet numérique, vérifiez les clauses qui déterminent ce que votre entreprise pourra conserver, reprendre ou faire évoluer après la livraison. Les engagements liés aux incidents et aux données personnelles doivent aussi être compréhensibles et cohérents avec les services achetés. Ces repères sont des informations générales : lisez intégralement le contrat, ses annexes et les documents auxquels il renvoie avant de le signer.

Propriété, réversibilité et documentation

Pour éviter toute ambiguïté après la livraison, contrôlez les clauses qui encadrent la propriété et la reprise du projet.

• Faites inscrire explicitement dans le contrat qui détient le code source, les développements spécifiques et les autres livrables d’un projet numérique ; cette mention clarifie vos droits d’utilisation et de modification.

• Distinguez les créations réalisées pour votre entreprise des composants préexistants ou tiers, puis vérifiez les droits accordés sur ces derniers ; une licence peut limiter leur réutilisation ou leur transfert.

• Décrivez les modalités de réversibilité : données exportées, format de restitution, code remis et échéance de transfert ; ces précisions rendent la reprise par un autre prestataire plus praticable.

• Prévoyez la restitution des accès d’administration, comptes d’hébergement et dépôts de code, ainsi que la procédure de transfert ; vous éviterez une dépendance à des identifiants détenus uniquement par le fournisseur.

• Énumérez les documents attendus, par exemple l’architecture, les consignes de déploiement et les notices d’exploitation ; ils aident une équipe entrante à comprendre et maintenir la solution.

Vérifiez enfin si la remise de ces éléments dépend d’une échéance ou d’un paiement final, afin de connaître précisément les conditions de sortie.

Maintenance, sécurité et confidentialité

Examinez les engagements applicables après la mise en service, en particulier les délais et responsabilités associés aux incidents.

Vérifiez les mesures de sécurité prévues pour les accès, les sauvegardes et les mises à jour ; des engagements identifiables permettent de comparer le service promis aux besoins de votre activité.
Repérez les obligations de confidentialité et les personnes autorisées à consulter les informations ; cette précision limite les accès aux intervenants qui en ont réellement besoin.
Si le prestataire traite des données personnelles pour votre compte en qualité de sous-traitant, vérifiez qu’un contrat conforme à l’article 28 du RGPD encadre ce traitement.
Contrôlez la procédure de signalement des incidents, les interlocuteurs et les informations à transmettre ; un processus défini facilite la coordination lorsqu’un service devient indisponible.
Examinez l’accord de niveau de service : il définit les délais de réponse et de correction selon les incidents ; vous pouvez ainsi distinguer prise en charge et résolution effective.
Vérifiez les horaires de couverture, les exclusions et les conditions de facturation des interventions ; ces éléments indiquent quand l’assistance est disponible et quels coûts peuvent s’ajouter.

Comparez ces engagements avec les horaires d’activité et le niveau de dépendance de votre entreprise au service. L’erreur fréquente consiste à supposer qu’une promesse évoquée oralement s’applique : faites vérifier sa présence dans le contrat signé.

La recette et la prise en main

La recette d’un projet numérique vérifie que la solution livrée correspond aux spécifications du cahier des charges numérique. Elle ne se limite pas à constater que l’application s’ouvre : les parcours doivent être testés avec des situations proches du travail quotidien. Des utilisateurs réels, leurs données et leurs appareils révèlent des difficultés qui échappent souvent à une démonstration. Après les tests, les défauts sont consignés et la décision d’acceptation est formalisée. La formation et le suivi après lancement permettent ensuite de rendre l’équipe autonome sans perdre de vue les problèmes à résoudre.

Tester avec de vrais cas

La recette compare chaque fonction livrée aux exigences convenues et se déroule selon des scénarios définis à l’avance. Pour organiser les tests de validation du logiciel, vérifiez les points suivants :

Reprenez chaque fonction attendue et associez-lui un scénario précis, afin de vérifier qu’aucune exigence du cahier des charges ne reste sans contrôle.
Décrivez les étapes, les données saisies et le résultat attendu pour chaque scénario ; ces critères rendent les constats comparables entre testeurs.
Utilisez des données représentatives des dossiers traités au quotidien, en masquant les informations personnelles lorsque leur présence n’est pas nécessaire.
Faites exécuter les parcours par les personnes qui utiliseront l’outil, car leurs gestes et leur vocabulaire font apparaître les blocages réels.
Répétez les essais sur les appareils et navigateurs employés dans l’entreprise, notamment les téléphones si des tâches doivent y être réalisées.
Inscrivez chaque défaut dans un tableau avec le scénario, le résultat observé et la gravité, pour suivre sa correction sans perdre le contexte.

Après correction, rejouez les scénarios concernés et consignez le résultat. La décision consiste à accepter la livraison ou à formuler des réserves ; le procès-verbal de recette, signé par les parties, garde trace de cette décision.

Former les utilisateurs

Une formation efficace part des tâches quotidiennes de chaque profil, plutôt que d’une présentation exhaustive des menus. Préparez un support court qui montre les opérations réellement confiées à l’équipe : créer un dossier, modifier une information, retrouver un document ou traiter une demande. Cette sélection aide chacun à relier les commandes à son travail. Faites pratiquer les parcours principaux sur l’environnement prévu pour l’usage, avec un exemple d’exercice par tâche. Demandez aux participants de réaliser eux-mêmes une opération complète, car une démonstration suivie passivement ne confirme pas qu’ils sauront la refaire. Notez les points qui provoquent des erreurs et ajoutez une consigne illustrée si une étape prête à confusion. Indiquez clairement le canal à utiliser après la séance et la personne qui recueille les questions : par exemple, un référent interne pour les usages courants et un contact technique pour les incidents. Cette répartition évite que les difficultés restent sans réponse ou soient transmises au mauvais interlocuteur.

Prévoir la suite

Le lancement demande quelques règles de fonctionnement concrètes pour protéger les données et maintenir le service. Vérifiez que les sauvegardes sont planifiées, qu’une personne sait où consulter leur état et qu’une restauration peut être testée ; une copie inutilisable ne permet pas de reprendre l’activité après une perte de données. Lorsqu’un salarié quitte l’équipe, faites désactiver ses comptes et réattribuer les accès nécessaires à son successeur. Cette vérification limite les accès devenus inutiles et évite qu’un dossier de travail reste lié à une seule personne. Tenez aussi une liste des défauts encore ouverts et des évolutions demandées, avec un responsable et une prochaine étape pour chacune, afin de distinguer une anomalie bloquante d’une amélioration à planifier. Désignez avant le lancement la personne qui répondra aux questions, recueillera les incidents et les transmettra au prestataire si nécessaire. L’erreur la plus fréquente consiste à considérer la mise en production comme la fin du projet : sans responsable identifié, les problèmes du premier mois s’accumulent et les utilisateurs contournent l’outil.