Les modèles d’IA générative sont très peu fiables et souvent erronés
Lorsque l’on parle d’IA générative, la plupart des gens imaginent des systèmes avancés capables de répondre instantanément, d’écrire du code, de résumer des documents ou même de créer des stratégies commerciales. C’est vrai, dans une certaine mesure. Mais le fait est que ces modèles se trompent souvent. Pas seulement de temps en temps. Beaucoup, c’est-à-dire 60 % du temps.
Allie Mellen, analyste principal chez Forrester, l’a dit simplement : « L’IA se trompe. Elle ne se trompe pas qu’un peu, elle se trompe tout le temps ». Lors du 2025 Security and Risk Summit de Forrester, elle a exposé la vérité qui se cache derrière le battage médiatique. Les modèles d’IA générative, comme ChatGPT et Gemini, ne sont pas intelligents au sens humain du terme. Ils créent des réponses qui semblent sûres d’elles, mais qui manquent souvent de précision ou de contexte. Ces systèmes génèrent des résultats basés sur la probabilité, et non sur la compréhension. C’est une différence essentielle que les dirigeants doivent garder à l’esprit.
Le Tow Center for Digital Journalism de l’université de Columbia a testé huit grands modèles. Le résultat ? 60 % des réponses étaient incorrectes. Laissez-vous convaincre par ce chiffre. Ces outils sont adoptés dans tous les secteurs, du service à la clientèle à la détection des menaces, et pourtant la majorité de leurs réponses ne sont pas fiables. Ce qui est encore plus inquiétant, c’est que les modèles n’échouent pas en silence. Ils réagissent de manière audacieuse, induisant souvent les utilisateurs en erreur en leur faisant croire que les résultats sont dignes de confiance.
Si vous intégrez l’IA dans vos opérations, vous devez être direct quant aux risques. Ne partez pas du principe que le modèle sait ce qu’il fait. Mettez en place des mesures de protection. Vérifiez les résultats. Utilisez-les comme des accélérateurs et non comme des décideurs finaux. Cet état d’esprit permet aux organisations de rester agiles sans devenir fragiles.
Les agents d’IA échouent systématiquement dans l’exécution de tâches d’entreprise réelles
L’idée que des agents d’intelligence artificielle puissent jouer un rôle dans l’entreprise, qu’il s’agisse d’automatiser les réponses aux courriels des clients ou de gérer la surveillance de l’infrastructure, suscite beaucoup d’enthousiasme. Tout cela semble formidable. Mais la réalité actuelle est plus décevante : L’IA ne termine pas le travail qui lui est confié. En fait, elle échoue la plupart du temps.
Jeff Pollard, vice-président et analyste principal de Forrester, a présenté des données qu’il est difficile d’ignorer. Il a partagé les résultats du benchmark AgentCompany de Carnegie Mellon. Ils ont testé des modèles de premier plan tels que Claude 3.5 Sonnet et GPT-4 sur 175 tâches commerciales pratiques. Les modèles les plus performants n’ont réussi à accomplir qu’environ 24 % de ces tâches sans aide. Si vous ajoutez de la complexité, le taux d’échec grimpe rapidement, atteignant 70 à 90 %.
Ce n’est pas de la performance. C’est la preuve de l’immaturité de la technologie. Même les recherches internes de Salesforce, partagées lors de Dreamforce 2024, ont montré que les agents d’IA axés sur la gestion de la relation client ne parvenaient pas à accomplir 62 % des tâches de base. Lorsque des contrôles de confidentialité ont été ajoutés pour renforcer la sécurité des données, les taux d’échec ont dépassé les 90 %. Il ne s’agit pas de simples bogues. Il s’agit de limites fondamentales aux capacités actuelles.
Voici ce qu’il faut retenir pour les dirigeants : N’automatisez pas à outrance en vous fiant au modèle. Cette approche crée des angles morts. Utilisez l’IA pour soutenir votre personnel, et non pour le remplacer, car cette technologie, dans sa forme actuelle, n’a pas la précision et la responsabilité requises dans les environnements d’entreprise.
Si vous intégrez l’IA dans des flux de travail critiques, mettez-la à l’épreuve. Introduisez des options de repli. Suivez sa précision par rapport aux indicateurs de performance clés. Jusqu’à ce que la fiabilité s’améliore, les dirigeants devraient considérer les agents d’IA comme des apprentis et non comme des experts. Cet état d’esprit permet de préserver votre réputation, votre qualité et la confiance de vos clients.
Le code généré par l’IA présente de sérieux risques de sécurité en raison de vulnérabilités intégrées
L’IA écrit plus de code que jamais. Cela peut sembler un progrès. Mais il y a un problème critique : près de la moitié de ce code présente des failles de sécurité. Il ne s’agit pas de spéculations, mais de mesures.
Le 2025 GenAI Code Security Report de Veracode a testé 80 tâches de codage sur plus de 100 grands modèles de langage (LLM) dans quatre langages de programmation : Java, Python, C et JavaScript. Les résultats sont directs et indéniables : 45 % du code généré par l’IA contenait des vulnérabilités connues du Top 10 de l’OWASP. Il s’agit notamment de problèmes tels que l’injection SQL, l’injection de logs et les scripts intersites. Même de petites erreurs dans ces domaines peuvent donner aux attaquants un accès complet aux bases de données, aux systèmes ou aux infrastructures critiques.
La véritable préoccupation ici n’est pas seulement la fréquence des failles de sécurité, mais aussi le décalage entre la capacité de l’IA à organiser le code et la sécurité dont elle fait preuve. Les modèles les plus récents peuvent produire un code propre et compilable, mais leurs performances en matière de sécurité ne se sont pas améliorées. Cela montre que des ensembles d’entraînement plus importants et des modèles syntaxiques plus raffinés ne permettent pas de résoudre le risque sous-jacent. Les vulnérabilités continuent de se propager à grande échelle.
Les résultats spécifiques aux différents langages donnent une image plus claire pour les responsables techniques. Java a obtenu le taux de réussite le plus faible en matière de code sécurisé (28,5 %). Python, C et JavaScript ont obtenu de meilleurs résultats, mais présentent encore des lacunes importantes, notamment en ce qui concerne les scripts intersites, pour lesquels les taux de réussite n’atteignent que 12 à 13 %. Cela signifie que huit résultats sur dix des outils d’intelligence artificielle ne sont pas sûrs dans certains environnements.
Si des équipes construisent des logiciels à l’aide de LLM, il faut que la direction s’en préoccupe. Incorporer l’IA dans le cycle de vie du développement sans contrôles de sécurité renforcés est risqué d’un point de vue opérationnel. La solution n’est pas d’arrêter l’utilisation de l’IA, mais plutôt d’ajouter des outils de validation de la sécurité, d’éduquer les développeurs sur le comportement du code généré par l’IA et d’imposer des révisions avant la production. Laissez l’IA vous assister, mais ne garantissez jamais la sécurité sans surveillance humaine.
La prolifération de l’IA exacerbe la prolifération des identités et augmente les surfaces d’attaque
À mesure que l’IA s’implante dans les entreprises, elle crée un nouveau type de risque : la prolifération des identités. Il ne s’agit plus seulement de connexions humaines. Les agents d’IA, les API, les informations d’identification des machines et les jetons éphémères sont désormais plus nombreux que les utilisateurs traditionnels dans de nombreux environnements. Et chaque nouvelle identité peut devenir une porte d’entrée pour les attaquants.
Merritt Maxim, vice-président et directeur de recherche chez Forrester, l’a clairement exprimé : « La sécurité de l’identité subit le changement le plus important depuis que le SSO s’est généralisé. Les permissions statiques sont remplacées par un accès juste à temps, souvent accordé automatiquement et révoqué quelques minutes plus tard. Ces droits dynamiques augmentent la flexibilité, mais aussi la complexité. Les équipes de sécurité doivent gérer l’accès en temps réel, avec des limites claires, sous peine de subir les conséquences d’une violation.
La violation du jeton OAuth en août 2025 est un excellent exemple de la concrétisation de ce risque. Plus de 700 clients de Salesforce ont été touchés. Ce ne sont pas les mots de passe ou les pare-feu qui ont été exploités, mais les jetons OAuth et les identifiants API. Il s’agit d’identités de machines. Si elles ne sont pas gérées comme des identifiants humains, elles deviennent des angles morts que les adversaires peuvent exploiter rapidement et à grande échelle.
L’adoption de l’IA entraîne également l’apparition de systèmes fantômesdes outils d’IA non approuvés que les employés intègrent sans passer par les processus de sécurité. Une récente étude de Veracode montre que 88 % des responsables de la sécurité admettent que leur organisation dispose d’une IA non autorisée. Cela signifie que presque toutes les entreprises fonctionnent actuellement avec des vecteurs de risque inconnus et non gérés, créés par leurs propres équipes.
La gestion de cette situation commence par la visibilité. Sans savoir combien d’identités de machines existent dans votre infrastructure, la gouvernance est impossible. Les responsables de la sécurité doivent étendre la gestion des identités et des accès (IAM) pour couvrir explicitement les identités générées par les machines et l’IA. Forrester prévoit que cette lacune alimentera la croissance du marché de l’IAM, qui atteindra 27,5 milliards de dollars d’ici 2029.
Si la gouvernance n’évolue pas à la vitesse des machines, les attaquants iront plus vite. Affectez des équipes à l’audit des informations d’identification créées par l’IA, à leur rotation automatique et à la priorisation de l’application des politiques sur les identités humaines et non humaines. C’est ainsi que les organisations resteront résilientes dans cette phase d’adoption de l’IA par les entreprises.
L’IA doit être gérée comme une classe d’identité distincte et à haut risque au sein des organisations.
Nous entrons dans une phase où les agents d’IA exécutent des tâches, accèdent à des données et interagissent avec des systèmes centraux. Ils sont donc plus que de simples logiciels, ce sont des entités opérationnelles, et ils doivent être gérés comme des identités. Ils ne doivent pas être considérés comme une extension des rôles existants des humains ou des machines, mais comme une catégorie unique avec ses propres risques, comportements et privilèges.
Andras Cser, vice-président et analyste principal chez Forrester, a été très clair : « Les agents d’IA se situent quelque part entre les machines et les identités humaines : volume élevé, autonomie élevée, impact élevé ». Les systèmes que nous avons utilisés pour gérer les rôles des utilisateurs ou les comptes de service n’ont pas été conçus pour ce niveau d’interaction autonome. Les outils IAM traditionnels n’offrent pas la granularité de surveillance ou la vitesse d’adaptation nécessaire pour que les agents d’intelligence artificielle créent de nouvelles tâches ou de nouveaux processus de manière dynamique.
L’implication pour les cadres est directe. Plus ces agents prolifèrent, plus ils créent des points d’exposition potentiels, pas nécessairement dus à de mauvaises intentions, mais à un manque de supervision structurée. Les agents d’IA peuvent initier des transactions, déplacer des données et réagir en temps réel. Sans une gouvernance conçue pour ce type d’entité, les organisations perdent toute visibilité sur les droits d’accès, l’historique des changements ou les déclencheurs de responsabilité.
L’architecture IAM traditionnelle s’effondre dans cet environnement. Ces outils s’attendent à des rôles fixes, des privilèges stables et des flux de travail linéaires. L’IA ne suit pas ces principes. La gouvernance a besoin de précision et d’adaptabilité. Les contrôles doivent être continus et non statiques, surveillés en temps réel, avec la possibilité de révoquer ou de limiter la portée en fonction du contexte et des performances du système.
Pour les décideurs, la demande est claire : mettre en place une gouvernance autour du fonctionnement de ces agents d’intelligence artificielle. Traitez-les comme des identités de premier ordre. Utilisez des plateformes dédiées qui offrent une visibilité en temps réel, des autorisations basées sur les événements et des pistes d’audit complètes à travers les points d’interaction. C’est ainsi que vous réduirez l’exposition, que vous assurerez la conformité et que vous maintiendrez la responsabilité au fur et à mesure que l’IA se développera.
Le red teaming de l’IA est essentiel pour détecter et traiter les vulnérabilités spécifiques aux modèles.
Jusqu’à récemment, le red teaming se concentrait sur les tests de l’infrastructure traditionnelle, les vulnérabilités du réseau, les défenses des points d’accès et l’exposition de la configuration. Cette orientation est en train de changer. Avec les agents d’IA de plus en plus intégrés dans les systèmes opérationnels, la cible n’est plus toujours le réseau. C’est le modèle d’IA lui-même.
Jeff Pollard de Forrester a souligné cette transition : « Les défauts de l’infrastructure sont importants, mais les défauts du modèle d’IA sont ce qui vous fera craquer. Il a raison. Ces systèmes introduisent un tout nouvel ensemble de risques, des attaques par injection rapide, l’exploitation de biais, l’inversion de modèle et des défaillances qui s’aggravent lorsque plusieurs agents d’IA interagissent. Les tests de pénétration standard ne les détecteront pas.
Il ne s’agit pas de risques théoriques. L’étude comparative AgentCompany de Carnegie Mellon a montré que les meilleurs modèles échouaient dans des tâches réelles dans 70 à 90 % des cas lorsque la complexité augmentait. Il ne s’agit pas de bogues isolés, mais de défaillances systémiques des performances. La session Dreamforce 2024 de Salesforce s’est fait l’écho de la même constatation : les agents d’IA axés sur la gestion de la relation client échouent dans plus de 60 % des tâches de base, des chiffres qui grimpent encore plus haut une fois que des contraintes de protection ont été appliquées.
L’équipe rouge de l’IA est la façon dont les entreprises s’adaptent à cette situation. Elle simule des comportements adverses entraînés explicitement pour exposer les faiblesses du modèle, des comportements qui exploitent la manière dont le système fait des hypothèses, interprète mal la logique ou dissimule des faux positifs derrière des résultats fiables. Contrairement aux tests d’infrastructure, cette méthode exige une approche pluridisciplinaire : la sécurité, la conception de modèles et l’expertise du domaine doivent travailler ensemble.
Pour les dirigeants qui font de l’IA une stratégie, la recommandation est directe. Si vous déployez des LLM ou des agents dans des environnements de production, mettez en place des équipes rouges dédiées à l’IA. Équipez-les d’outils capables d’observer les interactions entre les modèles, d’injecter des voies adverses et de surveiller la réponse du système. C’est ainsi que vous pourrez anticiper les faiblesses émergentes avant qu’elles n’apparaissent, ou pire, avant que les attaquants ne les trouvent.
Les organisations doivent considérer l’échec de l’IA comme une base de référence et mettre en place des mesures de protection en conséquence.
Les dirigeants doivent s’appuyer sur une vérité fondamentale concernant l’IA : les défaillances du système ne sont pas l’exception, c’est le comportement attendu. De nombreux modèles mis en production aujourd’hui, que ce soit pour la génération de contenu, les suggestions de code ou la réponse aux incidents, échouent avec un degré de confiance élevé. Ils sont donc difficiles à détecter et il est facile de leur faire confiance, pour de mauvaises raisons.
Allie Mellen, analyste principal chez Forrester, a été clair sur ce point lors du 2025 Security and Risk Summit. Les résultats générés par l’IA produisent aujourd’hui des faux positifs dans les environnements critiques, en particulier pendant les enquêtes et les flux de travail de réponse. Il ne s’agit pas d’erreurs passives. Les modèles les présentent avec certitude, déclenchant des actions injustifiées ou détournant les ressources des incidents légitimes.
Les recherches de l’université de Columbia vont dans ce sens. Les tests effectués sur huit grands modèles d’IA générative, dont ChatGPT et Gemini, ont révélé un taux d’échec de 60 %. La marge n’est pas mince. Ces outils échouent plus souvent qu’ils ne réussissent.
La leçon à tirer pour les dirigeants est simple : il faut construire des systèmes en tenant compte d’une imprécision constante. Cela ne signifie pas qu’il faille rejeter l’IA, loin de là. Cela signifie qu’il faut déployer l’IA en connaissant parfaitement ses limites et en les compensant par des processus de sauvegarde, de redondance et de vérification humaine chaque fois que le risque existe. Les résultats automatisés ne doivent pas contourner le jugement. Ils doivent l’éclairer.
La précision de l’IA va s’améliorer, mais pour l’instant elle n’est pas suffisante pour que la prise de décision non supervisée soit acceptable dans les domaines à fort impact. Fixez en interne un budget d’échec qui reflète les marges d’erreur attendues. Attribuez la responsabilité de l’examen du contenu généré par l’IA et intégrez l’évaluation de la confiance dans les pipelines opérationnels. L’excès de confiance dans l’IA est un risque. Prévoir l’erreur est une stratégie.
La dépendance excessive à l’égard de l’automatisation et des infrastructures héritées de la « confiance » constitue une menace croissante.
De nombreuses organisations s’appuient encore sur une infrastructure construite à une autre époque, où les systèmes fonctionnaient à la vitesse humaine et où les relations de confiance étaient statiques. Ces fondations sont en train de s’effondrer sous le poids des systèmes d’intelligence artificielle autonomes et rapides. L’hypothèse selon laquelle l’automatisation est synonyme d’amélioration n’est plus valable lorsque la confiance n’est pas vérifiée.
Jeff Pollard, vice-président et analyste principal chez Forrester, a lancé un avertissement sévère : « Les garde-fous ne sécurisent pas les agents, ils les font échouer silencieusement. Les efforts de Carnegie Mellon en matière de benchmarking confirment ce message. Lorsque des garde-fous et des contraintes de sécurité ont été appliqués à des agents avancés, les taux d’échec ont augmenté, dépassant souvent 90 %. Il s’agit là d’un effondrement des performances, et non d’une mesure de confinement.
Le risque lié aux systèmes existants et à la confiance aveugle dans l’automatisation est leur incapacité à gérer les erreurs composées. Ces systèmes ne remettent pas en question les résultats de l’IA, ils s’exécutent sur la base d’une configuration historique ou d’une logique de vérification statique. Cela ouvre la porte à l’exploitation. Si un attaquant compromet la logique de processus d’un agent d’IA et que les systèmes existants ne remettent pas en question cette logique, des impacts à grande échelle peuvent suivre rapidement.
Le changement nécessaire pour les dirigeants de niveau C est la vérification continue. Chaque nœud de l’automatisation, de l’événement déclencheur à l’action finale, doit être observable, vérifiable et interruptible. Ne comptez pas sur les garde-fous pour corriger le cap en plein vol. Ils n’ont pas été conçus pour évaluer les couches de décision intelligentes générées par les LLM.
Rétablissez les hypothèses de confiance dans les systèmes de contrôle actifs. Ne reportez pas la validation à des audits annuels. Intégrez la surveillance en direct et l’évaluation des risques en temps réel dans le cadre de la supervision de l’IA et de l’automatisation. Ce niveau de diligence garantit que l’échelle et la vitesse de l’IA ne dépassent pas votre capacité à la contrôler.
En conclusion
L’IA évolue rapidement, plus rapidement que ce que la plupart des cadres de gouvernance, des protocoles de sécurité et des systèmes existants peuvent gérer. Il s’agit là d’un problème de leadership, et non d’un problème technique. Les modèles échouent. Les agents agissent sans supervision. Et l’automatisation, si elle n’est pas contrôlée, devient une responsabilité silencieuse. Il ne s’agit pas de cas marginaux ; ils sont en train de devenir la norme.
Ce à quoi nous sommes confrontés aujourd’hui, ce n’est pas seulement à des résultats erronés ou à des prédictions biaisées. Il s’agit d’une exposition systémique, d’agents d’IA qui créent des identités qui ne sont pas suivies, qui envoient des codes non sécurisés en production, qui déclenchent des alertes basées sur des hallucinations et qui contournent des contrôles qui n’ont jamais été conçus pour les surveiller.
Si vous ne mettez pas en place une gouvernance de l’IA spécifiquement adaptée à ce changement, l’échec du modèle de quelqu’un d’autre deviendra votre désastre opérationnel. L’hypothèse ne peut plus être que l’outil fonctionne. Il faut partir du principe qu’il ne fonctionnera pas, et planifier en conséquence.
Engagez des équipes rouges d’IA. Mettez à niveau votre IAM. Surveillez les identités des machines comme vous le feriez pour vos cadres supérieurs. Et surtout, arrêtez de croire que les anciens systèmes vous protégeront dans un nouvel environnement. Le profil de risque a déjà changé. Il est temps que le cahier des charges des dirigeants le soit aussi.
