Guide pratique · Genitechs
Préparer un projet d’application sur mesure.
Un bon cahier de besoins décrit le travail à accomplir, les utilisateurs, les données et les contraintes. Il permet de comparer des propositions portant sur le même périmètre, avant de choisir une technologie.
Publié le 4 octobre 2026
Décrire le travail avant les fonctionnalités
Décrivez une situation actuelle et le résultat souhaité. Par exemple, une équipe reçoit des demandes par courriel, les recopie dans un tableur et relance les responsables manuellement. Une application pourrait centraliser l’entrée, l’attribution et le suivi. Il s’agit d’un exemple illustratif, pas d’un cas client.
Identifiez les utilisateurs et leurs responsabilités : qui crée une demande, qui la traite, qui approuve et qui consulte les résultats? Ces rôles déterminent les parcours et les permissions.
Choisir entre logiciel existant, configuration et sur mesure
| Option | À considérer lorsque | Questions à poser |
|---|---|---|
| Logiciel existant | Le processus correspond aux fonctions disponibles | Quel est le coût total et quelles sont les limites? |
| Configuration ou plateforme à faible code | Les adaptations restent dans les capacités de la plateforme | Qui maintient la solution et où sont les données? |
| Application sur mesure | Le processus ou les intégrations demandent un contrôle particulier | Quel périmètre justifie le développement et la maintenance? |
Définir une première version utile
Séparez les fonctions nécessaires au fonctionnement du processus des améliorations qui peuvent attendre. Une première version doit permettre de réaliser un travail complet, même si certains cas restent manuels.
Décrivez les exclusions. Une intégration, une migration de données, un rapport ou une application mobile ne sont pas inclus simplement parce qu’ils semblent liés au projet. Leur portée doit être explicite.
Valider les intégrations et la migration
Pour chaque système à relier, identifiez son propriétaire, les API disponibles, les permissions, les formats de données et les limites d’utilisation. Choisissez la source de référence quand deux systèmes contiennent une même information.
Si des données doivent être migrées, prévoyez leur nettoyage, un essai de migration, des contrôles de rapprochement et une procédure de reprise. L’accès réel aux systèmes doit être confirmé avant de figer les engagements de réalisation.
Comprendre ce qui influence le coût
Le nombre de parcours, les règles métier, les intégrations, la qualité des données, les exigences d’accès et les essais influencent l’effort. Le nombre de pages à l’écran est rarement une mesure suffisante.
Demandez de distinguer le développement initial des coûts récurrents : hébergement, licences, maintenance, surveillance et soutien. Comparez aussi les livrables, les hypothèses et les responsabilités plutôt que le prix seul.
Préparer l’acceptation et l’exploitation
- Scénarios d’essai et critères d’acceptation convenus.
- Responsables de la validation et du lancement.
- Droits sur le code et conditions de transfert précisés au contrat.
- Documentation et accès nécessaires à l’exploitation.
- Responsabilités de sauvegarde, de maintenance et de soutien.
- Procédure pour signaler une anomalie et demander une évolution.
Un canevas de demande en six points
- Contexte : quel problème cherchez-vous à résoudre?
- Utilisateurs : qui réalise le travail et qui l’approuve?
- Processus : quelles sont les principales étapes et exceptions?
- Systèmes : quels outils et quelles données sont concernés?
- Contraintes : budget, échéances, accès et exigences internes.
- Résultat : comment saurez-vous que la première version est utile?