Cahier des charges pour un logiciel sur mesure au Québec : modèle gratuit et grille de sélection

Un bon cahier des charges ne tente pas de prédire chaque écran au pixel près. Il permet plutôt à votre organisation et aux fournisseurs de comprendre le même problème, de chiffrer le même périmètre et de reconnaître une livraison acceptable. Le modèle ci-dessous est conçu pour un projet de logiciel sur mesure au Québec : portail client, application métier, automatisation interne, modernisation d’un système existant ou intégration de plusieurs plateformes.

Accès rapide : télécharger le modèle de cahier des charges en format Word et télécharger la grille d’évaluation des fournisseurs en format Excel. Vous pouvez aussi copier directement les sections et tableaux de cet article.

Qu’est-ce qu’un cahier des charges logiciel, concrètement?

L’Office québécois de la langue française définit le cahier des charges comme un document rattaché à un contrat ou à une convention qui précise des obligations administratives, techniques ou financières, ainsi que les travaux, les prestations et leurs modalités d’exécution. Appliqué au logiciel, il sert donc de référence commune entre les objectifs d’affaires, les besoins des utilisateurs, les contraintes techniques et la façon de vérifier le résultat.

Il ne remplace ni le contrat, ni une architecture détaillée, ni le carnet de produit qui évoluera pendant la réalisation. Son rôle est de fixer les frontières du projet et les règles de décision. Un fournisseur sérieux doit pouvoir y trouver assez d’information pour expliquer son approche, ses hypothèses, ses exclusions, son équipe, son calendrier et son prix. Votre comité doit pouvoir comparer les réponses sans se laisser guider uniquement par le plus beau diaporama ou le tarif quotidien le plus bas.

Le test des cinq questions

Avant de transmettre le document, demandez à une personne qui ne connaît pas le projet de le lire. Elle devrait pouvoir répondre clairement à ces cinq questions :

• Quel problème mesurable l’organisation veut-elle résoudre?
• Qui utilisera le logiciel, pour accomplir quels parcours prioritaires?
• Qu’est-ce qui est inclus dans la première livraison, et qu’est-ce qui ne l’est pas?
• Quelles contraintes de données, de sécurité, d’accessibilité et d’intégration s’appliquent?
• Sur quelles preuves la solution et le fournisseur seront-ils acceptés?

Avant de rédiger : réunir les bonnes personnes et les bonnes preuves

N’écrivez pas le cahier des charges seul dans un bureau. Organisez un court atelier avec le responsable d’affaires, un représentant des utilisateurs, le propriétaire des données, les TI, la sécurité, l’exploitation et la personne responsable de la protection des renseignements personnels. Ajoutez les finances ou l’approvisionnement lorsqu’ils participeront au choix. Pour un système déjà en place, invitez aussi une personne qui traite réellement les exceptions quotidiennes : c’est souvent elle qui connaît les règles absentes des procédures officielles.

Rassemblez les volumes actuels, les temps de traitement, les erreurs, les coûts, les diagrammes de processus, les interfaces existantes, les contrats de licences et quelques exemples anonymisés de dossiers. Ces éléments transforment une intention vague comme « automatiser les opérations » en une cible vérifiable comme « réduire la ressaisie manuelle de trois systèmes à une seule saisie et tracer chaque exception ».

Décider du niveau de détail

Le niveau attendu dépend de votre mode d’achat. Pour un prix fixe, le périmètre, les hypothèses et les critères d’acceptation doivent être particulièrement précis. Pour une équipe agile facturée au temps, le document peut laisser plus de latitude sur la solution, mais il doit tout de même fixer les résultats attendus, le budget maximal, la gouvernance, la définition de « terminé » et les conditions d’arrêt. Dans les deux cas, distinguez les exigences obligatoires des préférences.

Modèle de cahier des charges pour logiciel sur mesure

Copiez la structure suivante dans votre document. Remplacez les indications entre crochets et supprimez les exemples qui ne s’appliquent pas. Une réponse inconnue peut être indiquée comme telle, avec le responsable et la date prévue de décision; cacher l’incertitude ne la fait pas disparaître.

