Choisir un nouveau logiciel métier ne commence pas par une démonstration commerciale, mais par une question : qu’est-ce qui doit réellement mieux fonctionner dans l’entreprise ? Derrière une demande de remplacement se cachent souvent des doubles saisies, des validations trop lentes ou des informations dispersées. Un cahier des charges utile transforme ces difficultés en exigences vérifiables, sans enfermer prématurément le projet dans une technologie. Il permet de comparer les offres sur une base commune, d’anticiper les coûts cachés et de préparer l’adoption par les équipes. Pour illustrer cette démarche, suivons Atelier Boréal, une PME fictive qui souhaite remplacer ses tableurs commerciaux et son ancien outil de suivi des commandes.
1. Cadrer les besoins métiers avant de chercher un logiciel
Un cahier des charges décrit le problème à résoudre, les usages attendus et les conditions de réussite. Pour sélectionner une solution existante, il sert surtout à distinguer ce qui doit être couvert en standard, ce qui nécessite un paramétrage et ce qui demanderait un développement spécifique.
Cette distinction évite une confusion fréquente : acheter un produit n’équivaut pas à commander une application sur mesure. Dans le premier cas, l’entreprise évalue aussi sa capacité à adapter certaines pratiques ; dans le second, elle dispose d’une plus grande liberté de conception, avec des responsabilités supplémentaires de maintenance.
Observer les usages pour construire une analyse fonctionnelle fiable
Chez Atelier Boréal, la direction réclame initialement « un outil commercial plus moderne ». Cette formulation ne permet pourtant ni de comparer des éditeurs ni de justifier une dépense : moderne pour qui, et pour obtenir quel résultat ?
Une observation du travail révèle un problème plus précis : les commerciaux recopient les références produits depuis un tableur, puis demandent une validation des remises par courriel. Le responsable administratif ressaisit ensuite les commandes dans un autre environnement, ce qui multiplie les risques d’écart.
L’analyse fonctionnelle commence donc par des entretiens et quelques observations de terrain. Il faut associer les utilisateurs quotidiens, les responsables de processus et les personnes chargées des exceptions : une commande urgente ou un retour client révèle souvent davantage de contraintes qu’un parcours idéal.
Demandez des exemples récents plutôt que des opinions générales. « Montrez-moi votre dernière commande bloquée » produit une information plus exploitable que « quelles fonctionnalités souhaitez-vous ? », car la réponse expose les documents, les décisions et les échanges réellement nécessaires.
Relier chaque difficulté à un objectif mesurable
Les besoins métiers doivent ensuite être traduits en résultats observables. Atelier Boréal retient, à titre d’objectif à tester, la préparation d’un devis standard en moins de dix minutes, à partir d’un catalogue tarifaire validé et sans ressaisie dans la comptabilité.
Ce seuil n’est pas une promesse universelle de productivité. Il devient pertinent parce que l’entreprise définit le scénario concerné, mesure son temps actuel et précise les conditions du futur test : utilisateur formé, catalogue disponible et commande sans exception particulière.
- Problème constaté : les tarifs circulent dans plusieurs fichiers dont les versions divergent.
- Population concernée : commerciaux, administration des ventes et responsable financier.
- Résultat attendu : une source tarifaire unique et des validations traçables.
- Indicateur : durée de préparation et nombre de corrections sur un échantillon défini.
- Responsable : une personne désignée pour arbitrer les règles et vérifier le résultat.
Cette première formalisation doit également délimiter le projet. Remplacer la gestion commerciale n’implique pas automatiquement de renouveler la paie, le site marchand ou tous les outils de reporting ; les exclusions explicites protègent le calendrier autant que les fonctionnalités retenues.
Consignez aussi les contraintes déjà connues : fermeture annuelle, disponibilité limitée des référents ou engagement contractuel avec le fournisseur actuel. Une date souhaitée n’a pas la même portée qu’une échéance imposée par la fin d’un contrat.
Enfin, prévoyez une validation commune entre direction, métiers et informatique. Chacun doit pouvoir reconnaître ses enjeux dans le document, tandis qu’un décideur identifié tranche les désaccords plutôt que de laisser s’accumuler des demandes incompatibles.
Le bon point de départ n’est pas une liste d’écrans : c’est un accord sur les problèmes prioritaires et sur la manière de constater leur résolution.
2. Rédiger les exigences fonctionnelles et prioriser le périmètre
Une fois les objectifs partagés, le document doit décrire le travail à accomplir avec suffisamment de précision pour obtenir des réponses comparables. Une formule comme « gestion complète des devis » reste trop vague : deux fournisseurs peuvent l’accepter tout en proposant des capacités très différentes.
Pour Atelier Boréal, le parcours commence par la recherche d’un client, continue avec la sélection des produits et se termine par l’envoi d’un document validé. Entre ces étapes interviennent des règles de remise, des autorisations et parfois un blocage lié à un impayé.
Décrire des parcours et des règles plutôt que chaque bouton
Chaque exigence gagne à comporter un identifiant, un acteur, une action attendue et un critère de validation. Ajoutez les conditions de départ et les exceptions importantes ; cette structure donne au prestataire une base de chiffrage et à l’entreprise un futur scénario de recette.
Exemple : « F-012 : un commercial prépare un devis à partir du catalogue actif ; une remise supérieure au seuil autorisé déclenche une demande de validation ; l’envoi reste bloqué jusqu’à la décision du responsable. » Le besoin est explicite sans imposer l’emplacement d’un bouton.
Le critère associé peut être vérifié lors d’une démonstration : avec un compte commercial, une remise dépassant le seuil ne doit pas permettre l’envoi immédiat. Le responsable doit ensuite retrouver la demande et sa décision dans un historique consultable.
Des schémas simples facilitent la discussion, notamment lorsque plusieurs services se transmettent un dossier. Ils ne remplacent toutefois pas les règles écrites : une maquette montre un enchaînement d’écrans, mais précise rarement à elle seule les droits, les calculs ou les exceptions.
Faire apparaître les priorités et les compromis acceptables
Toutes les demandes ne doivent pas peser autant. Une fonction indispensable à la facturation ne se compare pas à une personnalisation esthétique ; sans hiérarchisation, une grille d’évaluation peut favoriser un produit séduisant qui échoue sur le cœur du métier.
| Exigence | Priorité | Preuve attendue | Compromis acceptable |
|---|---|---|---|
| Appliquer le catalogue tarifaire validé | Indispensable | Devis test conforme aux règles fournies | Aucun écart de calcul accepté |
| Valider les remises exceptionnelles | Indispensable | Démonstration avec deux profils distincts | Parcours différent si le contrôle reste garanti |
| Relancer automatiquement les devis | Souhaitable | Scénario de relance paramétrable | Traitement manuel temporaire |
| Personnaliser les tableaux de bord | Différable | Exemple de configuration | Rapports standards au démarrage |
Demandez ensuite aux candidats de qualifier chaque réponse : disponible en standard, accessible par configuration, fourni par une extension, soumis à développement ou absent. Une simple case « oui » dissimule trop facilement un coût, une dépendance ou une livraison future.
Les fonctionnalités annoncées sur une feuille de route doivent être évaluées séparément de celles déjà utilisables. Si leur disponibilité conditionne le lancement, exigez un engagement contractuel adapté plutôt que de fonder la décision sur une présentation commerciale.
Attention également à ne pas reproduire toutes les habitudes de l’ancien outil. Chez Atelier Boréal, trois validations successives existaient parce que les tarifs étaient peu fiables ; avec une base commune et des droits mieux définis, une seule approbation peut suffire.
Le document doit donc distinguer les obligations réelles des pratiques historiques. Cette clarification ouvre la comparaison à davantage de solutions et évite de financer des adaptations qui préserveraient surtout des lourdeurs anciennes.
Une exigence bien formulée laisse de la liberté sur la solution, mais aucune ambiguïté sur le résultat attendu.
3. Définir les spécifications techniques, les données et les interfaces
Une application peut satisfaire les utilisateurs pendant une démonstration et se révéler difficile à exploiter dans leur environnement réel. Les spécifications techniques doivent donc rendre visibles les contraintes qui influencent la disponibilité, la maintenance et les échanges avec les autres outils.
Pour un progiciel, il est rarement utile d’imposer un langage de programmation sans justification. Il vaut mieux exprimer les exigences d’interopérabilité, de performances et d’exploitation, puis demander au fournisseur d’expliquer comment son architecture y répond.
Documenter l’intégration des systèmes et préparer la migration
L’intégration des systèmes commence par une cartographie simple : quelles applications produisent les informations, lesquelles les consomment et laquelle fait référence ? Chez Atelier Boréal, le catalogue relève du référentiel produits, tandis que la comptabilité conserve la responsabilité des écritures financières.
Pour chaque échange, précisez les champs transmis, le sens de circulation et la fréquence nécessaire. Une synchronisation nocturne peut convenir à un rapport de gestion, mais pas forcément à une vérification de disponibilité utilisée au moment de confirmer une commande.
La présence d’une API ne garantit pas, à elle seule, une connexion opérationnelle. Il faut vérifier les possibilités de lecture et d’écriture, les limites d’usage, les mécanismes d’authentification, les coûts éventuels et le traitement des erreurs ou des doublons.
La reprise des données mérite un lot distinct. Inventoriez les clients, produits, documents, pièces jointes et historiques ; pour chacun, indiquez le volume, la qualité, les règles de transformation et la durée de conservation applicable.
Dans notre exemple, plusieurs fiches représentent parfois le même client sous des orthographes différentes. Importer sans nettoyage déplacerait le problème dans le nouvel environnement ; un responsable doit donc valider les règles de rapprochement avant les premiers essais.
Exigez une migration à blanc, suivie de contrôles quantitatifs et qualitatifs. Compter les enregistrements ne suffit pas : il faut aussi vérifier les totaux, les relations entre objets, les caractères particuliers et l’ouverture d’un échantillon de documents.
Rendre la sécurité des données vérifiable
La sécurité des données doit apparaître dans des exigences concrètes : gestion des habilitations, authentification multifacteur selon les risques, journalisation, chiffrement adapté et procédure de retrait des accès. Les profils doivent correspondre aux responsabilités réelles, pas seulement à l’organigramme.
Pour les données personnelles, précisez notamment les finalités, les durées de conservation, les modalités d’exercice des droits et les responsabilités contractuelles. Le RGPD ne se résume ni à une localisation d’hébergement ni à une déclaration générale de conformité.
Demandez la liste des sous-traitants pertinents, les lieux de traitement et les dispositions encadrant d’éventuels transferts hors de l’Espace économique européen. Les besoins de confidentialité peuvent également nécessiter des restrictions sur l’assistance à distance ou sur les environnements de test.
Si le produit propose des fonctions d’intelligence artificielle, vérifiez ce qui leur est transmis et dans quel but. L’utilisation des contenus de l’entreprise pour entraîner des modèles, les possibilités de désactivation et la validation humaine des résultats doivent être clarifiées.
Enfin, fixez des objectifs de continuité : perte de données maximale acceptable, délai de rétablissement et conditions de restauration. Une sauvegarde annoncée n’apporte pas la même garantie qu’une restauration régulièrement testée et documentée.
Les performances doivent elles aussi être contextualisées : nombre d’utilisateurs simultanés, taille des dossiers et opérations concernées. Une recherche rapide sur une base de démonstration ne prouve pas son comportement sur plusieurs années d’historique.
Une contrainte technique devient utile lorsqu’elle indique ce qu’il faut protéger ou garantir, et la preuve permettant de le vérifier.
4. Comparer les offres avec des critères de sélection et un budget complet
Le cahier des charges doit organiser la consultation autant que décrire les attentes. Si chaque candidat répond dans son propre format, les écarts de périmètre deviennent difficiles à repérer et le prix affiché prend une importance excessive.
Demandez un dossier homogène : matrice de couverture, hypothèses, exclusions, architecture proposée, planning, responsabilités, prestations et conditions commerciales. Les critères de sélection doivent être définis avant les démonstrations pour limiter l’influence d’une présentation particulièrement convaincante.
Construire une grille de comparaison fondée sur des preuves
Séparez d’abord les conditions éliminatoires des critères pondérés. Une impossibilité de récupérer les données ou l’absence d’une fonction réglementaire indispensable ne devrait pas être compensée par une interface agréable ou un abonnement moins cher.
Pour les autres dimensions, attribuez des poids selon vos enjeux. Une répartition illustrative pourrait réserver 35 % à la couverture fonctionnelle, 20 % à l’ergonomie, 20 % au coût global, 15 % à la technique et à la sécurité, puis 10 % à l’accompagnement.
Ces proportions ne constituent pas une norme. Une activité fortement réglementée donnera probablement davantage de place aux contrôles et à la traçabilité ; une équipe mobile pourra privilégier l’utilisation sur le terrain ou la continuité sans connexion.
Associez chaque note à une preuve et à une échelle commune. Par exemple, la meilleure appréciation peut correspondre à un scénario exécuté sans adaptation majeure, tandis qu’une réponse seulement déclarative doit rester moins bien évaluée.
Atelier Boréal fournit aux finalistes le même jeu de données fictives et le même parcours : création d’un client, devis avec remise exceptionnelle, validation, transfert et export. Les utilisateurs observent alors un travail comparable, plutôt que plusieurs démonstrations préparées autour des points forts de chaque produit.
Prévoyez un temps de manipulation autonome. Une interface paraît souvent simple lorsqu’un expert la pilote ; le test devient plus révélateur lorsqu’un futur utilisateur retrouve lui-même un dossier et corrige une erreur après une courte prise en main.
Établir le budget logiciel sur une durée cohérente
Le budget logiciel doit couvrir le coût total de possession, pas seulement les licences. Comparez les offres sur une même durée, par exemple trois ou cinq ans, avec des hypothèses identiques de croissance et de niveau de service.
Intégrez le paramétrage, les interfaces, la migration, la formation, l’assistance, les environnements supplémentaires et les développements spécifiques. Ajoutez les ressources internes mobilisées : nettoyer les données ou participer aux tests représente un effort réel, même sans facture externe.
Examinez aussi les unités de facturation : utilisateur nommé, utilisateur simultané, établissement, volume documentaire ou appels d’API. Un abonnement attractif au départ peut évoluer fortement avec le nombre de comptes ou la consommation de services complémentaires.
La réversibilité doit être chiffrée avant l’engagement. Précisez les formats d’export, la récupération des pièces jointes, les délais d’accès, l’assistance disponible et les coûts de sortie ; disposer d’un fichier partiel ne garantit pas une reprise exploitable.
Pour les adaptations sur mesure, vérifiez les droits d’utilisation, la maintenance et les conditions de remise du code. Le recours à des composants open source n’attribue pas automatiquement la propriété de tous les développements au client : les licences et le contrat restent déterminants.
La meilleure offre est celle dont la valeur, les coûts et les dépendances sont démontrés sur la durée, pas celle qui affiche le tarif d’entrée le plus faible.
5. Organiser la gestion de projet, la recette et la conduite du changement
Une sélection réussie ne garantit pas un déploiement réussi. Le document doit aussi préciser comment les décisions seront prises, comment les résultats seront contrôlés et comment les équipes passeront de l’ancien fonctionnement au nouveau.
La gestion de projet gagne à distinguer les responsabilités : qui arbitre le périmètre, qui valide les données, qui configure les règles et qui autorise la mise en production ? Un fournisseur ne peut pas décider seul d’une règle commerciale ou d’une durée de conservation.
Adapter les livrables au contrat et au mode de travail
Dans une prestation au forfait, le périmètre de référence, les hypothèses et les livrables doivent être suffisamment précis pour encadrer le prix et le calendrier. Une demande supplémentaire reste possible, mais son impact doit suivre une procédure d’évaluation et d’approbation.
En régie, la facturation porte généralement sur le temps mobilisé et les priorités peuvent évoluer. Cette souplesse ne supprime ni les objectifs ni la documentation : elle exige un suivi régulier de la consommation budgétaire, des résultats obtenus et du travail restant.
L’agilité ne dépend pas exclusivement du contrat choisi. Des démonstrations fréquentes, des lots testables et des retours utilisateurs peuvent être organisés dans différents cadres, à condition de définir clairement les engagements et les mécanismes de changement.
Pour Atelier Boréal, les livrables comprennent un dossier de configuration, une cartographie des interfaces, les comptes rendus de migration, les supports de formation et un plan d’exploitation. Chaque élément possède un responsable de validation et une échéance.
Préparer la recette et accompagner les utilisateurs
La recette transforme les exigences en vérifications reproductibles. Pour chaque scénario, indiquez les données d’entrée, le profil utilisé, les actions, le résultat attendu et la preuve conservée ; classez également les anomalies selon leur gravité et leur effet sur le démarrage.
Testez les exceptions autant que le parcours normal : doublon client, remise refusée, interface indisponible ou départ d’un salarié. Prévoyez les conditions de bascule et de retour arrière, avec des critères explicites pour autoriser ou reporter l’ouverture.
La conduite du changement commence avant la formation finale. Les référents participent aux essais, expliquent les nouvelles règles et recueillent les difficultés ; les séances doivent s’appuyer sur les tâches de chaque rôle plutôt que sur une visite exhaustive des menus.
Après le lancement, réservez une période d’assistance renforcée et mesurez les objectifs définis au départ. Des contournements fréquents ou des fichiers parallèles signalent un problème à traiter : règle mal comprise, fonctionnalité inadaptée ou accompagnement insuffisant.
Questions pratiques sur le cahier des charges logiciel métier
Le cahier des charges est-il obligatoire pour acheter un logiciel métier ?
Il n’existe pas d’obligation générale applicable à tout achat privé. Il reste fortement recommandé pour comparer les offres, formaliser les attentes et préparer la recette. Sa portée contractuelle dépend notamment de son incorporation aux documents signés et de leur ordre de priorité.
Faut-il rédiger toutes les spécifications avant de consulter les éditeurs ?
Les objectifs, parcours essentiels, contraintes et exigences éliminatoires doivent être clairs. Les modalités détaillées peuvent ensuite être précisées avec les candidats : cette démarche permet de découvrir les possibilités du marché sans abandonner les besoins prioritaires.
Quels outils utiliser pour préparer et valider le document ?
Un traitement de texte partagé, un tableur pour les exigences et un outil de schématisation suffisent souvent. Prévoyez surtout des identifiants stables, un historique des versions, des responsables de validation et un emplacement unique pour les décisions.
Quand faire intervenir un expert indépendant ?
Un accompagnement est utile lorsque les interfaces sont nombreuses, les données sensibles ou les ressources internes limitées. Définissez sa mission et vérifiez ses liens commerciaux avec les fournisseurs : sa contribution doit éclairer les arbitrages, sans remplacer la participation des futurs utilisateurs.