Développement logiciel : le cahier des charges que vous écrivez n’est pas celui dont vous avez besoin

Un projet de développement sur mesure échoue rarement sur le code. Il échoue sur l’écart entre ce qui avait été demandé et ce qui était réellement nécessaire, et cet écart n’apparaît qu’une fois que quelqu’un a utilisé quelque chose.

C’est une propriété gênante du métier, et les deux parties passent leur temps à faire comme si elle n’existait pas. Le client écrit un cahier des charges complet parce qu’on lui a appris que c’est sérieux ; le prestataire le chiffre au forfait parce que c’est rassurant.

Puis la première version arrive, les équipes s’en servent, et tout le monde découvre en même temps trois choses qui ne pouvaient pas être devinées. À ce moment-là, le contrat qui devait protéger les deux parties les met en opposition.

Cet article ne propose pas de supprimer le cahier des charges. Il propose d’écrire autre chose dedans, de le chiffrer autrement, et de reconnaître à l’avance ce que personne ne peut savoir — ce qui est la seule façon de ne pas se le reprocher plus tard.

La partie stable d’un projet est constituée de règles, et elles se formulent comme des phrases vraies indépendamment de toute interface.

Un numéro de commande ne se réutilise jamais. Une facture ne se modifie pas après émission, elle s’annule. Un client peut avoir plusieurs adresses de livraison mais une seule adresse de facturation. Un article ne peut pas être vendu en dessous de son prix d’achat sans une validation.

Ces phrases-là valent plus que trente maquettes. Elles sont vérifiables, elles se discutent avec les personnes du métier plutôt qu’avec un informaticien, et elles restent vraies quand l’écran change.

Le second bloc à écrire est celui des cas particuliers connus, ceux dont on se souvient. Ils ne seront pas exhaustifs — c’est le sujet de la section précédente — mais chacun d’eux écrit avant est un litige évité.

Le troisième est ce que l’outil ne fera pas. C’est le plus court et le plus utile : nommer explicitement les fonctions hors périmètre transforme une déception future en décision présente, et c’est la même règle que dans le bâtiment et l’événementiel.

Une erreur de conception revient systématiquement dans les logiciels métier : ils sont dessinés sur l’écran de celui qui les commande, pas sur celui de la personne qui s’en servira.

L’observatoire du marché de l’internet de l’ARPCE recense pour le deuxième trimestre 2025 quelque 59,10 millions d’abonnements internet en Algérie, dont 88,71 % de mobiles et 11,29 % de fixes.

Le rapport ne décrit pas votre entreprise, mais il décrit vos équipes en dehors du bureau : le magasinier, le livreur, le technicien en intervention, le vendeur en rayon. Aucun d’eux ne travaille assis devant deux écrans.

Les conséquences sont concrètes et se décident tôt. Un formulaire de vingt champs est inutilisable debout ; une saisie qui exige les deux mains ne se fait pas en portant quelque chose ; une opération qui suppose une connexion permanente échoue en réserve ou en sous-sol.

La règle que nous appliquons est d’aller voir. Une heure passée à côté de la personne qui fera la saisie, dans son environnement réel, change plus la conception que trois réunions — et elle a lieu avant le premier écran, pas après le premier refus.

Le passage de l’ancien système au nouveau est le moment le plus risqué du projet, et c’est celui qui reçoit le moins d’attention parce qu’il arrive quand tout le monde est fatigué.

La première décision est la bascule : tout d’un coup, ou en parallèle pendant une période. Le parallèle est plus sûr et beaucoup plus coûteux, puisqu’il suppose de tout saisir deux fois ; la bascule est plus rapide et n’a pas de retour arrière au-delà de quelques heures.

La deuxième est la date. Ne mettez jamais en service la veille d’une échéance métier — fin de mois, inventaire, période de forte activité. C’est évident écrit ici et c’est fait régulièrement, parce que la date est choisie sur le calendrier du projet et non sur celui de l’entreprise.

La troisième est la présence. Quelqu’un du prestataire doit être joignable et disponible pendant les premiers jours d’usage réel, et cela doit être écrit dans le contrat plutôt que promis oralement.

La quatrième est le retour en arrière. Écrivez avant la bascule ce qu’on fait si elle échoue : qui décide, à quel moment, et comment on revient. Un plan de repli qui n’a pas servi n’a rien coûté ; son absence coûte une journée d’arrêt.

Ce que nous refuserons : chiffrer au forfait un périmètre que personne n’a encore vu fonctionner. Nous pouvons le faire — cela se vend mieux — mais la marge de sécurité que nous devrions y mettre vous coûterait plus que la méthode que nous proposons à la place.

Nous refuserons aussi de commencer par un cahier des charges de quatre-vingts pages. Nous demanderons les règles, les cas particuliers dont vous vous souvenez et ce que l’outil ne fera pas, puis nous construirons le chemin le plus fréquent et nous vous le montrerons.

Une limite de compétence, dite clairement : nous ne connaissons pas votre métier. Les règles viennent de vous ; nous savons poser les questions qui les font sortir, et nous savons reconnaître quand une réponse décrit une habitude plutôt qu’une contrainte, mais nous ne les inventerons pas.

Ce que nous faisons : les règles écrites avant les écrans, une première version réduite au chemin le plus fréquent, la reprise de données testée sur vos données réelles dès le premier mois, une personne nommée de votre côté pour la recette, et un plan de repli écrit avant la bascule.

Et ce que vous devriez faire sans nous cette semaine : asseyez-vous une heure à côté de la personne qui fera la saisie et regardez-la travailler sans l’interrompre. Notez les trois choses qu’elle fait sans les avoir jamais décrites à personne. Ce sont vos règles, et elles valent plus que le cahier des charges que vous alliez écrire.