Logiciel métier sur mesure : comment rédiger un cahier des charges avant de demander des devis ?

Un devis de développement peut sembler précis tout en reposant sur une idée très différente de la vôtre. « Gestion des interventions » désigne aussi bien un formulaire partagé qu’une application capable de planifier des techniciens, gérer des pièces détachées, fonctionner sans réseau et synchroniser une comptabilité. Les deux réponses portent le même nom. Elles ne représentent ni le même investissement ni le même risque.

Le cahier des charges d’un logiciel métier sert à réduire cette ambiguïté avant de comparer les propositions. Son objectif n’est pas de dessiner chaque bouton. Il doit rendre explicites le problème, les règles de fonctionnement, les contraintes et les preuves attendues pour considérer le travail comme terminé.

Un document utile permet surtout au prestataire de dire : « Cette partie est comprise ; cette autre dépend d’une hypothèse qu’il faut vérifier. » C’est cette transparence qui rend un devis exploitable.

Partir du travail réel, pas de la liste des écrans

Commencez par un processus concret, depuis son déclencheur jusqu’au résultat attendu. Pour une entreprise de maintenance, le parcours peut être : recevoir une demande, vérifier le contrat, affecter une intervention, réserver une pièce, recueillir un compte rendu, préparer la facturation. Documentez qui intervient, quelles informations circulent et où apparaissent les blocages.

Observez quelques dossiers représentatifs avec les personnes qui les traitent. Demandez-leur de montrer les fichiers, messages et corrections nécessaires, plutôt que de décrire un fonctionnement idéal. Un tableau utilisé « provisoirement » depuis trois ans contient parfois une règle métier que personne n’a encore formulée.

Distinguez le symptôme de sa cause. Une double saisie peut venir de l’absence de connecteur ; elle peut aussi venir d’un référentiel client incohérent. Dans le second cas, développer un formulaire plus rapide ne résoudra pas le problème. Le cahier des charges doit signaler le travail sur les données, même si ce travail constitue un chantier séparé.

Définissez ensuite deux ou trois résultats observables. Par exemple : retrouver l’état d’un dossier sans interroger plusieurs personnes ; empêcher une affectation incompatible avec une habilitation ; préparer une facture à partir d’informations déjà validées. Évitez « moderniser l’entreprise », impossible à réceptionner.

Le sur-mesure n’est d’ailleurs pas toujours la première réponse. Avant de construire, comparez la couverture d’un outil existant, sa configuration et un développement spécifique. Le diagnostic permettant de savoir quand passer à un ERP aide à distinguer un besoin commun de gestion d’une particularité qui mérite réellement du code.

Définir un périmètre que chaque candidat comprend de la même façon

Une première version doit correspondre à un service complet, même limité. « Gérer les demandes urgentes d’un établissement » est plus facile à cadrer que « réaliser la moitié du futur système ». Une fonction coupée de ses utilisateurs, de ses données ou de sa validation peut coûter sans produire de résultat utilisable.

Classez les besoins selon leur rôle : indispensable au démarrage, nécessaire rapidement, amélioration ultérieure. La priorité ne dépend pas seulement de la préférence d’un responsable. Demandez ce qui empêcherait le fonctionnement, ce qui exposerait à une erreur importante et ce qui dispose déjà d’un contournement acceptable.

Écrivez aussi le hors périmètre. Si la première version ne remplace pas la paie, ne gère pas les filiales et ne propose pas d’application mobile native, dites-le. Un prestataire peut alors chiffrer la même frontière que ses concurrents. Un silence sera sinon interprété différemment par chacun.

Pour chaque besoin majeur, préparez une fiche courte : identifiant, utilisateur concerné, situation de départ, résultat attendu, règles, exceptions et critère d’acceptation. Une exigence comme « le responsable valide les demandes » reste floue tant que l’on ignore le montant déclenchant la validation, le remplaçant pendant les congés et la possibilité de modifier une demande déjà approuvée.

Voici un exemple fictif de formulation testable : « Lorsqu’un collaborateur soumet une demande supérieure au plafond affecté à son service, celle-ci reste en attente. Seul un responsable autorisé peut l’approuver. Le demandeur voit la décision et son motif. Une modification du montant après validation déclenche une nouvelle validation. » Ce paragraphe évite davantage de malentendus qu’une capture d’écran décorative.

N’exigez pas pour autant de connaître toutes les exceptions avant le premier échange. Identifiez les questions ouvertes et demandez qu’elles fassent l’objet d’une phase de cadrage chiffrée, avec livrables et décision de poursuite. L’incertitude devient ainsi visible plutôt que dissimulée dans une marge générale.

Les données et les connexions déterminent une grande partie du chantier

