Pourquoi 70% des POC IA finissent au placard (et comment éviter ça)

On a perdu le compte. Depuis dix-huit mois, on rencontre chaque semaine un dirigeant de PME qui ouvre la conversation par la même phrase : « On a déjà fait un POC IA l'an dernier, ça n'a rien donné. » Suivent, dans l'ordre : un budget à six chiffres, une boîte de conseil qui a livré un PowerPoint de 80 slides, et un assistant qui tourne encore sur l'ordi d'un stagiaire parti depuis.

Le chiffre de 70% de POC IA qui finissent au placard circule beaucoup. On pense qu'il est optimiste. Sur les dossiers qu'on reprend, c'est plutôt 8 sur 10, et la cause n'est presque jamais technique. C'est du cadrage, du scoping prod, et de la mesure. Trois choses très peu sexy.

Voici les cinq pièges qu'on voit revenir, et ce qu'on fait à la place quand on entre sur un projet.

Le piège n°1 : le POC en silo

La DSI lance le sujet. Elle choisit le cas d'usage (souvent un chatbot interne RH ou un résumé de documents). Elle pilote l'intégration. Elle livre. Le métier découvre l'outil en démo finale, hoche la tête, et n'y retourne jamais.

On a vu ça littéralement le mois dernier chez un assureur romand. Six mois de dev sur un assistant de souscription, validé par la DSI, refusé par les souscripteurs en quinze minutes : « il ne pose pas les bonnes questions, et on ne peut pas le corriger en live ». L'outil n'était pas mauvais. Il avait juste été conçu sans les gens qui s'en servent.

Un POC IA n'est pas un projet informatique. C'est un projet métier qui utilise de l'informatique. Tant que le métier n'est pas dans la salle au moment du cadrage — pas en validation finale, au cadrage — le résultat ne sera jamais adopté.

Le contre-test qu'on applique : à la première réunion, on demande qui va utiliser l'outil tous les jours. Si la réponse est floue, ou si ces personnes ne sont pas dans la boucle dès le cadrage, le projet est déjà mal parti. On a fini par mettre cette question dans notre devis : nom et prénom des trois utilisateurs pilotes, avec leur accord écrit. Ça paraît bureaucratique. Ça sauve des projets.

Takeaway : si le sponsor du POC est le DSI et pas un directeur métier, arrêtez avant de signer.

Le piège n°2 : le modèle qui hallucine sans qu'on le voie

Claude Sonnet 4.6 est bluffant. Mistral Large 2 aussi. Sur 95% des requêtes, ils répondent juste, vite, et avec une assurance qui désarme. Le problème, c'est les 5% restants.

Dans une PME qui traite des contrats de prêt, des polices d'assurance ou des fiches techniques industrielles, une réponse fausse présentée avec aplomb coûte plus cher que dix « je ne sais pas ». Et la plupart des POC qu'on auditbalance la réponse brute du modèle, sans citation de la source, sans grille d'évaluation, sans rejeu sur un jeu de cas connus.

Résultat : le métier découvre une erreur, perd confiance, et l'outil meurt. Pas en une fois. En trois semaines de défiance silencieuse.

Ce qu'on impose dès le départ : citations systématiques (avec lien vers le doc source), eval grid construite sur 30 à 50 cas réels fournis par le métier, et un taux d'hallucination cible mesuré avant le go/no-go. Pas une slide. Un chiffre.

Le piège n°3 : « on déploie après »

Celui-là est le plus coûteux. Le POC tourne sur le laptop d'un consultant, ou sur un compte ChatGPT Team partagé, avec des clés API en dur dans un notebook. Personne ne s'est posé la question de l'authentification SSO, des logs d'audit, du contrôle des coûts, du chiffrement des prompts, du périmètre RGPD ou nLPD.

Le POC fonctionne. La DSI veut le passer en prod. Et là, on découvre qu'il faut tout réécrire. Six mois, parfois plus. Sur des budgets qui n'étaient pas prévus, parce que personne n'avait chiffré le « delta POC vers prod » au démarrage.

On a repris l'an dernier un POC de classification de mails chez un acteur de l'immobilier. Le POC marchait à 92% de précision. Pour le mettre en prod : refonte de l'auth, intégration au SIEM, hébergement souverain en Suisse, journalisation conforme. Coût final : 3,4x le coût du POC. Personne n'avait prévenu le COO.

La règle qu'on applique : au scoping J1, on liste explicitement les contraintes prod (auth, audit, hébergement, coûts unitaires par requête, SLA, RGPD/nLPD). Si une contrainte n'est pas tenable, on le sait avant de coder. Pas après.

Concrètement, ça veut dire qu'on commence un projet par une page : qui se connecte avec quoi, où sont stockés les prompts et les réponses, combien coûte une requête moyenne, qui regarde les logs, et qui paie la facture API à la fin du mois. Si une de ces lignes est vide ou incertaine, on arrête tout et on va chercher la réponse. C'est moins glamour que de lancer un notebook. C'est ce qui sépare un POC qui passe en prod d'un POC qui meurt.

Le piège n°4 : le ROI flou

« On veut gagner du temps. » C'est l'objectif business qu'on entend dans 7 briefs sur 10. C'est aussi un piège, parce que personne ne sait combien de temps, sur quelle tâche, mesuré comment.

