Preuve de concept IA : cadrer un PoC et décider de la suite en 2026

Une preuve de concept (PoC) d'IA a une seule raison d'être : vous permettre de dire « oui, on continue » ou « non, on arrête » en connaissance de cause, pour une somme limitée. Beaucoup de PoC échouent à cette mission parce qu'ils ont été conçus pour impressionner, pas pour décider. Voici comment en cadrer un qui serve vraiment, en quatre à six semaines, et à quoi reconnaître un devis de PoC qui n'en est pas un.

Ce qu'un PoC doit établir, et ce qu'il n'a pas à établir

Un PoC répond à trois questions, dans cet ordre :

1. Est-ce faisable avec nos données ? Le système atteint-il la qualité requise sur vos cas réels, pas sur une démonstration choisie par le prestataire ?
2. Est-ce utile ? Le gain attendu (temps, erreurs, délai) se vérifie-t-il sur un échantillon mesuré ?
3. Sera-t-il utilisé ? Les personnes concernées acceptent-elles de s'en servir dans leur travail réel ?

Il n'a pas à être beau, robuste, sécurisé pour des milliers d'utilisateurs ni intégré à tous vos outils. Ces qualités appartiennent au pilote et au déploiement. Un PoC qui prétend déjà tout faire coûte plus cher et ne tranche rien de plus.

Le calendrier type, de la semaine zéro à la décision

Étape	Contenu	Votre rôle
Semaine 0 : préparation	Cas d'essai, accès aux données, critères de décision écrits	Fournir les exemples et signer les critères avant de commencer
Semaines 1 et 2 : prototype minimal	Version la plus simple qui traite les cas d'essai	Répondre vite aux questions sur les données
Semaine 3 : mesure	Rejouer tous les cas, noter, analyser les erreurs	Valider les notes avec un expert interne
Semaine 4 : essai utilisateur	Trois à cinq personnes l'utilisent sur leur travail réel	Libérer ces personnes, observer sans corriger
Semaines 5 et 6 : décision	Rapport, chiffrage de la suite, recommandation	Décider selon les critères posés au départ

Quatre semaines suffisent pour un cas simple ; six pour un cas qui touche plusieurs sources de données. Au-delà, vous construisez un pilote sans le dire.

Écrire les critères de décision avant le premier jour

C'est la règle qui sépare un PoC utile d'une démonstration. Rédigez, ensemble avec le prestataire et avant de commencer, trois critères chiffrés ou observables :

• Critère de qualité : sur les cas d'essai fournis, le système fournit une réponse exploitable dans au moins le seuil convenu, et reconnaît qu'il ne sait pas dans les cas prévus. La construction de ces cas est décrite dans notre modèle de cahier des charges.
• Critère de valeur : le temps ou l'erreur mesuré sur l'échantillon se situe en dessous du seuil qui justifierait la suite. Servez-vous des chiffres de départ de votre calcul de rentabilité.
• Critère d'adoption : au moins la majorité des testeurs déclarent qu'ils l'utiliseraient volontairement, et leurs corrections montrent pourquoi.

Si, à l'issue du PoC, le résultat est « presque », ce n'est pas un échec du projet : c'est un échec du critère, qui n'avait pas fixé le « presque ». Prévoyez trois issues dès le départ : continuer, ajuster puis re-tester une fois, arrêter.

Ce que doit contenir le livrable d'un PoC

• Les résultats cas par cas, avec les erreurs expliquées : où le système se trompe, et pourquoi (donnée absente, ambiguïté, limite du modèle).
• Les limites constatées et ce qu'il faudrait pour les lever.
• Le chiffrage honnête de la suite : pilote, déploiement, coûts récurrents d'usage et de maintenance.
• La documentation suffisante pour qu'un autre prestataire puisse reprendre le travail.

Ce dernier point est stratégique : il conditionne votre liberté de choix après le PoC. Demandez-le dans la proposition, pas après.

Les conditions contractuelles d'un PoC sain

• Vos données restent à vous. Aucune réutilisation pour d'autres clients ni pour entraîner un modèle, sauf accord écrit. Voir notre guide sur le RGPD et l'IA générative.
• Un périmètre et un prix fermes. Un PoC se facture à forfait pour un périmètre donné, pas en régie ouverte. C'est ce qui le range dans la tranche des projets de moins de 10 k€ sur ce site.
• Pas de clause qui vous engage sur la suite. Le prestataire peut espérer le pilote, il ne peut pas vous le garantir par contrat.
• Une propriété claire des livrables. Qui détient les consignes, les cas d'essai enrichis, le code d'intégration ?

Cinq erreurs qui transforment un PoC en dépense perdue

