# Quand un POC doit rester un POC
Un POC n’a pas vocation à devenir un produit complet dès les premières semaines.
Son rôle n’est pas de tout prévoir, ni de poser une architecture parfaite. Son rôle est beaucoup plus simple : vérifier qu’une idée mérite d’aller plus loin.
Le risque, c’est de vouloir industrialiser trop tôt un prototype alors que le besoin, l’usage ou la valeur ne sont pas encore confirmés.
Le mauvais réflexe
Transformer trop vite un POC en produit complet peut faire perdre beaucoup de temps.
Quand le parcours utilisateur reste flou, quand la donnée n’est pas encore validée ou quand le budget n’est pas sécurisé, ajouter trop d’abstractions, trop d’écrans ou trop de logique générique peut donner une impression de sérieux, mais pas forcément produire plus de valeur.
On finit parfois avec une base technique plus lourde, alors que la question principale n’a pas encore reçu de réponse : est-ce que ce projet sert vraiment à quelque chose ?
Ce qu’un POC doit prouver
Un bon POC doit rester concentré sur quelques questions essentielles :
- est-ce qu’un usage existe ?
- est-ce qu’une boucle fonctionnelle tient de bout en bout ?
- est-ce que la donnée nécessaire est disponible ?
- est-ce que la valeur est visible rapidement ?
- est-ce que les utilisateurs comprennent l’intérêt du projet ?
- est-ce que les limites principales sont identifiées ?
Le but n’est pas d’avoir un produit parfait. Le but est d’obtenir une réponse claire.
Ce qui peut attendre
Beaucoup de sujets peuvent rester volontairement hors champ au départ.
La généralisation du modèle de données, les abstractions larges, les écrans secondaires, les optimisations fines, les rôles avancés ou les automatisations complexes peuvent attendre.
Tant que le cœur du problème n’est pas confirmé, il vaut mieux garder un périmètre court, lisible et facile à modifier.
Un POC trop propre trop tôt peut devenir un piège : on hésite ensuite à le jeter, même s’il ne répond pas au bon problème.
Le bon moment pour durcir
Le passage du POC au produit commence quand les signaux deviennent concrets.
Quand les usages reviennent. Quand les utilisateurs demandent à s’en servir réellement. Quand les limites techniques commencent à bloquer l’exploitation. Quand les contraintes de sécurité, de performance ou de maintenance deviennent visibles.
À ce moment-là, l’architecture devient un investissement rentable.
Avant cela, le meilleur choix est souvent de rester simple, d’apprendre vite et de ne pas confondre prototype prometteur avec produit déjà validé.