La plupart des projets d'application métier qui dérapent ne le doivent ni à la technologie ni au prestataire. Ils le doivent au document de départ. Un cahier des charges qui décrit des écrans au lieu de décrire des processus, qui liste des fonctionnalités sans dire lesquelles comptent, ou qui oublie les règles de calcul que tout le monde applique de tête, produit mécaniquement des devis incomparables, un logiciel qui ne colle pas au terrain et un périmètre qui gonfle jusqu'à la livraison.
Ce guide décrit ce qu'un cahier des charges d'application métier sur-mesure doit contenir, dans quel ordre, et avec quel niveau de détail. Il s'adresse au dirigeant ou au responsable opérationnel qui va le rédiger, pas à un chef de projet informatique. L'objectif n'est pas de produire un document parfait, mais un document qui permette à un prestataire sérieux de comprendre votre métier, de chiffrer honnêtement et de construire le bon logiciel.
Ce que le cahier des charges doit accomplir
Avant de le rédiger, il faut savoir à quoi il sert. Un cahier des charges d'application métier remplit trois fonctions, et une bonne partie des erreurs vient de n'en viser qu'une.
Il sert d'abord à aligner votre propre organisation. Le commercial, la production, la comptabilité et la direction n'ont pas la même vision du processus de commande. Écrire le cahier des charges est le moment où ces visions se confrontent, avant que le logiciel ne fige l'une d'elles.
Il sert ensuite à obtenir des propositions comparables. Si trois prestataires reçoivent un document qui laisse ouvertes les questions structurantes, chacun y répondra différemment et les devis iront du simple au triple sans que vous puissiez dire lequel a raison.
Il sert enfin de référence pendant le projet. Quand une demande arrive en cours de développement, c'est le cahier des charges qui permet de dire si elle fait partie du périmètre ou s'il s'agit d'une évolution à chiffrer. Sans référence, chaque discussion sur le périmètre devient une négociation.
Partir des processus, pas des écrans
L'erreur la plus fréquente est de décrire l'application comme une suite d'écrans : « un écran de saisie des commandes avec les champs suivants », « un tableau de bord avec les indicateurs suivants ». Cette approche paraît concrète. Elle est en réalité prématurée et dangereuse.
Prématurée, parce que les écrans sont une conséquence des processus, et qu'un prestataire compétent en proposera de meilleurs que ceux que vous imaginez en reproduisant votre tableur actuel. Dangereuse, parce qu'un écran décrit sans son contexte ne dit rien de ce qui se passe avant, après, ni de ce qui arrive quand le cas n'est pas standard.
La bonne unité de description est le processus : une séquence d'étapes qui part d'un événement déclencheur et aboutit à un résultat métier. Pour chaque processus, le cahier des charges doit répondre à cinq questions.
Qui le déclenche et à quelle occasion ? Un appel client, une réception de marchandise, une date butoir, un événement dans un autre logiciel.
Quelles sont les étapes, et qui les réalise ? Nommer les rôles, pas les personnes. Préciser les étapes qui peuvent se dérouler en parallèle et celles qui doivent attendre une validation.
Quelles informations sont créées, consultées ou modifiées à chaque étape ? C'est ce qui permettra ensuite de dessiner le modèle de données.
Quels sont les cas particuliers ? Une commande annulée après expédition, un client en dépassement d'encours, une intervention reportée trois fois. Ce sont ces cas qui font la valeur réelle d'un logiciel métier, et ce sont eux qu'un cahier des charges oublie le plus souvent parce qu'ils sont gérés « à la main » aujourd'hui.
Comment sait-on que le processus est terminé, et avec quel résultat ? Un document généré, un statut atteint, une notification envoyée.
Une application métier de PME repose en général sur cinq à quinze processus. Les décrire tous avec cette rigueur représente l'essentiel du travail de rédaction, et c'est un travail qui ne peut pas être délégué : personne ne connaît vos processus mieux que vos équipes.
Formaliser les règles métier que tout le monde applique de tête
Chaque entreprise fonctionne avec des dizaines de règles que personne n'a jamais écrites. La remise accordée au-delà d'un certain volume. Le délai de livraison qui dépend du département. Le calcul de la commission commerciale. La priorité entre deux interventions urgentes. Le seuil au-delà duquel un devis doit être validé par la direction.
Ces règles sont invisibles dans les écrans et absentes des cahiers des charges, parce que ceux qui les appliquent ne les perçoivent plus comme des règles. Elles sont pourtant ce qui distingue un logiciel adapté d'un logiciel qu'il faut contourner en permanence.
Le cahier des charges doit les lister explicitement, avec pour chacune : la condition, le résultat, les exceptions connues et qui a le pouvoir d'y déroger. Une bonne méthode pour les faire émerger consiste à prendre dix dossiers récents, dont plusieurs compliqués, et à reconstituer les décisions prises à chaque étape en demandant systématiquement « pourquoi ». Les réponses sont vos règles métier.
C'est aussi à ce niveau que l'on distingue une application métier d'un ERP généraliste. Si vos règles sont standard, un ERP du marché correctement paramétré peut suffire. Si elles sont spécifiques, nombreuses ou changeantes, c'est précisément ce que le sur-mesure doit encoder proprement, et le cahier des charges est le seul endroit où elles seront écrites avant le code.
Décrire les données et leur cycle de vie
Une fois les processus et les règles posés, les données apparaissent presque d'elles-mêmes. Le cahier des charges n'a pas à fournir un modèle de base de données, mais il doit nommer les objets métier principaux et dire ce qui les caractérise.
Pour chaque objet, client, commande, intervention, article, contrat, il faut préciser les informations indispensables, les états par lesquels il passe, et les liens avec les autres objets. Un client peut avoir plusieurs sites de livraison. Une commande passe de brouillon à validée, préparée, expédiée, facturée, et certaines transitions sont interdites. Une intervention est rattachée à un contrat qui définit ce qui est facturable.
Deux points sont trop souvent oubliés. Le premier est la reprise des données existantes : d'où viennent-elles, dans quel état sont-elles, faut-il tout migrer ou seulement l'historique récent, qui les nettoiera. La reprise de données est fréquemment le poste le plus sous-estimé d'un projet et mérite un chapitre à part. Le second est la durée de conservation et les contraintes réglementaires, notamment pour les données personnelles. Décider dès le départ ce qui doit être archivé ou supprimé évite de le découvrir lors d'un contrôle.
Cartographier les intégrations
Une application métier ne vit jamais seule. Elle échange avec la comptabilité, la banque, le site e-commerce, l'outil de facturation, le transporteur, la messagerie, parfois une machine ou un capteur. Chaque intégration absente du cahier des charges est un surcoût garanti et, souvent, un blocage tardif.
Pour chaque système avec lequel l'application doit communiquer, le document doit indiquer ce qui est échangé, dans quel sens, à quelle fréquence, et ce qui se passe en cas d'échec. Il doit surtout préciser ce dont on dispose : une API documentée, un export de fichiers, un accès à la base, ou rien. Un logiciel comptable qui n'expose qu'un import de fichiers mensuels ne s'intègre pas de la même manière qu'un outil moderne avec une API, et le prestataire doit le savoir avant de chiffrer.
Si un site e-commerce est concerné, la question du flux de commandes et de stocks entre la boutique et l'application mérite une attention particulière, car c'est un endroit où les règles de deux systèmes entrent en conflit.
Préciser les rôles, les accès et les contraintes non fonctionnelles
Qui utilise l'application, depuis où, et avec quels droits ? Un technicien sur le terrain avec une tablette n'a pas les mêmes besoins qu'un comptable au bureau. Certains rôles voient tout, d'autres seulement leurs dossiers. Certaines actions doivent être tracées, avec l'auteur et l'heure. Lister les rôles et, pour chacun, ce qu'il peut consulter, créer, modifier et valider, évite les surprises au moment de la recette.
Les contraintes non fonctionnelles sont le chapitre que les cahiers des charges rédigés en interne laissent le plus souvent vide. Elles conditionnent pourtant l'architecture et le coût. Combien d'utilisateurs simultanés ? Quel volume de données à cinq ans ? L'application doit-elle fonctionner sans connexion ? Quel temps d'indisponibilité est tolérable ? Où les données doivent-elles être hébergées ? Qui assurera la maintenance après la livraison, et cette équipe a-t-elle des compétences qui orientent le choix technique ?
Ces réponses n'ont pas besoin d'être précises au chiffre près. Elles doivent donner un ordre de grandeur et signaler les contraintes fortes. Une application pour douze utilisateurs et une application pour trois cents ne se conçoivent pas de la même façon.
Prioriser : ce qui bloque, ce qui compte, ce qui peut attendre
Un cahier des charges qui met tout au même niveau oblige le prestataire à tout chiffrer au même niveau, et produit un devis global que vous ne pourrez ni réduire ni phaser. La priorisation est ce qui transforme une liste de souhaits en projet réalisable.
La méthode la plus simple consiste à classer chaque processus et chaque fonctionnalité en trois catégories. Ce sans quoi l'application ne peut pas remplacer l'outil actuel. Ce qui apporte un gain net mais dont on peut se passer quelques mois. Ce qui serait agréable mais n'a pas de justification économique immédiate.
Cette classification a un effet direct : elle permet de définir une première version livrable, généralement centrée sur deux ou trois processus critiques, qui entre en production rapidement et sur laquelle le reste se construit. C'est aussi ce qui rend possible une démarche progressive plutôt qu'un grand soir : le logiciel remplace l'existant module par module, avec un risque maîtrisé à chaque étape.
Définir comment on saura que c'est réussi
Le cahier des charges doit se terminer par les critères qui permettront de dire que l'application est conforme. Pas « le logiciel fonctionne », mais des scénarios précis : « une commande saisie avec un client en dépassement d'encours est bloquée et une alerte est envoyée au commercial », « la clôture mensuelle génère l'export comptable au format attendu sans retraitement manuel ».
Ces scénarios de recette découlent directement des processus et des règles décrits plus haut. Les écrire dès le cahier des charges a deux vertus. Ils forcent à préciser ce qui était encore flou. Et ils constituent la base contractuelle de la livraison, ce qui protège les deux parties.
Il est utile d'y ajouter les indicateurs business attendus : temps de traitement d'une commande divisé par deux, fin des doubles saisies entre deux outils, délai de facturation ramené à quarante-huit heures. Ces indicateurs ne sont pas des critères de recette, mais ils rappellent pourquoi le projet existe et servent à arbitrer quand un choix de conception se présente.
Les erreurs qui coûtent le plus cher
Certaines erreurs reviennent dans presque tous les cahiers des charges que nous recevons. Les connaître permet de les éviter.
Décrire l'outil actuel au lieu du besoin. Reproduire le tableur ou l'ancien logiciel, avec ses contournements, fige des défauts qu'un nouvel outil devrait précisément supprimer. Décrivez ce que le processus doit accomplir, pas comment il est bricolé aujourd'hui.
Oublier les cas hors norme. Le cas standard représente souvent moins de la moitié du travail réel. Une application qui ne gère que le cas standard sera contournée dès la première exception, et le tableur reviendra.
Ne pas consulter les utilisateurs de terrain. Un cahier des charges rédigé par la direction seule décrit le processus tel qu'il devrait être, pas tel qu'il est. Les écarts se découvrent à la recette, quand ils coûtent le plus cher à corriger.
Confondre exhaustivité et précision. Deux cents lignes de fonctionnalités sans contexte valent moins que dix processus décrits avec leurs règles et leurs exceptions.
Imposer une technologie sans raison. Sauf contrainte réelle d'intégration ou de compétences internes, laissez le prestataire proposer une stack adaptée et la justifier. Une contrainte technique arbitraire écarte de bonnes propositions.
Laisser le prestataire écrire seul le document qu'il chiffrera. Son aide est précieuse pour structurer et challenger, mais un cahier des charges rédigé entièrement par celui qui répondra devient rarement un outil d'arbitrage neutre.
Un plan type que vous pouvez suivre
Pour une application métier de PME, la structure suivante couvre l'essentiel sans noyer le lecteur.
- Contexte et objectifs : l'entreprise, le problème actuel, les résultats attendus et les indicateurs de succès.
- Périmètre : ce que l'application couvre, ce qu'elle ne couvre pas, ce qui est prévu pour plus tard.
- Utilisateurs et rôles : qui utilise quoi, depuis où, avec quels droits.
- Processus métier : un chapitre par processus, avec déclencheur, étapes, cas particuliers et résultat.
- Règles métier : la liste des règles, conditions, exceptions et responsables des dérogations.
- Données : les objets métier, leurs états, leurs liens, la reprise de l'existant et la conservation.
- Intégrations : les systèmes connectés, les flux, les moyens techniques disponibles.
- Contraintes non fonctionnelles : volumes, performance, disponibilité, hébergement, sécurité, maintenance.
- Priorités et phasage : ce qui compose la première version, ce qui suit.
- Critères de recette : les scénarios qui valident la livraison.
- Annexes : maquettes ou captures de l'existant, exemples de documents, exports de données.
Ce plan n'a rien d'original, et c'est voulu. Un prestataire qui reçoit un document structuré ainsi peut le lire en une heure, identifier immédiatement les zones à approfondir et produire un chiffrage argumenté.
Et si vous n'avez pas le temps de le rédiger
Rédiger un cahier des charges sérieux demande plusieurs jours de travail interne et des ateliers avec les équipes. C'est un investissement qui se rentabilise plusieurs fois sur la durée du projet, mais il arrive qu'il ne soit pas réalisable en interne, par manque de temps ou parce que personne n'a la vue d'ensemble.
Dans ce cas, la bonne approche n'est pas de sauter l'étape, mais de la mener sous une autre forme : une phase de cadrage courte, facturée séparément, pendant laquelle un développeur senior conduit les ateliers avec vos équipes, formalise les processus et les règles, et livre un document que vous restez libre de faire chiffrer par qui vous voulez. C'est également la démarche que nous recommandons quand une application existe déjà et qu'il s'agit de la remplacer : un audit technique de l'existant complète alors le cadrage fonctionnel.
Si vous préparez un projet d'application métier ou d'ERP sur-mesure et que vous hésitez sur la manière de le cadrer, décrivez-nous votre contexte. Nous vous dirons franchement si un cahier des charges suffit, si une phase de cadrage s'impose, et ce que représente le projet en ordre de grandeur.