Ce qu'un cahier des charges dit de l'organisation qui l'écrit

La situation

Dans le cadre du développement d’un nouveau logiciel métier, les utilisateurs exigent une chose dont ils ne veulent même pas discuter : il faut reprendre l’historique complet des dossiers de l’ancienne application. C’est une demande normale. Elle figure dans presque tous les cahiers des charges, elle rassure, et la refuser obligerait à se justifier.

Avant de chiffrer ce développement, nous avons analysé l’ancienne base et regardé ce qu’elle contenait. Des dossiers clôturés depuis longtemps. D’autres jamais clôturés mais sans la moindre activité depuis des années. Des enregistrements incomplets, des doublons. Transférer cela tel quel revenait à installer le désordre existant dans le nouveau logiciel dès son premier jour. Le transférer proprement supposait de passer en revue chaque dossier, un par un, de vérifier son état et de le corriger avant reprise. Ce tri manuel coûtait à lui seul davantage que le développement.

Aucune obligation légale n’imposait ici la conservation de cet historique, ce qui laissait le champ libre. Restait à savoir ce qui méritait d’être repris. Un critère simple a écarté le plus gros : un projet sans aucune prestation depuis trois ans n’est pas un projet ouvert, c’est soit un projet mort, soit un projet terminé que personne n’a clôturé.

Pour les autres, il a fallu aller voir la comptabilité et le service commercial pour savoir dans quelle situation contractuelle ils se trouvaient. On s’est rapidement rendu compte qu’un même projet n’y avait pas le même statut : clôturé et facturé d’un côté, en cours de l’autre, ouvert dans le logiciel de prestations. Pour démarrer, la reprise s’est donc limitée aux projets réellement actifs, encodés à la main département par département, les autres projets ont été encodés après au fil des besoins.

L’exigence de départ n’était pas absurde. Mais elle reposait sur une habitude, une évidence, mais n’avait simplement jamais été confrontée à l’état réel des données.

Pourquoi cette situation apparaît

Le cahier des charges s’écrit au moment où l’on veut rassurer. La décision de lancer le projet est prise, un budget est engagé, une direction attend. Ce n’est pas le moment que l’on choisit pour rouvrir des questions. Demander la reprise de l’historique ne coûte rien à celui qui l’écrit. Ne pas la demander l’obligerait à expliquer pourquoi, devant des gens qui n’ont pas envie de l’entendre.

Ajouter ne coûte rien, retirer coûte cher. Le document est transmis pour relecture à chaque service, chacun y ajoute ce qui le concerne ou sa touche personnelle. Personne ne relit l’ensemble, parce que personne n’en a la charge. Résultat, le document grossit, se contredit par endroits, et devient difficile à lire pour ceux à qui il est destiné. Celui qui ajoute une exigence s’est rendu utile, visible et légitime. Celui qui en retire sera peut-être critiqué et devra s’en expliquer.

On demande ce qu’on a vu ailleurs. Quelqu’un revient d’une conférence, d’une démonstration chez un confrère ou d’une vidéo de présentation. Il y a vu un tableau de bord, une application mobile, un système d’alertes automatiques. Tout est bien présenté, cela paraît moderne et utile, voire indispensable … et la fonctionnalité entre dans le document. Ce qu’il a vu, c’est un écran, une belle démo. Ce qu’il n’a pas vu, c’est le travail nécessaire tous les matins pour alimenter ce magnifique tableau de bord pour qu’il affiche quelque chose.

Oublier une exigence se remarque, en demander une inutile ne se remarque pas. Si une exigence manque, on le remarquera en cours de projet, il faudra la financer en supplément, et chacun se souviendra qu’il manquait quelque chose dans le cahier des charges. Si une exigence est inutile, elle sera développée, facturée, livrée, et peut-être jamais utilisée. Mais personne ne viendra demander pourquoi elle avait été commandée. Face à cette peur d’oublier quelque chose, dans le doute on demande plutôt que d’évaluer la pertinence de cette demande.

Les erreurs fréquemment observées

Décrire l’organisation dont on rêve plutôt que celle qui existe. Il arrive souvent qu’un cahier des charges explique un fonctionnement différent de la réalité terrain. Soit parce qu’on le rêve, soit parce qu’on ne le connaît pas véritablement. C’est ce qui est arrivé dans le cadre du développement d’un site web institutionnel qui exigeait la mise en place d’un circuit de validation des contenus. Le cahier des charges définit des profils de rédaction, de validation et de publication, déclinés par type de contenu comme on le retrouve dans de grosses administrations. Mais ici il s’agit d’une petite administration, l’équipe qui publie est composée de deux personnes qui travaillent dans le même bureau. Le circuit de validation a été développé comme demandé. Il n’a jamais servi. Quand un rédacteur a terminé son travail et qu’il doit être validé, il le demande oralement à son collègue en face de lui …

Cette exigence ne décrit pas un besoin, elle décrit un rêve.

Vouloir tout dès la première version. Le cahier des charges exige une fonctionnalité pour chaque cas particulier, même s’il se produit 1 ou 2 fois par an et même s’il peut se régler à la main ou via un autre outil. Le résultat est un logiciel cher, compliqué à utiliser, compliqué à tester, avec des traitements dont la complexité produit elle-même des erreurs.

Dire comment faire au lieu de dire ce qu’il faut obtenir. On pense que le cahier des charges doit décrire le moindre détail des écrans, des boutons et des enchaînements précis des opérations. Or cela revient à imposer une solution avant d’avoir posé l’objectif. Dans ces conditions, le fournisseur exécute. Il ne lui reste aucune possibilité de proposer des manières plus simples ou plus efficaces d’arriver au même résultat, ce qui était pourtant la principale raison de faire appel à lui.

