Risque projet

Risque projet : Événement identifié qui pourrait compromettre le résultat attendu, consigné au cadrage avec la parade envisagée.

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.

Où intervient Risque projet dans un projet

Risque projet appartient au langage commun du client et de l’équipe de conception. C’est souvent le premier mot qui manque quand une recette tourne au malentendu.

Le sujet se présente rarement seul. Il arrive au milieu d’une décision plus large, et c’est à ce moment qu’il faut savoir de quoi on parle.

De la définition à la ligne de cahier des charges

Un cahier des charges qui traite « Risque projet » sérieusement décrit aussi les cas qui vont mal : état vide, erreur, connexion perdue, droits insuffisants. C’est un tiers du travail réel.

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

• Le parcours principal, décrit du premier lancement à la première action utile.
• Les critères d’acceptation, rédigés de manière à pouvoir être refusés.
• Le nombre d’allers-retours de maquettes inclus dans le prix.
• Le niveau d’accessibilité visé, et les écrans sur lesquels il est vérifié.

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.

Le modèle de cahier des charges du guide reprend ces rubriques dans l’ordre attendu par une agence, et la grille de lecture des devis montre à quoi ressemble un chiffrage comparable.

Comment le vérifier à la recette

Ce qui touche à « Risque projet » se vérifie avec un utilisateur qui découvre l’application, pas avec celui qui l’a spécifiée.

• Reprendre les critères d’acceptation et les cocher un par un, sans indulgence.
• Utiliser l’application sur un petit écran, d’une seule main.
• Comparer les maquettes validées au résultat livré, écran par écran.

Ces vérifications s’inscrivent au cahier de recette, avec un nom en face de chacune. Une case sans responsable reste vide.

Erreurs fréquentes

Les mêmes causes reviennent d’un projet à l’autre, quel que soit le prestataire et quelle que soit la taille du budget.

• 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

Risque projet : de quoi parle-t-on exactement ?

Événement identifié qui pourrait compromettre le résultat attendu, consigné au cadrage avec la parade envisagée. La définition tient en une phrase, son application dépend du projet. C’est pour cette raison qu’elle doit figurer dans le cahier des charges plutôt que dans un échange de courriels.

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.