Le cahier des charges reste le réflexe de nombreux projets logiciels : décrire tout ce que l'outil doit faire, avant d'écrire une seule ligne de code. Sur le papier, c'est rassurant. En pratique, c'est souvent là que le projet se perd.
Pourquoi le cahier des charges déçoit
- Il faut des semaines pour l'écrire, et personne ne le lit en entier.
- Chacun imagine un écran différent derrière la même phrase.
- Les vrais besoins apparaissent à l'usage, donc trop tard.
- Chaque oubli devient un avenant, donc un surcoût.
| Cahier des charges | Prototype d'abord | |
|---|---|---|
| Avant de voir l'outil | Plusieurs semaines | 72 h |
| Ce que vous validez | Un document | Un outil qui marche |
| Les oublis | Découverts à la livraison | Corrigés sur le prototype |
| Le prix | Avenants possibles | Ferme, après validation |
La méthode « prototype d'abord »
- 30 minL'appel
Vous montrez vos fichiers et vos irritants.
- 72 hLe prototype
Vous cliquez dans votre futur outil.
- EnsuiteLe prix ferme
Basé sur ce que vous avez vu.
- 1 à 8 semainesLa mise en service
Données reprises, équipe formée.
Le prototype devient le cahier des charges. Il ne décrit pas l'outil : il le montre. Vous corrigez un écran, pas un paragraphe. Et le devis qui suit chiffre exactement ce que vous avez vu.
Ce qu'il faut quand même préparer
- Vos fichiers actuels : Excel, Word, formulaires, même imparfaits.
- Les trois irritants qui vous font perdre le plus de temps.
- Qui utilisera l'outil, et avec quels droits.
- Les données sensibles concernées, s'il y en a.
Une page suffit. Le reste se règle en trente minutes d'appel.
Pour comprendre comment un prototype tient en trois jours, lisez le prototype logiciel en 72 h. Et pour le calendrier complet, le délai de développement d'un logiciel sur-mesure.
