Ce qui empêche les projets d’IA de réussir à grande échelle

Un projet pilote d’IA réussi peut résumer un document, répondre à des questions sur les politiques, rédiger un e-mail, générer du code ou interroger une base de connaissances. Cela prouve la capacité à exécuter une tâche dans des conditions contrôlées. La production teste quelque chose de plus large : la capacité de l’entreprise à exploiter cette capacité de manière fiable, sécurisée et économique au sein d’un workflow réel.

L’organisation doit tester les données, les processus, les systèmes, les contrôles, l’économie et le modèle opérationnel autour du modèle. Une démonstration contrôlée peut isoler bon nombre de ces dépendances. Un workflow réel les met en évidence.

Un projet pilote d’IA réussi prouve la capacité à exécuter une tâche

Un projet pilote inspire confiance parce que les utilisateurs peuvent voir le système fonctionner. Ils soumettent des prompts et obtiennent des résultats utiles.

Les workflows d’entreprise ajoutent des dépendances autour de ces résultats. Par exemple, un système d’IA utilisé pour le traitement des sinistres peut avoir besoin d’accéder aux données de sinistres, aux documents de police, aux dossiers clients, aux règles d’approbation, aux systèmes d’identité et aux systèmes financiers. Il peut aussi nécessiter une autorisation spécifique à l’utilisateur, une piste d’audit et un circuit d’escalade défini.

Le succès d’un projet pilote montre que le système peut exécuter une tâche dans les conditions testées. Une décision de passage à l’échelle exige davantage de preuves : il faut savoir si l’entreprise peut transformer cette tâche en une capacité métier durable.

Un consultant indépendant en cloud et en IA indique observer cet écart depuis « les trois dernières années » tout en conseillant « de nombreuses entreprises » dans différents secteurs, tailles d’entreprise, environnements cloud et niveaux de maturité. Le consultant décrit des projets pilotes performants en démonstration, puis confrontés à des problèmes une fois connectés à des systèmes en production.

Les entreprises et les missions ne sont pas divulguées. Ces observations reflètent l’expérience d’un praticien et n’établissent pas un taux d’échec à l’échelle du secteur.

La production teste la capacité de l’entreprise

Un système d’IA en production s’insère dans un workflow existant et en hérite les contraintes. Un agent de service client peut avoir besoin de données CRM, tandis qu’un workflow d’approvisionnement peut dépendre de l’ERP et des systèmes financiers.

La connectivité n’est qu’une exigence parmi d’autres. La conception pour la production peut aussi nécessiter des contrôles d’identité, des autorisations, des pistes d’audit, des limites transactionnelles, des contrôles de latence, une classification des données, la gestion des exceptions, l’observabilité et des mécanismes de reprise. L’observabilité signifie disposer d’éléments probants permettant aux opérateurs de comprendre le comportement du système en production. L’organisation a également besoin d’un responsable de la performance après le lancement et d’un budget pour l’exploitation continue.

La question de la préparation est plus large que la seule qualité du modèle. Les dirigeants ont besoin de preuves que l’entreprise peut intégrer, sécuriser, gouverner, surveiller, financer et exploiter cette capacité dans la durée.

Un environnement contrôlé peut utiliser des documents sélectionnés, un nombre limité d’utilisateurs, des permissions simples, un faible trafic et une supervision étroite. Ces conditions définissent ce que le projet pilote a réellement testé. La préparation à la production exige de tester les conditions auxquelles le workflow réel sera confronté.

Cinq conditions que les projets pilotes peuvent masquer, mais pas la production

L’écart devient plus clair dans cinq domaines : les données, les processus, l’architecture, l’économie et la gouvernance. Chacun crée un test distinct de préparation à la production.

Le premier concerne les données. L’IA générative dépend du contexte qui lui est fourni. Un déploiement en entreprise peut se heurter à des dossiers clients fragmentés, des taxonomies produit contradictoires, des politiques obsolètes, des fichiers non classifiés, des métadonnées faibles, des règles de conservation incohérentes, des données dupliquées ou une propriété mal définie.

