_Résumé
Faut-il développer notre propre IA dédiée à la conformité, ou acheter des solutions d’IA ?
À un moment ou à un autre, la plupart des organisations qui gèrent des processus liés à l’ESG, à la réglementation ou à la diligence raisonnable se posent précisément cette question, et la réponse la plus courante que nous entendons est une variante de « nous gérons déjà l’IA en interne ».
C’est un réflexe tout à fait compréhensible. La technologie semble accessible, les modèles open source sont performants, et tout gérer en interne apparaît comme la voie la plus sûre et la plus maîtrisée. Les recherches sur les résultats concrets de ces projets, issues de plusieurs études indépendantes publiées au cours des douze derniers mois, brossent toutefois un tableau plus complexe et mettent en évidence un petit nombre de raisons spécifiques et récurrentes pour lesquelles les projets internes d’IA dans le domaine de la conformité piétinent.
Le problème, ce n’est pas de créer un prototype d’IA. C’est d’en faire un système qui fonctionne réellement.
La plupart des entreprises n’ont pas de mal à lancer un projet d’IA. Ce qu’elles ont du mal à faire, c’est à le mener à bien.
Une équipe interne peut développer un chatbot, connecter un modèle de langage de grande envergure (LLM) aux documents de l’entreprise, automatiser certaines tâches ou présenter une démonstration de faisabilité impressionnante en quelques semaines.
Le plus difficile, c’est après :
- Le système peut-il fonctionner de manière fiable avec les données réelles de l’entreprise ?
- Est-ce qu’il permet d’obtenir des résultats constants ?
- Les utilisateurs peuvent-ils se fier à ses réponses ?
- Est-il possible de retracer et d’expliquer chaque décision importante ?
- Peut-il s’intégrer aux systèmes existants ?
- Est-il possible d’assurer un suivi lorsque le modèle, la réglementation ou les données sous-jacentes changent ?
- Et, ce qui est peut-être le plus important, l’entreprise est-elle en mesure de prouver que cet investissement génère réellement une valeur commerciale mesurable ?
C’est là que les faits sont de plus en plus évidents : le fossé entre l’expérimentation de l’IA et son déploiement à grande échelle est énorme.
Et c’est précisément cette lacune qui constitue l’une des principales raisons pour lesquelles les entreprises devraient envisager de s’associer à un partenaire spécialisé dans les logiciels et l’IA plutôt que d’essayer de tout développer elles-mêmes.
L’adoption de l’IA en interne est élevée, mais sa mise en œuvre réussie ne l’est pas
Une étude réalisée en 2025 dans le cadre du projet NANDA du MIT, intitulée « The GenAI Divide : State of AI in Business 2025 », a analysé plus de 300 cas de mise en œuvre de l’IA rendus publics, ainsi que des entretiens et des enquêtes menés auprès de dirigeants d’entreprise et d’employés.
Sa conclusion la plus frappante est que 95 % des organisations participant à l’étude n’ont constaté aucun retour financier mesurable issu de leurs projets pilotes liés à l’IA générative. Seules environ 5 % d’entre elles en tiraient une valeur significative.
Mais l’essentiel, c’est ce que le MIT explique comme étant à l’origine de ce résultat.
Le problème ne résidait pas simplement dans le fait que les modèles d’IA n’étaient pas assez performants.
Le MIT a plutôt mis en évidence un « déficit d’apprentissage » : des systèmes qui ne s’adaptaient pas suffisamment au contexte de l’organisation, à ses flux de travail et à ses retours d’expérience. Cette étude souligne également un écart majeur entre l’expérimentation de l’IA et son intégration dans les processus métier réels.
Cette distinction est importante.
La question n’est pas :
« Peut-on faire fonctionner l’IA ? »
La question est la suivante :
« Pouvons-nous faire en sorte que l’IA fonctionne de manière fiable au sein de notre organisation ? »
Ce sont là des problèmes d’ingénierie très différents.
Du prototype à la production : à quel stade les projets internes se bloquent-ils généralement ?
Une autre donnée relative à la saison 2025/26 va dans le même sens.
Une étude menée par IDC et Lenovo révèle que, sur 33 projets de validation de concept en IA lancés par les entreprises, seuls environ quatre aboutissent à une mise en production.
En d’autres termes, une démonstration réussie n’est pas synonyme de produit d’IA réussi.
Un prototype peut fonctionner avec :
- un nombre limité de documents
- données nettoyées
- des exemples soigneusement sélectionnés
- un petit groupe d’utilisateurs passionnés
- vérification manuelle
- des ingénieurs disponibles pour résoudre les problèmes immédiatement
La production, c’est autre chose.
Un système de production doit faire face aux éléments suivants :
- données incohérentes
- des milliers ou des millions de documents
- évolution de la réglementation
- différents utilisateurs et cas d’utilisation
- sécurité et autorisations
- intégrations système
- mises à jour des modèles
- données inattendues
- surveillance et journalisation
- exigences de performance
- maîtrise des coûts
- contrôle humain
- exigences en matière d’audit
C’est à ce stade que de nombreux projets internes liés à l’IA cessent d’être de simples expériences dans ce domaine pour devenir des projets d’ingénierie logicielle.
Et c’est une entreprise bien plus ambitieuse que de choisir un modèle LLM et de développer une interface autour de celui-ci.
Pourquoi les projets d’IA en interne échouent-ils ?
Il n’y a pas de raison unique.
Les différentes études montrent que les projets d’IA échouent parce que les organisations sous-estiment l’environnement dans lequel s’inscrit l’IA.
On recense cinq problèmes récurrents.
1. Le prototype fonctionne, mais le flux de travail ne fonctionne pas
L’IA est souvent présentée comme un projet technologique :
« Voyons voir ce que ce modèle est capable de faire. »
Mais les entreprises n’ont pas besoin de modèles. Elles ont besoin de résultats.
Une équipe chargée de la conformité n’a pas besoin d’un chatbot sophistiqué. Elle a besoin d’un moyen plus rapide et plus fiable d’examiner les éléments de preuve, d’identifier les lacunes, de rédiger des rapports et de consigner les décisions.
Pour cela, il faut que l’IA soit intégrée au flux de travail proprement dit.
Les recherches menées par le MIT mettent clairement en évidence ce problème : les organisations qui parviennent à créer de la valeur ont tendance à aller au-delà des outils d’IA génériques et à développer des solutions étroitement intégrées à des processus métier spécifiques.
C’est l’une des raisons pour lesquelles de nombreux pilotes de ligne continuent d’exercer ce métier.
Cette technologie fonctionne.
Le processus métier associé n’a pas été repensé.
2. Une IA de qualité nécessite bien plus qu’un bon modèle
On serait tenté de considérer une plateforme d’IA comme :
Utilisateur → Modèle d’IA → Réponse
En réalité, un système destiné à la production ressemble souvent davantage à ceci :
Utilisateur → application → autorisations → données → extraction → plusieurs modèles/outils → validation → règles métier → vérification humaine → piste d’audit
Et tous ces éléments doivent fonctionner ensemble.
Dans le cadre d’un cas d’utilisation lié à la réglementation ou à la conformité, le système peut être amené à :
- identifier les documents pertinents ;
- retrouver le contexte réglementaire approprié ;
- distinguer les informations récentes des informations obsolètes ;
- en se fondant sur plusieurs sources ;
- générer une réponse ;
- identifier les incertitudes ;
- justifier votre réponse ;
- appliquer des règles métier ;
- transmettre les exceptions à un intervenant humain ;
- consigner les faits en vue d’un futur audit.
Le LLM n’est qu’un élément parmi d’autres.
Le véritable produit, c’est tout le système qui l’entoure.
Ce système doit être conçu, testé et entretenu.
3. Les équipes internes disposent souvent de l’expertise nécessaire dans leur domaine, mais pas des capacités requises pour mettre en place une plateforme d’IA.
Il s’agit là d’une distinction importante. Les professionnels de la conformité comprennent mieux l’activité qu’une société de logiciels externe ne pourra jamais le faire.
Ils savent que :
- quelles sont les réglementations qui comptent ;
- quels sont les documents faisant autorité ;
- là où le processus actuel s’interrompt ;
- quelles décisions nécessitent un jugement humain ;
- ce que les auditeurs demandent ;
- ce que les autorités de régulation attendent.
Cette expertise est indispensable.
Mais cela ne signifie pas pour autant que l’on soit capable de développer et d’exploiter un système d’IA.
Une étude réalisée en 2026 par Moody’s, fondée sur une enquête menée auprès de 600 professionnels de la gestion des risques et de la conformité, a révélé que 41 % d’entre eux considéraient le manque d’expertise ou de compétences en interne comme le principal obstacle au déploiement à grande échelle de l’IA. Parmi les autres obstacles majeurs figuraient l’incertitude réglementaire, l’intégration des systèmes existants et l’insuffisance des ressources.
C’est révélateur.
Le plus gros problème n’est pas forcément que les entreprises ne comprennent pas l’IA.
Le problème, c’est qu’ils ne disposent pas d’un nombre suffisant de personnes réunissant à la fois :
Ingénierie de l’IA + architecture logicielle + ingénierie des données + sécurité + évaluation de l’IA + maîtrise du domaine + opérations de production.
Il est difficile de disposer en interne de toutes ces compétences.
Et même lorsqu’une entreprise dispose de ces personnes, celles-ci doivent assurer la maintenance du système indéfiniment.
4. L’IA nécessite une gouvernance et un suivi dès le premier jour
Les logiciels traditionnels sont relativement déterministes. Si le même code reçoit la même entrée, on s’attend généralement à obtenir le même résultat.
Les systèmes d’IA remettent en cause cette hypothèse à un niveau plus profond. Une bonne équipe d’ingénieurs peut et doit maîtriser la plupart des éléments en jeu : verrouiller les versions des modèles, contrôler le contexte utilisé, gérer les versions des invites et surveiller les services externes.
Cette rigueur est certes nécessaire, mais elle ne résout pas le problème fondamental : le modèle lui-même est probabiliste. Même en conservant toutes les données d’entrée constantes, une même requête peut produire une réponse différente un mardi par rapport à un lundi, et aucune rigueur technique, quelle qu’elle soit, ne permet d’éliminer ce phénomène.
Cela permet justement de rendre cette variabilité traçable. C’est à cela que servent la gouvernance et l’évaluation : non pas pour empêcher le modèle d’être probabiliste, mais pour comprendre exactement pourquoi il a produit une réponse donnée, et pour détecter tout écart par rapport aux résultats attendus.
Cela signifie qu’un système d’IA d’entreprise doit disposer de son propre dispositif d’évaluation et de gouvernance.
Les organisations doivent savoir que :
- Quel est son degré de précision ?
- Dans quels cas cela ne fonctionne-t-il pas ?
- Quels types de cas ne sont pas fiables ?
- Quel modèle a donné cette réponse ?
- Quelles sources ont été utilisées ?
- À quelles données le système a-t-il accédé ?
- Quand ce résultat a-t-il été généré ?
- Y avait-il un être humain impliqué ?
- Que se passe-t-il lorsque l’IA ne peut pas fournir de réponse avec suffisamment de certitude ?
- Les performances ont-elles évolué depuis la dernière mise à jour du modèle ?
Le cadre de gestion des risques liés à l’IA du NIST considère explicitement que la gestion de ces risques est une question que les organisations doivent prendre en compte tout au long de la conception, du développement, du déploiement et de l’utilisation des systèmes d’IA. Son « profil d’IA générative » met davantage l’accent sur les considérations relatives à l’évaluation et à la fiabilité tout au long du cycle de vie de l’IA.
Et à mesure que l’IA gagne en autonomie, le problème devient encore plus difficile à résoudre.
Gartner prévoit que plus de 40 % des projets d’IA agentique seront annulés d’ici fin 2027, invoquant une escalade des coûts, une valeur commerciale incertaine et des contrôles des risques insuffisants.
La leçon à en tirer n’est pas que les agents d’IA ne fonctionnent pas.
C’est que cette autonomie accroît les besoins en matière d’ingénierie et de gouvernance liés au modèle.
5. Combien coûte réellement la mise en œuvre de l’IA en interne ?
Même les organisations qui surmontent les obstacles techniques et métier se heurtent à un troisième obstacle : l’aspect économique. L’enquête de KPMG du deuxième trimestre 2026 a révélé que près de la moitié des organisations ont déjà remis en question, reporté, revu à la baisse ou suspendu un déploiement d’IA dès lors que les coûts attendus ont commencé à dépasser sa valeur. Seul un tiers environ déclare disposer d’une visibilité totale sur le coût réel de fonctionnement quotidien de ses systèmes d’IA, et celles qui bénéficient de cette visibilité totale sont cinq fois plus susceptibles de faire état d’un retour sur investissement avéré que celles qui n’en disposent pas.
Les données de Moody’s spécifiques à la conformité viennent compléter ce tableau : 41 % des personnes interrogées citent le manque d’expertise ou de compétences en interne comme principal obstacle au déploiement à grande échelle de l’IA dans les domaines du risque et de la conformité, devant l’incertitude réglementaire, la complexité de l’intégration ou le budget lui-même.
Les ingénieurs spécialisés en IA, capables de développer et de maintenir un système prêt pour la production, sont rares et coûteux, et ce coût ne s’arrête pas au lancement : il revient à chaque fois qu’un modèle est mis à jour, qu’une réglementation change ou qu’un incident survient en production.
Le deuxième coût est celui lié à l’utilisation elle-même. La plupart des modèles de pointe sont facturés au jeton, et la consommation de jetons pour une charge de travail impliquant des documents volumineux et un raisonnement réglementaire itératif est véritablement difficile à prévoir à l’avance. La constatation de KPMG selon laquelle l’accès à des modèles à faible coût et haute fidélité est désormais le facteur qui influence le plus rapidement la stratégie en matière d’IA, avec une hausse de 7 points en un seul trimestre, reflète exactement cette pression : les organisations se rendent compte qu’utiliser l’IA et savoir ce qu’elle coûte et ce qu’elle vaut sont deux situations très différentes.
Questions courantes que se posent les responsables de la conformité avant de prendre une décision
« N’est-il pas moins coûteux à long terme de développer en interne, puisque cela nous évite de payer des frais récurrents aux prestataires ? »
En général, non, une fois que l’on prend en compte l’ensemble des coûts. Le coût initial de développement est la partie la plus facile à estimer. Ce qui est plus difficile à anticiper, ce sont les coûts récurrents : la formation continue à mesure que la réglementation évolue, la maintenance d’une infrastructure sécurisée et les compétences techniques spécialisées nécessaires pour la faire fonctionner, ce qui, selon une enquête menée par Moody’s auprès de professionnels de la conformité, constitue déjà le principal obstacle cité pour le déploiement à grande échelle de l’IA dans ce domaine.
« Nous disposons de solides compétences en ingénierie. N’est-ce pas suffisant pour développer cela nous-mêmes ? »
Les compétences techniques et l’exploitation durable de l’IA relèvent de disciplines différentes. Les recherches du MIT mettent en évidence un « déficit d’apprentissage » comme principale cause d’échec des projets d’IA en entreprise, ce qui signifie que ce n’est souvent pas la phase de développement initiale qui pose problème. Ce sont les mois et les années d’adaptation qui suivent qui sont en cause : c’est précisément à ce stade que, selon les données de KPMG, près de la moitié des organisations finissent par réduire leurs déploiements une fois que les coûts réels et la complexité apparaissent.
« Nos données sont trop sensibles pour être confiées à une plateforme externe ; ne devrions-nous donc pas la développer nous-mêmes ? »
C’est une préoccupation légitime, mais il s’agit en réalité d’un débat sur le lieu d’exécution de l’IA, et non sur qui la développe. Une plateforme spécialisée peut fonctionner entièrement au sein de votre propre environnement ou dans un centre de données situé dans l’UE ou en Suisse, sans qu’aucune donnée ne quitte ce périmètre, ce qui répond directement à la question de la souveraineté sans pour autant vous obliger à développer et à maintenir vous-même le système d’IA.
« Ne pourrions-nous pas commencer par un petit projet pilote, puis étendre le projet par la suite ? »
C’est précisément le scénario contre lequel met en garde cette étude. IDC a constaté que seuls environ 4 concepts de démonstration d’IA sur 33 aboutissent à une mise en production. Les prévisions de Gartner concernant les annulations dans le domaine de l’IA agentique décrivent exactement cette trajectoire : des projets pilotes prometteurs qui s’enlisent dès lors que le volume réel de documents, les subtilités réglementaires concrètes et la rigueur des audits entrent en jeu.
« Si nous décidons de nous lancer dans ce projet, quels sont les éléments indispensables dont nous aurions besoin, outre des compétences en ingénierie ? »
Au moins trois éléments sont systématiquement cités par les études comme faisant souvent défaut : un modèle de gouvernance de l’IA abouti (seule une organisation sur cinq en dispose, selon Deloitte), une méthode définie pour évaluer si le système fonctionne réellement (un tiers des équipes de conformité interrogées par Moody’s ne procèdent à aucune mesure de ce type) et une visibilité totale sur les coûts de fonctionnement du système, puisque KPMG a constaté que cette visibilité à elle seule est corrélée à un taux de retour sur investissement (ROI) cinq fois plus élevé.
Alors, pourquoi faire appel à une entreprise spécialisée dans les logiciels d’IA et pourquoi un partenariat peut-il s’avérer plus efficace que de tout développer seul ?
C’est sans doute l’argument le plus important à prendre en compte pour choisir entre « faire soi-même » et « acheter tout prêt ».
Les recherches menées dans le cadre du projet NANDA du MIT ont révélé que les partenariats externes avec des systèmes d’IA personnalisés et capables d’apprendre étaient déployés à un rythme environ deux fois supérieur à celui des outils développés en interne — soit environ 67 % contre 33 % dans l’échantillon de l’étude. Les chercheurs précisent toutefois que ces chiffres reposent sur un échantillon limité et ne doivent pas être interprétés comme un taux de réussite universel, mais cette tendance est significative.
Cela ne signifie pas pour autant que :
« Les entreprises devraient externaliser l’IA. »
C’est :
« Les entreprises ne devraient pas partir du principe que le développement en interne constitue automatiquement la solution la moins risquée. »
Dans de nombreux cas, la meilleure approche consiste à associer l’expertise interne dans un domaine donné à l’expertise externe en matière de logiciels.
L’entreprise conserve le contrôle de ses données, de ses règles métier et de ses décisions.
Le partenaire logiciel fournit la couche technologique nécessaire pour que ces décisions soient évolutives, mesurables et faciles à maintenir.
Une efficacité opérationnelle mesurable, une tarification prévisible de l’IA, une IA fiable et sécurisée avec Dydon AI
C’est sur cette couche que nous avons construit Dydon AI. Il ne s’agit pas d’un modèle unique qui gère tout, mais de plusieurs modèles et solutions techniques combinés pour répondre aux besoins réels de chaque étape du processus, le tout fonctionnant sur une infrastructure hébergée soit au sein de l’environnement propre au client, soit dans des centres de données situés en Suisse ou dans l’Union européenne.
C’est également la raison pour laquelle nous ne fixons pas nos tarifs en fonction de la consommation brute de jetons : nous travaillons avec nos clients pour identifier où réside réellement la valeur, puis nous structurons nos tarifs autour de résultats commerciaux prévisibles, afin que la budgétisation ne dépende pas d’estimations préalables de l’utilisation des jetons. Et c’est pourquoi chaque réponse fait l’objet d’une validation humaine avant d’apparaître dans un rapport, non pas par souci de restriction, mais parce que c’est là que, selon les propres répondants de Moody’s, le marché lui-même a déjà conclu que réside la véritable confiance.
Le choix entre « développer » et « acheter » ne dépend pas vraiment des capacités de votre équipe. Il s’agit plutôt de déterminer si le coût récurrent lié au développement, à la gestion, à l’évaluation et au financement d’un système d’IA conforme aux exigences réglementaires, et ce pour une durée indéterminée, correspond bien à la manière dont vous souhaitez que cette capacité soit mise en œuvre.
Vous souhaitez savoir où l’IA pourrait réellement apporter une valeur ajoutée à votre flux de travail ?
Dydon AI propose une analyse du potentiel de l’IA afin d’identifier les domaines dans lesquels l’IA peut apporter des gains d’efficacité mesurables, les étapes du processus où la validation humaine doit être maintenue, et à quoi pourrait ressembler une mise en œuvre adaptée aux besoins des entreprises.
Obtenez votre analyse du potentiel de votre IA →
Sources
- Challapally, A. et al. (2025). The GenAI Divide: State of AI in Business 2025. MIT Media Lab, Project NANDA.
- Gartner, Inc. (2025). Gartner Predicts Over 40% of Agentic AI Projects Will Be Canceled by End of 2027. Press release, June 25, 2025.
- IDC / Lenovo (2025). AI proof-of-concept to production benchmark findings.
- KPMG International (2026). Global AI Pulse Q2 2026: From Deployment to Value Realization. June 2026.
- Moody’s, with We Live Context (2025). From Reactive to Proactive: How AI is Transforming Risk and Compliance.
- Moody’s (2026). Navigating the Shift: How Agentic AI is Reshaping Risk and Compliance.
- Deloitte (2026). State of AI governance maturity findings, cited via Dreamix RegTech industry analysis.