Faisabilité d'une appli interne : la question à poser avant d'écrire un cahier des charges
La plupart des projets d'application interne qui dérapent partagent la même origine : un cahier des charges rédigé avant qu'on ait validé qu'on savait faire ce qu'il demande. Il existe un raccourci.
Résumer cet article avec une IA
Le lien ouvre l'assistant choisi avec une question pré-remplie pointant vers cette page.
La question à poser en premier
Pas « qu'est-ce que je veux ? », mais « qu'est-ce que je veux prouver ? ». Une faisabilité n'a pas pour but de livrer une application finie. Elle a pour but de lever les 2 ou 3 doutes majeurs du projet : accès aux données, volumétrie, adoption utilisateur, intégration à un existant.
Ce qui rentre dans une faisabilité utile
- Un prototype cliquable sur les 2 ou 3 écrans clés
- Un test réel de connexion aux sources de données concernées
- Une estimation de volumétrie et de performance
- Une architecture cible (Power Apps + Dataverse ? SharePoint ? SQL ?)
- Un chiffrage réaliste pour la suite, avec fourchette basse et haute
Ce qui n'y rentre pas
Le design final, les workflows secondaires, l'intégration à tous les systèmes périphériques. Une faisabilité qui essaye de tout couvrir coûte le prix d'un projet complet sans en livrer un.
Le bon moment pour la lancer
Dès qu'un décideur commence à demander « ça coûterait combien ? ». C'est le signal qu'il faut passer d'une conversation à un livrable. Un chiffrage sans faisabilité, c'est du poker.
Cadrer votre projet en 5 jours
Prototype, architecture et chiffrage - de quoi décider en connaissance de cause.
Voir l'offre Faisabilité express →