Définition du POC
Un POC, de l'anglais proof of concept ou preuve de concept, est une réalisation limitée et jetable destinée à vérifier qu'une hypothèse technique précise tient. Il répond à une question fermée : cette interface se connecte-t-elle ? ce volume de données passe-t-il ? ce modèle atteint-il la qualité attendue ? Il ne cherche ni à être complet, ni à être utilisable, ni à être conservé.
Le mot circule aussi hors informatique, où il désigne plus largement une démonstration de faisabilité. Dans un projet digital, il vaut mieux lui garder son sens étroit : sans question fermée écrite au départ, un POC devient un développement sans périmètre.
Ce qu'un POC doit prouver, et rien d'autre
Un POC se cadre par une seule phrase, écrite avant d'écrire la moindre ligne de code : « à la fin, nous saurons si… ». Si cette phrase ne tient pas en une ligne, ce n'est pas un POC.
Ce qu'il ne prouve pas mérite d'être dit aussi clairement, parce que c'est là que naissent les malentendus avec la direction : un POC ne prouve pas la tenue en charge, ni la sécurité, ni le coût d'exploitation, ni l'adoption par les utilisateurs, ni la maintenabilité du code. Il a été construit pour aller vite, au prix de tout le reste.
POC, prototype, MVP, pilote
Ces quatre mots sont employés l'un pour l'autre dans presque toutes les réunions, et ils ne désignent ni le même objet, ni le même public, ni le même sort après usage.
| Objet | Question posée | Pour qui | Devient quoi ensuite |
|---|---|---|---|
| POC | Est-ce techniquement possible ? | L'équipe technique | Jeté |
| Prototype | À quoi cela ressemble-t-il ? | Les utilisateurs, la direction | Jeté, ses enseignements gardés |
| MVP | Quelqu'un s'en sert-il vraiment ? | De vrais utilisateurs | Gardé et enrichi |
| Pilote | Cela tient-il dans nos conditions réelles ? | Un périmètre restreint en production | Généralisé ou arrêté |
La ligne qui compte est la dernière colonne. Un POC est fait pour être jeté ; un MVP est fait pour être gardé. Décider lequel on construit change le budget, l'exigence de qualité du code et la façon de le chiffrer.
Comment le cadrer pour qu'il se termine
- Une question, écrite, fermée. Elle tient en une ligne et admet une réponse oui ou non.
- Un critère de réussite chiffré ou observable, posé avant de commencer. Sans lui, le POC réussit toujours, parce qu'on ajuste l'objectif au résultat.
- Une durée ferme et courte. Un POC qui dure ne prouve plus rien : il devient un projet sans cahier des charges.
- Une décision prévue à la fin, avec la personne qui la prendra. On continue, on modifie l'approche, ou on arrête : les trois doivent être des issues acceptables avant de commencer.
- Un budget séparé de celui du projet. Mélanger les deux fait disparaître la possibilité d'arrêter.
Ce cadrage se documente comme le reste du projet : une page suffit, et elle s'inscrit naturellement dans le cahier des charges en amont du développement.
Le piège du POC qui part en production
C'est l'accident le plus courant, et il a une logique imparable : le POC marche, la démonstration a convaincu, la direction demande pourquoi refaire ce qui fonctionne déjà. Le code part alors en production avec des raccourcis assumés au départ : clés d'accès en clair, absence de gestion d'erreur, données de test, aucune sauvegarde.
La parade se pose avant, pas après : dire dès le lancement que le code sera jeté, et budgéter la réalisation réelle dans la même décision. Le sujet est traité en détail pour les projets d'intelligence artificielle, où il est devenu la règle plutôt que l'exception, dans mettre un prototype IA en production.
