Quand on demande à une IA de « faire une application pour suivre mes athlètes », elle le fait. Elle produit quelque chose de plausible, avec des menus, des couleurs, des graphiques. Et une semaine plus tard, on ne s'en sert plus, parce qu'elle ne répond à aucune question précise. Le problème n'était pas l'IA : c'était la demande.
Un cahier des charges n'est pas un document technique. C'est la description précise d'un besoin, dans vos mots. Voici la trame en huit sections que les stagiaires remplissent le premier jour de la formation.
1. L'utilisateur
Qui ouvre l'outil, sur quel appareil, à quel moment de la journée. « L'éducateur, sur son portable, le soir après l'entraînement » n'appelle pas le même outil que « l'athlète, sur son téléphone, dans le vestiaire ». Un seul utilisateur pour commencer. Toujours.
2. La décision
La question à laquelle l'outil doit répondre chaque fois qu'on l'ouvre. « Est-ce que quelqu'un a monté trop vite cette semaine ? » « Qui n'a pas refait son test depuis plus de huit semaines ? » Si vous ne pouvez pas l'écrire en une phrase, le périmètre est trop large.
3. Les données saisies
La liste exacte des champs, avec leur type et leurs valeurs possibles : une date, un nombre entre 1 et 10, un choix dans une liste. Moins il y en a, plus l'outil sera utilisé. Cinq champs, c'est bien. Quinze, personne ne saisira.
4. Les calculs
Ce que l'outil calcule à partir des saisies, avec la formule. « Charge = durée × RPE. » « Évolution = (dernier résultat − précédent) / précédent. » C'est la section où l'on découvre qu'on n'avait jamais vraiment défini ce qu'on regardait.
5. Les alertes
Les règles qui déclenchent quelque chose : un seuil, une durée sans saisie, une étape non validée. Et ce qui se passe : une couleur, une ligne en haut de l'écran. Les seuils doivent être modifiables sans refaire l'outil.
6. Les écrans
Un écran par usage, décrit en une phrase et un croquis au crayon. L'écran de saisie, l'écran de lecture, l'écran de groupe. Trois écrans, c'est déjà beaucoup pour un premier outil.
7. Les exports et la sauvegarde
Comment on récupère ses données si l'outil meurt : un export tableur, une sauvegarde en un clic. Cette section est celle qu'on oublie, et celle qui sauve tout six mois plus tard.
8. Les contraintes et le hors périmètre
Les contraintes : fichier unique, hors connexion, données locales, aucune donnée de santé. Et le hors périmètre, écrit noir sur blanc : tout ce que l'outil ne fera pas. C'est la liste qui empêche l'IA — et vous — d'ajouter des fonctions que personne n'a demandées.
Les trois erreurs classiques
- Le logiciel de gestion du club. Adhérents, cotisations, créneaux, suivi, compétitions : cinq outils dans un. Ça ne se construit pas en deux jours, ni en deux mois. On choisit un problème.
- Le champ « au cas où ». Chaque champ facultatif est un champ qu'on ne remplira pas et qui encombrera l'écran. Si vous ne savez pas quelle décision il sert, il sort.
- Tout demander d'un coup. On transmet le cahier des charges, on regarde la première version, on corrige un point à la fois. Une demande de vingt lignes produit un outil qui a raison sur dix-huit, et qu'on ne sait plus corriger.
Pourquoi c'est le document qui compte
L'application est jetable. Le cahier des charges est ce qui dure.
Un outil finit toujours par casser, ou par ne plus convenir. Avec le document, vous relancez la génération et vous obtenez une version neuve, souvent meilleure, en quelques minutes. Sans lui, vous repartez de zéro — ou vous appelez quelqu'un. C'est toute la raison pour laquelle la formation passe une journée entière sur le papier avant de toucher un clavier. La trame complète, avec les questions à se poser à chaque section, fait partie du parcours en ligne.