Un logiciel neuf reçoit rarement des informations parfaitement propres. Listez les sources : fichiers, application ancienne, annuaire, comptabilité, portail client. Pour chacune, indiquez son propriétaire, son format, sa fréquence de mise à jour et sa qualité connue. Joignez des échantillons anonymisés représentatifs, y compris des cas incomplets.

Définissez les identifiants de référence. Quel numéro désigne un client ? Une même organisation peut-elle posséder plusieurs établissements ? Une référence produit peut-elle changer ? Ces décisions conditionnent les doublons, les rapprochements et les échanges avec les autres outils. Les laisser au dernier moment oblige souvent à reprendre plusieurs modules.

La migration doit apparaître comme une prestation identifiable. Demandez l’inventaire, les règles de transformation, un essai de reprise, les contrôles de cohérence et une procédure de retour en arrière. Une affirmation comme « import des données inclus » ne précise ni le volume ni les responsabilités lorsqu’un ancien champ mélange plusieurs informations.

Pour chaque interface, documentez le sens des échanges, les données concernées, la fréquence et le comportement en cas d’échec. Une synchronisation quotidienne n’offre pas le même service qu’une actualisation immédiate. Demandez comment seront évités les envois en double et comment un utilisateur repérera une commande qui n’a pas été transmise.

Un connecteur annoncé dans une brochure n’est pas une preuve d’intégration disponible pour votre configuration. L’accès à l’API peut dépendre d’un abonnement, d’autorisations ou d’une limite technique. Faites identifier qui obtient ces accès, qui paie les frais et qui entretient la connexion lorsque le service tiers change.

Préparez enfin un tableau de correspondance des données réellement importantes. Un champ obligatoire dans la nouvelle application mais absent de l’ancien système appelle une décision métier : compléter, calculer selon une règle explicite ou accepter un statut provisoire. Le développeur ne doit pas inventer cette réponse à votre place.

Écrire les contraintes invisibles dans une maquette

Deux logiciels peuvent présenter le même écran et offrir une fiabilité très différente. Précisez les périodes critiques, le nombre d’utilisateurs simultanés attendu, les volumes et les délais de réponse acceptables. Une exigence de performance doit être accompagnée de conditions de mesure : jeu de données, réseau, scénario et charge.

Dans un exemple purement pédagogique, demander l’ouverture d’une fiche en moins de deux secondes pour les parcours courants n’a de sens que si l’on précise le volume de fiches et le nombre de sessions actives. Ce chiffre ne constitue pas une norme universelle. L’engagement doit correspondre à l’usage et être vérifiable lors des essais.

La gestion des droits mérite sa propre description. Qui voit, crée, modifie, exporte et supprime chaque information ? Que se passe-t-il au départ d’un salarié ? Un administrateur technique doit-il pouvoir consulter les données métier ? Prévoyez des comptes individuels et une séparation adaptée aux responsabilités, plutôt qu’un mot de passe commun à tout un service.

Quand le prestataire traite des données personnelles pour votre compte, la relation doit être encadrée conformément au RGPD. La CNIL rappelle notamment l’importance du contrat de sous-traitance. Transformez ce sujet en questions concrètes : localisation des traitements, sous-traitants ultérieurs, assistance, accès, suppression et restitution. La présence d’une formule « conforme RGPD » ne répond pas à ces questions.

Précisez aussi les sauvegardes, leur protection et les tests de restauration. Une sauvegarde réussie ne démontre pas, à elle seule, qu’un service peut être rétabli dans le délai utile. Décrivez la perte de données maximale acceptable et la durée d’interruption que l’activité peut supporter ; demandez au candidat la solution et les limites correspondant à ces objectifs.

L’accessibilité et l’usage sur les équipements réels doivent être pris en compte dès le cadrage. Un formulaire utilisé debout sur une tablette avec des gants n’a pas les mêmes contraintes qu’un tableau consulté sur un grand écran. Photographier l’environnement de travail, sans données sensibles, peut expliquer davantage qu’une page de souhaits graphiques.

Avant la consultation, prévoyez un registre des décisions. Chaque choix important doit avoir une date, un auteur et un motif : privilégier un accès navigateur, reporter un connecteur ou conserver une validation manuelle. Ce registre évite qu’une discussion ancienne soit réouverte sans connaître la contrainte qui avait conduit à la décision.

Faites également distinguer les hypothèses confirmées des estimations. Une API non testée, une volumétrie inconnue et une règle métier à arbitrer ne représentent pas le même risque. Le candidat doit préciser comment il compte lever chaque incertitude, à quel moment et avec quel effet possible sur le budget. Vous pourrez alors financer une vérification ciblée plutôt que demander une certitude artificielle.

