POC IA en 2 semaines : prouver la faisabilité avant d'investir

Avant d'engager 8 semaines de pilote et plusieurs milliers d'euros, une question doit être tranchée : est-ce que l'idée tient techniquement, et est-ce qu'elle a assez de valeur pour valoir l'investissement ? Le POC (preuve de concept) répond à ça en 2 semaines, sur un périmètre minuscule et jetable. Voici la méthode appliquée en amont de chaque projet sérieux.

Pourquoi faire un POC avant de lancer un projet IA ?

Le POC et le pilote sont deux choses différentes, souvent confondues. Un POC répond à une question de faisabilité. Un pilote sur 8 semaines est un déploiement réel encadré, avec des utilisateurs, des KPIs métier et un go/no-go de mise en production. Le POC vient avant. Il vérifie que ça vaut la peine de lancer le pilote.

La logique est lean : au lieu de spécifier un gros projet sur le papier puis de découvrir au bout de 6 semaines que la partie centrale ne marche pas, on attaque tout de suite le risque le plus élevé. Si la brique risquée tient, le reste est de l'intégration classique. Si elle ne tient pas, on l'a su pour 2 000 € au lieu de 14 000 €.

Un POC sert concrètement à :

• Tester l'hypothèse technique la plus incertaine (l'IA sait-elle vraiment faire ça sur vos données ?)
• Estimer un niveau de qualité réel, pas un espoir de plaquette commerciale
• Désamorcer le risque technique avant d'écrire un cahier des charges complet
• Sortir avec une décision go/no-go étayée par des chiffres

Ce qu'un POC n'est PAS : un produit fini, une démo jolie, un MVP utilisable en production. Le prototype est jetable par conception. On le construit pour apprendre, pas pour le garder. Confondre POC et produit, c'est la première cause de dérapage.

Comment choisir le bon périmètre de POC ?

L'erreur réflexe est de vouloir tout couvrir. Un POC ne teste pas le projet. Il teste un point. Le bon périmètre répond à une règle simple : on attaque ce qui ferait tout capoter si ça ne marchait pas.

Deux critères pour choisir :

• Le plus risqué techniquement : la brique dont on n'est pas sûr qu'elle soit faisable. Exemple : extraire correctement les montants et dates depuis des factures fournisseurs scannées de mauvaise qualité.
• Le plus à valeur : la brique qui, si elle marche, justifie à elle seule le projet. Exemple : classer automatiquement 80% des emails entrants du SAV par typologie.

Si une brique cumule les deux (risquée ET à forte valeur), c'est le candidat évident. On ignore délibérément tout le reste : l'interface, les intégrations multiples, les cas marginaux, la robustesse. Ça viendra au pilote.

Concrètement, un bon périmètre de POC tient en une phrase : "vérifier que l'agent sait classer correctement les demandes entrantes du SAV à partir de 200 emails réels archivés". Rien de plus. Pour arbitrer quel process attaquer en premier, notre méthode pour prioriser les process à automatiser avec une matrice aide à isoler le cas qui mérite le POC.

Comment définir un critère de succès avant de commencer ?

C'est le point qui sépare un POC d'un bricolage. Le critère de succès se fixe avant d'écrire la moindre ligne, et il est chiffré. Sans lui, on regarde le résultat à la fin et on se convainc que "c'est plutôt pas mal", ce qui ne décide rien.

Un bon critère de succès tient en une phrase mesurable :

• "L'agent classe correctement 85% des demandes sur un échantillon de 200 cas réels"
• "L'extraction des montants est juste sur 9 factures sur 10 parmi 150 documents scannés"
• "Le temps de traitement d'une demande passe de 6 minutes à moins de 90 secondes"

Le seuil doit être réaliste et utile. 85% de classification correcte est souvent le bon ordre de grandeur : en-dessous, le gain humain résiduel mange le bénéfice ; au-dessus de 95%, vous fixez probablement une barre que même un humain ne tient pas. Le seuil dépend du coût d'une erreur : un POC de tri d'emails tolère 15% d'erreur, un POC sur des données comptables non.

Avant de lancer, on tranche aussi la grille de décision :

Cette grille se signe avant le jour 1. Elle évite le débat politique de fin de POC où l'on étire le verdict parce qu'on a déjà investi. Pour relier le critère de succès à la rentabilité réelle ensuite, voir notre méthode pour mesurer le ROI d'un projet IA en PME.

À quoi ressemble un POC réussi sur 2 semaines (jour par jour) ?

Deux semaines, soit 10 jours ouvrés. La première construit le prototype, la seconde l'itère et le confronte aux cas réels. Pas de phase de "production-readiness" : on reste jetable.

Semaine 1 : données et premier prototype. Le jour 1 cadre et fige le critère. Les jours 2 et 3 servent à réunir des cas réels représentatifs, c'est le point le plus chronophage et le plus négligé. Les jours 4 et 5 produisent un premier prototype qui tourne, même grossier. Fin de semaine 1, on a une première mesure, souvent décevante, c'est normal.

Semaine 2 : itération, test et mesure. L'itération concentre l'effort sur les cas ratés du premier passage. On ajuste, on remesure, on recommence. Le jour 9, on lance le passage complet sur l'échantillon de test, sans y toucher. Le jour 10, on confronte le chiffre obtenu au critère fixé au jour 1 et on tranche.

Le livrable n'est pas un outil. C'est une note de 2 à 3 pages : le chiffre obtenu, les types de cas qui passent, ceux qui échouent et pourquoi, et une recommandation go/no-go avec une estimation du coût et du délai d'un pilote. Si le POC est concluant, la suite est le pilote sur 8 semaines, qui transforme le prototype jetable en déploiement réel encadré.

Quels pièges font échouer un POC ?

Trois pièges reviennent systématiquement et ruinent la valeur d'un POC.

Piège 1 - Le POC qui dérive en projet. À force d'ajouter "tant qu'on y est, autant gérer aussi ce cas", le POC gonfle, dépasse 2 semaines, et finit par tester 5 choses mal au lieu d'une bien. Le périmètre minuscule n'est pas une contrainte subie, c'est l'outil qui garde le test honnête. Toute envie d'élargir se note pour le pilote, pas pour maintenant.

Piège 2 - Le POC sans critère de succès. Sans seuil chiffré fixé à l'avance, le verdict devient une impression. On regarde la démo, ça a l'air de marcher, on dit GO, et on découvre en production que le taux réel était de 62%. Le critère signé au jour 1 est la seule protection contre l'auto-persuasion.

Piège 3 - Le POC sur données bidon. Tester sur 10 exemples choisis ou inventés donne un faux 100%. La vraie messe se dit sur des cas réels non triés, avec leurs fautes, leurs formats variables et leurs exceptions. Un POC qui ne tourne pas sur vos vraies données ne prouve rien. C'est souvent là que la collecte des jours 2 et 3 se révèle décisive.

À ces trois-là s'ajoute un faux problème fréquent : croire qu'un POC raté est un échec. Un NO-GO étayé pour 2 200 € qui évite un projet à 18 000 € voué à l'impasse est un excellent retour sur investissement. Le but du POC n'est pas de dire oui, c'est de décider juste. Sur le calendrier global, notre point sur les délais réels d'automatisation d'un process en PME situe le POC dans la chronologie complète.