Les grands modèles de langage et les agents autonomes échouent sur des catégories de tâches précises, identifiables, et souvent sous-estimées par les équipes qui les déploient. Comprendre où l’IA est mauvaise permet d’éviter des pertes de temps réelles, parfois mesurées en dizaines de pourcents de productivité en moins.
Tâches multiétapes et agents IA : un plafond bas et documenté
Les agents IA, conçus pour enchaîner des actions de manière autonome, restent fragiles dès que la séquence dépasse quelques étapes. Dans le benchmark TheAgentCompany, qui évalue des tâches réalistes de navigation web, programmation et communication en entreprise, le meilleur agent n’accomplissait qu’environ 30 % des tâches dans la révision 2025. Les tâches simples passaient, les séquences longues échouaient presque systématiquement.
A découvrir également : Quelle est la semaine 1 en 2026 ?
Le problème n’est pas la compréhension d’une consigne isolée. C’est la capacité à maintenir un plan cohérent sur plusieurs décisions successives, à récupérer après une erreur intermédiaire, et à s’adapter quand l’environnement change entre deux étapes. Un agent qui réussit une action isolée à 80 % voit son taux de succès chuter exponentiellement sur une chaîne de dix actions dépendantes.
Nous observons le même phénomène dans WebArena, un benchmark d’interaction web : le meilleur agent GPT-4 atteignait 14,41 % de réussite, contre 78,24 % pour les humains. L’écart se creuse sur les tâches impliquant plusieurs décisions et la récupération après erreur.
A lire également : Comment savoir si un drone me filme ?
Interfaces graphiques et travail sur écran : les modèles perdent pied
L’interaction avec des applications non standardisées constitue un angle mort majeur. Dans OSWorld, qui évalue l’utilisation d’applications et d’interfaces graphiques de bureau, les progrès récents n’ont pas comblé le fossé avec les opérateurs humains. Le problème est structurel : les modèles de vision ne gèrent pas correctement les interfaces changeantes, les menus contextuels imbriqués, ni les cas où un clic produit un résultat inattendu.
Pour les équipes qui envisagent d’automatiser des processus impliquant des logiciels métier avec interfaces propriétaires, cette limitation est critique. Un RPA classique à base de règles reste souvent plus fiable qu’un agent IA sur ce type de workflow.
Développeurs expérimentés ralentis par l’IA : le paradoxe de la productivité perçue
L’idée que l’IA accélère systématiquement le développement logiciel ne résiste pas à l’examen sur les profils seniors. Une étude randomisée de METR, menée auprès de 16 développeurs open source expérimentés sur 246 tâches dans des dépôts qu’ils connaissaient, a mesuré un résultat contre-intuitif : les développeurs étaient 19 % plus lents avec les outils IA disponibles au début de 2025.
Le détail qui compte : après l’expérience, ces mêmes développeurs estimaient encore avoir été plus rapides. Le biais de perception est mesurable. Sur du code familier, dans un contexte maîtrisé, le temps passé à formuler des prompts, vérifier les suggestions et corriger les hallucinations dépasse le gain brut de génération.
Où l’IA ralentit concrètement le travail de développement
- Les bases de code complexes avec beaucoup de dépendances internes, où le contexte dépasse la fenêtre du modèle et produit des suggestions incohérentes
- Le débogage de problèmes subtils, où le modèle propose des corrections plausibles mais fausses, ajoutant une couche de vérification supplémentaire
- La refactorisation architecturale, qui exige une compréhension globale du système que le modèle ne possède pas
Pour les profils juniors ou sur des tâches de boilerplate, le gain existe. Sur du travail expert dans un environnement connu, l’IA introduit un coût cognitif net que la plupart des utilisateurs ne perçoivent pas.
Raisonnement causal et fiabilité répétée : deux faiblesses structurelles des modèles
Les grands modèles de langage simulent le raisonnement par corrélation statistique. Quand une tâche exige un raisonnement causal authentique (identifier pourquoi un système a échoué, distinguer une corrélation d’une causalité dans des données, anticiper les conséquences d’une modification dans un processus complexe), les résultats se dégradent fortement.
Cette faiblesse se combine avec un problème de constance. Un modèle peut produire une réponse correcte sur une tâche isolée, puis échouer sur la même tâche formulée différemment. Pour un usage opérationnel, la fiabilité répétée sur des centaines d’exécutions compte davantage que la performance ponctuelle. Les benchmarks mesurent le taux de réussite moyen, pas la variance, ce qui masque le risque réel en production.
Domaines où le raisonnement causal reste hors de portée
- L’analyse de causes racines dans des incidents techniques ou industriels, où le modèle confond symptômes et causes
- La planification stratégique impliquant des boucles de rétroaction, où chaque décision modifie les conditions de la suivante
- L’évaluation de la crédibilité de données contradictoires, où le modèle tend à produire une synthèse lissée plutôt qu’un jugement tranché
Confidentialité des données et systèmes d’IA en entreprise
Au-delà des limites techniques, l’utilisation de l’IA en contexte professionnel pose un problème concret de sécurité des informations. Des salariés soumettent régulièrement des documents internes à des outils d’IA générative hébergés par des tiers, exposant involontairement des données sensibles.
Le risque n’est pas théorique. Les données soumises à un modèle hébergé par un tiers sortent du périmètre de contrôle de l’entreprise. Les modèles n’ont pas besoin de « mémoriser » un document spécifique pour que l’information soit compromise : le simple fait de la transmettre via une API tierce constitue une fuite.
Nous recommandons de traiter tout outil d’IA générative externe comme un canal de communication non sécurisé, au même titre qu’un email non chiffré. Les politiques internes doivent explicitement lister les catégories de données interdites de soumission, plutôt que de s’appuyer sur la bonne foi des utilisateurs.
L’IA n’est pas uniformément mauvaise. Elle est mauvaise sur des tâches spécifiques et identifiables : les séquences longues, les interfaces non standardisées, le travail expert dans un contexte familier, le raisonnement causal, et la manipulation de données sensibles. Cartographier ces zones de faiblesse avant de déployer un outil reste le seul moyen d’éviter que les gains attendus se transforment en pertes mesurables.
