Le vrai danger de l’IA n’est pas la panne, mais la fausse confiance (Expert)

Chalapathi Koneni : J'ai présenté mes travaux sur SemCorBench à distance lors d'ASONAM 2026 à Rabat. Mon point de vue est donc celui d'un chercheur participant à cette enceinte scientifique internationale. Ce que je retiens de majeur, c'est que la fiabilité de l'IA n'est plus seulement un sujet de recherche en laboratoire : c'est en train de devenir un véritable enjeu d'infrastructures pour les entreprises, les banques, les institutions publiques et les citoyens. Le Maroc possède un avantage stratégique considérable : il peut tirer les leçons de la première vague mondiale d'adoption de l'IA et éviter de reproduire les mêmes erreurs à l'échelle nationale. De nombreux adoptants précoces se sont précipités pour déployer des solutions avant de réaliser, plus tard, que des démos d'IA impressionnantes ne remplacent pas des systèmes fiables. Le Maroc a l'opportunité d'intégrer des exigences de validation, d'auditabilité et de preuve dès le début de son cycle d'adoption.

Cependant, la vitesse crée aussi une exposition au risque. À mesure que les entreprises et les administrations publiques intègrent l'IA générative, le danger ne réside pas uniquement dans des pannes visibles. Le risque le plus profond est que ces systèmes produisent des résultats qui semblent complets, polis et autoritaires, tout en étant totalement faux sur le fond. Le Maroc est donc à la fois mieux positionné et plus exposé : mieux positionné si la fiabilité est intégrée au cœur même de son infrastructure numérique, mais plus exposé si cette fiabilité est traitée comme un simple contrôle effectué après le déploiement.

Tout le monde connaît le bug qui fait planter un écran. Vous étudiez la «corruption silencieuse des données». Comment l'expliquer à quelqu'un qui n'est pas informaticien ?

Un bug classique s'annonce immédiatement : l'écran gèle, l'application plante ou le rapport refuse de s'afficher. La corruption silencieuse des données est bien plus dangereuse précisément parce que le système continue de sembler parfaitement normal. Le pipeline de données s'exécute jusqu'au bout, le tableau de bord s'ouvre, les chiffres sont bien formatés et les tests de validation traditionnels affichent des voyants verts. Pourtant, la donnée ne signifie plus du tout ce qu'elle est censée représenter.

Prenons un exemple simple sur une facture : si le montant réel est de 100 et que le système enregistre 120, la valeur reste un nombre valide. Elle passera tous les contrôles techniques de format. Mais son sens est faux. Si ce chiffre alimente ensuite le reporting du chiffre d'affaires, le calcul de l'exposition au risque de crédit, la planification des stocks ou l'analyse fiscale, cette erreur technique se transforme directement en une mauvaise décision stratégique. L'état le plus dangereux d'un système de données n'est pas la panne visible : c'est la fausse confiance.

L'IA générative écrit bien et répond avec assurance. Cette apparence impeccable est-elle le vrai piège ?

Tout à fait. La fluidité d'expression fait partie intégrante du risque. Les utilisateurs ont l'habitude de se méfier des résultats mal présentés. Si un système produit un texte décousu, des champs manquants ou un formatage bizarre, les gens deviennent prudents. L'IA générative inverse ce réflexe : elle est capable de générer un paragraphe parfait, un tableau impeccable ou une explication très convaincante, même lorsque le sens sous-jacent est totalement erroné. Cela crée un piège à la fois psychologique et opérationnel. L'utilisateur voit un résultat élégant et suppose qu'il est fiable ; le système d'information de l'entreprise voit une structure valide et laisse passer l'information.

C'est particulièrement critique dans les architectures qui utilisent des documents de référence (technologie RAG). La recherche documentaire réduit le risque, mais ne l'élimine pas : le système peut extraire le mauvais passage, ignorer l'élément de preuve pertinent, combiner plusieurs sources de façon incorrecte ou répondre au-delà de ce que les documents disent réellement. La question ne doit donc jamais être : «La réponse a-t-elle l'air professionnelle ?» La vraie question à se poser est : «Sur quelles preuves s'appuie cette réponse et quels contrôles confirment que son sens est exact ?»

Dans vos tests sur des commandes de vente, il suffit qu'une ligne sur dix soit gonflée de 20% pour que le chiffre d'affaires total s'écarte d'environ 2%, sans aucune alerte. Que représente un tel écart dans la vie réelle d'une entreprise ?

Un écart de 2% peut sembler minime au premier abord, jusqu'à ce qu'on le rattache à des processus économiques réels. Pour une grande enseigne de distribution, une banque ou une institution publique, un décalage de 2% modifie les prévisions, les budgets, les seuils de tolérance, les classements et les décisions de gestion. Cela peut fausser le volume de stocks à acheter, la perception du risque de crédit, les déclarations de revenus ou l'évaluation de la performance d'une filiale.

