Pourquoi l’IA d’entreprise casse après le déploiement – et que faire à ce sujet

Attention : le problème n’est pas le modèle

En 2023, la ville de New York a lancé le chatbot MyCity pour aider les entreprises à naviguer dans les réglementations complexes. L’idée était simple : rendre les informations juridiques plus accessibles.

Dans la pratique, le système a produit des réponses qui étaient non seulement incorrectes, mais également trompeuses sur le plan juridique – allant des règles de pourboire à la discrimination dans le logement en passant par les lois sur les paiements.

Une audit ultérieure a révélé que 71,4 % des commentaires des utilisateurs étaient négatifs. Au lieu de résoudre les problèmes sous-jacents, la réponse a été d’ajouter des avertissements. Le chatbot est même resté en version « bêta » pendant plus de deux ans avant d’être arrêté.

L’échec n’était pas technique. Le système s’est effondré en production parce qu’il n’y avait pas de mécanisme pour assurer l’exactitude, pas de responsabilité claire et pas de moyen d’intervenir lorsque les choses allaient mal.

C’est le modèle derrière l’IA d’entreprise aujourd’hui : la technologie fonctionne, mais les organisations ne sont pas conçues pour l’exploiter de manière fiable une fois qu’elle est en ligne.

De l’essai à la production : où tout se dégrade

Construire un essai est assez simple – choisir un cas d’utilisation, sélectionner un modèle, préparer des données, trouver un sponsor. Exécuter un système en production est une tout autre ligue.

L’écart est comme la différence entre sauter dans une piscine et sauter de la stratosphère, comme Felix Baumgartner l’a fait en 2012. Mêmes principes physiques de base, conditions complètement différentes – et conséquences très différentes en cas d’échec.

En production, l’IA entre dans les flux de décision réels, interagit avec les clients et crée des conséquences juridiques et opérationnelles. C’est là que les lacunes commencent à apparaître – non dans le modèle, mais dans la façon dont il est géré.

L’Europe rend cela visible plus tôt que la plupart des régions. Les réglementations telles que le règlement AI de l’UE, le RGPD et le NIS2 n’entravent pas l’adoption – elles exposent si les organisations peuvent exploiter les systèmes d’IA sous des contraintes réelles.

En 2025, 55 % des grandes entreprises de l’UE utilisaient déjà l’IA. L’adoption se fait déjà à grande échelle. Le défi est ce qui se passe après le déploiement.

À ce stade, des questions opérationnelles de base commencent à émerger. Et souvent, personne ne peut y répondre : qui est responsable des sorties et des décisions autonomes de l’IA ? Que se passe-t-il lorsque le système se comporte de manière inattendue ? Et qui le détectera avant que les dommages n’atteignent les médias ?

La responsabilité repose sur l’entreprise, et non sur la technologie. Le chatbot d’Air Canada a fourni à un client des informations incorrectes sur les tarifs de deuil. Le client s’est fié à ces informations et a été ultérieurement refusé un remboursement. Un tribunal a décidé que la compagnie aérienne était responsable – le chatbot n’était pas une entité distincte.

Même problème, angle différent : le système McHire de McDonald’s a exposé des données sensibles de près de 64 000 candidats. La cause n’était pas une attaque sophistiquée – le login d’administrateur utilisait « admin » et « 123456 ». Le système semblait avancé. L’échec était élémentaire.

Lorsque vous ajoutez une gouvernance à un système en direct, il est déjà trop tard. Le déploiement d’un système est une décision technique. L’exploitation d’un système de manière fiable est une décision organisationnelle. Et c’est la partie que la plupart des entreprises sous-estiment.

Qui possède réellement le risque lié à l’IA ? Personne.

C’est le cœur du problème, et paradoxiquement, c’est la partie la moins discutée. Le département IT gère les infrastructures. Le département juridique gère la conformité. Les équipes commerciales poussent les cas d’utilisation. Mais personne ne possède le risque lié à l’IA de bout en bout.

