« On a déjà un prototype, on veut juste que tu nous aides à le déployer. » J'entends cette phrase régulièrement. Dans presque tous les cas, le prototype fonctionne, il impressionne en réunion, et personne ne sait dire ce qu'il faudrait pour qu'il serve tous les jours. Le problème n'est pas technique. Il est en amont.
Pourquoi le POC séduit
Un POC est agréable à faire. On voit un résultat en quelques jours, on a quelque chose à montrer, l'équipe est fière. C'est une vraie qualité : ça crée de l'élan, et l'élan compte.
Le piège, c'est qu'un POC répond à la question « est-ce que la technologie sait faire ça ? ». En 2026, sur la plupart des usages textuels, la réponse est oui. Tu dépenses des semaines à démontrer un point qui n'était plus vraiment en débat, pendant que les vraies questions restent ouvertes :
- Qui va utiliser l'outil, combien de fois par jour ?
- Qu'est-ce que cette personne fait aujourd'hui à la place ?
- Comment saura-t-on qu'une sortie est bonne ?
- Qui maintient l'outil dans six mois ?
Aucune de ces questions ne se répond en codant.
Le symptôme : le POC sans critère d'arrêt
Le signe le plus fiable qu'un POC va mal finir, c'est l'absence de condition de sortie. Personne n'a écrit ce qui déclencherait un passage en production, ni ce qui déclencherait un arrêt.
Un POC sans critère d'arrêt ne meurt jamais vraiment. Il devient un sujet permanent en comité, on l'améliore par petites touches, on ajoute une fonctionnalité pour convaincre le dernier sceptique. Au bout d'un an, il a coûté le prix d'un vrai projet et il n'a été adopté par personne. Je préfère largement un POC arrêté proprement au bout de trois semaines avec une conclusion écrite.
Avant de lancer quoi que ce soit, fais formuler ça à voix haute :
On passe en production si, sur vingt cas réels traités par l'équipe, au moins seize sorties sont utilisables sans reprise, et si le temps de traitement moyen baisse. Sinon, on arrête et on écrit pourquoi.
Les nombres sont à toi de les fixer. Ce qui compte, c'est qu'ils existent avant.
Ce que l'audit fait et que le POC ne fait pas
Un cadrage préalable vérifie que le problème mérite d'être résolu, et que l'entreprise est en état de le résoudre. Il cartographie les processus réels, chiffre les gains attendus, teste la disponibilité des données, identifie le propriétaire côté métier, repère les sujets de conformité à faire regarder par un juriste.
Il fait aussi une chose que le POC ne fera jamais : il compare plusieurs cas d'usage entre eux. Un POC valide une piste. Un audit dit laquelle des huit pistes vaut ton premier euro. C'est exactement le réflexe que j'ai pris en product management : on ne construit pas la première idée qui arrive, on met les idées en concurrence sur des critères explicites.
Dans mon expérience, l'audit d'abord se défend dans la quasi-totalité des situations. Il coûte moins cher qu'un POC, il dure moins longtemps, et il évite de payer trois fois le même apprentissage.
Les cas où attaquer directement par un POC se défend
Il y en a. Trois conditions, et il faut les trois.
Le cas d'usage est évident et isolé. Une seule équipe, un seul geste répétitif, pas de dépendance à un autre service. Typiquement : la reformulation de comptes rendus, le tri d'une boîte de demandes entrantes.
Les données sont déjà là et accessibles. Pas « on doit pouvoir les sortir », mais un export réel, entre tes mains, cette semaine.
Une équipe identifiée reprendra l'outil. Pas une intention. Une personne nommée, avec du temps prévu, qui a dit oui.
Si ces trois cases sont cochées, un cadrage lourd ferait perdre du temps. Fais le POC, mais fixe quand même le critère d'arrêt et la date de la décision.
Ce qui rate quand on inverse l'ordre
J'ai vu ce scénario plusieurs fois, sous des formes différentes. On construit une démo convaincante sur des données de test propres. On la présente. Enthousiasme général. Puis on branche les vraies données : elles sont incomplètes, hétérogènes, parfois fausses. La qualité s'effondre. L'équipe métier, qui n'a pas été associée au départ, conclut que « l'IA ne marche pas chez nous » — et cette conclusion-là est très difficile à défaire. Le coût réel du POC mal cadré n'est pas le budget dépensé, c'est la crédibilité brûlée pour les deux ans suivants.
À l'inverse, quand le cadrage a eu lieu, le premier chantier est souvent moins spectaculaire mais il tient. Il s'appuie sur des données qu'on a vérifiées, il vise un gain qu'on sait mesurer, et quelqu'un l'attend.
Le test à faire avant de trancher
Prends une feuille. Écris le problème que tu veux résoudre, sans nommer d'outil ni de technologie. Puis écris comment tu sauras, dans trois mois, qu'il est résolu.
Si tu y arrives en cinq minutes, tu peux prototyper. Si tu bloques, c'est que tu as besoin d'un cadrage — et c'est une bonne nouvelle, parce que c'est plus court et moins cher que ce que tu allais lancer.