Du POC IA à la production : pourquoi ça bloque, et comment passer

Dans beaucoup d’organisations, on compte souvent plus d’une dizaine de POC IA. Certains ont été lancés par la DSI, d’autres par une direction métier, quelques-uns par une équipe motivée avec un abonnement à un assistant. La plupart ont produit une démonstration réussie. Très peu tournent tous les jours, sur des données réelles, pour des utilisateurs qui n’ont pas participé au projet.

On cite souvent des chiffres spectaculaires sur ce taux d’échec. Je préfère m’en tenir à ce que j’observe : le passage du POC à la production est le moment où la plupart des projets IA s’arrêtent, et les raisons se ressemblent d’une organisation à l’autre.

Un POC prouve une chose, la production en exige dix

Un POC répond à une seule question : le modèle sait-il faire la tâche, sur un échantillon choisi, dans de bonnes conditions ? C’est utile. Mais c’est une petite partie de ce qu’un système en production doit garantir.

Ce que le POC ne teste presque jamais :

• Les données réelles, avec leurs trous, leurs formats hétérogènes et leur vocabulaire maison.
• L’intégration dans les outils existants : CRM, outil de ticketing, référentiels, droits d’accès.
• Le traitement des erreurs : que se passe-t-il quand le système se trompe, et qui reprend la main ?
• Le coût d’exploitation à volume réel, pas sur cent requêtes de test.
• Le changement de travail pour les équipes qui vont vivre avec l’outil.
• La conformité : RGPD, et désormais AI Act selon le cas d’usage.
• La mesure : un indicateur de référence avant, un suivi après.

Chacun de ces points peut, seul, empêcher la mise en production. Ensemble, ils expliquent pourquoi une démo réussie ne dit presque rien de la suite.

Le ratio 70 / 30

Les transformations IA réussies ressemblent à 70 % à une transformation organisationnelle, et à 30 % à un projet technique.

C’est la conviction qui structure mon travail. Quand on inverse ce ratio, on passe des semaines à comparer des modèles et à affiner des prompts, alors que le point de blocage est ailleurs : personne n’a décidé qui porte le système, ni comment le travail des équipes change le lundi matin.

Les cinq blocages que je retrouve le plus souvent

1. Pas de propriétaire métier. Le POC appartient à l’équipe qui l’a construit. Personne, côté opérations, n’est responsable du résultat ni des arbitrages.
2. Un succès défini en démo, pas en indicateur. « Ça marche bien » ne survit pas à la première réunion budgétaire. Il faut un chiffre, une référence de départ et une cible.
3. Des données de POC qui ne ressemblent pas à la production. Un échantillon nettoyé à la main donne une précision que le flux réel ne retrouvera pas.
4. Un processus qui ne bouge pas. On ajoute l’IA par-dessus l’existant au lieu de redessiner le circuit : qui reçoit quoi, qui valide, qui escalade.
5. Le risque et la conformité arrivent à la fin. Le juridique découvre le projet au moment du go-live, et tout s’arrête pour des mois.

Aucun de ces blocages ne se règle avec un meilleur modèle.

Ce qu’il faut décider avant d’écrire une ligne de code

Le cadrage est la partie la plus rentable du projet. Avant de construire, je demande aux équipes de répondre par écrit à six questions :

1. Quel problème opérationnel résout-on, formulé en volume, en délai ou en coût ?
2. Quel indicateur prouve le résultat, et quelle est sa valeur aujourd’hui ?
3. Qui est le propriétaire métier, avec le pouvoir d’arbitrer ?
4. Quel est le périmètre, et surtout ce que le système ne fera pas ?
5. Que se passe-t-il quand il se trompe : escalade, reprise humaine, traçabilité ?
6. Quel budget d’exploitation est acceptable à volume réel ?

Si l’on ne sait pas répondre, le projet n’est pas prêt. Ce n’est pas un échec : c’est une information, obtenue avant d’avoir dépensé le budget de construction.

Le passage : un périmètre borné, mesuré, puis élargi

La méthode qui fonctionne n’a rien de spectaculaire. Elle consiste à réduire le périmètre jusqu’à ce qu’il soit maîtrisable, puis à l’élargir sur preuve.

1. Cadrage opérationnel de quelques jours : les six questions ci-dessus, les données réellement disponibles, les contraintes.
2. Pilote en conditions réelles sur un segment limité : une catégorie de demandes, une équipe, un site.
3. Instrumentation dès le premier jour : chaque décision du système est journalisée et comparable à la référence.
4. Boucle d’amélioration avec les équipes terrain, qui signalent les erreurs et enrichissent le vocabulaire métier.
5. Élargissement par paliers, chaque palier conditionné à des seuils fixés à l’avance.

C’est la logique d’un produit minimum viable appliquée à l’IA : on cherche à apprendre vite sur le terrain, pas à impressionner en démo. Et c’est la logique d’une roadmap des hypothèses : chaque palier valide une hypothèse explicite.

Ce que montre le cas Home Partners

Chez Home Partners of America, filiale du groupe Blackstone, la mission portait sur le contact center d’un parc résidentiel de 30 000 unités. Le système IA qualifie, route et résout les demandes des locataires. Il a été déployé en production sur l’ensemble du portefeuille, dans les contraintes opérationnelles et réglementaires d’un opérateur immobilier.

Mission réalisée chez Home Partners of America, filiale du groupe Blackstone, période 2022 – 2023. Données publiques, parties prenantes informées, dans le respect des accords de confidentialité applicables.

Ces trois chiffres ne mesurent pas un modèle. Ils mesurent une chaîne opérationnelle : ce qui est résolu sans agent, ce qui est bien compris dans la langue du métier, et le temps que met une demande à être réglée. C’est exactement ce que la production exige, et ce qu’un POC ne mesure pas. J’explique comment instrumenter ces indicateurs dans mesurer un assistant IA de support.

Questions fréquentes

Combien de temps faut-il pour passer d’un POC à la production ?

Cela dépend du périmètre et de l’état des données, mais un plan réaliste se raisonne en mois, pas en semaines. Un horizon de 3 à 6 mois pour mettre en production les meilleurs candidats d’un portefeuille est un ordre de grandeur sain, à condition d’avoir tranché les questions de propriété et de mesure dès le départ.

Faut-il arrêter de faire des POC ?

Non. Il faut arrêter de faire des POC sans critères de sortie. Un POC utile précise dès le départ l’indicateur visé, le propriétaire métier et la décision qui sera prise selon le résultat : industrialiser, réorienter ou arrêter.

Qui doit porter un projet IA en production ?

Un responsable métier, appuyé par la technique. Si le projet est porté uniquement par la DSI ou par une équipe innovation, il restera un projet. Le propriétaire est celui qui vivra avec le résultat et qui peut changer le processus autour.

Et maintenant, par où commencer ?

Selon votre situation, j’interviens sous trois formats bornés :

• Audit AI Production (15 à 20 jours) pour les organisations qui accumulent 5 à 15 POC dont peu passent en production : diagnostic du portefeuille et plan de mise en production sur 3 à 6 mois.
• AI Act Readiness (30 à 45 jours) quand l’IA touche les RH, le scoring, la biométrie ou des infrastructures : inventaire, classification Annexe III et plan de conformité opérationnel.
• Transformation IA opérationnelle (60 à 90 jours) pour transformer une chaîne support ou ops à fort volume : conception et lancement d’un système en production, borné et mesuré.

Toutes commencent par un cadrage opérationnel de 5 à 7 jours. Pour les PME, ClairAI propose aussi des applications métier et un guide sur le budget d’une application métier.