Modèle de cahier des charges pour une application web

Voici un modèle de cahier des charges pour une application web, à copier dans un document et à remplir question par question. Il est pensé pour un outil métier de PME : un portail client, un outil de suivi, un back-office, une application qui remplace des fichiers Excel partagés. Une réponse d'une phrase vaut mieux qu'une rubrique vide, et « je ne sais pas » est aussi une réponse utile : le prestataire saura qu'il doit poser la question.

Le rôle de chaque rubrique est expliqué dans le guide du cahier des charges d'un logiciel sur mesure. Ici, on remplit. Les exemples en italique sont inventés pour l'illustration.

Avant de commencer

• Remplissez le modèle avec deux ou trois personnes qui font le travail au quotidien, et pas seulement avec la direction.
• Rassemblez les documents existants : fichiers Excel, formulaires papier, exports d'un logiciel, modèles de devis ou de bons de livraison. Joints en annexe, ils en disent plus qu'une longue description.
• Décrivez ce qui se passe dans l'entreprise, sans dessiner l'outil que vous imaginez. Le prestataire propose la solution, vous décrivez le travail.
• Gardez une rubrique « plus tard » ouverte pendant toute la rédaction. Chaque idée qui n'est pas indispensable au démarrage y va.

Partie 1 : l'entreprise et le projet

1.1 Présentation

• Que fait l'entreprise, combien de personnes y travaillent, sur combien de sites ?
• Quel service ou quel métier est concerné par le projet ?
• Qui sera l'interlocuteur du prestataire, et qui prend les décisions ?

1.2 La situation actuelle

• Comment la tâche se fait-elle aujourd'hui, étape par étape ?
• Quels outils sont utilisés : papier, Excel, logiciel, e-mails, messagerie ?
• Où sont les ressaisies, les oublis, les erreurs, les temps d'attente ?
• Qu'est-ce qui fonctionne bien et doit être conservé ?

1.3 L'objectif

• Qu'est-ce qui doit avoir changé six mois après la mise en service ?
• Comment le mesurerez-vous : temps passé, nombre d'erreurs, délai de réponse aux clients ?
• Une date compte-t-elle : saison, salon, échéance réglementaire, fin de contrat d'un logiciel actuel ?

Exemple : « Nos quatre commerciaux saisissent leurs devis dans Excel, puis l'assistante les ressaisit dans le logiciel de facturation. Nous voulons qu'un devis accepté devienne une facture sans ressaisie, et savoir chaque lundi quels devis attendent une réponse. »

Partie 2 : ce que l'application doit faire

2.1 Les utilisateurs et leurs droits

• Quels types d'utilisateurs : administrateur, salarié, responsable, client, fournisseur ?
• Combien de personnes par type, aujourd'hui et dans trois ans ?
• Qui voit quoi, qui modifie quoi, qui valide quoi ?
• D'où se connectent-ils : bureau, déplacement, téléphone, tablette, zone sans réseau ?
• L'outil doit-il exister en plusieurs langues, pour des salariés ou des clients étrangers ?

Exemple : « Huit commerciaux sur la route, sur téléphone ; deux assistantes au bureau ; le directeur valide les remises. Les clients n'ont pas d'accès pour l'instant. »

2.2 Les fonctions

Pour chaque type d'utilisateur, listez les actions sous la forme « en tant que…, je veux…, pour… ». Cette tournure oblige à dire à quoi sert chaque fonction, ce qui aide ensuite à trier.

Exemple : « En tant que responsable d'atelier, je veux voir les commandes du jour classées par date de livraison, pour répartir le travail le matin. »

2.3 Les règles de gestion

• Quels calculs l'outil fait-il : prix, remises, délais, quantités, primes ?
• Quelles validations sont nécessaires, et par qui ?
• Par quels statuts passe un dossier, de sa création à son archivage ?
• Quels cas particuliers arrivent, même rarement : annulation, avoir, livraison partielle, remplacement d'un collègue absent ?

Exemple : « Une remise de plus de 10 % doit être validée par le directeur commercial. Une commande annulée après préparation repasse en stock, sauf les produits frais. »

2.4 Les documents et les alertes

• Quels documents l'outil produit-il (devis, bons, rapports, attestations), et sous quel format ?
• Quels e-mails ou alertes envoie-t-il, à qui, à quel moment ?
• Quels tableaux de bord ou exports la direction attend-elle ?

Partie 3 : les données et les autres logiciels

3.1 Les données à reprendre

• Quelles données existent déjà (clients, articles, historique), dans quels fichiers ou logiciels ?
• Combien d'années d'historique faut-il reprendre, et que peut-on archiver en lecture seule ?
• Qui nettoie les doublons et les erreurs : vous, le prestataire, ou les deux ?

