Preuve de concept : le guide du fondateur non-technique pour la PoC

Un fondateur que nous étions en train de connaître a reçu un devis de 40 000 € pour une PoC. Le périmètre disait “valider la faisabilité technique de la plateforme”. Quatre semaines, trois personnes, une présentation finale.

Il voulait savoir ce qu’était une PoC. Moi, je voulais savoir pourquoi le chèque avait la taille d’un MVP entier.

C’est ici que vit la confusion. Une PoC, ou preuve de concept (de l’anglais proof of concept), est une expérience courte et peu chère qui répond à une seule question technique : “est-ce que c’est possible, et à quel coût ?”. Ce n’est pas un produit. Ce n’est pas un prototype. Ce n’est pas un MVP. C’est un exercice de réduction de risque que vous menez avant d’engager le budget de tout un projet. Chez un prestataire sérieux, elle dure entre une et trois semaines, coûte entre 3 000 € et 20 000 €, et le livrable principal n’est pas du joli code. C’est de la connaissance.

Si vous êtes fondateur non-technique et que quelqu’un vous propose une PoC, ce guide existe pour vous expliquer ce que vous achetez réellement, quand cela vaut le coup de payer, et quand le mot “PoC” est devenu une façon polie de vous facturer la propre courbe d’apprentissage du prestataire.

La PoC, en une phrase

Une PoC répond à une question technique à laquelle personne dans votre salle ne peut répondre avec assurance. Trois exemples de ce à quoi ressemble cette question, dans le monde réel :

• “Peut-on synchroniser les données de l’ancien système de la clinique avec notre app sans réécrire le legacy ?”
• “Ce modèle d’IA peut-il lire les factures de nos fournisseurs avec plus de 95 % de précision ?”
• “L’API DSP2 supporte-t-elle le cas d’usage que nous avons promis au client pilote ?”

Chacune est une question fermée : la réponse est “oui”, “non”, ou “oui, mais”. La PoC existe pour atteindre cette réponse en quelques jours, avec du code jetable, avant que le budget du projet entier ne soit en jeu. Quand la question n’est pas fermée (quand elle est en fait “le client veut-il ça ?” ou “le marché paiera-t-il pour ça ?”), vous n’avez pas besoin d’une PoC. Vous avez besoin d’autre chose, et la section suivante désambiguïse laquelle.

PoC, MVP, prototype, spike : la carte rapide

Quatre mots, quatre instruments différents, et le vocabulaire du marché les mélange tous. Le résumé honnête :

• PoC. Valide une hypothèse technique. Répond à “est-ce possible ?”. Code jetable. Audience : l’équipe produit et ingénierie. Ne va pas au client.
• Prototype. Valide une hypothèse de design. Répond à “les gens comprennent-ils cette interface ?”. Peut être statique dans Figma ou cliquable. Va vers des utilisateurs en test, pas en production.
• MVP. Valide une hypothèse business. Répond à “quelqu’un l’utilise, quelqu’un paye ?”. C’est un produit petit, mais c’est un produit : il va vers de vrais clients, dans le vrai monde, avec de vraies données. C’est la phase pour laquelle la plupart du travail de discovery produit sert de préparation.
• Spike. C’est la version plus petite de la PoC, généralement dans un seul sprint, sans livrable formel. L’équipe plonge dans une question technique pendant 2 à 5 jours et revient avec une recommandation. Martin Fowler décrit le pattern en une page, à lire.

Quand on vous propose une PoC et que le périmètre se lit comme “nous allons construire une première version du produit”, vous ne regardez pas une PoC. Vous regardez un MVP avec le nom changé, et le prix le confirme presque toujours.

Ce qu’une PoC sérieuse livre vraiment

La livraison d’une PoC utile a quatre composants, et l’absence de l’un d’eux est un signe que le travail n’a pas été fait avec rigueur :

1. Un rapport qui dit “oui”, “non” ou “oui, mais”. En une ou deux pages. Avec la question d’origine en haut et la réponse au deuxième paragraphe. Si vous devez lire 30 slides pour comprendre le verdict, ce n’est pas un rapport, c’est une défense de budget.
2. Le code (ou les artefacts) utilisés pour arriver à cette réponse. Même jetable, il reste dans votre repo. Vous l’avez payé ; il est à vous. Si le prestataire dit “le code reste chez nous”, c’est un signe que quelque chose ne va pas, et le meilleur moment pour le découvrir, c’est maintenant. C’est l’un des points qui sépare un contrat de développement logiciel sérieux d’un template téléchargé sur internet.
3. Une liste honnête de ce qui a été laissé de côté. Toute PoC coupe les coins. Performance, sécurité, cas extrêmes. La livraison doit nommer ce qui a été sauté, pour que personne ne lise le “oui” du rapport comme “prêt à passer à l’échelle”.
4. Une estimation mise à jour du projet qui suit. Fourchette d’heures, fourchette de risque, fourchette de coût. Toute la raison d’être de la PoC, c’est que l’estimation d’avant était un pari. Après, le pari doit se resserrer.

