Le problème n'est pas qu'un Proof of Concept échoue. Le problème, c'est qu'il rassure parfois à tort.
Dans de nombreuses entreprises, le Proof of Concept est présenté comme une étape destinée à réduire les risques avant un développement logiciel sur mesure. Pourtant, certains POC produisent l'effet inverse : ils donnent l'impression que le projet est prêt à passer en production, alors que les principales incertitudes n'ont pas encore été levées.
Cette confusion ne vient pas du Proof of Concept lui-même, mais de ce que l'on attend de lui. Un POC n'a jamais eu pour vocation de démontrer qu'un projet sera un succès. Son rôle est beaucoup plus précis : apporter des éléments de preuve sur une hypothèse clairement identifiée afin d'éclairer une décision.
Lorsqu'il est utilisé pour répondre à des questions qu'il ne peut pas trancher, le Proof of Concept cesse d'être un outil d'aide à la décision. Il devient une démonstration rassurante qui peut conduire à des choix coûteux.
Dans cet article, nous verrons pourquoi certains Proof of Concept ne tiennent pas leurs promesses et comment des erreurs pourtant fréquentes peuvent les détourner de leur véritable mission : éclairer la décision.
Pourquoi un Proof of Concept ne peut pas tout démontrer
Dans de nombreuses entreprises, le Proof of Concept est perçu comme une étape capable de répondre à toutes les questions d'un projet. Si le POC est concluant, le projet est considéré comme viable. S'il échoue, l'idée est souvent abandonnée.
Cette vision est rassurante, mais elle repose sur une confusion fréquente : celle entre réduire une incertitude et valider un projet.
En réalité, un Proof of Concept ne répond jamais à toutes les questions. Il est conçu pour lever une incertitude précise, dans un périmètre volontairement limité. Lui demander de démontrer la valeur du projet, son adoption future ou son retour sur investissement revient à lui confier une mission qu'il n'a jamais eu vocation à remplir.
C'est précisément cette confusion qui explique pourquoi certains Proof of Concept donnent une impression de réussite sans pour autant permettre de prendre une meilleure décision.
Les quatre dérives qui empêchent un Proof of Concept de remplir son rôle
1. Le PoC-vitrine
Dans notre précédent article, nous avons suivi une entreprise confrontée à une question que se posent de nombreux dirigeants : notre besoin justifie-t-il réellement le développement d'un logiciel sur mesure ? Après avoir démontré que le projet méritait d'aller plus loin, elle décide de lancer un Proof of Concept afin de réduire les principales incertitudes avant d'investir davantage.
La démonstration se déroule parfaitement.
Les demandes des clients sont correctement classées. Les réponses arrivent en quelques secondes. Les équipes sont convaincues que l'intelligence artificielle est prête à être intégrée au futur logiciel.
Pourtant, le Proof of Concept n'a peut-être pas testé la partie la plus risquée du projet.
Pendant la démonstration, l'IA n'a traité que des demandes simples, bien rédigées et faciles à interpréter. En revanche, personne ne l'a confrontée aux situations qu'elle rencontrera réellement : un client qui mélange plusieurs sujets dans le même message, une demande incomplète, une pièce jointe illisible ou un vocabulaire métier très spécifique.
Le résultat est un PoC convaincant mais uniquement dans les conditions choisies pour la démonstration.
C'est ainsi qu'un Proof of Concept devient parfois un PoC-vitrine. Au lieu de chercher à mettre la solution en difficulté, il met en avant ce qu'elle sait déjà faire. Les cas les plus complexes sont laissés de côté, alors que ce sont précisément eux qui devraient être testés en priorité.
Pourtant, l'objectif d'un Proof of Concept n'est pas de démontrer que la solution fonctionne dans le meilleur des cas. Il est de vérifier qu'elle résistera aux situations qui présentent le plus de risques pour le projet.
Un PoC est généralement développé rapidement, avec un périmètre limité. Une démonstration réussie dans un environnement contrôlé ne permet donc pas, à elle seule, de conclure que la solution fonctionnera dans les mêmes conditions une fois déployée.
La qualité d'un Proof of Concept ne se mesure donc pas à sa capacité à impressionner pendant une démonstration, mais à sa capacité à révéler ce qui pourrait réellement compromettre la réussite du projet.
Le Proof of Concept est concluant. Les équipes sont rassurées et souhaitent désormais passer à l'étape suivante. C'est à ce moment qu'apparaît une nouvelle dérive.
2. Le PoC recyclé
Le Proof of Concept a atteint son objectif. L'intelligence artificielle classe correctement les demandes des clients, y compris dans les situations les plus complexes. Les équipes sont satisfaites et le projet peut désormais entrer dans une nouvelle phase.
Une idée s'impose alors naturellement : pourquoi repartir de zéro alors qu'une première version existe déjà ?
Cette réaction est compréhensible. Réutiliser le PoC semble permettre de gagner du temps, de limiter les coûts et d'accélérer le développement.
Pourtant, c'est souvent une fausse bonne idée.
Un Proof of Concept est conçu pour apprendre rapidement, pas pour servir de fondation au futur logiciel. Certaines décisions techniques sont prises pour aller vite, des contrôles sont volontairement simplifiés et de nombreux compromis sont acceptés parce qu'ils n'ont aucun impact sur l'objectif du test.
Ces choix sont parfaitement adaptés à un PoC. Ils le sont beaucoup moins lorsqu'il s'agit de développer une application destinée à être utilisée pendant plusieurs années.
Microsoft rappelle d'ailleurs qu'un Proof of Concept n'a généralement pas vocation à devenir la première version du produit final. Développé rapidement et avec un périmètre limité, il répond à un objectif d'expérimentation, pas aux exigences de qualité, de sécurité ou de maintenabilité attendues d'un logiciel en production. InfoQ met également en garde contre cette pratique, qui conduit souvent à intégrer dans le projet final un code conçu pour explorer une hypothèse, et non pour durer.
Un bon Proof of Concept produit avant tout de la connaissance. Si son code peut parfois être réutilisé, ce ne doit jamais être l'objectif qui guide sa conception.
3. Le PoC fourre-tout
Dans notre précédent article, nous expliquions pourquoi un besoin récurrent ne justifie pas toujours le développement d'un logiciel sur mesure. L'une des entreprises étudiées envisageait de créer un portail client afin de permettre à ses clients de suivre leurs demandes en toute autonomie. Après avoir confirmé que le projet méritait d'aller plus loin, elle lance un Proof of Concept pour en valider les principales hypothèses identifiées et s’assurer qu'elle sera réellement adoptée par les utilisateurs.
Les premiers retours sont encourageants. Les clients retrouvent facilement leurs informations et les équipes internes constatent une diminution des sollicitations.
Le Proof of Concept aurait pu s'arrêter là. Mais très vite, de nouvelles idées apparaissent.
Le service commercial souhaite que les devis soient accessibles depuis le portail. La comptabilité aimerait y intégrer les factures. Le support propose une messagerie sécurisée. Le marketing imagine un centre de ressources, tandis que la direction demande quelques tableaux de bord.
Individuellement, chaque demande paraît pertinente.
En quelques semaines pourtant, le Proof of Concept ne cherche plus à répondre à une seule question. Il tente de démontrer plusieurs fonctionnalités, plusieurs usages et plusieurs objectifs à la fois.
C'est ce que l'on pourrait appeler un PoC fourre-tout.
Cette évolution est fréquente. Lorsqu'un projet est lancé, chaque équipe voit l'opportunité d'y intégrer ses propres besoins. Le périmètre s'élargit progressivement, jusqu'à rendre le Proof of Concept difficile à interpréter.
Si les résultats sont positifs, qu'a-t-on réellement démontré ? Que les clients utiliseront le portail ? Que la messagerie est pertinente ? Que les tableaux de bord répondent aux attentes ? Ou simplement que certaines fonctionnalités fonctionnent correctement ?
À vouloir répondre à trop de questions, le Proof of Concept finit par n'apporter aucune réponse véritablement décisive.
Les spécialistes du Product Discovery recommandent au contraire de concevoir chaque expérimentation autour d'une hypothèse clairement définie. Plus le périmètre est ciblé, plus les résultats sont faciles à interpréter et plus la décision qui en découle est fiable.
Un bon Proof of Concept ne cherche pas à tout démontrer. Il cherche à lever une incertitude majeure avant de passer à l'étape suivante.
Le périmètre du Proof of Concept est désormais clair et les résultats sont encourageants. Pourtant, une dernière dérive peut encore conduire à une mauvaise décision : croire qu'un PoC concluant signifie que le projet est prêt à être déployé.
4. Le PoC déconnecté de la réalité
Reprenons notre portail client. Le Proof of Concept est concluant. Les utilisateurs testeurs retrouvent facilement leurs demandes, les équipes sont satisfaites et la démonstration confirme que la solution répond bien au besoin identifié.
À ce stade, beaucoup d'entreprises pensent que le plus difficile est derrière elles.
Quelques mois plus tard, le portail est progressivement ouvert à l'ensemble des clients.
C'est à ce moment que les premières difficultés apparaissent.
Certaines données ne sont pas correctement synchronisées avec l'ERP. Les équipes doivent corriger manuellement plusieurs informations. Les clients continuent d'appeler le service support parce qu'ils ne trouvent pas certaines réponses. Ce qui fonctionnait parfaitement pendant le Proof of Concept devient beaucoup plus complexe à gérer à grande échelle.
Pourtant, cela ne signifie pas que le Proof of Concept a échoué.
Au contraire, il a parfaitement rempli sa mission.
Son rôle était de vérifier que le portail répondait au besoin identifié et que les utilisateurs y trouvaient un intérêt. Il n'avait jamais vocation à préparer le déploiement à grande échelle, à définir l'architecture de la solution ou à anticiper toutes les contraintes d'exploitation.
L'erreur ne vient donc pas du Proof of Concept. Elle vient du fait qu'on lui attribue parfois un rôle qui n'est pas le sien.
En considérant qu'un PoC concluant suffit à lancer directement le développement, certaines entreprises sautent des étapes pourtant essentielles : préciser les besoins fonctionnels, concevoir l'architecture de la solution, anticiper les contraintes techniques ou préparer le déploiement.
Chez Keleo, c'est précisément cette transition que nous accompagnons. Le Proof of Concept permet de prendre une première décision. Notre rôle est ensuite de transformer ces enseignements en un projet logiciel réellement viable, en sécurisant les étapes qui suivent avant d'engager un développement plus conséquent.
Un Proof of Concept n'est donc pas une étape à franchir avant un développement logiciel sur mesure. C'est un outil d'aide à la décision.
Bien utilisé, il ne cherche pas à prouver qu'il faut développer un logiciel. Il apporte les éléments de preuve nécessaires pour décider si le projet mérite réellement d'être poursuivi.
Il peut ainsi conduire à une conclusion tout aussi précieuse : qu'une solution existante répond déjà au besoin, qu'une hypothèse mérite d'être approfondie ou que le projet doit être repensé avant d'engager un développement plus conséquent.
Le succès d'un Proof of Concept ne se mesure donc pas au nombre de fonctionnalités démontrées, mais à la qualité des décisions qu'il permet de prendre.
Ce qu'il faut retenir
Un Proof of Concept n'a pas pour objectif de rassurer, de démontrer que le projet réussira ou de répondre à toutes les questions dès le départ.
Son rôle est beaucoup plus précis : réduire une incertitude suffisamment importante pour permettre de prendre une meilleure décision.
C'est précisément pour cette raison qu'un bon Proof of Concept reste volontairement limité. Il teste une hypothèse clairement définie, dans un périmètre maîtrisé et avec des critères de réussite établis à l'avance.
À l'inverse, lorsqu'il cherche à convaincre, à répondre à trop de questions ou à préparer directement le futur logiciel, il s'éloigne progressivement de sa mission.
Un Proof of Concept n'est donc pas une étape à franchir avant un développement logiciel sur mesure. C'est un outil d'aide à la décision.
Bien utilisé, il apporte les éléments de preuve nécessaires pour décider si le projet mérite réellement d'être poursuivi.
Il peut ainsi conduire à une conclusion tout aussi précieuse : qu'une solution existante répond déjà au besoin, qu'une hypothèse mérite d'être approfondie ou que le projet doit être repensé avant d'engager un développement plus conséquent.
Le succès d'un Proof of Concept ne se mesure donc pas au nombre de fonctionnalités démontrées, mais à sa capacité à éclairer la décision qui suit.
Après le POC, décider de la suite
Un bon POC laisse une trace exploitable : une hypothèse, un protocole, des résultats, des limites et une recommandation argumentée.
C’est cette matière qui permet de préparer la suite : poursuivre le développement, organiser un pilote, examiner une solution existante ou renoncer avant d’investir davantage.
Avant de lancer un POC, une question mérite donc d’être posée : quelle décision prendrons-nous différemment grâce à ses résultats ?
Vous envisagez un POC logiciel ou IA ? Découvrez l’accompagnement Prototype & POC IA de Keleo. Un premier échange permet de préciser l’incertitude à tester, les preuves attendues et le périmètre utile de l’expérimentation.