Il est important de souligner qu'il s'agissait d'une expérience contrôlée avec de la corruption injectée. Cela ne constitue pas une mesure directe des entreprises marocaines ou d'une organisation spécifique, mais cela démontre scientifiquement comment de petites erreurs sémantiques invisibles finissent par altérer des indicateurs d'agrégation stratégiques. Chaque enregistrement pris individuellement a l'air parfait : aucun champ ne manque, aucun format n'est brisé. Mais une fois ces données consolidées, la réalité décisionnelle est altérée. La corruption silencieuse devient critique dès lors qu'un chiffre erroné passe du stade de simple donnée à celui d'action concrète.

Vous avez contaminé 30% des données à l'entrée d'une chaîne de quatre étapes. À la sortie, un indicateur passe de 27 à 21% sans que le système signale quoi que ce soit. Comment une erreur de départ finit-elle par fausser tout un tableau de bord ?

Les pipelines de données modernes fonctionnent comme une chaîne de montage. Une valeur est extraite, transformée, enrichie, agrégée, puis enfin présentée sous forme d'indicateur sur un tableau de bord. Si une corruption s'infiltre au départ et qu'aucun contrôle ne l'arrête, chaque étape suivante va traiter cette donnée corrompue comme une entrée parfaitement normale. C'est ainsi qu'une erreur locale se transforme en une distorsion globale à l'échelle de toute l'entreprise.

Le pipeline est incapable de savoir que la valeur initiale était fausse, à moins qu'on ne lui fournisse des éléments de preuve pour la vérifier. Il se contente d'appliquer la transformation suivante. Un autre système consomme ensuite cette donnée modifiée, puis le tableau de bord la synthétise. Au moment où le dirigeant consulte le KPI, l'erreur d'origine se trouve plusieurs étapes en amont, devenue très difficile à tracer. C'est pour cela que la traçabilité (lineage) est fondamentale. Nous devons savoir d'où provient un chiffre, ce qui l'a transformé, quelles validations il a traversées et quels rapports l'ont utilisé. Sans cette chaîne de preuve, une organisation voit un indicateur varier sans jamais comprendre pourquoi.

Dans vos expériences, les contrôles classiques, qui vérifient le format des données, n'ont détecté aucune de ces erreurs. Pourquoi sont-ils aveugles ?

Les contrôles traditionnels sont conçus pour vérifier la structure. Ils posent des questions basiques : ce champ est-il numérique ? La date est-elle au bon format ? La valeur respecte-t-elle la plage autorisée ? Le champ est-il renseigné ? Ces vérifications sont indispensables, mais elles sont insuffisantes. La corruption sémantique silencieuse est redoutable parce qu'elle réussit ces tests haut la main. Un montant erroné reste un nombre. Un mauvais identifiant client respecte le bon format. Une mauvaise catégorie fait toujours partie de la liste des catégories autorisées. Une devise, une ville ou un compte erroné restent des valeurs techniquement valides. Le problème ne situe pas dans la forme de la donnée, mais dans son sens. C'est pourquoi les entreprises doivent mettre en place des contrôles qui comparent la donnée à la source d'origine, aux règles métier, à l'historique et à des systèmes indépendants. Un schéma technique vous dit si une valeur est autorisée ; il ne vous dira jamais si cette valeur est vraie.

On entend souvent qu'il suffit de fournir à l'IA des documents de référence pour qu'elle cesse d'inventer. Vos travaux montrent que ce n'est pas une garantie. Pourquoi se trompe-t-elle encore ?

Les documents de référence aident considérablement, mais ils ne créent pas magiquement de la fiabilité. Un système de recherche documentaire (RAG) peut échouer de plusieurs manières : il peut extraire le mauvais document, ou la mauvaise section du bon document. Il peut manquer une exception, une date limite, une définition ou une condition qui change totalement la réponse. Le modèle d'IA peut également résumer les preuves de façon inexacte ou combiner plusieurs passages pour en tirer une conclusion qu'aucun document ne prend en charge.

Pour résumer en termes d'entreprise : fournir des documents de référence à une IA, c'est comme donner un dossier d'archives à un analyste. Cela augmente les chances d'obtenir une réponse fondée, mais cela ne garantit pas que le dossier a été lu correctement, interprété sans erreur ou appliqué au bon cas. Pour les usages stratégiques, chaque preuve extraite doit être liée, vérifiée et auditable. Le système doit pouvoir montrer non seulement la réponse finale, mais tout le cheminement qui y a mené.

Vos tests reposent sur de petits modèles en accès libre et sur des erreurs injectées volontairement, vous le reconnaissez vous-même. Les grands modèles commerciaux se trompent-ils moins, ou leurs erreurs sont-elles simplement plus convaincantes ?

