Un POC réussi n'est pas un POC parfait. C'est un POC qui répond à une question binaire en un temps contraint : est-ce que ça marche assez bien pour mériter d'aller en production ? Tout le reste est secondaire.
Le périmètre minimal viable
Le périmètre du POC doit tenir en deux phrases. Exemple : « Le POC teste la capacité du modèle à produire un premier draft de synthèse de réunion client à partir d'une transcription brute, en moins de 2 minutes, avec un taux de correction humaine inférieur à 20% sur 50 cas tests. »
Ce que ce périmètre exclut explicitement : l'intégration avec le CRM, la gestion des langues multiples, la personnalisation par type de client, l'historique des réunions précédentes. Tout cela vient après. Pas maintenant.
Si vous ne pouvez pas écrire le périmètre en deux phrases, c'est qu'il est trop large. Coupez jusqu'à ce que ce soit possible.
Les données à préparer — et l'erreur fatale à éviter
La règle absolue : utilisez les vraies données de production dès le premier jour. Pas des données fictives. Pas des données nettoyées spécialement pour le POC. Les données telles qu'elles existent dans vos systèmes, avec leurs imperfections.
Pourquoi ? Parce que 70% des POC qui échouent en production échouent à cause de l'écart entre les données du POC et les données réelles. Si le modèle performe bien sur vos données sales et incomplètes, vous savez qu'il fonctionnera en production. Si vous attendez d'avoir des données propres, vous repoussez la découverte du vrai problème.
Préparez un jeu de 50 à 100 exemples réels, avec leur résultat attendu. C'est votre jeu de test de référence.
Les critères de succès — binaires, pas subjectifs
Définissez vos critères avant de commencer le POC, pas après avoir vu les résultats. Un critère de succès valable est binaire : atteint ou non atteint. Pas « satisfaisant », pas « prometteur ».
Exemples de bons critères :
- Précision supérieure à 85% sur le jeu de test de 100 cas
- Temps de traitement inférieur à 90 secondes par document
- Taux de validation humaine sans correction supérieur à 70%
- Score de satisfaction utilisateur (5 testeurs internes) supérieur à 4/5
Si vos critères ne sont pas chiffrés, vous allez passer les deux prochaines semaines à débattre de si « ça marche assez bien ». Ce débat n'a pas de fin.
L'équipe minimale nécessaire
Trois personnes suffisent pour un POC de semaine 3 :
- Un développeur ou data scientist qui monte le pipeline technique (prompt, appel API, intégration basique).
- Un référent métier qui définit les cas tests, valide les outputs et joue le rôle de premier utilisateur.
- Un décideur sponsor qui a autorité pour décider go/no-go à la fin de la semaine et qui bloque du temps dans son agenda pour la revue finale.
Ne constituez pas une équipe projet de dix personnes. Plus l'équipe est grande, plus les réunions prennent de la place et moins le POC avance.
Les pièges classiques du POC
Le perfectionnisme. Le premier prompt ne sera pas parfait. Le pipeline ne sera pas scalable. Les outputs auront des erreurs. C'est normal et attendu. L'objectif est de répondre à la question binaire — pas de livrer un produit fini. Résistez à la tentation de tout optimiser avant d'avoir démontré que la direction fonctionne.
Le scope creep. Quelqu'un va demander « et si on ajoutait aussi… » en milieu de semaine. La réponse est toujours : « C'est une excellente idée pour la phase 2. Pour l'instant, on reste sur le périmètre défini. » Documentez la demande et passez à autre chose.
Les données trop propres. Vous avez préparé 20 beaux exemples qui fonctionnent tous. Mais vos 80 autres exemples, les vrais, ceux que vos utilisateurs soumettront, sont beaucoup plus bruités. Testez sur les cas difficiles, pas sur les cas faciles.
Comment itérer rapidement
La semaine 3 fonctionne en sprints d'un jour. Lundi : setup technique et premiers tests sur 10 cas. Mardi : analyse des échecs, ajustements du prompt, 30 cas. Mercredi : test sur le jeu complet de 100 cas, identification des patterns d'échec. Jeudi : derniers ajustements, test de validation avec le référent métier. Vendredi : revue go/no-go avec le sponsor.
Quand arrêter et pivoter
Si en milieu de semaine vous n'atteignez pas 60% de vos critères de succès, posez-vous deux questions : est-ce un problème de prompt (ajustable rapidement) ou un problème structurel (mauvais cas d'usage, données insuffisantes, modèle inadapté) ? Si c'est structurel, pivotez vers le deuxième cas d'usage de votre shortlist. Mieux vaut pivoter en semaine 3 que de passer en production sur quelque chose qui ne tient pas la route.
Bilan semaine 3
- Périmètre tenu en deux phrases, avec cas exclus explicitement documentés
- 100 cas de test sur données réelles de production
- Critères de succès binaires définis avant le démarrage
- Décision go/no-go prise vendredi sur la base des critères — pas du ressenti
Si le POC est concluant, la semaine 4 est la plus critique : c'est là que 80% des projets s'arrêtent, faute de gouvernance et de préparation du passage en production.