Cela crée deux problèmes immédiats. La décision d’aller de l’avant ralentit – car personne ne veut prendre la responsabilité. Et la décision d’arrêter ralentit également – car personne ne sait qui peut le faire.

Les données le reflètent. Moins de 10 % des cas d’utilisation de l’IA passent de l’essai à la production, et la plupart des organisations luttent pour générer un impact commercial mesurable. Dans le même temps, de nombreuses entreprises déployant déjà l’IA – mais selon un rapport sur la maturité de la gouvernance, seulement 7 % avaient une gouvernance bien structurée et appliquée de manière cohérente.

Pourquoi cela se produit-il de manière si constante ? Parce que la plupart des cadres et des politiques d’entreprise définissent ce qui devrait se passer – et non qui est responsable lorsque cela compte. Lorsqu’un système commence à produire des sorties incorrectes à minuit un vendredi, la question n’est pas théorique. Qui agit ? Et qui a l’autorité de décider ?

Cela ne fait qu’empirer avec la taille. Un système peut être géré de manière informelle. Lorsque vous en avez trente, la responsabilité se fragmente entre les équipes, et personne n’a une vision d’ensemble.

La Banque Commonwealth d’Australie fournit un exemple clair. La banque a remplacé 45 travailleurs du service client par des robots vocaux IA, s’attendant à ce que la demande diminue. Elle n’a pas diminué. Les appels ont augmenté, les gestionnaires sont intervenus pour gérer le surplus, et la banque a dû réembaucher les 45 employés. Lorsqu’elle a été contestée, elle n’a pas pu démontrer que l’automatisation avait réduit la charge de travail.

Personne n’avait validé les hypothèses avant le déploiement. Personne n’était propriétaire du résultat lorsque ces hypothèses ont échoué. C’est à quoi ressemble un vide de responsabilité dans la pratique.

Il ne suffit pas d’avoir des règles. Vous avez besoin d’un mécanisme

La plupart des organisations ne manquent pas de politiques. Elles manquent de systèmes qui fonctionnent lorsque quelque chose va mal.

Une politique définit ce qui devrait se passer. Un mécanisme détermine ce qui se passe réellement – lorsque un modèle produit des sorties incorrectes, lorsque un fournisseur modifie quelque chose en arrière-plan ou lorsque le système commence à se comporter de manière inattendue.

Cette différence devient visible en production – lorsque les décisions doivent être prises dans des conditions réelles.

Ces échecs suivent une dynamique cohérente. Dans chaque cas, les mêmes lacunes opérationnelles apparaissent – sous différentes formes.

La propriété vient en premier

Chaque système d’IA déployé a besoin d’un propriétaire clairement responsable – une personne, et non une équipe ou un département, avec l’autorité d’approuver, de suspendre et d’arrêter.

Sans cela, ni le déploiement rapide ni l’intervention sécurisée n’est possible. Comme le montre l’exemple de la Banque Commonwealth, l’absence de propriété claire conduit directement à l’échec opérationnel.

Les données et la clarté juridique sont souvent manquantes

De nombreux systèmes sont mis en ligne sans flux de données documentés, sans base juridique vérifiée ou sans clarté sur les obligations qui s’appliquent une fois le système en production.

L’action du régulateur italien contre DeepSeek en 2025 illustre clairement cela. Le problème n’était pas la qualité du modèle – c’était l’incapacité à expliquer comment les données personnelles étaient traitées. Le résultat a été une interruption soudaine du service pour les utilisateurs européens.

Les tests ne reflètent rarement l’utilisation dans le monde réel

Les systèmes sont souvent évalués sur des scénarios où ils fonctionnent bien, mais pas sur les cas où l’échec aurait le plus d’importance.

Le chatbot MyCity est un exemple clair. Des cas de base – autour du droit du travail, de la discrimination dans le logement ou des règles de paiement – n’ont pas été détectés avant le déploiement. Une fois exposés à des utilisateurs réels, ces échecs sont devenus publics immédiatement.