Organiser une consultation qui produit des devis comparables

Envoyez aux candidats le même dossier et une trame de réponse. Demandez une décomposition par phases et livrables, les hypothèses, les exclusions et les dépendances. Un total unique empêche de comprendre si l’écart provient de la migration, de l’accompagnement ou de fonctionnalités absentes.

Séparez le coût de réalisation des coûts récurrents : hébergement, licences, services externes, maintenance, supervision, assistance et évolutions. Demandez une projection sur une durée commune en précisant les volumes retenus. Une offre moins chère à construire peut devenir plus coûteuse si chaque nouvel utilisateur déclenche un abonnement important.

Le calendrier doit montrer ce qui dépend de votre entreprise : validation d’une maquette, disponibilité d’un expert métier, fourniture de données, ouverture d’un accès. Un délai global sans ces dépendances peut sembler contractuel tout en restant impossible à tenir. Désignez un interlocuteur qui arbitre et un groupe réduit d’utilisateurs capables de tester.

Évaluez les offres à partir de preuves. Faites expliquer une fonctionnalité complexe avec vos propres cas, demandez un exemple de dossier de recette et vérifiez qui réalisera effectivement le projet. La qualité d’une présentation commerciale ne renseigne pas forcément sur l’équipe de développement ou sur la continuité du support.

Une grille peut attribuer une place distincte à la compréhension du métier, à la solution technique, au coût complet, aux garanties d’exploitation et à la qualité de la méthode. Les poids dépendent de votre risque. Il serait incohérent de choisir principalement sur le prix un outil dont une panne arrêterait la préparation des commandes.

Surtout, centralisez les questions. Lorsqu’une réponse change le périmètre, transmettez-la à tous les candidats encore consultés. Vous préserverez une base commune au lieu de comparer des offres fondées sur des informations différentes.

Préparer la réception et la sortie avant de signer

La recette consiste à vérifier le résultat attendu, pas simplement à constater que l’application s’ouvre. Préparez des scénarios de bout en bout, avec des jeux de données identifiés et des résultats attendus. Incluez les erreurs prévisibles : donnée manquante, utilisateur non autorisé, connexion interrompue, double clic et document rejeté.

Reliez chaque exigence importante à un test. Cette traçabilité permet de savoir ce qui est validé, ce qui ne l’est pas et ce qui a changé. Définissez des niveaux d’anomalie selon leur impact, les modalités de correction et les conditions d’une éventuelle mise en service limitée. Un défaut cosmétique ne bloque pas comme une erreur de montant.

Les livrables doivent dépasser le programme exécutable : documentation d’exploitation, procédure de déploiement, configuration, schéma des échanges, instructions de sauvegarde et guide utilisateur adapté. Si votre stratégie implique l’accès au code source, précisez les conditions contractuelles, les dépendances, les droits concernés et les éléments effectivement remis. Une archive de code impossible à reconstruire n’assure pas une reprise.

Demandez comment récupérer vos données dans un format documenté, avec pièces jointes, historiques et relations. La réversibilité doit être praticable sans reconstruire tout le système. Précisez le délai, l’assistance et le coût de cette sortie, y compris lorsqu’un contrat se termine dans de mauvaises conditions.

La maintenance doit distinguer correction d’anomalies, adaptation aux changements externes et nouvelles fonctionnalités. Indiquez le canal de signalement, les horaires couverts et les engagements associés à chaque gravité. Un délai de prise en compte n’est pas un délai de résolution ; cette différence doit être comprise avant le premier incident.

Enfin, prévoyez une phase d’observation après le lancement. Mesurez quelques résultats liés aux problèmes initiaux : dossiers incomplets, ressaisies, temps de recherche, erreurs de transfert. Un logiciel métier ne vaut pas par le nombre d’écrans livrés. Il vaut par la capacité des équipes à accomplir correctement leur travail, y compris les jours où le scénario ne ressemble pas à la démonstration.

Le dossier minimal à remettre aux candidats

Une version exploitable peut réunir une synthèse du problème, les parcours actuels, le périmètre priorisé, les règles métier, l’inventaire des données, les interfaces, les exigences d’exploitation et les critères de réception. Ajoutez les inconnues et la trame de chiffrage. Ces éléments n’ont pas besoin de former un document interminable : leur cohérence compte davantage que leur volume.

Faites relire le dossier par un utilisateur, un responsable opérationnel et la personne qui exploitera le système. Chacun doit pouvoir repérer ce qu’il devra fournir et ce qu’il recevra. Si les trois interprètent différemment une même exigence, corrigez-la avant la consultation.

C’est le meilleur moment pour rendre une ambiguïté peu coûteuse.