1. Fiche d’identité du projet

• Nom du projet : [nom court et distinctif]
• Organisation et unité responsable : [nom et service]
• Responsable d’affaires : [rôle, pouvoir de décision]
• Responsable technique : [rôle et coordonnées]
• Responsable de la protection des renseignements personnels : [rôle et coordonnées]
• Date de diffusion / questions / remise : [dates et fuseau horaire]
• Budget : [fourchette, plafond ou demande de ventilation]
• Date cible et raison : [échéance réelle et dépendance associée]

2. Contexte, problème et résultats mesurables

Texte à compléter : « Aujourd’hui, [utilisateurs] réalisent [processus] au moyen de [outils]. Cette situation entraîne [délais, erreurs, coûts, risques ou irritants], mesurés par [données de référence]. Le projet doit permettre [résultat], sans [contrainte ou effet indésirable]. Le succès sera évalué [moment et méthode]. »

Choisissez de trois à cinq indicateurs avec une valeur de départ, une cible et une fenêtre de mesure. Exemples : temps médian de traitement, taux de dossiers retournés, pourcentage d’étapes automatisées, disponibilité pendant les heures critiques, adoption active après 90 jours ou délai de résolution d’un incident prioritaire. Évitez « interface moderne » comme objectif; c’est une préférence, pas un résultat.

3. Portée, hors portée et hypothèses

Présentez trois listes distinctes. La portée de la première version pourrait inclure l’authentification, la création d’un dossier, le dépôt de documents, les notifications, un tableau de suivi et l’administration. La section hors portée pourrait nommer explicitement l’application mobile native, la migration des archives antérieures à une date, l’analytique prédictive ou le remplacement de l’ERP. Les hypothèses devraient préciser, par exemple, qui fournit l’accès aux API, qui nettoie les données et combien de représentants utilisateurs seront disponibles.

Ajoutez un mécanisme de changement : toute modification doit décrire le besoin, l’effet sur le coût et l’échéancier, les risques, les solutions de rechange et la personne autorisée à l’approuver. Cette règle simple protège autant le client que le fournisseur.

4. Utilisateurs, rôles et parcours prioritaires

Pour chaque groupe, indiquez le nombre approximatif d’utilisateurs, leur contexte, leurs permissions et leurs besoins d’accompagnement. Un agent qui travaille huit heures par jour sur ordinateur n’a pas les mêmes contraintes qu’un client qui consulte son dossier une fois par mois sur téléphone, ou qu’un administrateur qui effectue une opération sensible.

Format à copier pour chaque parcours :

1. Déclencheur : [ce qui démarre le parcours]
2. Acteur et autorisation : [rôle et conditions d’accès]
3. Parcours nominal : [étapes principales, sans imposer inutilement l’interface]
4. Exceptions : [donnée manquante, doublon, refus, panne d’un système tiers]
5. Résultat et preuve : [état final, notification, journal ou rapport]
6. Critère d’acceptation : [scénario observable et résultat attendu]

5. Exigences fonctionnelles priorisées

Donnez un identifiant unique à chaque exigence et utilisez une méthode constante, par exemple Obligatoire, Souhaitable ou Ultérieur. Une exigence devrait exprimer une capacité et une règle, non dicter une technologie sans justification.

Exemple de registre d’exigences fonctionnelles

ID	Priorité	Exigence	Critère d’acceptation	Source
F-01	Obligatoire	Un client peut reprendre un brouillon sur un autre appareil.	Après reconnexion, les données confirmées et pièces jointes sont présentes sans doublon.	Atelier clients
F-02	Obligatoire	Un superviseur peut réassigner un dossier avec justification.	Le nouveau responsable, l’ancien responsable, l’heure et le motif figurent au journal.	Opérations
F-03	Souhaitable	Un agent peut enregistrer une vue filtrée.	La vue est retrouvée à la prochaine session et peut être supprimée.	Agents

6. Données, migration et intégrations