Les tests ne concernent pas seulement les performances – ils concernent l’identification des points où le système échoue avant que les utilisateurs, les régulateurs ou les journalistes ne le fassent.

L’intervention est peu claire ou trop lente

Même lorsque les problèmes sont visibles, il n’y a souvent pas de déclencheur clair ou d’autorité pour suspendre ou arrêter le système.

Le Zillow Offers démontre cela à grande échelle. Le système utilisait un algorithme pour fixer les prix et acheter des maisons. Lorsque le marché s’est refroidi en 2021, le système a continué à acheter à des prix gonflés. Il n’y avait pas de mécanisme pour détecter le décalage à temps, et pas de point de décision clair pour l’arrêter. Le résultat a été des pertes dépassant 880 millions de dollars et la fermeture de toute la division.

La surveillance n’est pas la propriété

La surveillance est souvent réduite à des tableaux de bord, mais ce n’est pas ce qui empêche les échecs.

Ce qui compte, c’est la responsabilité définie : qui suit les signaux, quel déclencheur déclenche l’escalade et qui est censé agir.

Le cas de Deloitte Australia montre ce qui se passe lorsque cela manque. Un rapport gouvernemental comprenait des citations hallucinées et des références juridiques incorrectes car personne n’était explicitement responsable de la vérification des sorties avant la livraison. Le résultat a été un remboursement partiel et des dommages à la réputation.

IA agente : ce qui vient sera encore plus difficile

L’IA générative produit des sorties. L’IA agente prend des décisions. Cela change complètement le risque.

Au lieu d’une seule réponse à évaluer, une instruction peut déclencher une chaîne de décisions à travers les systèmes – des appels d’API, des accès aux données, des transactions, des mises à jour – souvent sans intervention humaine à chaque étape.

Lorsque quelque chose va mal, le problème n’est plus l’exactitude. C’est la traçabilité. Quelle étape a causé le problème ? Quelles données ont été utilisées ? Qui a autorisé l’action ? Dans de nombreux cas, ces questions sont difficiles à répondre après coup.

C’est là que les lacunes existantes deviennent critiques. La propriété peu claire, la surveillance faible et le manque d’intervention ne persistent pas seulement – ils s’accumulent. Une réponse erronée peut être corrigée. Une action erronée peut créer des conséquences avant que quiconque ne s’en aperçoive.

Les signaux précoces pointent déjà dans cette direction. Gartner estime que plus de 40 % des projets d’IA agente seront annulés d’ici la fin de 2027 – non pas en raison des limites du modèle, mais parce que les organisations luttent pour contrôler les coûts, les risques et les résultats. C’est le même modèle que nous voyons avec l’IA générative après le déploiement. Mais avec des enjeux plus élevés.

Les régulateurs répondent déjà avec un principe simple : l’automatisation ne supprime pas la responsabilité. Pour les organisations, cela crée une implication claire : si la propriété et le contrôle sont peu clairs aujourd’hui, passer à des systèmes agents ne résoudra pas le problème. Cela l’amplifiera.

Exploitez-le – ou perdez-le

L’IA n’est plus la contrainte. Les modèles sont largement disponibles, capables et de plus en plus commodifiés. Le véritable facteur de différenciation n’est pas si une organisation peut construire de l’IA – mais si elle peut l’exploiter de manière fiable une fois qu’il est en ligne.

C’est là que la plupart des échecs se produisent – non pas dans la façon dont les systèmes sont construits, mais dans la façon dont ils sont exécutés. Les organisations qui réussiront ne seront pas celles qui ont les modèles les plus avancés. Ce seront celles qui ont les structures opérationnelles les plus claires autour d’eux.

Cela peut être testé directement. Prenez votre système d’IA le plus important et répondez à trois questions :

• Qui peut l’arrêter ?
• Comment savez-vous lorsqu’il échoue ?
• Que se passe-t-il lorsqu’il échoue ?

Si ces réponses sont peu claires, le système n’est pas prêt pour la production.

Le modèle peut l’être. L’organisation ne l’est pas.