Notez ce qui n’est pas dans la liste : écrans finalisés, documentation technique complète, manuel utilisateur, vidéo promotionnelle. Une PoC ne livre pas tout ça. Si la proposition promet tout cela pour 40 000 € en quatre semaines, quelqu’un va finir déçu, et historiquement c’est le fondateur.

Quand une PoC a du sens pour le fondateur non-technique

Il y a quatre scénarios où il vaut la peine de payer pour une PoC avant le projet principal. En dehors d’eux, c’est en général du gaspillage :

1. Le projet dépend d’une intégration que personne dans votre équipe n’a jamais faite. DSP2, ERPs hospitaliers legacy, systèmes de greffe, APIs d’assureurs santé. Si la viabilité du produit dépend du fonctionnement de cette intégration, et que personne ne peut vous le garantir sur le papier, la PoC sort moins chère que de découvrir le problème à mi-chemin du projet.

2. Le cas d’usage dépend d’un modèle d’IA atteignant un niveau de qualité spécifique. “Extraire la donnée X du document Y avec 95 % de précision” est une question de PoC. “Construire une plateforme d’IA” ne l’est pas. Quand la viabilité du produit dépend d’une métrique quantitative d’un modèle, validez cette métrique d’abord, isolée, avant de construire l’interface autour.

3. L’architecture proposée a une décision à six chiffres intégrée. Microservices ou monolithe ; base de données relationnelle ou de graphes ; cloud A ou cloud B. Quand le mauvais choix au départ coûte cher à inverser plus tard, une PoC concentrée sur la comparaison de deux chemins rembourse son propre coût dix fois.

4. Vous avez besoin de munition factuelle pour une conversation avec un investisseur ou un client pilote. “Oui, l’intégration avec l’ERP du client est faisable ; voici le rapport technique” est un argument différent de “on pense que c’est faisable”. Quand le cycle commercial est conditionné à un signal technique, la PoC achète ce signal.

Quand “PoC” est devenu autre chose

Le mot est aussi utilisé avec d’autres significations, et le fondateur non-technique doit reconnaître chacune pour ne pas payer pour la mauvaise :

PoC comme “MVP pas cher”. Le prestataire appelle PoC ce qui est, en pratique, la première version du produit. C’est généralement une façon de baisser le prix d’entrée du projet, ou de fermer une vente en cycle court. Il n’y a pas de problème à acheter une petite première version. Il y a un problème à l’appeler PoC, parce que le vocabulaire change les attentes : une PoC est jetable, un MVP est fondation. Si vous pensez valider la faisabilité et qu’en réalité vous construisez une fondation, vous allez prendre des raccourcis dangereux.

PoC comme “diagnostic payant”. Courant dans les projets d’IA générative en 2025 et 2026. Le prestataire facture pour découvrir si la technologie qu’il vend marche dans votre cas. Sur certains marchés, c’est raisonnable. Sur d’autres, c’est vous facturer la propre courbe d’apprentissage du prestataire. La différence est de savoir qui repart propriétaire de la connaissance à la fin : vous, ou eux.

PoC comme “discovery déguisée”. Quand ce dont le projet a réellement besoin, c’est de comprendre le problème de l’utilisateur, de cartographier les processus, de mener des entretiens, et que le prestataire l’emballe en PoC pour éviter le mot “conseil”. C’est une discovery, elle vaut la peine d’être faite, mais le vocabulaire correct compte : discovery et PoC ont des livrables et des équipes différentes.

Le test en quatre questions avant d’approuver une PoC

Avant de signer, lisez le périmètre de la PoC proposée et répondez à ces quatre questions. Si vous ne pouvez pas répondre à trois d’entre elles, arrêtez et renvoyez le document :

1. Quelle est, en une phrase, la question à laquelle cette PoC répond ? Si la réponse est “valider la faisabilité technique de la plateforme”, le périmètre est flou. Vous voulez “valider si l’on peut synchroniser les données du système X avec notre système Y dans un SLA de 5 minutes”. Spécifique. Fermée. Vérifiable.

2. Quel est le critère de “oui” et celui de “non” ? La PoC devrait décrire, avant de commencer, ce qui compte comme succès et ce qui compte comme échec. “Plus de 95 % de précision” est un critère. “Présenter des résultats prometteurs” n’en est pas un. Sans critère, n’importe quel résultat devient “oui”.