La génération augmentée par récupération (RAG) récupère des informations pertinentes de l’entreprise et les fournit à un modèle génératif comme contexte. Le RAG dépend toujours de la qualité et de la gouvernance de ces informations. Si deux documents se contredisent et que l’organisation n’a jamais décidé lequel fait autorité, les deux peuvent devenir disponibles comme contexte. Des règles d’accès floues créent un problème similaire : l’organisation doit décider quelles informations chaque utilisateur ou système peut récupérer.

Un système génératif peut formuler les informations fournies dans un langage fluide. Les entreprises ont donc besoin de règles claires concernant l’autorité, la propriété, la classification, l’accès et la qualité des données utilisées par le système.

Le deuxième domaine est le processus. L’IA agentique renforce l’importance de la conception des processus, car un agent peut récupérer des informations, appeler des outils, interagir avec des systèmes et exécuter une séquence d’actions vers un objectif.

Prenons un workflow avec des règles d’approbation non documentées, une gestion informelle des exceptions et des conditions d’arrêt non définies. Avant de déléguer des étapes à un agent, l’organisation doit définir le parcours attendu, les outils autorisés, les limites d’autorité, les circuits d’escalade, la surveillance et les procédures de reprise.

La conception des processus fait partie du déploiement. Le workflow doit être suffisamment défini et contrôlé pour que l’organisation puisse décider quelles actions le logiciel peut exécuter et à quel moment une intervention humaine est nécessaire.

Le troisième domaine est l’intégration et l’architecture. Un système autonome qui répond à des questions fonctionne dans un environnement différent de celui d’un système intégré à l’order-to-cash, au procure-to-pay, à l’onboarding client, aux opérations commerciales, à la livraison logicielle, au service terrain ou au traitement des sinistres.

L’usage opérationnel peut introduire des permissions, des interfaces système, des exigences de fiabilité, de la journalisation, de l’évaluation, de la surveillance, de la gestion des exceptions et des mécanismes de reprise. Il peut aussi nécessiter une coordination entre les plateformes ERP, CRM, supply chain, achats, RH, finance, sinistres, production et service client.

Ces dépendances doivent entrer dans la décision d’architecture. Un modèle peut produire le résultat attendu alors que le workflow environnant échoue parce qu’une action n’a pas l’autorisation requise, qu’un service amont est indisponible, qu’une exception n’a pas de circuit défini ou que les opérateurs ne peuvent pas reconstituer ce qui s’est passé.

Le quatrième domaine est l’économie. Un projet pilote contrôlé peut avoir un faible usage, des prompts courts, peu d’utilisateurs et une architecture simple. Un déploiement plus large peut avoir une structure de coûts différente.

Les prompts longs consomment davantage de tokens. La récupération peut ajouter des coûts d’embedding, de stockage, de recherche et d’orchestration, tandis que les agents peuvent effectuer des appels répétés au modèle et que les chaînes de modèles peuvent ajouter des coûts d’inférence. Le filtrage de sécurité, la journalisation, la surveillance, l’évaluation et la haute disponibilité peuvent encore augmenter les coûts d’exploitation.

L’unité économique doit correspondre au résultat métier. Le routage des modèles, la mise en cache, l’optimisation des prompts, la segmentation des charges de travail et les politiques de sélection de modèles plus petits ou moins coûteux peuvent alors être évalués à l’aune de ce résultat.

Le cinquième domaine est la gouvernance. Les exigences de sécurité, de conformité, de gouvernance et d’exploitation peuvent façonner l’architecture. Les systèmes d’IA utilisés avec des dossiers clients, des données réglementées, de la propriété intellectuelle, des documents juridiques, des recommandations financières, des informations sur les employés ou des contrôles opérationnels exigent des limites opérationnelles explicites.

Ces limites peuvent définir ce qui peut se dérouler automatiquement, ce qui exige une revue, ce qui doit être journalisé, où une approbation humaine est requise et quelles tâches l’organisation exclura de l’automatisation.

