Projet IA en entreprise : pourquoi les POC échouent et comment les rendre utiles

Ce qu’on appelle POC ici

Une phase courte, périmètre restreint, destinée à décider : on continue, on recadre, ou on arrête. Ce n’est pas une démo commerciale. Ce n’est pas non plus « la mise en production en petit ».

Quatre causes d’échec fréquentes

Les échecs que l’on voit se répètent pour des raisons banales :

1. Pas d’indicateur. « Voir si l’IA marche » n’est pas un critère. Il faut un nombre décidé avant (délai de traitement d’un type de dossier, taux d’erreur vs un échantillon annoté, volume d’une file).
2. Données inaccessibles. Extraire un CSV une fois n’est pas un pipeline. Si personne n’a le droit d’ouvrir le SI, le POC s’arrête au slide.
3. Hors SI. Un notebook sur l’ordinateur du consultant ne dit rien de l’intégration (identité, logs, droits, latence).
4. Pas de no-go. Sans date et sans seuil, le prototype dure et devient une dette.

Ce que les cadres publics rappellent

Le NIST AI RMF demande de gouverner, cartographier, mesurer et gérer le risque. Un POC sans mesure n’entre pas dans « measure ». Les principes OCDE sur l’IA (responsabilité, transparence, robustesse) ne prescrivent pas un format de POC ; ils rendent visible l’absence de responsable et de trace quand le prototype est « juste pour voir ».

Déroulé utile

1. Énoncé du problème métier en une phrase, avec un indicateur.
2. Liste des accès (données, outils, interlocuteur nommé).
3. Construction volontairement étroite — un flux, pas un produit.
4. Test sur un périmètre réel, même petit.
5. Lecture du résultat contre l’indicateur. Décision écrite : industrialiser, recadrer, arrêter.

La mise en production n’est incluse que si le contrat le dit. Homi peut fournir un profil pour cette phase via le staffing IA nearshore ; ce n’est pas « la prod en petit » par défaut. Voir aussi comment juger le profil avant de lancer le POC.