Pourquoi ton POC IA finit au placard (et la méthode pour l'éviter)

Le POC a bien marché. La démo a impressionné le comité de direction. Six mois plus tard, personne ne l’utilise, et plus personne n’en parle en réunion.

Ce scénario est tellement fréquent qu’il est devenu la norme. Et dans la quasi-totalité des cas, l’échec n’est pas technique : le modèle fonctionnait très bien. Le problème était ailleurs, et il était visible dès le cadrage.

TL;DR

Un POC IA meurt pour quatre raisons, et une seule est technique :

1. Il ne remplaçait aucune tâche existante. On a créé un nouvel usage que personne n’avait demandé.
2. Il a été construit sans les utilisateurs. L’outil arrive fini, il est contourné en trois semaines.
3. Personne n’avait défini ce qu’était le succès. Sans critère, aucun POC ne peut « réussir ».
4. Le passage à l’échelle n’avait pas été pensé. Ce qui marche sur 3 documents casse sur 3 000.

La méthode qui marche tient en cinq étapes : partir d’une tâche existante, cartographier le processus réel, réduire le périmètre, construire avec les équipes, mesurer avant/après.

Cause 1 : le POC n’automatisait aucune tâche existante

C’est la cause d’échec numéro un, et elle est presque toujours invisible au moment du lancement.

Un POC conçu autour de la question « qu’est-ce qu’on pourrait faire avec l’IA ? » produit systématiquement un usage nouveau : un assistant que personne n’a réclamé, un chatbot interne que personne n’ouvre, un outil de recherche que tout le monde préfère remplacer par une question posée à un collègue.

La reformulation qui change tout : au lieu de « qu’est-ce que l’IA peut faire ? », demande « quelle tâche vos équipes détestent-elles le plus ? ». La réponse arrive en dix secondes, et elle est presque toujours la bonne cible.

Une tâche existante possède trois propriétés qu’un nouvel usage n’aura jamais : quelqu’un la fait déjà (donc elle a de la valeur), on peut chronométrer le temps qu’elle prend (donc on peut mesurer le gain), et son résultat existe déjà (donc on peut comparer). C’est cette logique qui structure tous les cas d’usage réellement déployés en entreprise.

Cause 2 : le processus réel n’était pas celui qui est documenté

Voici ce qui se passe systématiquement quand on cartographie un processus sur le terrain : la procédure officielle décrit sept étapes. La réalité en compte onze, dont quatre contournements inventés par les équipes pour compenser les limites de l’outil en place.

Automatiser la procédure officielle produit un outil qui ne correspond à rien. Il est techniquement conforme et pratiquement inutilisable.

La cartographie qui marche se fait en observant, pas en lisant :

• Regarde quelqu’un faire la tâche, en vrai, sans le guider. Chronomètre.
• Note chaque outil ouvert, y compris le tableur personnel et les notes dans un carnet.
• Repère les contournements : ce sont les vraies contraintes du métier, et ce sont souvent eux qui doivent être automatisés en priorité.
• Identifie les points de décision : où faut-il un jugement humain, et où applique-t-on une règle ?

Ce dernier point conditionne toute l’architecture : il détermine ce qui revient au modèle et ce qui reste du code classique, exactement comme décrit dans l’article sur la différence entre déterministe et probabiliste.

Cause 3 : personne n’avait défini ce qu’était le succès

Demande à l’équipe projet, en fin de POC : « alors, c’est un succès ? ». Si la réponse commence par « ben, c’est prometteur », le critère n’avait pas été fixé.

Un critère de succès utilisable est chiffré, daté, et défini avant le lancement :

• « Le temps de traitement d’une demande passe de 12 à moins de 5 minutes en moyenne. »
• « 80 % des brouillons générés partent avec au plus une correction mineure. »
• « Les cinq personnes du service l’utilisent encore spontanément après un mois, sans relance. »

Le troisième est le plus révélateur, et le plus souvent oublié : l’usage spontané à un mois. Un outil que les gens continuent d’utiliser une fois que le chef de projet a arrêté de le rappeler en réunion a réussi. Tous les autres indicateurs sont secondaires.

Cause 4 : le passage à l’échelle n’avait jamais été testé

Un POC tourne sur un échantillon propre : dix documents bien choisis, un utilisateur qui connaît l’outil, aucune contrainte de délai. La production, c’est l’inverse sur les trois plans.

Trois ruptures surviennent presque toujours au changement d’échelle :

1. Le volume de données de référence. Un système qui pioche dans trois documents se comporte très différemment quand il doit trancher entre trois mille. C’est le point de rupture classique des projets de recherche documentaire.
2. La saleté des données réelles. Scans de travers, fichiers mal nommés, doublons, versions obsolètes qui traînent.
3. La diversité des utilisateurs. Chacun formule sa demande à sa façon, et rarement comme la personne qui a conçu la démo.

Le test qui vaut tous les POC : prends 30 cas tirés au hasard dans les données réelles (pas choisis) et fais tourner le système dessus. Le taux d’erreur obtenu est ton vrai taux d’erreur. Celui de la démo ne veut rien dire.

La méthode en 5 étapes

Étape 1 : Choisir une tâche existante, chronométrée

Une tâche que quelqu’un fait déjà, plusieurs fois par semaine, et dont on peut mesurer la durée. Si tu ne peux pas la chronométrer, tu ne pourras pas prouver le gain.

Étape 2 : Cartographier le processus réel et les outils

Par l’observation, pas par la documentation. Note tous les outils traversés, y compris ceux qui n’ont ni API ni export, ils déterminent la faisabilité technique bien plus que le choix du modèle.

Étape 3 : Réduire le périmètre jusqu’à ce que ça paraisse trop petit

Un service, un type de document, une équipe, un mois. Le réflexe naturel est d’élargir pour « montrer le potentiel ». C’est exactement l’inverse qu’il faut faire : plus le périmètre est étroit, plus le résultat est net, et plus l’extension ultérieure est facile à défendre.

Étape 4 : Construire avec les équipes, pas pour elles

C’est le facteur d’adoption numéro un, loin devant la qualité technique.

Concrètement : les utilisateurs finaux voient une première version imparfaite dès la deuxième semaine. Ils la critiquent, ils demandent des changements, ils obtiennent des changements. Un outil qu’ils ont contribué à façonner est un outil qu’ils défendront. Un outil qui arrive fini sera contourné, quelle que soit sa qualité.

Corollaire important : laisse-leur toujours la main. Un système qui produit un brouillon modifiable est adopté ; un système qui décide à la place de l’utilisateur est rejeté.

Étape 5 : Mesurer avant, mesurer après

Le « avant » se mesure avant de commencer. C’est évident, et c’est presque jamais fait, d’où l’impossibilité de démontrer quoi que ce soit à la fin.

Trois indicateurs suffisent : temps par tâche, taux de reprise, et usage spontané à un mois.

Et la conformité dans tout ça ?

Un point à traiter au cadrage, pas à la mise en production : dès qu’un traitement IA porte sur des données personnelles à une échelle significative, une analyse d’impact peut être requise. La CNIL détaille les cas concernés et la démarche dans sa page dédiée à l’analyse d’impact relative à la protection des données.

Découvrir cette obligation après le développement, c’est ajouter des semaines de délai sur un projet qu’on croyait terminé. La traiter à l’étape 2, c’est un point de checklist.

Checklist : lancer un projet IA qui survit au POC

• La tâche visée est déjà réalisée manuellement, par une personne identifiée.
• J’ai chronométré la durée actuelle de la tâche, avant tout développement.
• J’ai observé le processus réel, pas lu la procédure documentée.
• J’ai listé tous les outils traversés, y compris ceux sans API.
• Le périmètre initial me paraît trop petit : c’est bon signe.
• Les utilisateurs finaux ont vu une version imparfaite dès la deuxième semaine.
• L’utilisateur garde la main : la sortie est un brouillon modifiable, pas une décision.
• J’ai écrit le critère de succès chiffré, daté, avant de commencer.
• J’ai testé sur 30 cas tirés au hasard dans les données réelles.
• La question de la conformité a été posée au cadrage.

FAQ

Combien de temps doit durer un POC IA ?

Assez pour observer un usage réel sur plusieurs semaines, pas assez pour que le projet s’installe dans un flou permanent. Quatre à six semaines est un bon ordre de grandeur : une semaine de cartographie, deux de construction avec les utilisateurs, et trois d’usage réel mesuré. Un POC qui dure six mois n’est plus un POC, c’est un projet sans décision.

Faut-il commencer par un cas d’usage à fort impact ou à faible risque ?

Faible risque, systématiquement, pour le premier. L’objectif du premier projet n’est pas de transformer l’entreprise mais de lui apprendre à travailler avec de l’IA : découvrir les questions de données, de validation, de mesure, sur un terrain où l’erreur ne coûte rien. Le cas à fort impact vient en deuxième, quand ces réflexes sont acquis.

Que faire si les équipes sont hostiles au projet ?

Écouter la raison de l’hostilité avant de chercher à convaincre. Dans la majorité des cas, elle est légitime : crainte sur l’emploi, mauvaise expérience d’un outil précédent imposé, ou simplement le fait que le projet a été décidé sans elles. La réponse efficace est de leur laisser choisir la tâche à automatiser. Quand c’est la corvée qu’elles ont désignée qui disparaît, l’hostilité tombe d’elle-même.

Comment justifier le budget auprès de la direction ?

Avec le chiffrage du « avant » : nombre d’occurrences de la tâche par mois multiplié par la durée unitaire, converti en jours-homme. Ce chiffre est la valeur maximale récupérable. Le gain réel en sera une fraction, il faut déduire le temps de relecture humaine, qui ne disparaît pas. Une estimation honnête à 40 % du potentiel théorique est bien plus solide devant un comité qu’une promesse de suppression totale de la tâche.

Conclusion

Un POC IA ne meurt presque jamais d’un problème de modèle. Il meurt d’un périmètre trop large, d’un processus mal compris, d’utilisateurs consultés trop tard et d’un succès jamais défini.

La bonne nouvelle : ces quatre causes sont entièrement sous ton contrôle, et elles se traitent avant la première ligne de code. Une semaine d’observation sur le terrain vaut trois mois de développement à l’aveugle.

Avant de lancer ton prochain projet, pose une seule question à l’équipe concernée : « quelle tâche détestez-vous le plus ? ». Tout le reste découle de la réponse.

Cette méthode est détaillée dans la MasterClass « Les vrais cas d’usage de l’IA », construite à partir de six accompagnements en entreprise.