POC payant

POC payant : Développement court et facturé destiné à lever un doute technique précis avant d’engager le budget complet du projet.

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

Où intervient POC payant dans un projet

POC payant se lit dans un devis ou dans un contrat, rarement dans une démonstration. C’est pourtant à ce niveau que se creuse l’écart entre le budget annoncé et le budget dépensé.

Sur un projet réel, la question ne se pose jamais en théorie : elle arrive dans un devis, dans une réunion de cadrage ou dans un rapport de recette.

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

POC payant se négocie avant la signature, pas pendant la recette. Le cahier des charges est le dernier moment où la formulation peut encore évoluer sans avenant.

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

• Ce que couvre la garantie après la mise en ligne, et sa durée.
• Le contenu du forfait de maintenance, distinct du budget des évolutions.
• Les profils affectés au projet, et leur taux de présence réel.
• Le tarif des évolutions après le lancement, fixé avant la signature.

Le niveau de détail à viser est celui qui permet à deux prestataires différents de chiffrer la même chose. En dessous, les écarts de prix ne veulent rien dire.

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.

Vérifier plutôt que croire

Le contrôle de « POC payant » se fait à chaque jalon, jamais à la fin. Un écart repéré tôt se corrige, un écart repéré tard se subit.

• Vérifier que l’avenant précède les travaux qu’il couvre, jamais l’inverse.
• Contrôler que les accès et les comptes sont ouverts au nom du client.
• Comparer budget engagé et budget initial à chaque jalon, pas à la fin.

Ce qui n’est pas vérifié à la recette ne sera pas vérifié du tout : le jour de la mise en ligne, plus personne n’a le temps.

Erreurs fréquentes

Aucune de ces erreurs ne se voit le jour où elle est commise. Toutes se paient plus tard, au moment le moins commode.

• Oublier la maintenance annuelle dans le budget, puis la découvrir la première année.
• Confondre le prix de fabrication et le coût total de possession de l’application.
• Ne pas prévoir la réversibilité, et se retrouver captif d’un prestataire.
• Bâtir un retour sur investissement sur des hypothèses d’usage jamais vérifiées.
• Repousser l’arbitrage au sprint suivant, autant de fois qu’il y a de sprints.

Termes liés

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

• Cahier des charges
• TJM
• Forfait
• Régie
• MRR

Questions fréquentes

Qu’est-ce que « POC payant » ?

Développement court et facturé destiné à lever un doute technique précis avant d’engager le budget complet du projet. 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.

Quel ordre de budget prévoir ?

Les fourchettes du guide des prix donnent le cadre : 15 000 à 40 000 € HT pour un MVP, 40 000 à 120 000 € HT pour une application d’ambition moyenne, 120 000 à 300 000 € HT pour un projet complexe. Le poste exact dépend du périmètre écrit.

Est-ce que ça se retrouve dans le devis ?

Un devis lisible sépare conception, design, développement, tests, publication et suivi. La grille de lecture des devis détaille poste par poste ce qui doit y apparaître.

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