Depuis quelques mois, nous observons une même erreur revenir dans les projets impliquant l’intelligence artificielle générative (ChatGPT, Copilot, Gemini, Claude et compagnie) : on lui confie des tâches pour lesquelles elle est structurellement mal outillée. Le cas le plus fréquent est celui des calculs mathématiques, mais ce n’est qu’un exemple parmi d’autres. Selon McKinsey, 88% des organisations utilisent maintenant l’intelligence artificielle de façon régulière, mais 51% ont déjà rapporté au moins une conséquence négative liée à l’inexactitude de ces outils (Axis Intelligence). Le problème ne vient pas des modèles eux-mêmes, mais de la façon dont on les intègre dans le processus de conception d’une solution.
Probabiliste
L’IA générative repose sur des modèles de langage (large language models ou LLM) qui prédisent le prochain mot le plus probable en fonction d’un contexte. Contrairement à d’autres branches du machine learning utilisées pour la classification ou la prédiction, ces modèles ne sont ni un moteur de calcul, ni une base de données, ni un outil déterministe (qui donne toujours le même résultat pour une même entrée). Ils produisent une réponse plausible, pas une réponse vérifiée. Même en fixant la « température » du modèle à zéro (paramètre qui vise à réduire la variabilité), les réponses restent non-déterministes en raison de facteurs techniques liés au calcul en virgule flottante sur les GPU.
Cette nature probabiliste explique aussi pourquoi les hallucinations (informations générées avec assurance mais incorrectes) constituent un phénomène structurel de l’IA générative. Des travaux récents ont même prouvé mathématiquement qu’il est impossible d’éliminer complètement ce comportement dans les modèles actuels. À cela s’ajoute le fait qu’un LLM reste une boîte noire : nous savons ce qui entre et ce qui sort, mais le raisonnement interne demeure largement inobservable.
Erreurs silencieuses
Le calcul mathématique est l’illustration la plus limpide du problème. L’IA générative peut annoncer un total, un pourcentage ou une projection financière qui « sonne juste », sans avoir réellement calculé quoi que ce soit. Ces erreurs se cachent souvent derrière une mise en forme professionnelle et une prose confiante (un bonus mal calculé de 3%, un total de taxes légèrement sous-estimé, un chiffre de revenus qui « a l’air bon »). Contrairement à une hallucination visible, une erreur numérique passe les révisions et se propage (Forbes).
Le même raisonnement s’applique à d’autres cas où un outil dédié demeure plus fiable. Toute recherche de donnée factuelle précise (chiffres officiels, statistiques réglementaires, dates historiques) devrait se faire via une API officielle ou une base de données interne plutôt qu’en demandant à ChatGPT ou un autre modèle de « se souvenir ». De la même manière, toute requête sur un ensemble de données structurées volumineuses (extraction, agrégation, filtres) donnera un résultat exact et reproductible dans un logiciel de type Excel, SQL ou Power BI, alors que l’IA générative tend à « résumer » ou à « estimer ». On pourrait ajouter à cette liste la validation de formats (courriels, numéros de TPS/TVQ, IBAN), la manipulation de dates et de fuseaux horaires, ou la génération d’identifiants uniques.
Orchestration
L’approche que nous privilégions consiste à traiter l’intelligence artificielle comme un outil parmi d’autres plutôt que comme un exécutant unique. Le modèle comprend la demande, découpe le problème, puis peut déléguer les portions critiques (calculs, extractions, validations) à des outils déterministes avant de reformuler le résultat pour l’utilisateur. Cette logique doit apparaître dès le cahier des charges du projet et de la conception architecturale : quels calculs ou validations doivent rester déterministes (algorithmique), et quelle part revient au modèle génératif.
Concrètement, cela se réalise très bien avec les outils d’orchestration disponibles aujourd’hui. Un flux Power Automate peut par exemple recevoir une facture, envoyer les données brutes à une action Excel ou à une API comptable pour le calcul, puis retourner le résultat vérifié à Copilot Studio pour la mise en forme et la réponse à l’utilisateur. La même logique s’applique aux agents IA construits sur d’autres plateformes (Azure AI Foundry, plateformes d’agents autonomes, orchestrateurs internes développés sur mesure). Le principe reste le même : le modèle sert de couche de compréhension et de dialogue, pas de couche de calcul.
Ce découpage améliore aussi la traçabilité. Chaque calcul devient auditable, reproductible et corrigeable indépendamment du modèle d’IA générative utilisé. Pour une équipe qui agit en maîtrise d’œuvre sur un projet client, cette capacité à démontrer d’où vient chaque chiffre est un gage de qualité.
Précautions
Cette architecture réduit les risques, mais ne les élimine pas. L’intelligence artificielle reste responsable d’interpréter correctement la demande initiale et de sélectionner le bon outil. Une mauvaise interprétation en amont produira un calcul juste sur les mauvaises données. Il faut aussi surveiller les coûts liés à ces flux automatisés (appels d’API, exécutions Power Automate, jetons consommés), qui peuvent s’additionner rapidement. Enfin, une automatisation trop poussée comporte un risque d’érosion des compétences internes : à force de déléguer certaines analyses au duo modèle génératif et outil déterministe, les équipes peuvent perdre la maîtrise fine des calculs qu’elles produisent.
Sources
- McKinsey, The State of AI in 2025 (2025)
- Axis Intelligence, AI Hallucination Statistics 2026 (2026)
- Forbes, Why LLMs Fail At Basic Math (And How To Fix It) (2026)
- Deloitte, State of Generative AI in the Enterprise (2025)
- Microsoft, Work Trend Index Annual Report (2025)
- OpenAI, o3 and o4-mini System Card (avril 2025)
- Xu et al., Hallucination is Inevitable: An Innate Limitation of Large Language Models (2024)
