Faut-il rédiger un cahier des charges avant de lancer un projet de logiciel ou commencer par un diagnostic

Cahier des charges ou diagnostic, par quoi commencer son projet

Rédiger un cahier des charges détaillé avant d'avoir observé le terrain fige des hypothèses. Commencer par un diagnostic, puis formaliser l'essentiel, donne un projet plus juste. Voici la marche à suivre.

Faut-il rédiger un cahier des charges avant de lancer un projet de logiciel ou commencer par un diagnostic

À retenir

  • Commencez par une note de cadrage courte, puis un diagnostic, et seulement ensuite un cahier des charges.
  • Un cahier des charges rédigé sans observation du terrain fige des suppositions.
  • Décrivez des résultats attendus et des contraintes plutôt qu'une liste d'écrans.
  • Quand une procédure impose un document en amont, prévoyez une phase de diagnostic dans le marché.

Commencez par le diagnostic. Un cahier des charges détaillé écrit avant d'avoir observé le travail réel transforme des suppositions en exigences contractuelles. L'ordre le plus sûr tient en trois temps : une courte note de cadrage qui fixe l'objectif, un diagnostic conduit sur site, puis un cahier des charges nourri de ce que le diagnostic a révélé.

À quoi sert réellement un cahier des charges ?

Le cahier des charges remplit trois fonctions utiles. Il oblige l'organisation à formuler ce qu'elle attend. Il permet de comparer plusieurs propositions sur une base commune. Il sert de référence en cas de désaccord sur ce qui était convenu. Aucune de ces fonctions n'est à rejeter.

Le problème vient du moment où il est rédigé et du niveau de détail qu'on lui donne. Écrit trop tôt et trop précisément, il décrit la solution au lieu de décrire le besoin. On y lit la liste des écrans, des menus et des champs, imaginés en salle de réunion par des personnes qui ne sont pas celles qui utiliseront l'outil.

Pourquoi le cahier des charges rédigé en premier échoue-t-il souvent ?

Trois mécanismes se répètent d'un projet à l'autre.

  • Il décrit la procédure officielle. Les rédacteurs s'appuient sur les textes et les organigrammes, pas sur ce qui se passe au guichet ou à l'entrepôt.
  • Il fige des choix prématurés. Une fois signé, chaque ligne devient une obligation. Le prestataire livre ce qui est écrit, même quand tout le monde a compris en cours de route que ce n'était pas la bonne réponse.
  • Il oublie les contraintes du terrain. La connexion instable, les coupures d'électricité, le niveau d'aisance des agents ou l'état des données existantes figurent rarement dans le document, alors qu'ils orientent toute la conception.

Le résultat est connu : un logiciel conforme au cahier des charges et inadapté à l'usage. Chacun a respecté ses engagements, et l'outil n'est pas utilisé.

Un cas typique : le document parfait et l'outil boudé

Une administration prépare l'informatisation de la délivrance d'autorisations. Un groupe de travail rédige pendant plusieurs mois un cahier des charges très complet, qui détaille chaque étape du circuit réglementaire et chaque pièce à fournir. Le prestataire retenu livre exactement ce qui est décrit.

À la mise en service, les agents constatent que l'outil exige toutes les pièces avant d'enregistrer un dossier. Or, dans la pratique, les demandeurs viennent de loin et déposent des dossiers incomplets, que le service accepte à titre provisoire en attendant le complément. Cette tolérance, connue de tous, ne figurait dans aucun texte. Les agents ont continué à tenir un registre des dossiers en attente, et l'application n'a reçu que les dossiers complets, soit une minorité. Une journée d'observation au guichet aurait suffi à repérer ce point avant d'écrire la première exigence.

Diagnostic et cahier des charges : que compare-t-on ?

Cahier des charges rédigé seulDiagnostic préalable
Source d'informationRéunions, textes, organigrammesObservation sur site, dossiers réels, agents
Ce qu'il décritLe fonctionnement prévuLe fonctionnement constaté et ses raisons
Contraintes du siteSouvent absentesRelevées et intégrées
Rapport au changementRigide une fois signéSert de base à une conception ajustable
Implication des utilisateursFaibleForte dès le départ

