Le PoC qui va en prod, pas la démo qui reste au tiroir

La plupart des PoC ne vont jamais en production. Ils sont construits, présentés, applaudis en comité de pilotage, puis dorment dans un dépôt que plus personne n'ouvre, parce que le contrat qui les finançait visait surtout la vente, pas la preuve. On vend l'inverse : un PoC qui est soit rejeté vite et à moindre coût, soit qui part directement en production parce qu'il a été construit comme du code de production dès le premier jour, sur vos vraies données, sans bouton de reset invisible caché de l'autre côté.

Pourquoi la plupart des PoC sont du théâtre

Un PoC financé par un éditeur porte un conflit d'intérêt structurel : l'équipe qui le construit est payée pour faire briller la plateforme, pas pour répondre honnêtement à votre vraie question. Il tourne en général sur un échantillon de données trié, évite vos pires cas d'intégration, et est présenté par les mêmes personnes qui ont besoin de votre signature le trimestre suivant. Rien de malveillant là-dedans, c'est juste ce qui arrive quand le succès du PoC et le revenu de l'éditeur sont le même événement.

Notre règle : un PoC est une décision, pas un argument de vente

On est payés pour la prestation, que la réponse soit oui ou non. Ça change ce qu'on construit : de vraies données issues de vos systèmes, pas un échantillon trié ; les deux ou trois cas les plus risqués de votre process, pas les plus faciles ; et du code écrit au niveau qu'il aurait besoin d'avoir si vous décidiez de le garder, pas une démo jetable. S'il fonctionne, vous avez déjà absorbé la majorité du risque qu'une construction complète aurait révélé plus tard, à un coût bien plus élevé.

Sans lock-in, par construction

Le code du PoC vous appartient dès la livraison, point final. Pas de runtime propriétaire qu'il faudrait continuer à louer, pas de noyau obscurci que seuls nous pouvons toucher, pas de dépendance conçue pour rendre le départ coûteux. Ce n'est pas de la générosité, c'est la seule façon pour un PoC d'être un instrument honnête : si partir vous coûte quelque chose, le résultat cesse d'être une vraie réponse et devient un otage.

Ce qui se passe après un PoC qui fonctionne

• Vous l'exploitez vous-même. Le code et la documentation suffisent à une équipe interne pour prendre le relais, c'est le cas par défaut qu'on conçoit, pas une exception qu'on décourage.
• Vous le confiez à un autre prestataire. Rien dans la construction n'est écrit pour rendre ça plus difficile que nécessaire.
• Vous nous demandez de continuer à construire. On chiffre la phase de production séparément, avec ses propres standards, parce qu'un PoC et un système de production ne sont pas le même livrable et ne devraient pas être facturés comme tels.

Rapidité voulue, pas négligence par accident

Un PoC met volontairement de côté certaines pratiques de niveau production, gestion d'erreurs exhaustive, tests complets, documentation soignée, parce que l'objectif est de répondre vite à une question, pas de livrer un système que vous ferez tourner pendant des années. C'est un arbitrage cadré qu'on fait exprès et qu'on vous annonce à l'avance, pas un raccourci qu'on cache. Le développement assisté par l'IA rend cet arbitrage plus favorable chaque trimestre : ce qui prenait des semaines d'échafaudage prend désormais des jours, ce qui explique pourquoi un PoC rapide et jetable redevient une première étape réaliste, plutôt qu'un luxe réservé aux gros budgets.

Comment distinguer un vrai PoC d'un piège commercial

• Demandez ce qui arrive au code si vous partez. Si la réponse honnête implique une licence, un runtime hébergé, ou « il faudrait le reconstruire », ce n'est pas un PoC, c'est un essai gratuit.
• Demandez s'il tourne sur vos vraies données ou un échantillon trié. Un PoC qui évite vos cas les plus moches ne teste pas ce que vous avez vraiment besoin de savoir.
• Demandez qui est payé si la réponse est non. Si le seul chemin vers le paiement passe par un oui, l'incitation est déjà cassée avant même le premier jour.

Questions fréquentes

Qu'est-ce qui compte comme PoC ici, un jeu de slides ou du code qui tourne ?

Du code qui tourne, connecté à de vraies données de vos systèmes, pas un jeu de données factice. Un PoC qui ne fonctionne que sur un dataset fictif ne prouve rien sur votre vrai risque d'intégration. S'il fonctionne, il est déjà à mi-chemin de la production.

Si le PoC fonctionne, suis-je obligé de continuer avec vous ?

Non. Le PoC est une prestation livrée et facturée, pas un pied dans la porte. Une fois terminé, le code et la décision vous appartiennent : l'exploiter vous-même, le confier à votre équipe, ou nous demander de continuer à construire. Les trois sont des issues normales pour nous.

Si le PoC échoue, je paie quand même ?

Vous payez le travail de le construire et de le tester honnêtement, ce qui a une vraie valeur même quand la réponse est non. Ce que vous ne payez pas, c'est une garantie de résultat positif, personne ne peut vendre ça honnêtement. Un PoC qui révèle un vrai blocage tôt coûte souvent moins cher qu'une construction complète qui le découvre plus tard.

Mettre les bonnes pratiques de côté pour aller vite, ça ne crée pas de dette technique ?

Pour un PoC, oui, et c'est le bon arbitrage à ce stade : l'objectif est de répondre vite à une question, pas de livrer un système maintenable. Si la réponse est oui et que vous passez en production, c'est une phase distincte avec ses propres standards, tests, gestion d'erreurs, documentation, qu'on cadre et chiffre séparément.