- IA
Pourquoi les POC d'intelligence artificielle n'arrivent pas en production
Ce n'est pas la qualité du modèle qui bloque. C'est le passage du portable au serveur, une métrique jamais tranchée, et une donnée dont la qualité n'a pas été mesurée avant de commencer.
· 4 min de lecture · AzerOps
La proportion de preuves de concept en intelligence artificielle qui n'atteignent jamais la production est élevée dans toutes les organisations. Les causes sont remarquablement constantes, et aucune n'est un problème d'algorithme.
Cause 1 : la métrique n'a jamais été tranchée
Le projet démarre avec un objectif formulé en langage naturel : « mieux prévoir la demande », « détecter les anomalies ». Personne n'a écrit ce que « mieux » signifie chiffré, ni par rapport à quoi.
Conséquence : à la fin du POC, l'équipe présente une précision de 87 %. La direction demande si c'est bien. Personne ne sait répondre, parce que la question n'a de sens que comparée à la pratique actuelle, qui n'a jamais été mesurée.
Le correctif tient en une phrase : avant la première ligne de code, écrire la métrique, sa valeur actuelle, et le seuil à partir duquel le projet est considéré comme réussi. Faire signer par le métier.
Cause 2 : le POC tourne sur des données que la production n'aura pas
L'extraction utilisée pour le POC a souvent été préparée à la main, nettoyée par quelqu'un qui connaît le sujet, et couvre une période choisie pour sa qualité.
En production, la donnée arrive en flux, avec ses valeurs manquantes, ses doublons et ses changements de format non annoncés. Le modèle qui atteignait 87 % en tombe à 60 %, et personne ne comprend pourquoi parce que le POC n'a jamais été confronté à cette réalité.
Le correctif : construire le POC sur le flux réel, avec ses défauts, dès le premier jour. C'est plus lent au démarrage et cela supprime la mauvaise surprise principale.
Cause 3 : le coût d'industrialisation n'a pas été budgété
Le POC coûte quelques dizaines de milliers d'euros. L'industrialisation — packaging, déploiement, pipeline de réentraînement, monitoring, gestion des erreurs, documentation d'exploitation, reprise par l'équipe interne — coûte souvent davantage.
Quand ce montant n'a pas été anticipé, il arrive au moment le plus défavorable : le POC est un succès, tout le monde est enthousiaste, et il faut demander un second budget supérieur au premier pour un projet qui « marche déjà ». Beaucoup de projets meurent exactement là.
Le correctif : présenter dès le départ un budget en deux tranches, avec la seconde chiffrée. Un prestataire qui ne mentionne pas le coût d'industrialisation dans sa proposition initiale ne vous rend pas service.
Cause 4 : personne ne sait qui exploitera le modèle
Un modèle en production a besoin d'un propriétaire : quelqu'un qui reçoit les alertes de dérive, décide d'un réentraînement, et répond quand un utilisateur conteste une prédiction.
Ce rôle n'est presque jamais attribué pendant le POC. Le modèle est livré à une équipe qui ne l'a pas demandé et n'a pas les compétences pour le diagnostiquer. Six mois plus tard, il se dégrade en silence.
La séquence qui fonctionne
- Deux semaines de cadrage : faisabilité sur données réelles, métrique arbitrée, baseline établie.
- Décision explicite de continuer ou d'arrêter, avec le budget complet des deux tranches.
- Développement du modèle avec la règle qu'il doit battre la baseline pour être déployé.
- Industrialisation, y compris le monitoring de dérive et le runbook d'incident.
- Transfert nommé, avec un propriétaire identifié et formé.
Chacune de ces étapes coûte moins cher que de refaire un POC de plus.