Les deux ne s'opposent pas. Le diagnostic fournit la matière, le cahier des charges la met en forme. C'est l'ordre qui fait la différence.

Dans quel ordre procéder, concrètement ?

  1. Rédiger une note de cadrage. Une à deux pages : le problème à résoudre, les services concernés, les résultats attendus, les contraintes connues, le calendrier souhaité.
  2. Préparer le terrain en interne. Rassembler les documents utilisés, désigner un référent, et si possible cartographier sommairement vos processus.
  3. Faire conduire le diagnostic sur site. Observation, entretiens au poste de travail, relevé des contraintes. Notre article sur le diagnostic de terrain en détaille le contenu.
  4. Valider la restitution. Les équipes confirment que la description correspond à leur réalité, la direction arbitre les points ouverts.
  5. Formaliser le cahier des charges. Il reprend les résultats attendus, les règles de gestion confirmées, les contraintes et les priorités, en laissant de la latitude sur la manière d'y répondre.

Et si une procédure impose un cahier des charges dès le départ ?

C'est le cas de nombreux marchés publics et de projets financés par des bailleurs : un document doit exister avant la consultation. Cette obligation n'interdit pas de bien faire. Trois aménagements sont possibles.

Le premier consiste à rédiger le document en termes de résultats et de contraintes plutôt que d'écrans : « un agent doit pouvoir enregistrer un dossier incomplet et le compléter plus tard » dit davantage que la description d'un formulaire. Le deuxième consiste à inscrire dans le marché une phase de diagnostic en première étape, dont les conclusions préciseront le périmètre. Le troisième est de prévoir un mécanisme d'ajustement, pour que les découvertes faites sur le terrain puissent être intégrées sans remettre en cause l'ensemble du contrat. Ces dispositions se discutent avec le service chargé de la passation, dans le respect des règles applicables.

Que doit contenir un bon cahier des charges ?

Un document utile est court et précis sur l'essentiel : le contexte et les objectifs, les utilisateurs et leurs rôles, les processus à couvrir avec leurs cas particuliers, les conditions d'usage (sites, connectivité, matériel), les exigences de sécurité et de traçabilité, la propriété du code et des données, la formation et l'accompagnement attendus, les modalités d'évolution. Il gagne à rester ouvert, car une solution sur mesure a vocation à couvrir toute l'activité et à s'étendre avec elle.

Chez Linking Development, nous commençons toujours par un diagnostic conduit sur site, y compris lorsque le client arrive avec un cahier des charges déjà rédigé. Le document sert alors de point de départ, que l'observation vient confirmer, nuancer ou compléter.

Vous avez un projet en tête, avec ou sans cahier des charges ? Contactez-nous pour en parler avant de figer quoi que ce soit.

Questions fréquentes

Peut-on lancer un projet sans cahier des charges ?

Oui, si un diagnostic sérieux en tient lieu et si ses conclusions sont formalisées et validées. Ce qui compte est de disposer d'une référence écrite et partagée, quelle que soit sa forme.

Qui doit rédiger le cahier des charges ?

L'organisation qui porte le projet, avec l'appui des services concernés et, idéalement, à partir de la restitution du diagnostic. Un document rédigé uniquement par la direction ou par l'informatique passe à côté des usages réels.

Que faire d'un cahier des charges déjà rédigé ?

Le conserver comme base de travail et le confronter au terrain. Le diagnostic confirmera certains points, en corrigera d'autres et ajoutera les contraintes absentes. Mieux vaut l'amender que de développer sur des hypothèses non vérifiées.

Le diagnostic retarde-t-il le projet ?

Il déplace l'effort vers le début. Le temps consacré à observer est repris ensuite, car le développement avance sans les retours en arrière provoqués par des besoins mal compris.

cahier des chargesdiagnosticcadrage projetexpression de besoindigitalisation

Votre réalité. Votre solution. Votre souveraineté.

Vous nous confiez un besoin. Nous nous occupons de tout.

Décrivez votre situation : nous revenons vers vous pour organiser un premier diagnostic.