Le problème n’est plus de monter un projet d’IA. C’est de le faire entrer dans votre entreprise.

Pendant un temps, nous avons eu un problème assez simple : savoir si l’intelligence artificielle pouvait créer de la valeur dans les entreprises. Cette question commence aujourd’hui à perdre de son intérêt.

BearingPoint, un cabinet de conseil, vient de publier une étude menée en août auprès de 1 050 dirigeants d’organisations publiques et privées en Europe, aux États-Unis et en Chine. Parmi les organisations qui utilisent déjà l’IA dans leur activité, 74 % disent en constater des effets mesurables sur leurs coûts ou sur leurs revenus. Pourtant, 13 % seulement déclarent avoir étendu leurs projets en suivant de bout en bout le plan sur lequel ils avaient été approuvés. Cela ne veut pas dire que les autres ont échoué : une expérimentation sert justement à changer d’avis.

Mais il y a un détail plus intéressant. Le premier obstacle cité, d’après le communiqué, est la complexité des règles. Vient juste après l’intégration avec les systèmes et les processus que les entreprises utilisent depuis longtemps, et plus de la moitié des dirigeants jugent décisif de pouvoir compter sur des données fiables. Bref, le modèle a souvent déjà montré qu’il savait faire le travail. Ce qui coince vient après.

Des chiffres à lire avec prudence

Ces chiffres sont à lire avec prudence. BearingPoint vend précisément le genre de travail dont parle l’étude, et un sondage auprès de dirigeants n’est pas une statistique officielle. Il ne décrit pas non plus forcément les entreprises italiennes. L’Italie figure bien dans l’échantillon, mais elle n’apparaît que dans l’infographie, sous une rubrique « autre Europe » avec l’Autriche, l’Irlande, les Pays-Bas et la Suisse, et n’a jamais de chiffre à elle. Les 74 % aussi méritent d’être lus jusqu’au bout. Ils sont calculés sur les 685 organisations qui ont déjà quelque chose en production, et la page de l’étude ajoute que pour près de la moitié l’effet reste inférieur à 4 % des coûts et à 2 % des revenus.

Pour l’Italie, une statistique officielle existe, et elle donne des chiffres bien plus bas. Selon l’ISTAT, l’institut national de statistique italien, 16,4 % des entreprises d’au moins dix salariés utilisaient en 2025 au moins une technologie d’intelligence artificielle : 53,1 % des grandes, 15,7 % des petites et moyennes. Parmi celles qui l’utilisent, une sur trois n’indique aucune finalité pour l’entreprise, contre 15,5 % un an plus tôt. L’institut parle d’une adoption de plus en plus répandue mais encore peu structurée.

La même prudence vaut pour les pourcentages qui circulent depuis deux ans sur la part des projets d’IA qui échouent. Les 95 % attribués au MIT viennent d’un rapport qui qualifie lui-même ses chiffres de « directionally accurate », c’est-à-dire indicatifs, parce qu’ils reposent sur des entretiens et non sur des données officielles des entreprises. Le « plus de 80 % » que l’on cite comme un chiffre de la RAND est une estimation que la RAND reprend d’un article de Fortune de 2022 : ses 65 entretiens portaient sur les causes des échecs, pas sur leur fréquence. Les 30 % de Gartner étaient une prévision pour 2025, faite en 2024. Ces chiffres mesurent des choses différentes, et mis bout à bout ils disent surtout qu’à la question « combien échouent » il n’y a pas une seule réponse. Cela arrive aussi en l’espace de quelques heures : la dépêche en anglais de Reuters sur l’étude de BearingPoint écrit que moins d’un tiers des entreprises ont réussi à dépasser le stade des projets pilotes. Ce chiffre ne figure pas dans le communiqué, et la répartition que publie BearingPoint indique que 65 % des organisations ont déjà quelque chose en production.

D’autres font remarquer que la difficulté de faire entrer une technologie nouvelle dans une organisation complexe est aussi vieille que l’informatique d’entreprise : nous l’avons connue avec les progiciels de gestion, puis avec le passage au cloud. Beaucoup d’entreprises en sont encore à explorer, et il est sain qu’un projet change de route quand il découvre que certaines hypothèses de départ étaient fausses. L’étude elle-même dit que près des trois quarts ont revu le périmètre initial ou se sont étendus moins que prévu, ce qui n’est pas la même chose qu’échouer. Je le pense aussi, et c’est pourquoi je ne bâtis pas mon raisonnement sur l’idée que 13 %, c’est peu. Ce qui m’intéresse, c’est de comprendre où se logent, de plus en plus souvent, les problèmes qui apparaissent après la démonstration. À mon avis, ils se logent dans l’environnement où nous voulons faire travailler le modèle.