Dressez l’inventaire des catégories de données, leur source officielle, leur qualité connue, leur volume, leur croissance, leur sensibilité, leur durée de conservation et leur destination. Pour une migration, exigez un essai complet sur un échantillon représentatif, un rapport de rapprochement, le traitement des rejets, une stratégie de retour arrière et la validation du propriétaire des données.

Pour chaque intégration, nommez le système, son propriétaire, le protocole ou l’API disponible, la fréquence, les volumes de pointe, l’environnement d’essai, les limites, le comportement en cas d’échec et la responsabilité du soutien. Précisez si l’échange est synchrone, différé ou par lot. Si votre projet dépend d’un ERP, d’un CRM ou d’un partenaire externe, notre page sur l’intégration d’API, de systèmes ERP et CRM au Québec présente les aspects techniques à anticiper.

7. Exigences non fonctionnelles mesurables

Remplacez les adjectifs par des seuils et une méthode de test. « Rapide », « sécuritaire » et « évolutif » ne peuvent pas être acceptés objectivement. Documentez au minimum :

• Performance : temps de réponse visé par parcours, volume simultané, taille des fichiers et jeu de données d’essai.
• Disponibilité : plages critiques, exclusions planifiées, objectif, mesure et crédits ou correctifs attendus.
• Résilience : reprise après panne, traitement idempotent, sauvegardes, objectifs de perte de données et de remise en service.
• Observabilité : journaux structurés, métriques, traces, corrélation, alertes et durée de conservation.
• Compatibilité : navigateurs, appareils, résolutions et versions soutenues.
• Maintenabilité : conventions, documentation, revue de code, couverture pertinente, gestion des dépendances et dette technique.

Pour préparer les critères de validation, consultez aussi notre approche de qualité, tests et sécurité applicative au Québec.

8. Vie privée et EFVP au Québec

Si une entreprise privée acquiert, développe ou refond un système d’information ou une prestation électronique de services qui implique des renseignements personnels, l’article 3.3 de la Loi sur la protection des renseignements personnels dans le secteur privé prévoit une évaluation des facteurs relatifs à la vie privée (EFVP) et la consultation du responsable de la protection des renseignements personnels dès le début du projet. L’évaluation doit être proportionnée notamment à la sensibilité, à la finalité, à la quantité, à la répartition et au support des renseignements. Confirmez avec vos conseillers les obligations qui s’appliquent à votre organisation et à votre secteur.

Le guide d’accompagnement de la Commission d’accès à l’information propose de commencer l’EFVP dès le début, d’inventorier les renseignements et de tracer leur parcours, de la collecte à la destruction, en identifiant les personnes, organisations, systèmes et supports concernés. Intégrez cette démarche au cahier des charges au lieu de la reporter à la veille du lancement.

Questions à documenter : quelles données sont réellement nécessaires? À quelles fins? Qui y accède et pourquoi? Où sont-elles hébergées, sauvegardées et communiquées? Quelles durées de conservation et règles de destruction s’appliquent? Comment une personne exerce-t-elle ses droits? Que se passe-t-il en cas d’incident? Les fournisseurs et sous-traitants accèdent-ils aux données, notamment à l’extérieur du Québec? Qui approuve les mesures d’atténuation et en vérifie l’application?

9. Sécurité applicative et exploitation

Décrivez les attentes selon le risque : authentification multifacteur pour les rôles sensibles, autorisation par rôle ou attribut, chiffrement en transit et au repos, gestion des secrets, journalisation des actions privilégiées, analyse des dépendances, correction des vulnérabilités, tests de sécurité avant lancement et processus d’incident. Demandez au fournisseur d’expliquer son modèle de menace, les preuves remises et la séparation des responsabilités entre votre équipe, l’hébergeur et lui.

Ajoutez la gestion opérationnelle : heures de soutien, niveaux de priorité, délais de prise en charge et de rétablissement, escalade, entretien, mises à jour, sauvegardes, surveillance et bilan post-incident. Une garantie de disponibilité sans méthode de mesure ni procédure d’escalade reste difficile à appliquer.

10. Accessibilité, langue et expérience inclusive

