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

La situation

Le cahier des charges d’un nouveau logiciel métier contient une exigence que personne ne discute : reprendre l’historique des dossiers de l’ancienne application. C’est une demande normale. Elle figure dans presque tous les documents de ce type, elle rassure, et la refuser obligerait à se justifier.

Avant de chiffrer ce développement, nous avons ouvert 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. C’est ce qui a rendu la suite possible.

La solution retenue est beaucoup plus simple, et rien n’a été développé. On ne reprend rien. Lorsqu’une nouvelle prestation doit être encodée sur un dossier ancien, ce dossier est recréé à ce moment-là, avec les seules informations utiles. Quelques mois plus tard, tout ce qui vit se trouve dans le nouveau logiciel, et le reste n’y est jamais entré.

L’exigence n’était pas absurde. Elle n’avait simplement jamais été confrontée à l’état réel des données. La vérifier a pris une demi-journée. Ne pas la vérifier aurait coûté un développement, puis le tri de milliers de dossiers, puis des données douteuses installées à demeure.

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 circule de service en service, chacun y ajoute ce qui le concerne. Personne ne relit l’ensemble, parce que ce n’est le travail de personne. Le document grossit, se contredit par endroits, et devient difficile à lire pour ceux à qui il est destiné. Celui qui ajoute une exigence est visible et légitime. Celui qui en retire une 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. Cela paraît moderne et utile, et la fonctionnalité entre dans le document. Ce qu’il a vu, c’est un écran. Ce qu’il n’a pas vu, c’est le service de trois personnes qui alimente ce tableau de bord tous les matins pour qu’il affiche quelque chose.

Oublier une exigence se remarque, en demander une inutile ne se remarque pas. Si une exigence manque, elle réapparaîtra en cours de projet, il faudra la financer en supplément, et chacun se souviendra de qui avait rédigé cette partie du document. Si une exigence est inutile, elle sera développée, facturée, livrée, et jamais utilisée. Personne ne viendra demander pourquoi elle avait été commandée. Devant ce déséquilibre, chacun rédige de la même façon : dans le doute, on demande.

Les erreurs fréquemment observées

Décrire l’organisation dont on rêve plutôt que celle qui existe. Un site institutionnel doit être doté 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. L’équipe qui publie est composée de deux personnes qui travaillent dans le même bureau. Le circuit a été développé. Il n’a jamais servi. Le même document prévoyait une lettre d’information avec inscription, désinscription, publication et archives consultables. L’entreprise n’avait personne pour l’écrire. Ces exigences ne décrivent pas un besoin, elles décrivent une organisation que l’on aimerait être.

Vouloir tout dès la première version. Chaque exception du métier réclame sa fonctionnalité, y compris celles qui se produisent trois fois par an et qui se règlent très bien à la main ou dans un autre outil. Le résultat est un logiciel compliqué à utiliser, compliqué à tester, avec des traitements dont la complexité produit elle-même des erreurs. On paie cher, et longtemps, pour des cas marginaux.

Dire comment faire au lieu de dire ce qu’il faut obtenir. Un cahier des charges qui décrit des écrans, des boutons et un enchaînement précis d’opérations impose une solution avant d’avoir posé l’objectif. Le fournisseur exécute. Il ne lui reste aucune place pour dire qu’il existe une manière plus simple 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. Le cahier des charges décrit le circuit tel qu’il existe aujourd’hui, étape par étape, et demande au logiciel de le reproduire à l’identique. À partir de là, la question ne peut plus être posée. 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. Le projet était le bon moment pour revoir ces 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, il a suffi d’ouvrir la base et de compter : combien de dossiers, combien encore actifs, dans quel état. Une demi-journée de vérification a supprimé une ligne entière du budget. 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, elle se vérifie, et elle se vérifie avant d’écrire l’exigence plutôt qu’après l’avoir commandée.

Poser trois questions à chaque fonctionnalité demandée. Qui s’en servira, nommément. À quelle fréquence. Et que se passe-t-il si elle n’existe pas. Le circuit de validation à trois profils ne survit pas à la première question. La lettre d’information ne survit pas à la deuxième. Une exception traitée trois fois par an ne survit pas à la troisième, puisque la réponse est qu’on la traitera comme aujourd’hui, à la main.

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 ensuite sans tout reprendre ». 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 mandat de retirer. Un document écrit à plusieurs mains a besoin d’une main 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 ?

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.