« Très bien, maintenant on l’utilise tous »

Quiconque, dans une entreprise ou une administration, a validé un essai réussi connaît le jour où quelqu’un, satisfait, lance : « Très bien, maintenant on l’utilise tous ». À partir de là, la question change. Tant qu’il s’agissait d’un essai, il suffisait que le système fonctionne sur cinquante documents choisis avec soin, avec celui qui l’avait construit assis juste à côté. Désormais il doit fonctionner sur les vrais documents, respecter les règles sur qui peut voir quoi, tenir face aux exceptions et rester compréhensible pour des gens qui n’ont pas participé au projet.

Chaque étape répond à une question différente. La démonstration sert à savoir si le système sait faire une chose. L’expérimentation vérifie s’il sait la faire sur une partie de notre travail, avec de vraies données et de vrais utilisateurs. Il faut ensuite savoir si nous sommes capables de le faire fonctionner toujours de la même façon, en gardant la main sur les coûts et sur les accès. La dernière question est d’une autre nature : pouvons-nous nous permettre d’en dépendre ? Quand une activité entre dans le travail de tous les jours, il ne suffit pas que le système fonctionne en moyenne. Il faut savoir qui en répond, comment on s’aperçoit que quelque chose tourne mal, ce qui se passe si le modèle cesse de répondre, quelle version a produit tel résultat et comment on revient en arrière. Ce que l’on voit pendant la démonstration n’est que le début du travail.

L’essai réussit parce que quelqu’un le protège

Une expérimentation peut réussir précisément parce qu’elle écarte, pour quelques semaines, presque tout ce qui rend l’usage quotidien difficile. On travaille sur des données propres, on choisit des utilisateurs convaincus, on resserre le périmètre, et les exceptions sont connues d’avance. L’équipe technique observe chaque étape, et quand il se passe quelque chose d’étrange, quelqu’un le corrige à la main avant que cela ne devienne un problème.

Ces conditions sont très utiles pour savoir si une capacité existe, et elles sont l’inverse de ce qui viendra ensuite. Les données seront ce qu’elles sont, les utilisateurs n’auront participé à rien, l’équipe technique travaillera sur autre chose, et le système devra s’expliquer tout seul la semaine où celui qui l’a construit est en congé. D’une certaine façon, l’essai réussit parce que l’organisation le protège, et l’usage quotidien lui retire justement cette protection.

Rédiger l’offre, c’était la partie facile

J’imagine une entreprise de taille moyenne qui vend des services à d’autres entreprises et veut un assistant pour aider ses commerciaux à préparer leurs offres. Pendant l’expérimentation, l’assistant reçoit la grille tarifaire, dix offres déjà envoyées, les fiches des services et un modèle de document. En quelques minutes il produit un premier jet étonnamment bon, et l’on décide de le donner à toute l’équipe commerciale.

C’est là qu’on découvre que la grille officielle ne correspond pas toujours à celle qu’on applique vraiment. Certains clients ont des conditions particulières, convenues dans un échange de courriels et jamais reportées ailleurs. Certaines fiches existent en trois versions, dont une seule est à jour. Un service ne peut pas se vendre dans certaines combinaisons, et seuls le savent ceux qui sont dans la maison depuis longtemps. Certaines offres doivent être validées par ceux qui exécuteront ensuite le travail ou par le directeur financier, d’autres peuvent partir tout de suite.

L’essai avait montré que l’assistant savait rédiger une offre. Le passage à toute l’équipe montre que rédiger l’offre était la partie facile, et qu’un système qui travaille pour de bon doit connaître l’organisation. Dans un hôpital ou dans une mairie, la liste comporterait d’autres lignes, et elle serait au moins aussi longue.

Ce que les gens compensaient