À la fin du POC, le commanditaire demande : « alors, ça marche ? » et personne ne peut répondre. Le consultant montre un chatbot qui répond bien. Le métier dit que c'est sympa. Le CFO demande le ROI. Silence.

Une métrique business chiffrée, définie avant de coder, ça ressemble à ça :

• « 30 minutes par dossier d'analyse crédit, mesurées sur 20 dossiers témoins, baseline à 95 minutes »
• « 40% de mails de niveau 1 traités sans intervention humaine, mesurés sur la file support pendant 4 semaines »
• « Temps de réponse à un appel d'offres divisé par 2, mesuré sur les 10 derniers AO »

Pas « gain de productivité ». Pas « meilleure expérience utilisateur ». Une métrique qu'on peut mesurer avant, mesurer après, et écrire dans un Excel. Sinon, le débat de fin de POC est perdu d'avance.

Le piège n°5 : le succès qui ne scale pas

Celui-là, c'est le plus traître, parce qu'il arrive après une réussite. Le POC marche. Cinq utilisateurs power-users sont ravis. On décide de passer à 50, puis 200.

Et là, trois choses cassent simultanément :

• Les coûts : 5 utilisateurs à 30 requêtes/jour, ça passe. 200 utilisateurs à 80 requêtes/jour, ça explose le budget API. Un POC qui n'a pas chiffré le coût marginal par requête se prend une note de 40k CHF mensuelle qui n'était nulle part dans le business case.
• La qualité perçue : les power-users formulent bien leurs questions. Les utilisateurs lambda, non. Le taux d'erreur double. Le NPS s'effondre.
• Le support : personne n'a prévu qui répond quand l'outil hallucine ou plante. La DSI dit « c'est métier ». Le métier dit « c'est DSI ». L'outil meurt.

Un POC IA ne se valide pas sur 5 utilisateurs triés sur le volet. Il se valide en au moins deux paliers : un noyau dur, puis une vague élargie de profils variés. Avec mesure des coûts unitaires et du support à chaque palier. Sur un projet récent dans l'industrie, on a découvert au palier 2 que 30% des utilisateurs reformulaient leur question trois fois avant d'obtenir une réponse exploitable. La réponse n'était pas dans le modèle — elle était dans un guide d'usage de deux pages qu'on a co-écrit avec le métier. Coût : zéro. Impact : taux de satisfaction passé de 51 à 84%.

Ce qu'on fait à la place

On a structuré notre approche autour de ces cinq pièges, parce qu'on s'est pris les pieds dans certains à nos débuts. Voici la méthode qu'on applique sur chaque projet, sans exception.

1. Cadrage 1h avec le métier, pas la DSI. Une session d'une heure, en face à face, avec le directeur métier et un ou deux opérationnels. Pas de slides. On déroule notre grille de cadrage en 1h : volume de l'activité, coût actuel, critères de succès, contraintes réglementaires. À la fin, on sait si le cas est viable ou non. Si non, on le dit. On a refusé 4 projets cette année comme ça.

2. Eval grid sur cas réels, avant le code. Le métier nous fournit 30 à 50 cas représentatifs, avec la réponse attendue. On construit la grille d'évaluation à partir de là. C'est notre baseline. Tout changement de modèle, de prompt, de RAG est rejoué dessus. Sans grille, on ne sait pas si on progresse — on a juste une impression.

3. Scoping prod dès J1. On liste l'auth (SSO Entra ID, Okta, ou autre), l'audit (logs, traçabilité), l'hébergement (souverain CH ou FR, ou cloud public selon contrainte), les coûts unitaires cibles, et le RGPD/nLPD. Si une contrainte est rédhibitoire, on le voit avant de coder. Le delta POC vers prod est chiffré dans le devis initial, pas découvert six mois plus tard.

4. Métriques business chiffrées, signées. Avant de coder une ligne, on signe avec le sponsor métier les métriques de succès : valeur de baseline, valeur cible, mode de mesure, fenêtre. C'est court (une page), c'est précis, et ça évite les débats de fin de POC. Si la cible n'est pas atteinte, on l'arrête.

5. Montée en charge par paliers. On déploie sur 5 utilisateurs, puis 20, puis 50. À chaque palier, on mesure coûts unitaires, qualité, et incidents support. On ne passe au palier suivant que si les trois indicateurs sont au vert. Sinon, on corrige avant d'élargir.

C'est aussi pour ça qu'on a construit Atlas : pour donner au métier un point d'entrée unique vers les docs internes, avec citations et hébergement souverain, plutôt que de re-développer un chatbot custom à chaque cas d'usage. Beaucoup de POC qu'on voit échouer auraient pu être évités en commençant par poser une couche de connaissance propre — sujet qu'on traite ailleurs (ChatGPT Enterprise ne suffit pas).

Et maintenant ?

Si vous avez un POC qui dort dans un tiroir, prenez dix minutes pour le passer au crible des cinq pièges. Sur lequel s'est-il fracassé ? Et surtout : est-ce qu'il était sponsorisé par un directeur métier, ou par la DSI ? La réponse à cette seule question explique déjà 60% des échecs qu'on voit.

L'IA appliquée à une PME, ce n'est pas un sujet de prouesse technique. C'est un sujet de discipline de cadrage. La bonne nouvelle, c'est que cette discipline s'apprend — et qu'elle se rentabilise dès le deuxième projet.