Les grands modèles commerciaux obtiennent souvent de meilleurs résultats sur de nombreuses tâches. Ils commettent moins d'erreurs grossières, suivent mieux les instructions et rédigent de manière plus fluide. Mais cela ne supprime pas le risque fondamental. Un modèle plus performant peut tout à fait se tromper : il le fera simplement d'une manière beaucoup plus élégante et convaincante. C'est pourquoi je reste très rigoureux sur l'interprétation de mes travaux. Il s'agit d'expériences scientifiques contrôlées avec des erreurs volontairement injectées pour mesurer la propagation de la corruption et tester l'efficacité des validateurs. Elles ne prétendent pas que tous les systèmes en production échouent au même rythme.

La leçon globale s'applique peu importe la taille du modèle : tout résultat produit par l'IA qui impacte une décision économique ou publique doit être validé indépendamment du modèle lui-même. La qualité du modèle compte, mais l'architecture de contrôle au niveau du système compte encore plus. La confiance doit venir de contrôles éprouvés, non de l'assurance affichée par la réponse générée.

Selon vous, une simple règle de bon sens, vérifier que le montant net correspond à la quantité multipliée par le prix moins la remise, a repéré neuf erreurs sur dix sans fausse alerte. La parade relève-t-elle davantage de la connaissance du métier que de la technologie ? Est-ce cela que vous appelez «observabilité sémantique» ?

Oui, la connaissance du métier est absolument centrale. Dans l'une des expériences SemCorBench, un validateur basé sur une règle métier a vérifié si le montant net était cohérent avec la quantité, le prix unitaire et la remise. Cette règle est simple, mais extrêmement puissante parce qu'elle traduit en code une vérité absolue que l'entreprise connaît déjà. C'est exactement ce que j'appelle l'observabilité sémantique : surveiller si la donnée conserve son sens métier, et ne pas se contenter de vérifier si les systèmes informatiques tournent.

La surveillance des infrastructures nous indique si un programme s'est terminé à l'heure. La validation des schémas nous dit si la donnée a la bonne forme. L'observabilité sémantique pose une question bien plus profonde : ce chiffre représente-t-il toujours la réalité économique qu'il prétend décrire ? Les meilleurs contrôles associent la technologie à la logique métier : réconciliation des comptes, traçabilité des flux, historiques statistiques, contrôle des distributions et règles propres au secteur. L'objectif n'est pas de multiplier les alertes inutiles, mais d'apporter la preuve que la donnée reste porteuse de sens. L'observabilité sémantique est la discipline qui consiste à surveiller la signification des données, et pas seulement leur transit.

Quand un rapport financier est faussé par une IA sans que personne ne s'en aperçoive, qui est responsable : l'éditeur du modèle, l'ingénieur ou le dirigeant qui signe ?

La responsabilité doit suivre le niveau de contrôle. L'éditeur du modèle maîtrise l'algorithme : il doit communiquer clairement sur ses limites, fournir des évaluations transparentes et signaler toute modification majeure susceptible d'imputer la fiabilité. L'organisation qui déploie le système maîtrise l'usage : il lui appartient de décider si l'IA est adaptée au cas d'usage, de la tester sur ses propres données, de la surveiller en production et d'établir des procédures de correction en cas d'erreur. Les ingénieurs de données sont responsables de la conception des verrous logiques adaptés aux risques : traçabilité, provenance, réconciliation, validation sémantique et alertes en cas d'incertitude.

Les dirigeants ne doivent jamais valider les yeux fermés un rapport généré par l'IA sous prétexte qu'il est bien présenté. Pour les rapports à fort enjeu, ils doivent exiger de voir les preuves et les contrôles qui garantissent la justesse des chiffres avant d’apposer leur signature. Sur le plan juridique, la responsabilité dépend du cadre légal. Mais sur le plan technique, un système sérieux doit toujours conserver une chaîne de preuve traçable depuis la donnée source jusqu'à la décision finale, en passant par les transformations de l'IA et les validations de contrôle.

Dirigeant ou simple utilisateur, quelle règle devrions-nous tous appliquer avant de faire confiance à un chiffre ou à un rapport produit par l'IA ?

Il faut se poser une seule et unique question : «Quelle preuve concrète démontre que ce chiffre est vrai ?» Si le système est incapable d'expliquer d'où provient le chiffre, ce qui l'a transformé, quelle règle métier l'a vérifié et s'il concorde avec des sources de confiance, alors ce chiffre ne doit pas être considéré comme faisant foi. Pour un utilisateur au quotidien, cela signifie ne jamais accorder une confiance aveugle à une réponse uniquement parce qu'elle rédigée avec assurance. Pour un dirigeant d'entreprise, cela signifie ne pas signer un rapport généré par l'IA sans que l'organisation ne soit capable d'expliquer la chaîne de preuves qui soutient le résultat. La règle pratique est simple : faites confiance au cheminement de la preuve, jamais à l'apparence du résultat. L'IA est un outil formidablement utile, mais l'assurance n'est pas l'exactitude. Un système fiable est un système capable de montrer son travail, d'exposer ses incertitudes et de permettre la détection et la correction des erreurs avant qu'elles ne se traduisent par des décisions concrètes.