Écrire un document si fermé qu’il empêche toute proposition. Ce point est le plus contre-intuitif. Plus le document est précis, plus les offres reçues se ressemblent, et moins il devient possible de distinguer un bon fournisseur d’un mauvais. Toutes les offres cochent les mêmes cases. Il ne reste que le prix pour départager, ce qui est exactement ce que l’on voulait éviter.

Graver le fonctionnement actuel dans le document. Un cahier des charges qui décrit le circuit tel qu’il existe aujourd’hui, étape par étape, et demande au logiciel de le reproduire à l’identique ne permet pas de questionner la pertinence du fonctionnement. Le fournisseur qui suggérerait de supprimer une étape sortirait du cadre contractuel. L’employé qui la trouve inutile depuis des années n’aura pas d’occasion de le dire. Un nouveau projet est le bon moment pour revoir ses habitudes, et le document vient de le faire passer.

Une approche plus pertinente

Confronter chaque exigence à la réalité avant de la commander. Dans l’exemple de la reprise de données, un critère a fait le plus gros du travail : trois ans sans mouvement. Il a suffi à écarter la majeure partie de ce que le document demandait de reprendre, et il peut se transposer à d’autres projets. La règle est simple : une exigence qui porte sur des données existantes ne s’écrit pas sans avoir regardé ces données. Et si elle est déjà écrite, il reste toujours possible de la vérifier avant de la payer. Cette question se pose évidemment autrement quand la loi impose la conservation et la traçabilité des données. Une obligation légale ne se discute pas mais elle se vérifie, et de préférence avant de l’avoir commandée.

Demander aux autres services ce qu’ils savent des mêmes dossiers. Une base de données ne dit que ce que son logiciel a enregistré. La comptabilité, le commercial ou le service juridique ont souvent une autre vérité sur les mêmes objets, et l’écart entre ces versions est en soi une information. Confronter deux ou trois sources avant de décider d’une reprise coûte quelques entretiens et évite de récupérer un désordre que personne ne reconnaîtra comme le sien.

Poser trois questions à chaque fonctionnalité demandée. Qui s’en servira. À quelle fréquence. Et que se passe-t-il si elle n’existe pas.

Distinguer ce qui peut attendre de ce qui doit être là dès le départ. Commencer simple est un bon principe, mais il a une limite qu’il faut connaître. Certaines choses s’ajoutent facilement plus tard : un écran, un état, une automatisation de confort. D’autres ne s’ajoutent pratiquement jamais parce qu’elles touchent aux fondations : la structure des données, la traçabilité des opérations, la gestion des droits. La bonne question n’est donc pas « en avons-nous besoin tout de suite », mais « pourrons-nous l’ajouter facilement ensuite ». Ce qui peut être ajouté attend. Le reste est traité dès le début, même s’il ne se voit pas.

Écrire des objectifs et laisser le chemin ouvert. Plutôt que de décrire l’enchaînement d’écrans qui permet de valider une commande, décrire ce qu’il faut obtenir : qui doit approuver, dans quel délai, avec quelle trace. Le fournisseur propose alors une manière d’y parvenir, et les propositions reçues deviennent enfin comparables sur autre chose que le prix.

Confier la relecture finale à une seule personne, avec le pouvoir de retirer ce qui est inutile. Un document écrit à plusieurs a besoin d’un responsable unique à la fin. Non pas pour arbitrer sur le fond, mais pour supprimer les redondances, lever les contradictions et poser la question de l’utilité là où personne ne l’a posée. Sans ce mandat explicite, cette relecture n’aura pas lieu.

Les questions à se poser

Avons-nous regardé les données dont nous exigeons la reprise ?

Les autres services ont-ils le même statut que nous pour les mêmes dossiers ?

Une obligation légale nous impose-t-elle de les conserver, et l’avons-nous vérifiée auprès de quelqu’un qui en répond ?

Pour chaque fonctionnalité demandée, sommes-nous capables de nommer la personne qui s’en servira et de dire à quelle fréquence ?

Cette exigence décrit-elle notre organisation telle qu’elle est, ou telle que nous aimerions qu’elle soit ?

Que se passe-t-il si nous ne la développons pas ? Si la réponse est « on continuera comme aujourd’hui », est-ce si grave ?

Cette fonctionnalité pourra-t-elle être ajoutée dans deux ans sans tout reconstruire ? Si oui, pourquoi la traiter maintenant ?

Décrivons-nous ce que nous voulons obtenir, ou la manière de l’obtenir ?

Qui a relu l’ensemble du document, et cette personne avait-elle le droit d’en retirer des choses ?

Conclusion

Un cahier des charges est censé décrire un besoin. Dans les faits, il décrit surtout l’organisation qui l’a écrit : ses habitudes, ses craintes, ses non-dits, et l’image qu’elle se fait d’elle-même. Un document qui grossit sans jamais maigrir raconte une organisation où personne n’a le mandat de trancher. Un document rempli de fonctionnalités rêvées raconte une organisation qui ne s’est pas regardée en face.

Il est bien plus facile de retirer une exigence d’un document que de faire disparaître une fonctionnalité déjà développée et facturée. Relire son cahier des charges en se demandant non pas ce qui manque, mais ce qui ne servira jamais, prend une journée. C’est probablement la journée la mieux employée de tout le projet.