Beaucoup d’ETI et de grands comptes ont multiplié la conception de POC et POV IA ces derniers mois. Les directions IT et data butent pourtant au moment critique : transformer des expérimentations locales en leviers de valeur fiables et scalables au niveau de l’entreprise.
Les enquêtes récentes (ex : The State Of AI de McKinsey de mars 2025 et le rapport Deloitte “The State of Generative AI in the Enterprise – 2024« confirment ce décalage : pour plus de deux tiers des organisations, moins d’un tiers des initiatives GenAI passeront à l’échelle à court terme, et l’impact réel de la réussite des déploiements dépend de la ré-architecture des workflows, pas seulement des modèles.
Pour partager des retours concrets, nous croisons les regards d’Evan, MLOps, qui travaille à proposer les outils et standards pour permettre aux équipes de partager, déployer et opérer et de Renaud, ML Engineer, qui intervient auprès de plusieurs équipes pour industrialiser des projets de data science.
Quels sont, selon vous, les principaux freins et risques lorsqu’il s’agit de passer des POCS IA réalisés par des Data Scientists à l’échelle de l’entreprise ?
Renaud :
Le premier sujet, c’est la coordination et la vision d’ensemble. Les Proof of Concept naissent côté data science, le besoin est poussé par le produit, et la tech arrive à la fin… Les équipes de Data Scientists multiplient les POC, souvent sans rationalisation et sans architecture d’ensemble, avec des zones de recouvrement. Il arrive par exemple que des équipes travaillent et investissent du temps sur des sujets proches sans en avoir conscience. En production, cela se traduit alors par une mosaïque d’assets hétérogènes et un manque de règles communes. Une de nos priorités est alors de reprendre l’existant avec les équipes tech, de rationaliser et reconnecter proprement.
Le deuxième frein, c’est l’écart entre le succès d’un POC et la réalité de la prod. Le POC tourne sur un échantillon maîtrisé ; en prod, des valeurs et des cas non prévus apparaissent. L’impact des évolutions est souvent difficile à mesurer, si elle ne s’appuie pas sur des tests de non-régression fiables. À cela s’ajoute un décalage de temporalité : la data science évolue vite — ce qui marchait il y a un an peut déjà être obsolète — alors que les comités de cadrage au niveau des équipes techniques sont parfois lourds. Sans alignement des cadences, soit vous déployez trop vite du fragile, soit vous arrivez trop tard avec quelque chose qui n’est plus au bon standard.
Enfin, il y a un enjeu d’alignement sur les critères de succès. Le benchmark scientifique peut être bon, mais il peut être décorrélé des KPI côté business ou des exigences côté tech : latence, coût par transaction, tolérance à l’erreur, UX. Tant que ces critères ne sont pas co-définis entre produit, data science et tech, la réussite reste subjective et difficile à mesurer !
Un dilemme est l’écart entre d’un côté la volonté de se détacher des contraintes tech pour innover, et de l’autre l’enjeu final de créer de la valeur métier dans un environnement réel. Les deux doivent bien s’aligner à un moment et c’est ce merge qui est complexe !
Evan :
En effet, du côté des expérimentations autour de l’IA, tout va très vite : nouveaux outils, nouveaux modèles chaque semaine. Nous distinguons l’exploration utile — liée à un cas d’usage précis — d’une exploration “pour le plaisir”. Nommer et prendre conscience de cette distinction dans notre rôle de MLE ou MLOps aide à arbitrer, à clôturer proprement ce qui n’ira pas en prod, et à concentrer l’effort là où il y a de la valeur.
Bien sûr, c’est lorsque nous industrialisons que les contraintes réelles apparaissent. Le POC peut très bien fonctionner à son échelle, dans son périmètre précis et devoir être réadapté complètement pour être basculé en environnement production.
Je noterai en particulier 3 prismes. Sur la donnée, le POC travaille souvent sur un échantillon et en prod, nous découvrons des valeurs non prévues ! Cela impose d’uniformiser et de vérifier systématiquement les cas non prévus. La gestion du coût apparait aussi lors de la MEP et doit être anticipé pour éviter les mauvaises surprises : gérer des dizaines ou centaines de milliers de produits en production change complètement la donne ! Sur ce point, nous reviendrons aussi par la suite sur l’importance de lier cela à une démarche FinOps. La sécurisation apporte aussi des contraintes. Si la confidentialité des données est normalement réglée dès le POC, la gestion de l’authentification, l’intégrité et la traçabilité des flux ne sont pas toujours anticipées.
Face à cela, il faut accepter d’itérer en production de manière contrôlée. Côté business, la frilosité est compréhensible sur les périmètres critiques ; dans certains cas, nous excluons un lot plutôt que de risquer une régression globale.
Dans le cadre de vos derniers projets de passage d’un POC à l’échelle, quelles décisions techniques ont été décisives ?
Evan :
De nombreux algorithmes utilisent Snowflake. Cependant, lorsque le contexte et les enjeux business impliquent de faire du temps réel, il faut trouver des alternatives. C’est un excellent entrepôt analytique pour explorer, beaucoup moins pour opérer en forte volumétrie : temps de synchronisation, coût qui peut exploser avec la multiplication des requêtes…. Cela implique une transformation technologique qui est complexe !
Pour poursuivre sur ces changements de volumétrie, il y a la dimension d’optimisation et de contrôle. Nous pouvons basculer du mode synchrone à asynchrone pour gagner en performance. Sur les LLM, nous avons mis en place un rate limiting, parce que sans garde-fous l’entreprise surconsomme des tokens pour rien. Un autre point oublié en POC, c’est l’historisation des appels, ainsi que le monitoring et le logging qui sont utiles pour piloter et auditer les usages.
Renaud :
Les Data Scientists travaillent sur des notebooks et non du code exécuté de bout en bout : ils font un appel, attendent le retour, font un autre appel… et n’ont pas la culture ni les bonnes pratiques de développement. Ce n’est bien sûr pas possible dans un environnement avec de fortes volumétries, des enjeux de performance et de fiabilité. Je reprends donc l’ensemble de l’architecture et de la structuration du code.
L’adaptation de l’expérimentation IA en production doit aussi prendre en compte l’intégration dans les systèmes existants. C’est-à-dire l’ingénierie et la conception en plus de la restructuration du code. Les Data Scientists se focalisent sur les données d’entrée et de sortie, pas le système global. Je commence donc par modéliser avec les équipes de Data Science le chemin fonctionnel afin d’identifier les contraintes liées à l’environnement final.
Le troisième point, c’est la stack technologique autorisée en production ! Dans les POC il peut y avoir du Shadow IT et cela implique de basculer sur des composants, outils et technologies approuvés par la DSI.
Au-delà des enjeux techniques de déploiement de l’IA à l’échelle, des transformations organisationnelles et culturelles sont-elles aussi nécessaires ?
Renaud :
Oui, clairement. Les équipes tech doivent s’embarquer dans ces sujets, aux côtés des profils MLE et Data Scientists. Elles sont parfois réticentes à s’intéresser aux projets IA et restent sur une vision « boite noire ». C’est un enjeu d’acculturation et d’efficacité : chacun doit comprendre les tenants et aboutissants des autres (produit, DS, IT), sinon les temporalités s’entrechoquent — processus de prod lourds côté tech vs rythme d’itération côté IA. Politiquement, cela suppose aussi d’assumer la responsabilité sur les produits IA en production : gouvernance, critères d’acceptation, et qui décide quoi.
Les silos entre services sont encore plus présents dans les projets IA !
Sur la stratégie, il faut trancher des choix structurants, par exemple entre disposer d’une infrastructure en interne et des solutions cloud. La décision dépend de chaque contexte, chaque niveau de maturité et de l’expertise FinOps de l’organisation. Sera-t-il plus rentable d’acheter du matériel en interne malgré l’évolution rapide des modèles ? Comment optimiser la consommation dans le cas de solutions Cloud ?
Evan :
Les métiers ont leurs règles, les PO leurs objectifs, les Data Scientists leurs cibles d’innovation, l’IT la sécurité de l’environnement de production : chacun voit une partie seulement des enjeux. Notre travail, côté MLE/MLOps, est aussi d’ouvrir ces silos, de renforcer la communication entre Data Science et IT, identifier des rôles clairs et une politique de responsabilité sur les services IA.
Dans mon contexte de mission, l’utilisation d’une plateforme centralisée, Azure OpenAI – est déjà un premier pas important pour garder le même écosystème entre exploration et prod. L’ajout d’une surcouche d’API Management permet de découper la consommation et la traçabilité par projet, en définissant nos propres règles d’accès afin de monitorer précisément les coûts et les appels.
Côté culture, je plaide pour des expérimentations simplifiées en production, à faible risque et limitées dans le temps : parfois, il est impossible d’évaluer un POC hors prod à cause d’écarts de données (préprod rafraîchie mensuellement) ou de matériel non iso (GPU). En encadrant ces tests, nous anticipons de nombreux aspects sans mettre l’exploitation en danger et surtout nous pouvons mesurer l’intérêt réel du cas d’usage IA
Nous observons des évolutions au niveau des directions : les rôles bougent, le service Data Science se repositionne dans l’organisation. L’objectif, c’est d’avoir des équipes plus transverses..
Quelles sont vos recommandations pour une entreprise qui souhaite structurer le passage à l’échelle de ses POC IA ?
Renaud :
Mon premier conseil, c’est de poser une structure commune. Dans mes missions, nous avons conçu des templates qui donnent, dès le départ, une organisation claire et des bonnes pratiques partagées quand nous lançons un nouveau projet MLE.
Je suis convaincu qu’il faut davantage structurer toute la chaîne, de la data science jusqu’à la production : les expérimentations sont nécessaires, mais dès qu’un minimum de maturité est atteint, Machine Learning Engineer et IT doivent intervenir pour intégrer les contraintes de prod, fixer des benchmarks alignés au métier et mesurer le résultat.
Il faut challenger plus tôt l’intérêt métier réel des expérimentations IA et ne pas attendre la bascule en production !
Ensuite, mettez l’observabilité au cœur du dispositif : pas seulement “est-ce que ça tourne ?”, mais aussi les erreurs, performances et l’impact métier ! L’IA a un coût : il faut évaluer la valeur produite et retirer un asset si nécessaire. J’encourage aussi des datasets standardisés et des GO/NO-GO plus tôt. Il faut sortir du tunnel séquentiel de l’expérimentation par le data scientist à la production.
Renforcer la mesure de la valeur réelle, et l’alignement sur les métriques à suivre permet de sortir du côté « Hype de l’IA ». Les expérimentations IA mises en production qui ont finalement un impact négatif ou nul ne sont pas toujours décommissionnées !
Enfin, acceptez d’itérer, même en production. La frontière POC/Prod doit se réduire. Intégrer plus tôt les processus IT dans les POC crée un vrai gain à la mise à l’échelle, même si cela “ralentit” un peu l’exploration au début.
La data science n’est pas une science exacte — elle itère ; l’IT vise la prévisibilité — elle sécurise. Chacun doit faire un pas : c’est à ce prix que les POC deviennent des services utiles et durables.
Evan :
Ma première préconisation, c’est de mettre en place un canal de discussion et une instance bimensuelle entre toutes les personnes qui réalisent des expérimentations IA.
L’objectif : arrêter les doublons et les recoupements — si quelqu’un lance un outil de reformulation, éviter d’en avoir trois qui font la même chose ! Centralisez les idées, mutualisez les ressources et favoriser un fonctionnement par brique réutilisable plutôt qu’une “compétition” du meilleur algo. Cette recentralisation passe aussi par une historisation et une classification des POC : une nouvelle équipe doit pouvoir s’ajouter à une expérimentation au lieu de repartir de zéro.
Côté plateforme, nous mettons les services à disposition des équipes de Data Science qui souhaitent tester leur modèle. En échange, recevoir des retours structurés comme les ratios coût/performance, leurs feedbacks… sont des insights essentiels pour améliorer la plateforme et les pratiques. Nous capitalisons ainsi aussi les bonnes pratiques pour les prochaines demandes.
Enfin, avoir une démarche FinOps mature (LIEN page expertise FINOPS) est bien sûr importante pour maîtriser les coûts. En production, les appels LLM peuvent exploser en quelques heures. L’IA est censée in fine améliorer la performance de l’organisation et réduire les dépenses ; cela implique de piloter les coûts, les budgets et la consommation, ainsi que d’être alerté dès qu’il y a des dépassements.
Comment Inside se positionne et accompagne ces clients sur la mise à l’échelle de l’IA dans l’entreprise ?
Renaud
Chez Inside, nous avons intégré l’IA dans toutes nos expertises. L’IAxLab, notre laboratoire dédié à l’IA nous apporte un cadre transversal pour tester vite, en sécurité, documenter les apprentissages et préparer l’atterrissage vers la production (idéation, MVP testables, retours d’expérience). Nous intervenons ainsi depuis l’acculturation des organisations, l’accompagnement au changement des processus, la conception des POVs, POCs et MVP jusqu’au conseil et aux prestations opérationnelles d’industrialisation.
Evan :
Et plus spécifiquement sur la mise à l’échelle, nous intervenons aussi là où la valeur bascule : du POC utile au service opérable ! La complémentarité entre Renaud, ML Engineer, et moi-même, MLOps, se retrouve dans les dispositifs qu’Inside peut mettre en place pour structurer la chaine de bout en bout et déployer les environnements et les architectures adaptées à l’industrialisation des usages IA.
Vous souhaitez optimiser vos processus de mise à l’échelle de l’IA ?