Faisabilité

Faisabilité : Appréciation de la possibilité de réaliser une fonctionnalité dans les délais, le budget et les contraintes techniques du projet.

Cette entrée du glossaire relève de la famille « Produit et UX ». Elle donne la définition, sa traduction en exigences, et les erreurs vues le plus souvent sur des projets réels.

À quoi sert Faisabilité

Faisabilité décrit une réalité observable du côté de l’utilisateur. On peut donc s’en assurer autrement qu’à l’intuition, ce qui met une équipe d’accord plus vite qu’un débat d’opinion.

Ce que le mot recouvre exactement dépend du projet. Ce qui suit vaut pour la plupart des applications mobiles françaises, et sert de point de départ à la discussion.

La traduction en exigences

Dans un cahier des charges, ce qui relève de « Faisabilité » se décrit par des écrans, des rôles, des règles ou des indicateurs, jamais par une intention. Une phrase sans critère de recette ne se chiffre pas.

À écrire noir sur blanc, dans le chapitre qui correspond :

• Les rôles utilisateurs, et ce que chacun a le droit de faire.
• Les écrans concernés, listés, avec leur état vide et leur état d’erreur.
• Ce qui est explicitement hors périmètre de la version 1.
• Les contenus fournis par le client, et la date à laquelle ils arrivent.

Une exigence bien écrite tient en trois lignes et se refuse en une. Si elle ne peut pas être refusée à la recette, elle n’est pas encore écrite.

Pour le cadre général, le guide des prix donne les fourchettes constatées en France et le modèle de cahier des charges la structure qui les rend opposables.

Les contrôles à prévoir

À la recette, « Faisabilité » se juge sur le parcours complet, pas sur un écran isolé qui fonctionne en démonstration.

• Vérifier chaque état vide et chaque message d’erreur, écran par écran.
• Relire les textes affichés : fautes, jargon interne, phrases tronquées.
• Contrôler ce que voit un utilisateur qui n’a encore aucun contenu.

Un prestataire sérieux propose ces contrôles de lui-même. Quand ce n’est pas le cas, c’est au client de les inscrire au cahier de recette.

Ce qui tourne mal le plus souvent

Sur ce point précis, voici ce qui coûte le plus cher aux porteurs de projet, dans l’ordre où on le rencontre.

• Décrire une fonctionnalité par une intention plutôt que par des écrans et des règles.
• Oublier les cas qui vont mal : liste vide, erreur réseau, droits insuffisants.
• Confondre l’avis de trois collègues et un test auprès de vrais utilisateurs.
• Laisser le back-office hors du cahier des charges, alors qu’il pèse lourd dans le chiffrage.
• Reprendre la formulation d’un autre projet sans vérifier qu’elle décrit bien celui-ci.

Termes liés

Les entrées du glossaire déjà publiées sur des sujets voisins :

• MVP
• Onboarding
• Churn
• Wireframe
• User story

Questions fréquentes

Que signifie « Faisabilité » ?

Appréciation de la possibilité de réaliser une fonctionnalité dans les délais, le budget et les contraintes techniques du projet. Cette définition suffit pour une discussion de cadrage. Pour un contrat, il faut y ajouter ce que le terme recouvre exactement sur votre application.

Faut-il tout traiter dès la version 1 ?

Non, et c’est le principal levier de budget. Ce qui compte est d’écrire ce qui est repoussé, pour que la version 1 reste défendable et que la suite reste chiffrable.

Où placer ce point dans le cahier des charges ?

Dans le chapitre qui correspond à sa nature, jamais dans une ligne fourre-tout. Le modèle de cahier des charges propose les rubriques attendues et l’ordre dans lequel les remplir.

Toutes les définitions publiées sont rassemblées dans l’index du glossaire, classées de A à Z et par famille.