Je crois que l’IA fait remonter des problèmes qui étaient déjà là : des données incohérentes, un savoir dispersé entre les personnes et leurs boîtes de messagerie, des droits d’accès accumulés au fil du temps, des procédures qui n’ont jamais été écrites nulle part. Tant que seules des personnes travaillaient dans ces processus, elles compensaient en permanence. Elles demandaient à un collègue, se souvenaient de la façon dont on s’y était pris la dernière fois. Elles savaient quelle valeur recopier à la main d’un système à l’autre, et quel champ ignorer.

Quiconque travaille sur un progiciel de gestion qui a dix ans d’histoire sait qu’il peut contenir trois champs appelés à peu près « statut du client », et qu’un seul dit vrai. Un assistant lit très bien notre langue et n’a aucun moyen de savoir lequel des trois regarder. Le défaut tient à la façon dont nous avons organisé l’information au fil des années, et le modèle se contente de le rendre visible d’un seul coup. C’est pourquoi je pense que les projets d’IA mettent surtout à l’épreuve une chose qu’aucun modèle ne maîtrise : à quel point une entreprise est lisible pour quelqu’un qui n’y travaille pas depuis des années.

Une difficulté plus vieille que le logiciel

On me dira que je donne un nom neuf à la vieille transformation numérique. C’est en bonne partie vrai, et c’est ce qu’il est le plus utile de reconnaître. Pendant quelques années, nous avons traité l’IA en entreprise comme un monde à part, avec son vocabulaire et ses spécialistes. Mais dès qu’un système entre vraiment dans le travail quotidien, il retrouve les problèmes que le logiciel affronte depuis des décennies : les données, les accès, les intégrations, les responsabilités.

L’histoire est d’ailleurs plus ancienne que le logiciel. En 1990, l’historien de l’économie Paul David, pour comprendre pourquoi les ordinateurs n’apparaissaient pas encore dans les statistiques de productivité, est allé voir ce qui s’était passé avec le moteur électrique. En 1899, près de vingt ans après les premières centrales, les moteurs électriques fournissaient moins de 5 % de la force motrice des usines américaines. Il a fallu vingt ans de plus pour arriver à la moitié, et l’effet sur la productivité ne s’est vu que dans les années 1920. Le moteur fonctionnait dès le premier jour. Mais les usines étaient bâties pour la force de l’eau et de la vapeur, avec des arbres de transmission suspendus au plafond et des courroies qui descendaient entraîner les machines, et tant que ces bâtiments tenaient, personne n’avait intérêt à les refaire. Le gain est venu quand on a commencé à donner à chaque machine son propre moteur et à dessiner le bâtiment en conséquence.

Avec les progiciels de gestion, il s’est passé à peu près la même chose. Dans une étude de 2002, Erik Brynjolfsson, Lorin Hitt et Shinkyu Yang rapportent que dans une installation type de SAP R/3, autour de vingt millions de dollars, le matériel et le logiciel pesaient moins d’un cinquième. Le reste partait dans la définition des besoins, l’adaptation du programme, la refonte des processus et la formation des personnes.

La différence, cette fois, c’est que le composant nouveau ne répond pas toujours de la même façon à la même question, et que nous avons tendance à lui laisser de plus en plus d’autonomie. Ces problèmes en deviennent plus délicats et moins faciles à remettre à plus tard. La partie nouvelle ne fonctionne donc que si la partie ancienne du métier est bien faite.

Les règles posent les mêmes questions, par écrit

C’est aussi pourquoi je ne suis pas surpris que le premier obstacle cité par l’étude soit la complexité des règles. Dans la santé ou dans une administration, les textes posent par écrit, et à l’avance, les questions que le travail quotidien poserait de toute façon, à commencer par celle de savoir qui répond d’une décision et comment on la reconstitue.

L’AI Act le fait presque mot pour mot. À ceux qui utilisent un système à haut risque, l’article 26 demande de confier le contrôle humain à des personnes « qui disposent des compétences, de la formation et de l’autorité nécessaires », et de conserver pendant au moins six mois les journaux que le système génère. Le Digital Omnibus a reporté ces obligations à décembre 2027, et j’ai déjà écrit pourquoi ce report change peu de chose pour ceux qui construisent le système maintenant : un journal qui n’existe pas dès le premier jour ne se reconstitue pas après coup.

