Cahier des charges logiciel sur mesure en PME : pourquoi les specs de 30 pages font échouer les projets

Le réflexe du cahier des charges (et d'où il vient)

La logique paraît solide : avant de confier un projet de développement à un prestataire, écrire ce qu'on attend. Lister les fonctionnalités, décrire les écrans, préciser les règles de gestion. Le cahier des charges fonctionnel rassure la direction, structure la consultation et, en théorie, protège contre les malentendus.

Ce réflexe vient de la commande publique et du monde de la maîtrise d'ouvrage bâtiment, où le CDC est un document contractuel opposable. Il s'est importé dans le monde des projets SI par analogie, souvent portée par des consultants formés sur ces référentiels. La transposition n'est pas neutre : dans le bâtiment, les matériaux et les dimensions ne changent pas pendant le chantier. Dans un projet logiciel, les exigences évoluent à mesure que les équipes comprennent mieux ce qu'elles veulent.

Dans une PME de 30 à 150 personnes sans DSI structurée, le CDC cristallise une vision du projet à un instant T, portée par une seule personne, souvent le dirigeant ou un responsable de service. Cette personne a une bonne connaissance de son périmètre, mais rarement une vue complète des processus de tous les services concernés, ni des interdépendances entre eux. Ce qui sort de cette rédaction ressemble davantage à une liste de voeux technologiques qu'à une cartographie de la réalité.

Pourquoi les prestataires l'acceptent quand même

Un prestataire qui accepte un CDC de 30 pages sans questionner la méthode y trouve son intérêt : le document lui permet de chiffrer rapidement, de délimiter contractuellement son périmètre et de se protéger contre les demandes d'évolution. Ce qu'il ne voit pas, ou ne dit pas, c'est que ce CDC va générer deux à trois fois plus d'allers-retours en cours de projet que si la démarche avait démarré par une phase de terrain.

Pour le client, l'illusion est symétrique : avoir produit un CDC donne le sentiment d'avoir cadré le projet. En réalité, le vrai cadrage, celui qui aligne les équipes sur les objectifs réels et qui anticipe les points de friction, reste à faire.

Ce qu'un CDC de 30 pages ne peut pas capturer

Les équipes savent ce qu'elles font. Ce qu'elles ne savent pas toujours faire, c'est formuler en langage fonctionnel ce qu'elles font. La rédaction d'un CDC oblige à traduire une pratique en specs, et cette traduction introduit des pertes importantes.

Première perte : les exceptions et les cas non nominaux. Dans tout processus métier, les cas standard représentent la majorité des situations. Les exceptions, les scénarios aléatoires, les règles qui s'appliquent seulement sous certaines conditions, n'entrent jamais dans un CDC. Elles émergent en cours de développement, quand les équipes terrain découvrent que le logiciel ne couvre pas leur quotidien réel. C'est à ce moment que le projet dérape.

Deuxième perte : les dépendances implicites entre processus. Un CDC liste des fonctionnalités. Il ne documente pas que la fonctionnalité B ne peut démarrer que si la fonctionnalité A a généré un statut particulier. Ces dépendances sont dans les têtes, pas dans le document. Elles créent des blocages en développement que personne n'avait anticipés et qui obligent à reprendre des briques déjà développées.

Troisième perte : le vocabulaire métier précis. Chaque PME a son jargon, ses raccourcis, ses noms d'entités internes. Un CDC rédigé en langage générique (« gestion des clients », « suivi des commandes ») fait perdre cette précision. L'architecture qui en résulte sera générique elle aussi, sans ancrage dans le modèle de données réel de l'entreprise.

« On est venu non plus avec des specs, avec un cahier des charges, mais avec une compréhension de leur quotidien et de leurs objets métier. »

Cette formulation résume le déplacement de posture : là où le CDC part de la solution imaginée, le travail de terrain part du problème vécu. L'écart entre les deux n'est pas anodin. C'est souvent là que se concentrent la majorité des allers-retours en cours de projet.

Ce que le terrain révèle là où les specs échouent

Le travail de terrain consiste à interviewer les équipes dans leur quotidien, pas dans une réunion de spécification. La différence n'est pas anodine : en réunion, on parle du processus idéal ; sur le terrain, on observe le processus réel. Ce sont deux choses différentes dans la quasi-totalité des PME.

Ce que le terrain révèle de manière systématique, d'abord : les contournements habituels. Chaque équipe a développé des workarounds autour des outils existants. Un export Excel intermédiaire, un fichier partagé en dehors du CRM, une convention de nommage non écrite qui fait office de règle de gestion. Ces contournements ne disparaîtront pas avec un nouveau logiciel si on ne les a pas compris. Ils se réincarneront dans le nouvel outil sous une autre forme.

Ensuite : les dépendances entre services. Le commercial crée un devis, l'ADV valide, la production reçoit une commande, la comptabilité facture. Chacun de ces passages est une interface, et chaque interface a ses règles implicites. Aucune de ces règles n'apparaît dans un CDC rédigé par une seule personne depuis la direction.

Enfin : les objets métier propres à l'entreprise. Dans l'énergie, un « contrat » n'est pas la même chose que dans une ESN. Dans une PME de négoce, une « commande » peut avoir trois statuts intermédiaires que personne d'autre dans le secteur n'a. La robustesse d'un logiciel sur mesure dépend directement de la qualité avec laquelle ces entités sont modélisées. Cette modélisation ne peut pas se faire depuis un CDC générique.

Pour aller plus loin sur la structuration du SI qui supporte ces objets métier : notre approche du diagnostic SI en tant que livrable à part entière.

La méthode alternative : partir des objets métier, pas des fonctionnalités

L'alternative au CDC n'est pas l'absence de document, c'est un document différent. Là où le CDC liste des écrans et des actions, le mapping d'objets métier liste des entités, leurs attributs, leurs relations et les règles qui gouvernent leurs transitions d'état.

Concrètement, ce travail commence par une cartographie des entités principales de l'entreprise : qu'est-ce qu'un client, un contrat, une mission, une pièce, un ordre de fabrication ? Chaque entité a des attributs (les champs qui la décrivent), des statuts possibles et des règles qui conditionnent le passage d'un statut à l'autre. Ce sont ces règles, souvent implicites dans la tête des équipes, qui font la complexité réelle du logiciel à construire.

Le résultat est un document que les développeurs peuvent exploiter directement. Il leur donne le modèle de données, pas une liste de voeux à interpréter. Il réduit les allers-retours en cours de développement parce que les questions de fond ont été traitées en amont, pas découvertes en production.

Un cas concret : 18 mois de blocage débloqués en quelques semaines

Chez un grand groupe du luxe dont le projet SI était bloqué depuis dix-huit mois, c'est cette démarche qui a déblocqué la situation. Le projet ne stagnait pas faute de specs. Il stagnait parce que personne n'avait cartographié les objets métier partagés entre les équipes de différents pays. La direction artistique, les équipes de commercialisation et les équipes techniques parlaient de la même entité sous trois noms différents, avec des attributs différents selon les interlocuteurs.

Le travail de terrain a produit un mapping visuel que la responsable de projet a pu présenter aux équipes d'architectes à travers le monde pour aligner tout le monde sur une nomenclature commune. Le développement a suivi, sans les allers-retours chroniques du projet précédent. Résultat : livraison en huit mois, avec un mois d'avance, là où le projet stagnait depuis dix-huit.

Ce n'est pas un résultat exceptionnel. C'est le résultat normal quand le cadrage part du terrain plutôt que d'un document de spécification rédigé en chambre.

Pour comprendre comment cette approche s'articule avec le brief de projet global : le template de brief projet digital qui évite 80% des malentendus.

Quand le CDC reste pertinent, et sous quelle forme

Le CDC n'est pas inutile par principe. Il est inadapté au contexte PME quand il est rédigé avant toute investigation terrain, quand il cherche à être exhaustif avant de comprendre ce qui est prioritaire, ou quand il sert principalement à protéger une relation contractuelle avant même que la confiance soit établie.

Il reste pertinent dans trois cas distincts. Pour les appels d'offres publicssoumis à réglementation, où le format s'impose. Pour un périmètre très figé et très standard, quand l'entreprise a déjà une expérience solide du type de logiciel qu'elle cherche et que le risque de découverte terrain est faible. Et enfin, pour la formalisation post-terrain : quand le mapping d'objets métier a été fait et que le CDC cristallise ce travail en format contractuel.

Dans ce dernier cas, le CDC n'est plus un document de départ mais un livrable de fin de cadrage. Il traduit ce qu'on a compris du terrain, pas ce qu'on imaginait depuis un bureau. C'est une différence fondamentale sur la qualité du résultat final.

Si votre projet démarre par la rédaction d'un CDC de 30 pages sans investigation terrain préalable, prenez un temps d'arrêt. Demandez à votre prestataire s'il a une méthode pour comprendre votre quotidien avant de chiffrer. S'il ne sait pas répondre à cette question, le risque ne vient pas des specs manquantes, il vient de la méthode.

Sur la note de cadrage qui structure ce travail amont : le guide complet de la note de cadrage projet digital.