Elles exigent aussi une responsabilité continue. Les modèles, les prompts, les données, les réglementations, le comportement des utilisateurs et les politiques métier peuvent évoluer après le lancement. Le modèle opérationnel doit prendre en compte ces changements tout au long de la vie du système.

Ces cinq domaines créent des tests supplémentaires pour la capacité visée. Les intégrer dès le départ rapproche davantage le projet pilote des conditions de production.

Mesurer le résultat du workflow

La même logique s’applique à la manière dont une initiative d’IA est définie. Des objectifs tels que « améliorer la productivité », « renforcer l’innovation » et « moderniser le travail de la connaissance » sont trop larges pour établir une performance de référence, des métriques cibles, des hypothèses d’adoption, des contraintes de coûts, une tolérance au risque ou une responsabilité opérationnelle.

Une exigence métier doit identifier un résultat précis du workflow. Le temps de traitement des sinistres et la résolution au premier contact en sont des exemples. L’organisation peut alors définir sa propre base de référence, sa cible, sa contrainte de coût et son niveau de risque acceptable.

Un outil conversationnel peut utiliser le coût par interaction. Le traitement automatisé des sinistres peut utiliser le coût par dossier résolu. Une mesure proche du résultat métier visé aide les dirigeants à distinguer une adoption utile d’une simple augmentation de l’activité du système.

Cela relie la responsabilité technique à la responsabilité financière. Les équipes peuvent comparer les coûts d’inférence, d’infrastructure, de sécurité, de surveillance et d’exploitation au résultat généré. La finance peut évaluer l’évolution de la performance du workflow, et le responsable du système dispose d’un résultat mesurable à piloter après le déploiement.

Concevoir l’initiative d’IA autour du workflow de production

Un projet pilote doit constituer une partie d’une décision de préparation à la production. Son périmètre peut tester les dépendances qui comptent pour le workflow visé au lieu d’isoler la performance du modèle jusqu’à un stade tardif du projet.

Un projet d’IA peut démarrer sans transformation large de l’infrastructure de l’entreprise. Son périmètre doit néanmoins inclure la qualité des données, la conception des processus, l’intégration, la sécurité, la gouvernance, l’économie et le travail opérationnel nécessaires au résultat visé.

Ce périmètre modifie aussi l’ordre des décisions technologiques. Sélectionner un modèle, une base de données vectorielle, un service cloud, un outil d’orchestration, un copilot ou un framework d’agents avant de définir le workflow et le résultat risque d’optimiser un composant avant que l’organisation n’ait établi les exigences du système complet. Définir d’abord le workflow met au jour les dépendances tant qu’elles peuvent encore orienter l’architecture, les contrôles, les tests, la responsabilité et le financement.

Points clés à retenir pour les décideurs

• Préparation des données : La performance de l’IA dépend de la qualité et de la gouvernance des informations auxquelles elle peut accéder. Les dirigeants doivent établir des normes claires de propriété, d’autorité, de classification, d’accès et de qualité des données avant le passage à l’échelle.
• Préparation des processus : L’IA agentique exige des workflows avec des règles définies, des limites d’autorité, des circuits d’escalade et des procédures de reprise. Les dirigeants doivent clarifier le processus avant de décider quelles actions l’IA peut exécuter de manière autonome.
• Intégration et architecture : L’IA en production doit fonctionner de manière fiable à travers les systèmes existants, les permissions, les interfaces et les exceptions. Les décisions d’architecture doivent refléter les exigences du workflow complet plutôt que la seule performance du modèle.
• Économie de la production : Les coûts d’un projet pilote représentent rarement l’économie d’un déploiement à grande échelle. Les dirigeants doivent mesurer l’IA à l’aide d’unités pertinentes pour le métier, comme le coût par workflow terminé ou par dossier résolu, en incluant les coûts d’infrastructure, de surveillance, de sécurité et d’inférence.
• Gouvernance et responsabilité : L’IA en production exige des limites explicites pour l’automatisation, la revue, la journalisation et l’approbation humaine. Les dirigeants doivent aussi attribuer une responsabilité continue pour gérer les changements de modèles, de données, de politiques, de réglementations et de comportement des utilisateurs.