Pour un organisme public visé, le Standard sur l’accessibilité des sites Web SGQRI 008 3.0 fixe des exigences précises et une cible générale de niveau AA fondée principalement sur WCAG 2.1, avec certains critères de WCAG 2.2. Une entreprise privée peut aussi utiliser cette référence pour définir une cible contractuelle, sans prétendre que le standard lui est automatiquement applicable. Précisez la norme, le niveau, les écrans couverts, les technologies d’assistance testées, les preuves attendues et le traitement des défauts.

Indiquez les langues de l’interface, du contenu, des messages système, du soutien et de la documentation. Prévoyez l’expansion des libellés, les formats québécois de date, d’heure, d’adresse et de nombre, ainsi qu’un processus de traduction et de validation. Ne laissez pas le français comme une adaptation finale de l’interface anglaise.

11. Livraison, gouvernance et critères d’acceptation

Définissez les jalons par résultats : découverte validée, prototype testé, architecture approuvée, première tranche utilisable, migration répétée, essai d’acceptation, lancement et stabilisation. Pour chaque jalon, nommez les livrables, l’approbateur, le délai de révision et le traitement des réserves. Exigez une démonstration régulière sur un environnement accessible plutôt qu’un rapport de pourcentage d’avancement.

Votre définition de « terminé » peut exiger : code revu et intégré, tests automatisés réussis, critères d’acceptation démontrés, vulnérabilités critiques corrigées, accessibilité vérifiée, télémétrie active, documentation mise à jour et déploiement reproductible. Spécifiez qui fournit les environnements, les données d’essai, les licences et les accès. Pour voir comment ces pratiques se traduisent dans des mandats réels, consultez nos projets de développement et de modernisation.

12. Modalités commerciales, propriété et réversibilité

Demandez une ventilation comparable : découverte, conception, développement, intégrations, migration, tests, déploiement, licences, nuage, soutien et taxes. Faites expliciter les hypothèses, les exclusions, le taux des rôles, la validité du prix et le coût des options. Le prix initial n’est pas le coût total : incluez l’exploitation, les licences, l’évolution, la sortie et le transfert à une autre équipe.

Faites encadrer juridiquement la propriété du code et des livrables, les composants tiers, les licences, la confidentialité, les garanties et la responsabilité. Sur le plan technique, exigez l’accès continu aux dépôts, pipelines, configurations, schémas, comptes et documentation; un format exportable pour les données; une procédure de transfert; et un effort de transition chiffré. Aucun fournisseur ne devrait être le seul détenteur d’un accès indispensable à votre exploitation.

Grille d’évaluation pondérée des fournisseurs

Évaluez d’abord la conformité aux exigences éliminatoires, puis notez les offres admissibles sur une échelle commune : 1 = insuffisant, 2 = faible, 3 = acceptable, 4 = très bon, 5 = excellent et démontré. Pour chaque critère, calculez note ÷ 5 × pondération. Le total maximal est 100. Inscrivez une justification et une preuve; une note sans trace devient vite une impression.

Exemple de grille de sélection d’un fournisseur de logiciel sur mesure

Critère	Poids	Preuves attendues	Note (1–5)	Points pondérés
Compréhension du besoin	10	Reformulation, risques, questions, hypothèses et exclusions	[ ]	[ ]
Approche et architecture	20	Décisions, compromis, intégrations, données, évolutivité et réversibilité	[ ]	[ ]
Équipe proposée et expérience pertinente	15	Rôles nommés, disponibilité, projets comparables et références vérifiables	[ ]	[ ]
Livraison et gouvernance	15	Jalons, validation, changements, transparence et gestion des dépendances	[ ]	[ ]
Qualité, sécurité, vie privée et accessibilité	15	Pratiques, livrables de preuve, EFVP, tests et traitement des défauts	[ ]	[ ]
Coût total et modalités	20	Ventilation, hypothèses, licences, exploitation, options et sortie	[ ]	[ ]
Références, soutien et adéquation	5	Références comparables, SLA, documentation, formation et transfert	[ ]	[ ]
Total	100			[ /100]

Questions de diligence à poser aux finalistes