3. Qu’est-ce qui vous reste à la fin ? Code, rapport, données, ou juste une présentation ? Qui est propriétaire du code ? Où est-il stocké ? Si le prestataire ne répond pas à ces questions de façon directe, la PoC est vendue comme un service, pas comme un livrable.

4. Si la PoC donne “non”, qu’est-ce qui change dans votre étape suivante ? Si la réponse est “on avance quand même”, vous n’avez pas besoin d’une PoC. Vous avez besoin du courage de commencer et de la discipline d’ajuster le cap. Une PoC n’a de sens que si son résultat peut vous faire arrêter.

Combien ça coûte, combien de temps ça prend, qui doit le faire

Fourchettes honnêtes, de ce que l’on voit chez des prestataires sérieux pour du logiciel sur mesure en 2026 :

• Durée. Une à trois semaines. Au-dessus de quatre, ce n’est plus une PoC, c’est un projet. En dessous d’une, c’est probablement un spike et cela ne nécessiterait même pas un budget séparé.
• Coût. Entre 3 000 € et 20 000 €, la majorité des cas sains se situant entre 6 000 € et 12 000 €. Des PoC à 40 000 € ou plus existent (intégrations complexes, régulation), mais la barre de justification monte vite.
• Équipe. Une à trois personnes. Typiquement un ingénieur senior qui prend les décisions techniques, éventuellement un spécialiste (sécurité, IA, données), et un mi-temps d’une personne produit qui rédige le rapport.
• Qui doit le faire. Idéalement la même équipe qui mènerait le projet entier ensuite, ou une équipe qui va remettre la recommandation à une autre équipe pour l’exécuter. Ceux qui ont fait la PoC ont le contexte ; ceux qui ont seulement lu le rapport vont inventer la moitié de ce qu’ils croyaient savoir. C’est l’une des raisons pour lesquelles le staff augmentation est rarement le bon modèle pour une PoC : le contrat se termine et la connaissance part avec la personne.

Si votre proposition tombe en dehors de ces fourchettes, demandez pourquoi. La réponse peut être légitime (réglementation bancaire, intégration avec un système d’État, équipe spécialisée). Ou elle peut être que vous payez un MVP au prix d’une PoC, et que le vocabulaire a été calibré sur ce qui rentrait dans le budget.

Questions fréquentes

PoC et preuve de concept, c’est la même chose ?
Oui. PoC est le sigle en anglais de proof of concept, traduit par “preuve de concept”. Le marché tech français utilise les deux formes, parfois dans la même phrase. Pas de différence de sens.

Que signifie POC en dehors du contexte logiciel ?
Le sigle apparaît ailleurs et brouille la recherche. En BTP, “POC” peut être une mesure d’avancement de chantier (percentage of completion). En médecine, c’est “point of care”, soit le point de soins. Ce guide ne traite que de la PoC logicielle.

PoC, MVP ou prototype : par lequel commencer ?
Cela dépend de la question à laquelle vous avez besoin de répondre. Si le doute est technique (“est-ce possible ?”), commencez par la PoC. Si le doute est sur le design (“les gens comprennent-ils ça ?”), commencez par le prototype. Si le doute est sur le marché (“est-ce que quelqu’un paye ?”), sautez directement au MVP. Aucun des trois n’est “antérieur” aux autres : ce sont des instruments pour des questions différentes.

Puis-je sauter la PoC et aller directement au projet ?
Oui, et dans la plupart des cas c’est ce qui a du sens. La PoC ne vaut le coup que quand il y a une incertitude technique réelle qui peut tuer le projet et qu’il sort cher de découvrir plus tard. Si votre produit est une version de quelque chose qui existe déjà, sur une stack connue, la PoC devient du théâtre de processus.

Combien de temps dure une PoC d’IA ?
Même règle que les autres : une à trois semaines pour répondre à une question spécifique et fermée. Les PoC d’IA qui durent deux mois ne valident généralement pas une hypothèse ; elles construisent un produit sans dire que c’est le produit.

Le code de la PoC va-t-il devenir la base du produit ?
Non, et c’est la partie la plus difficile à accepter. Le code d’une PoC est optimisé pour la vitesse de réponse, pas pour la maintenance. La majeure partie sera jetée quand le projet commencera. Ce qui reste, c’est l’apprentissage, consigné dans le rapport et dans la tête des personnes impliquées. Si un prestataire vous promet que le code de la PoC “sera réutilisé à 80 % pour le produit”, méfiez-vous : soit la PoC va se transformer en un mauvais MVP, soit le produit héritera de raccourcis qui paraissaient peu chers sur le moment et qui restent chers pour toujours.