Méthodologie d'un POC IA : 5 étapes, du cadrage au go/no-go

I Cadrer : une question, un seuil, un sponsor

Un POC prouve la faisabilité d'un cas d'usage précis, sur vos données : le niveau de qualité attendu est-il atteignable, à un coût et avec des risques acceptables ? La valeur d'usage relève du MVP, la tenue dans la durée de la mise en production. Le cadrage, qui tient en une page et deux à trois jours pris sur la durée du POC, sert à écrire noir sur blanc ce que le POC doit trancher. La fiche de cadrage répond à six questions :

• La question. Une phrase, un cas d'usage : « un assistant peut-il répondre aux demandes de support de niveau 1 aussi bien qu'un conseiller, à partir de notre base de connaissances ? »
• Le critère de succès. Un seuil chiffré sur une mesure que le métier reconnaît (taux de bonnes réponses, temps de traitement, taux d'erreur), fixé avant la première ligne de code, assorti d'un plafond de coût par requête.
• Le périmètre. Un type de document, une langue, un profil d'utilisateur, et la liste de ce qui est explicitement hors périmètre.
• Les données. Les sources, la personne qui ouvre les accès et les conditions d'utilisation (données personnelles, confidentialité, hébergement).
• Les personnes. Le sponsor qui tranchera à la fin et le référent métier qui validera les réponses attendues.
• Les contraintes. Sécurité, hébergement, première lecture RGPD et AI Act : le niveau de risque du cas d'usage conditionne ce qu'il faudra prévoir au MVP.

Une règle simple : si l'accès aux données réelles n'est pas obtenu à la fin du cadrage, mieux vaut décaler le POC que le démarrer sur des données fictives. Un POC mené sur un export idéal prouve seulement que l'export était idéal.

II Constituer le jeu d'évaluation et la référence

C'est l'étape la plus souvent sautée, et celle qui décide de tout le reste. Le jeu d'évaluation rassemble des cas réels, chacun accompagné de la réponse attendue, validée par le référent métier. Il doit contenir les cas difficiles, ambigus ou rares, et ceux où la bonne réponse est « je ne sais pas ». Mieux vaut quelques dizaines de cas représentatifs que des milliers d'exemples faciles.

La référence décrit la façon dont la tâche est faite aujourd'hui : délai, taux d'erreur, charge humaine. Sans elle, le POC peut atteindre son seuil sans que personne ne sache dire si c'est mieux que l'existant. Si la référence montre que le seuil fixé au cadrage était mal calibré, c'est le moment de le corriger : avant les premières mesures du prototype, jamais après les résultats.

Ce jeu d'évaluation est l'actif le plus durable du POC. Il sert à mesurer chaque version du prototype, puis de test de non-régression pendant le MVP et en production : chaque changement de modèle, de prompt ou de source documentaire est rejoué dessus avant d'être livré.

III Prototyper : la solution la plus simple qui puisse réussir

La tentation est de commencer par l'architecture la plus impressionnante. La bonne pratique est inverse : un appel de modèle bien instruit avant un RAG, un RAG avant un agent, un agent doté d'un seul outil avant un système multi-agents. On ne monte d'un cran que si le jeu d'évaluation montre que le cran inférieur ne suffit pas. Pour le passage au multi-agents, la deuxième règle de Descartes, relue pour l'IA agentique, s'applique à la lettre : diviser autant qu'il est requis, pas davantage.

• Itérer en cycles courts. Chaque version est mesurée sur le jeu d'évaluation : on compare des scores, pas des impressions de démonstration.
• Écrire du code réutilisable dès le POC. Versionné, testé a minima, avec les prompts et les paramètres de modèle séparés du code. C'est ce qui évite la réécriture au moment du MVP.
• Rester dans le périmètre de sécurité convenu. Les données ne quittent pas l'environnement validé au cadrage, même « juste pour tester ».

IV Évaluer : qualité, coût unitaire, latence, risques

L'évaluation finale ne se limite pas à la qualité des réponses. Un POC qui atteint son seuil à un coût par requête intenable, ou qui cède à la première entrée malveillante, est un échec différé.

V Décider : continuer, ajuster ou arrêter

Le POC se termine par une note de décision courte : les résultats sur chaque dimension, l'écart au seuil, les risques identifiés et, si l'on continue, une estimation du MVP (périmètre, équipe, durée). Trois issues sont possibles, et toutes sont légitimes :

• Continuer. Le seuil est atteint et le coût unitaire est soutenable : on lance un MVP de 6 à 12 semaines avec de vrais utilisateurs, en réutilisant le code et le jeu d'évaluation.
• Ajuster. Le seuil est presque atteint et la cause de l'écart est identifiée (une source manquante, un périmètre trop large) : on revient à l'étape 3 avec une nouvelle échéance, sans toucher au seuil, et pas pour une durée indéfinie.
• Arrêter. Le seuil est hors d'atteinte, ou le coût ne tiendra pas aux volumes réels. Un arrêt documenté est un POC réussi : il a coûté quelques semaines au lieu d'un projet entier.

Pour situer la suite dans le temps, le tableau comparatif de notre guide POC IA en entreprise détaille la durée, l'équipe et les livrables du MVP puis de la mise en production.

VI Les spécificités d'un POC agentique

Quand le prototype n'est plus un assistant qui répond mais un agent qui agit — il lit un CRM, crée un ticket, envoie un message —, la méthode reste la même mais le cadrage s'enrichit de quatre garde-fous :

• Un périmètre d'action explicite. La liste des outils autorisés, en lecture seule d'abord ; l'écriture vient ensuite, outil par outil.
• Une validation humaine avant toute action irréversible ou engageante pour l'entreprise.
• Un journal de chaque appel d'outil : entrée, sortie, décision de l'agent. Utile pour déboguer, indispensable pour la traçabilité.
• Des tests adversariaux : des instructions cachées dans un document ou un e-mail que l'agent va lire, pour vérifier qu'il ne les exécute pas.

Le jeu d'évaluation d'un agent contient donc des scénarios complets — une demande, les actions attendues, celles qui sont interdites — et pas seulement des paires question-réponse. L'autonomie se gagne ensuite par degrés, à mesure que l'agent fait ses preuves sur ce jeu.

VII Cinq erreurs qui font échouer un POC IA

• Démarrer sans critère de succès. La décision finale devient une affaire d'opinion, et le POC se prolonge.
• Juger sur une démonstration. Trois questions bien choisies ne remplacent pas un jeu d'évaluation.
• Travailler sur des données nettoyées ou fictives. Le POC réussit, la production échoue.
• Choisir l'architecture la plus impressionnante plutôt que la plus simple qui atteint le seuil.
• Prolonger un POC « presque concluant » sans cause identifiée ni nouvelle échéance.

Un POC bien conduit ne garantit pas pour autant le passage en production : les raisons pour lesquelles tant de prototypes restent bloqués en chemin font l'objet de notre analyse POC Purgatory : pourquoi les POC IA restent bloqués avant la production.