Fr
En
De
It
Es
Uk
Comment mener une preuve de concept IA en 4 semaines ?
On mène une preuve de concept IA en 4 semaines en la réduisant à une seule question, en convenant à l'avance du résultat qui vaut succès, en construisant un jeu d'évaluation à partir de vos données réelles en semaine 1, en y mesurant deux ou trois approches en semaine 2, en testant un petit pilote avec de vrais utilisateurs en semaines 3 et 4, et en terminant par une décision go ou no-go écrite. Un POC est une mesure, pas une démo.
La plupart des pilotes IA qui s'enlisent le font pour des raisons prévisibles : personne n'a défini ce que signifiait le succès, le test a utilisé des exemples propres au lieu de cas réels, ou le coût de fonctionnement a été découvert après le lancement. Chacun de ces problèmes coûte peu à prévenir en semaine 0 et cher à corriger au sixième mois. Ce guide décrit la méthode que nous suivons ; si vous voulez que nous la menions avec vous, consultez notre service de preuve de concept IA.
| Quand | Objectif | Livrable |
|---|---|---|
| Semaine 0 | Une question, un seuil de succès, l'accès aux données | Un brief de POC d'une page |
| Semaine 1 | Jeu d'évaluation et premières mesures | 30 à 100 exemples réels, résultats de référence pour 2 ou 3 modèles |
| Semaine 2 | Ajuster et analyser les échecs | Précision, latence, coût par requête ; go ou no-go préliminaire |
| Semaines 3 et 4 | Pilote avec de vrais utilisateurs | Retours d'usage, rapport final, décision |
À quelle question un POC IA doit-il répondre ?
Un POC IA doit répondre à une seule question, sous cette forme : cette approche IA peut-elle accomplir cette tâche précise sur nos données réelles, avec une précision suffisante et un coût suffisamment bas pour mériter d'être construite ? "L'IA peut-elle aider notre équipe support ?" est trop large pour être testé. "Un modèle peut-il rédiger des premières réponses aux tickets de facturation qu'un responsable support accepte sans modification au moins 8 fois sur 10 ?" peut être testé en quatre semaines.
Les bons candidats au POC ont quelques points communs. La tâche est réalisée aujourd'hui par des personnes : il existe donc des exemples réels et quelqu'un capable de juger les résultats. La précision compte assez pour qu'il vous faille un chiffre avant d'investir. Les données sont désordonnées ou inhabituelles, si bien qu'il n'est pas évident que cela fonctionne. Exemples typiques : extraire des champs de documents scannés, classer et router des demandes entrantes, répondre à des questions sur des documents internes, rédiger des réponses, ou un agent qui exécute un workflow à travers vos outils.
Vous n'avez probablement pas besoin d'un POC lorsque la tâche est bien comprise et peu risquée, comme résumer des fils de support. Construisez-la alors directement. Si vous avez plusieurs idées sans priorité claire, classez-les d'abord ; notre audit IA le fait pour un produit existant.
Comment fixer les critères de succès avant de commencer ?
Écrivez les critères de succès avant toute ligne de code, avec un chiffre pour la qualité, une limite pour le coût et, lorsque des utilisateurs attendent la réponse, une limite pour la latence. Faites-les valider par le responsable métier du processus. Un seuil fixé après avoir vu les résultats n'est pas un seuil.
| Type de tâche | Critère de qualité | Critères de coût et de vitesse |
|---|---|---|
| Extraction de documents | Au moins 90 à 95 % des champs corrects sur le jeu d'évaluation | Sous un coût défini par document ; traitement par lots acceptable |
| Classification et routage | Au moins 90 % de catégories correctes ; les erreurs connues coûtent peu | Sous un coût défini par élément |
| Rédaction de réponses | 8 brouillons sur 10 acceptés sans modification par un expert du domaine | Réponse en moins de 10 secondes |
| Questions sur des documents | 85 à 90 % de réponses correctes et appuyées par une source citée | Moins de 5 secondes avant les premiers mots |
| Agent pour un workflow | Réussit 8 cas de test sur 10 sans action dangereuse | Sous un coût défini par tâche accomplie |
Les chiffres ci-dessus sont des points de départ typiques, pas des règles. Utilisez ce que le cas métier exige : si une extraction erronée coûte un remboursement, visez plus haut ; si un humain relit de toute façon chaque résultat, la barre peut être plus basse, car la valeur réside dans le temps gagné. Définissez aussi ce que "correct" signifie pour chaque type de résultat, idéalement avec deux ou trois exemples notés, afin que différents relecteurs jugent de la même façon.
Comment construire le jeu d'évaluation ?
Construisez le jeu d'évaluation à partir de 30 à 100 entrées réelles, chacune associée au résultat attendu ou à des critères de notation. Ce jeu est l'élément le plus précieux que produit le POC : il continue de mesurer la qualité à chaque changement ultérieur de prompt, de modèle ou de pipeline de données.
Comment le constituer :
- Échantillonnez, ne choisissez pas à la main. Prenez des cas réels récents au hasard, puis ajoutez les cas difficiles connus : scans, champs manquants, langues mélangées, demandes ambiguës.
- Rédigez le résultat attendu avec la personne qui réalise la tâche aujourd'hui. Pour du texte libre, rédigez des critères de notation plutôt qu'une seule bonne réponse.
- Séparez-le. Mettez de côté environ un cinquième des exemples et ne les regardez pas pendant l'ajustement ; notez-les seulement à la fin, pour savoir que le résultat n'est pas surajusté.
- Masquez les données sensibles si nécessaire. Des données anonymisées conviennent pour un POC, tant que la structure et la difficulté restent réelles.
- Écrivez le script de notation dès la semaine 1 : correspondance exacte pour les champs structurés, grille de notation appliquée par un second modèle avec des vérifications humaines ponctuelles pour le texte libre.
Que se passe-t-il au cours de chacune des quatre semaines ?
Semaine 1 : données et résultats de référence
Obtenez l'accès aux données, construisez le jeu d'évaluation et lancez une première mesure simple avec deux ou trois modèles, par exemple un modèle d'OpenAI, un d'Anthropic et un modèle open source si les données doivent rester sur vos serveurs. Journalisez chaque appel avec le nombre de tokens dès le premier jour. À la fin de la semaine, vous savez à peu près à quelle distance du seuil se trouve chaque modèle. Notre comparaison des API Claude et OpenAI explique les principales différences entre fournisseurs.
Semaine 2 : ajuster et analyser les échecs
Améliorez la ou les deux meilleures approches face au jeu d'évaluation : de meilleurs prompts et exemples, une sortie structurée, de la recherche documentaire si les réponses dépendent de documents (voir notre guide de mise en œuvre du RAG), ou un autre pipeline. Lisez ensuite chaque échec et regroupez-les par cause. À la fin de la semaine 2, vous disposez de la précision, de la latence et du coût par requête, et généralement d'un go ou no-go préliminaire.
Semaines 3 et 4 : pilote
Si les chiffres sont prometteurs, intégrez la meilleure approche dans une interface ou une API minimale, avec journalisation et limites de coût, et laissez quelques vrais utilisateurs l'essayer sur leur travail réel. Un pilote répond à ce qu'un jeu d'évaluation ne peut pas mesurer : les gens l'utilisent-ils, lui font-ils confiance, et fait-il gagner du temps ? Terminez par la notation finale sur les exemples mis de côté et par le rapport.
Comment prendre la décision go ou no-go ?
Prenez la décision au regard des critères de la semaine 0, avec l'analyse des échecs à côté des chiffres. Il existe plus de deux issues possibles, et les nommer évite d'étirer un résultat faible jusqu'à en faire un projet.
| Résultat | Décision | Étape suivante |
|---|---|---|
| Atteint les seuils de qualité, de coût et de vitesse ; les utilisateurs du pilote continuent de s'en servir | Go | Développement de production avec permissions, supervision et déploiement |
| Proche du seuil ; les échecs se concentrent sur une cause corrigeable | Go sous conditions | Corriger la cause (données, périmètre plus étroit, relecture humaine), puis construire |
| Fonctionne seulement sur une partie des cas | Go restreint | Construire pour cette partie, router le reste vers des personnes |
| Loin du seuil ou trop cher par requête | No-go | Documenter pourquoi ; envisager une solution sans IA ou y revenir plus tard |
Un no-go est un résultat valable et utile. Dans l'AI Grief Companion que nous avons construit pour une startup américaine, le prompting seul ne permettait pas de reproduire la voix d'une personne précise, ce qui a conduit à un fine-tuning LoRA sur Qwen2.5-7B. C'est exactement le type de question qu'un POC tranche tôt, avant que tout le développement soit planifié autour de la mauvaise approche.
Combien coûte une preuve de concept IA ?
Le coût dépend de ce que le POC doit prouver et du fait qu'il tourne ou non sur des données et des systèmes réels. Chez nous, un POC IA se déroule dans un AI Sprint : 10 000 USD forfaitaires pour 4 semaines maximum, avec le cadrage, le jeu d'évaluation, le prototype, la comparaison des modèles, le pilote, le rapport et un appel de passation. L'utilisation des modèles et de l'hébergement pendant le POC est payée directement par vous et reste généralement faible ; nous l'estimons à l'avance.
Si la réponse est go, un MVP IA fonctionnel demande généralement 8 à 14 semaines de plus. Lorsque vous comparez les devis d'autres prestataires, vérifiez ce que "preuve" veut dire : une démo sur des exemples choisis à la main et un prototype déployé, mesuré sur des cas réels, s'appellent tous deux un POC, mais ce n'est pas le même achat. Notre guide du développement IA au forfait explique comment les comparer.
Que devez-vous obtenir à la fin d'un POC IA ?
À la fin d'un POC IA bien mené, vous devez posséder cinq éléments, que vous poursuiviez ou non avec la même équipe :
- Le code du prototype dans votre dépôt, écrit pour que son cœur puisse passer en production.
- Le jeu d'évaluation et le script qui note toute version future par rapport à lui.
- Un rapport de résultats : précision sur les exemples mis de côté, schémas d'échec, latence, coût par requête et coût mensuel estimé à votre volume, pour chaque modèle testé.
- Une note d'architecture pour la version de production : flux de données, garde-fous, points d'intégration et risques ouverts.
- Un go ou no-go écrit, avec son raisonnement et, en cas de go, le périmètre de l'étape suivante.
Notre verdict
Lancez un POC IA lorsque l'issue est réellement incertaine et qu'un mauvais pari coûterait cher. Limitez-le à une question, fixez le seuil avant de commencer, utilisez des données réelles y compris les cas difficiles, mesurez le coût dès le premier appel et écrivez la décision. Quatre semaines suffisent pour la plupart des POC portant sur une seule tâche, et la réponse est généralement visible dès la fin de la semaine 2.
Prochaine étape
Décrivez la tâche et envoyez quelques exemples réels. Lors d'un appel de 30 minutes, nous vous dirons si un POC est la bonne étape, quel seuil retenir et de quelles données nous avons besoin. Consultez notre service de preuve de concept IA et l'AI Sprint, ou contactez-nous.