La reprise de données lors d'une migration est souvent le poste le plus sous-estimé d'un projet. Une réponse précise ici évite une mauvaise surprise sur le devis.

3.2 Les liaisons

• Avec quels logiciels l'outil doit-il échanger : comptabilité, CRM, paie, site internet, banque, plateforme de facturation ?
• Dans quel sens circulent les données, et à quelle fréquence ?
• Ces logiciels proposent-ils une API (une porte d'entrée documentée pour que d'autres programmes s'y connectent), ou seulement des exports de fichiers ?

Exemple : « Les factures validées doivent partir chaque soir vers notre logiciel de comptabilité. Aujourd'hui, nous exportons un fichier à la main chaque fin de mois. »

3.3 Les données personnelles

• L'outil contiendra-t-il des données sur des personnes : salariés, clients particuliers, candidats ?
• Lesquelles sont indispensables ? La CNIL recommande de restreindre la collecte au strict nécessaire.
• Combien de temps chaque donnée doit-elle être conservée, puis archivée ou supprimée ?

Source : CNIL, Guide RGPD du développeur, consulté le 22 octobre 2026.

Partie 4 : les contraintes

• Hébergement. Avez-vous déjà un serveur, un hébergeur, une exigence sur le lieu de stockage des données ? Les options d'hébergement d'une application métier aident à répondre.
• Sécurité. Qui peut se connecter depuis l'extérieur ? Faut-il une double authentification, un historique des modifications ?
• Disponibilité. L'outil doit-il fonctionner la nuit, le week-end, sans connexion ?
• Facturation électronique. L'outil émet-il ou reçoit-il des factures ? La réception électronique est obligatoire pour toutes les entreprises depuis le 1er septembre 2026, et l'émission le sera pour les PME et les micro-entreprises au 1er septembre 2027.
• Contraintes internes. Logiciel imposé par un donneur d'ordre, matériel existant, informaticien interne qui devra intervenir.

Source : Entreprendre.service-public.gouv.fr, Facturation électronique : c'est pour bientôt !, consulté le 22 octobre 2026.

Si le prestataire héberge ou traite des données personnelles pour votre compte, la CNIL recommande de signer avant le début de la prestation un contrat reprenant les exigences de l'article 28 du RGPD : sécurité, gestion des incidents, restitution et destruction des données en fin de contrat. Ajoutez une ligne au modèle pour le demander.

Source : CNIL, Sécurité : gérer la sous-traitance, consulté le 22 octobre 2026.

Partie 5 : budget, déroulement et après-livraison

5.1 Budget et calendrier

• Quelle enveloppe envisagez-vous, même approximative ?
• Préférez-vous une première version réduite livrée vite, ou un outil complet plus tard ?
• Quelles périodes faut-il éviter pour la mise en service ?

Pour situer l'enveloppe, la page sur le prix d'une application web sur mesure rassemble les repères publics du marché.

5.2 Déroulement

• Comment souhaitez-vous découper le projet en étapes, et payer chacune ?
• Qui teste chaque livraison chez vous, et combien de temps pourra-t-il y consacrer ?
• À quelle fréquence voulez-vous voir l'avancement ?

Un échéancier de paiement par étapes se prépare dès ce stade : c'est à vous de dire ce que chaque étape doit permettre de faire. C'est d'ailleurs ainsi que je travaille, avec un prix fixe découpé en étapes, chacune payée une fois livrée et validée, et la possibilité d'arrêter après n'importe laquelle.

5.3 Après la livraison

• Qui corrige les anomalies, pendant combien de temps, à quelles conditions ?
• Qui fait évoluer l'outil ensuite ?
• Le code source, les accès (hébergement, nom de domaine, comptes des services utilisés) et la documentation vous sont-ils remis ?
• Qui forme les utilisateurs, et quand ?

Ces questions paraissent lointaines au moment de la rédaction. Elles décident pourtant de votre liberté après la livraison : sans code source ni accès, changer de prestataire revient souvent à repartir de zéro. Le guide sur la propriété du code source d'un logiciel détaille ce qu'il faut prévoir au contrat.

5.4 Plus tard

Terminez par la liste des idées écartées du premier périmètre, avec une phrase pour chacune. Elle montre au prestataire où l'outil doit aller ensuite, sans entrer dans le chiffrage, et l'aide à construire une base qui pourra les accueillir.

Exemple : « Plus tard : portail où les clients suivent leurs commandes ; application pour les livreurs ; statistiques par commercial. »

Une fois le modèle rempli, relisez-le avec les personnes interrogées, puis envoyez la même version à chaque prestataire consulté. Les questions qu'ils vous renverront complètent le document : ajoutez les réponses et transmettez-les à tous, pour que chacun chiffre sur la même base.