L’étude contient un chiffre qui va dans le même sens, à prendre avec la même prudence. Dans le secteur public et la santé, près de la moitié des organisations en sont encore à explorer ou à expérimenter. Chez les banques et les assureurs, qui n’ont pas moins de règles à respecter, elles sont 22 %, et c’est le secteur le plus avancé de tout l’échantillon. Je ne sais pas ce que pèsent la taille et les budgets de ceux qui ont répondu. Mais si c’étaient les règles en elles-mêmes qui freinaient, je m’attendrais à trouver les banques et les assureurs en queue de peloton.

Pour celui qui construit le système, les règles sont une contrainte de conception, et mieux vaut les traiter ainsi dès le premier jour.

Ce qui est devenu difficile à trouver

Cela change aussi ce qui est difficile à trouver sur le marché. Au début, l’avantage allait à ceux qui savaient montrer ce que l’IA pouvait faire pour une entreprise. Cet avantage me semble s’user vite : les modèles s’améliorent et coûtent moins cher, et une démonstration convaincante se monte en quelques jours. Il reste difficile de trouver des gens qui savent comprendre un processus et le redessiner, relier des systèmes qui n’ont pas été conçus pour se parler, décider qui peut voir quoi et accompagner ceux qui devront utiliser le résultat. Ce sont les disciplines de toujours du logiciel fait avec soin, qui doivent maintenant faire de la place à un composant moins prévisible que les autres.

La même étude relève que moins d’un tiers des organisations évaluent formellement, avant de lancer un projet d’IA, s’il pourra être étendu. Les questions d’architecture, de données, de responsabilité et d’organisation du travail arrivent donc souvent quand le projet a déjà montré qu’il fonctionnait. C’est le pire moment pour les découvrir, parce qu’à ce stade tout le monde s’attend seulement à appuyer sur l’interrupteur.

L’intérêt que j’ai dans cette histoire

C’est aussi pour cela que les projets que je trouve les plus intéressants commencent souvent quand la démonstration a déjà réussi. À ce stade, la question du modèle a sa réponse. Reste à savoir quels systèmes il doit traverser, quelles données il peut utiliser, quelles exceptions il doit gérer et ce qui doit se passer pour que l’entreprise puisse se permettre d’en dépendre.

Là-dessus, j’ai un intérêt direct. Je travaille dans une entreprise de logiciel qui vit justement de ce bout de chemin entre un essai réussi et un système sur lequel une entreprise ou une administration peut compter. Une étude qui décrit ce bout de chemin comme le plus difficile m’arrange autant qu’elle arrange ceux qui l’ont publiée. Le critère doit donc s’appliquer d’abord à nous.

Chez nous, une grande partie du code est déjà écrite par une machine, à partir d’une spécification que nous rédigeons, et la relecture reste confiée à une personne. Si notre métier se résumait à écrire du code, nous serions parmi les premiers à le voir perdre de sa valeur. Le reste du métier, celui que j’ai décrit jusqu’ici, se prouve projet après projet, et ceux qui travaillent avec nous ont le droit de nous demander comment nous nous y prenons.

Tous les essais n’ont pas à devenir un système

Il y a enfin une conséquence moins confortable pour ceux qui vivent de l’intégration. Toutes les expérimentations ne méritent pas de devenir un système d’entreprise. Un assistant utilisé par trois personnes, qui fait gagner des heures sans toucher à rien d’autre, peut rester tel quel, et c’est un choix raisonnable. D’autres fois, rendre un essai fiable coûte plus qu’il ne rapportera, et le découvrir tôt est un bon résultat : cela vaut bien mieux que de passer trois ans à défendre une démonstration réussie. Celui qui gagne sa vie en intégrant a tout intérêt à répondre qu’il faut toujours intégrer.

Voici à quelle aune je demande qu’on nous juge : dire avant de signer combien il en coûtera de rendre fiable un essai réussi, et le dire aussi quand la bonne réponse est de le laisser tel quel.

À ceux qui décident, je laisse une question. Quel est votre projet d’IA qui fonctionne déjà à l’essai, mais que vous ne confieriez pas encore à cent vrais utilisateurs sans garder à côté la personne qui l’a construit ?

L'auteur

Andrea MargiovanniIA

Je suis le rapport entre IA et régulation européenne comme un fait politique, pas comme un spectacle technique. Je travaille avec des équipes qui doivent la rendre compatible avec AI Act, CRA, NIS2 sans réduire la conformité à une liste à cocher.

Voir le parcours →