Tester un cahier des charges avant d'écrire une ligne de code

Un cahier des charges n'arrive jamais seul

Le client est arrivé avec un document déjà rédigé, déjà chiffré, et un budget déjà fixé. En clair : un autre développeur avait fait l'étude, et moi je devais exécuter à ce prix-là. C'est une situation courante en freelance, et elle n'est pas disqualifiante en soi. Ce qui compte, c'est ce qu'il y a dans le document.

Avant de dire non, j'ai donc essayé 4 combos pour garder le projet. Les voici, dans l'ordre.

Combo 1 : tester les specs

J'ai fait sur ce cahier des charges ce que je fais sur du code : du shift-left testing. Pas de la relecture : de la recherche active de ce qui va casser. Que se passe-t-il si l'utilisateur abandonne au milieu du parcours ? Qui a le droit de modifier quoi ? Que voit-on quand la liste est vide ? Quel est le comportement attendu en cas d'échec de paiement ?

Résultat : des dizaines de questions sans réponse claire, et un certain nombre sans aucune réponse. Ce n'est pas un reproche au document. C'est simplement ce qui arrive à toute spécification qu'on n'a pas encore attaquée.

Tester les specs avant de coder coûte dix fois moins cher que corriger après.

Combo 2 : réécrire le cahier des charges, et le facturer

Je lui propose de reprendre le cahier des charges de zéro, à ses frais, pour qu'on parte d'une base que nous comprenons tous les deux de la même façon. Il refuse. C'est son droit. Mais un cahier des charges flou, c'est la garantie d'un projet qui dérape facilement. Et le dérapage se paie toujours : simplement plus tard, et plus cher.

Combo 3 : livrer par lots, priorisés

Puisqu'on ne pouvait pas tout clarifier d'avance, je lui propose d'avancer par itérations, avec une priorisation MoSCoW : ce qui doit être livré, ce qui devrait l'être, ce qui pourrait l'être, ce qui ne le sera pas. Livrer par petits lots réduit le risque des deux côtés : il voit avancer, je ne construis pas six semaines dans le vide.

Il valide. À l'instant T, je me dis « yes, on va y arriver ».

Combo 4 : indexer le paiement sur les livrables

C'est là que ça s'est arrêté. Quand je lui dis que le paiement suivra les itérations, il refuse. Lui voulait trois tranches calées sur le calendrier, la plus grosse au milieu. En gros : si le projet s'interrompt en cours de route, j'ai travaillé à perte. Le paiement doit suivre les livrables, pas les dates. C'est la seule façon d'aligner les intérêts des deux côtés.

La goutte d'eau

Dernière demande : commencer sans acompte, « pour voir ce que ça donne sur deux semaines ». Donc même pas de quoi sécuriser la toute première itération. L'argument avancé : « avec l'IA, tout est facile et rapide aujourd'hui ».

Ce que l'IA ne fait pas

L'IA accélère le code. Elle ne remplace ni le cadrage, ni la confiance, ni le respect du travail. Un cahier des charges ambigu produit exactement le même projet raté qu'avant, simplement plus vite.

Refuser un projet, ce n'est pas perdre un client. C'est protéger son temps, son énergie, et la qualité de ce qu'on livre ailleurs.

Bonus : les questions que je pose à un cahier des charges

C'est ma checklist de shift-left testing sur les specs. Elle ne couvre pas tout, mais si un document ne répond à aucune de ces questions, vous savez déjà comment le projet va se passer.

Les parcours

1. Que se passe-t-il si l'utilisateur abandonne au milieu d'un parcours (inscription, commande, paiement) ? Reprend-il où il s'était arrêté ?
2. Que voit-on quand il n'y a rien à afficher : liste vide, aucun résultat de recherche, historique vierge ?
3. Quel est le comportement attendu en cas d'échec : paiement refusé, fichier trop lourd, connexion perdue en cours d'envoi ?

Les droits

4. Qui a le droit de créer, modifier, supprimer quoi ? Et qui peut voir quoi ?
5. Que devient le contenu d'un utilisateur supprimé ou désactivé ?

Les données

6. Quelles données sont obligatoires, lesquelles sont facultatives, et qu'affiche-t-on quand une donnée facultative manque ?
7. Y a-t-il des limites : longueur des textes, taille des fichiers, nombre d'éléments ? Que se passe-t-il quand on les atteint ?

Le périmètre

8. Pour chaque fonctionnalité : est-elle indispensable au lancement, ou peut-elle attendre une itération suivante ?
9. Qu'est-ce qui est explicitement hors périmètre ? (La question qui évite le plus de conflits en fin de projet.)
10. Comment saura-t-on que le projet est terminé ? Quel est le critère d'acceptation de chaque livrable ?

Un cahier des charges qui répond à ces dix questions n'existe presque jamais au premier jet. Ce n'est pas grave : c'est précisément à ça que sert la phase de cadrage. Le problème, c'est de coder sans avoir posé les questions.