• Quelle hypothèse de notre cahier des charges influence le plus votre prix ou votre échéancier?
• Quel risque pourriez-vous réduire durant les deux premières semaines, et par quelle preuve?
• Qui travaillera réellement sur le mandat, à quelle disponibilité, et comment un remplacement sera-t-il géré?
• Montrez un exemple anonymisé de plan de tests, de décision d’architecture et de rapport d’incident.
• Comment aurons-nous accès au code, aux environnements, aux données et aux indicateurs durant le projet?
• Que se passe-t-il si le budget est consommé avant la fin de la portée?
• Comment organisez-vous le transfert vers notre équipe ou vers un autre fournisseur?
• Quelle partie de votre solution crée une dépendance commerciale ou technologique, et quelle alternative existe?

Un processus de comparaison qui produit une décision défendable

1. Publier le même dossier. Donnez à chaque fournisseur les mêmes annexes, volumes, contraintes et règles de réponse.
2. Centraliser les questions. Fixez une période de questions et transmettez les réponses utiles à tous, sans révéler l’auteur.
3. Vérifier l’admissibilité. Traitez d’abord les exigences obligatoires : capacité, conflits, assurances, langue, sécurité ou échéance, selon votre contexte.
4. Noter individuellement. Chaque évaluateur inscrit sa note, sa justification et la page de preuve avant la discussion collective.
5. Faire une démonstration scénarisée. Demandez aux finalistes de résoudre le même cas réel et d’expliquer leurs choix, plutôt que de réciter une présentation générale.
6. Valider les références. Parlez à des clients comparables et questionnez-les sur la prévisibilité, les problèmes, la transparence et la qualité du transfert.
7. Documenter la décision. Conservez les notes, écarts, réserves, clarifications et conditions de négociation.

Checklist avant d’envoyer le cahier des charges

• Le problème, les indicateurs de départ et les cibles sont écrits.
• Les utilisateurs et leurs parcours prioritaires ont été validés avec de vraies personnes.
• La portée, la hors-portée, les hypothèses et les dépendances sont séparées.
• Chaque exigence importante a une priorité et un critère d’acceptation observable.
• Les volumes, pointes, historiques et objectifs de performance sont chiffrés.
• Les systèmes à intégrer, leurs propriétaires et leurs contraintes sont identifiés.
• Les données personnelles ont été inventoriées et l’EFVP a été amorcée lorsque requise.
• La sécurité, l’accessibilité, le français et les exigences sectorielles ont des preuves attendues.
• La migration, le retour arrière, l’exploitation et le soutien sont inclus.
• Les livrables, approbateurs, jalons et règles de changement sont explicites.
• Les coûts récurrents, licences, options et conditions de sortie sont demandés.
• La grille, les poids, l’échelle et les seuils ont été approuvés avant les réponses.

Six erreurs fréquentes à éliminer

1. Décrire uniquement des écrans. Sans règles d’affaires, données et exceptions, la maquette cache la complexité.
2. Tout déclarer obligatoire. Le fournisseur ne peut plus proposer de compromis utiles et ajoute une réserve de risque au prix.
3. Imposer une technologie sans motif. Écrivez la contrainte réelle — compétences internes, hébergement, intégration ou sécurité — et demandez au fournisseur d’expliquer sa réponse.
4. Reporter les données et la vie privée. Une architecture choisie avant l’inventaire des renseignements peut créer une refonte coûteuse.
5. Choisir sur le prix initial. Comparez le coût total, les hypothèses, les exclusions, la qualité et la réversibilité.
6. Oublier l’après-lancement. Le logiciel doit être surveillé, corrigé, mis à jour, documenté et transférable.

Passer du modèle à un mandat réalisable

Hamdi Services peut vous aider à cadrer ou à réaliser un logiciel sur mesure .NET et Angular à Montréal. Consultez nos projets pour voir des contextes de modernisation et d’intégration, ou contactez-nous avec votre cahier des charges, même préliminaire. Nous pouvons en faire une revue technique, relever les risques et proposer une démarche de livraison adaptée.

Rappel : télécharger le modèle Word et télécharger la grille Excel.