1. Tester sur des données idéales. Le prestataire nettoie un échantillon impeccable, le résultat est superbe, le déploiement échoue sur vos vrais documents. Imposez des cas réels, y compris moches.
2. Juger sur une démonstration. Une démo se prépare ; un jeu de cas inconnus se subit. Gardez une partie de vos cas secrète jusqu'à la mesure.
3. Ignorer l'intégration. Un PoC dans un outil à part prouve la faisabilité technique, pas l'utilité dans le flux de travail. Au minimum, simulez le point d'entrée réel.
4. Oublier les utilisateurs. Si personne n'est libéré pour tester, l'adoption restera une hypothèse.
5. Ne pas écrire la décision. Sans critères, la décision sera politique, et le projet continuera ou s'arrêtera selon l'humeur du comité.

Un exemple de critères remplis (situation fictive)

Reprenons le service client d'un distributeur dont l'assistant doit répondre aux questions de suivi de livraison. Les critères signés avant le début pourraient se lire ainsi :

• Qualité : sur les quarante questions fournies, au moins trente-deux réponses jugées exactes par la responsable du service ; sur les cinq questions sans réponse possible, cinq transmissions à un conseiller ; aucune réponse inventée.
• Valeur : temps de première réponse, mesuré sur l'échantillon d'essai, inférieur à la moitié du temps constaté aujourd'hui, et part des demandes traitées sans conseiller supérieure à celle qui justifie le coût d'usage prévisible.
• Adoption : quatre conseillers sur quatre acceptent de l'utiliser une semaine, et au moins trois sur quatre déclarent vouloir le garder.

Remarquez la forme : chaque critère se vérifie sans débat à la fin. Si le prestataire hésite à signer des critères de ce type, c'est une information sur la façon dont il envisage la suite.

Le temps que vous devez prévoir de votre côté

Un PoC « clé en main » n'existe pas : même bien mené, il demande une implication de votre équipe. Comptez en ordre de grandeur quelques heures par semaine pour une personne référente sur le terrain (répondre aux questions, valider les notes), un expert métier disponible pour corriger les cas d'essai, et deux à quatre personnes libérées pendant une à deux journées pour l'essai utilisateur. Si ce temps n'est pas disponible, repoussez le PoC : un projet sans interlocuteur côté client produit un prototype sans enseignement.

La valeur d'un « non »

Un PoC qui conclut à l'arrêt n'est pas un échec : il vous a évité un déploiement coûteux sur une hypothèse fausse, pour une dépense limitée à la tranche des moins de 10 k€. Deux conditions pour que ce soit vrai. Le rapport doit expliquer pourquoi : donnée insuffisante, tâche trop ambiguë, gain trop faible, utilisateurs réticents. Et il doit proposer, quand c'est possible, une version réduite qui garderait l'essentiel de la valeur. Un « non » documenté nourrit le projet suivant ; un « non » sans explication ne sert à rien.

Huit questions à poser à un prestataire qui propose un PoC

1. Quelles questions précises ce PoC doit-il trancher, et lesquelles ne tranchera-t-il pas ?
2. Quels critères de décision proposez-vous, et acceptez-vous de les signer avant de commencer ?
3. Sur quelles données travaillerez-vous, et qui les prépare ?
4. Quelle part du travail est du prototype jetable et quelle part pourra être réutilisée ?
5. Combien de temps attendez-vous de mon équipe, et à quels moments ?
6. Que contient le rapport final, et à qui appartiennent les livrables ?
7. Comment chiffrerez-vous la suite, coûts d'usage inclus ?
8. Si le résultat est négatif, que me remettez-vous ?

Les réponses précises, sans jargon, sont le meilleur indice de sérieux. Les réponses évasives sur la dernière question en disent long : certains prestataires construisent leurs PoC pour réussir à tout prix.

Comment se servir d'un PoC pour choisir un prestataire

Avec deux prestataires finalistes, rien ne vaut un PoC payé, court et identique, sur les mêmes cas d'essai : ce sont des preuves comparables, ce que ne sont jamais des plaquettes commerciales. Le surcoût est modeste au regard du risque d'un mauvais choix. Si le budget ne le permet pas, demandez au moins que chaque finaliste traite un échantillon de vos cas en direct, devant vous. Pour comprendre ce que contiennent les propositions, voyez comment lire et comparer deux devis.

Et après le PoC ?

Un PoC réussi débouche sur un pilote : un groupe limité d'utilisateurs, les vraies intégrations, la supervision et les coûts d'usage réels, pendant quelques semaines. Ce n'est qu'ensuite que l'on déploie. Si vous cherchez des équipes pour le PoC, le classement des agences IA permet de repérer des interlocuteurs ; vous pouvez aussi décrire votre projet en indiquant que vous souhaitez démarrer par une preuve de concept.