- L'IA invente parfois avec assurance. Ce n'est pas un défaut temporaire, c'est une propriété de son fonctionnement.
- Elle n'est pas constante. Deux fois la même question peut donner deux réponses différentes.
- Elle ne connaît pas votre entreprise. Tout ce qui n'est écrit nulle part lui est invisible.
- Elle calcule mal. Un modèle de langage n'est pas une calculatrice, même quand il en a l'air.
- Elle ne porte aucune responsabilité. La vôtre reste entière.
- La bonne nouvelle : chacune de ces limites se gère par la conception. Aucune n'empêche un projet utile. Toutes empêchent un projet naïf.
Pourquoi j'écris ça
Presque tout ce qui s'écrit sur l'IA en français est soit de la promotion, soit de la peur. Les deux vous laissent sans repères pour décider.
Ce guide fait l'inverse. Il liste ce que ces systèmes ne font pas bien, en 2026, avec ce que ça implique concrètement pour un projet d'entreprise. Vous n'y trouverez pas de conclusion du genre « donc l'IA est surévaluée ». Je gagne ma vie à en implanter et je continue de le faire, parce que ça marche quand c'est bien conçu. Mais bien conçu veut dire conçu autour de ces limites, pas en les ignorant.
Si vous devez lire une seule section de la grappe IA avant de signer quoi que ce soit, lisez celle ci.
Limite 1. Elle invente, et elle le fait avec aplomb
C'est la limite la plus connue et la plus mal comprise.
Un modèle de langage produit du texte plausible. Quand il connaît la réponse, le texte plausible est aussi le texte vrai. Quand il ne la connaît pas, il produit quand même du texte plausible. Une date, un numéro d'article de loi, un nom de norme, un montant. Rien dans la formulation ne signale la différence, et c'est exactement ce qui rend le phénomène dangereux.
Ce que les gens comprennent mal, c'est qu'il ne s'agit pas d'un bogue en attente de correctif. Ça découle de la mécanique même du système. Les meilleurs modèles se trompent moins souvent. Une bonne architecture réduit encore le taux. Personne ne l'amène à zéro.
Comment on conçoit autour. On fait répondre le système à partir de documents fournis plutôt que de sa mémoire générale, on exige qu'il cite ses sources, et on place une validation humaine partout où l'erreur coûte cher. Un système qui répond « je ne trouve pas cette information dans vos documents » est un bon système, pas un système défaillant.
Le vrai test à faire avant d'acheter : demandez au fournisseur de vous montrer ce que son système répond à une question dont la réponse n'existe pas dans vos documents. Vous apprendrez tout ce que vous devez savoir en trente secondes.
Limite 2. Elle n'est pas constante
Posez deux fois la même question, vous obtiendrez possiblement deux formulations différentes. Parfois deux contenus légèrement différents.
Pour de la rédaction, c'est sans conséquence, voire souhaitable. Pour de l'extraction de données, c'est un problème sérieux. Un système qui lit une facture doit sortir le même montant à chaque fois, point.
Comment on conçoit autour. On abaisse les réglages de créativité, on impose des formats de sortie stricts, on ajoute des vérifications automatiques qui rejettent une réponse mal formée, et on teste sur un volume représentatif plutôt que sur trois exemples choisis. Un fournisseur sérieux vous montrera un taux d'exactitude mesuré sur des dizaines de cas réels, pas une démonstration réussie.
Limite 3. Elle ignore tout de votre entreprise
Le modèle a lu Internet. Il n'a jamais vu votre liste de prix, votre convention collective, votre procédure d'approbation des soumissions, ni le fait que le client Tremblay a un tarif particulier depuis 2019.
Et surtout, il ne connaît pas ce que personne n'a jamais écrit. Or dans la plupart des PME, une partie considérable du savoir vit dans la tête de trois ou quatre personnes. Ce savoir tacite est invisible pour la machine.
Comment on conçoit autour. On lui donne accès aux documents pertinents, avec la méthode appropriée. Et on accepte une vérité inconfortable : un projet d'IA révèle presque toujours que votre documentation est incomplète. Ce n'est pas un échec du projet, c'est un diagnostic gratuit sur l'état de vos connaissances internes. Plusieurs de mes clients ont tiré plus de valeur de cette prise de conscience que de l'automatisation elle même.
Limite 4. Elle calcule mal
Ça surprend toujours. Un système capable de résumer un contrat de 60 pages peut se tromper en additionnant une colonne de chiffres.
La raison est simple : il ne calcule pas, il prédit à quoi ressemble une réponse de calcul. Les systèmes modernes contournent le problème en appelant une vraie calculatrice ou votre base de données. Mais ça doit avoir été prévu.
Comment on conçoit autour. Toute donnée chiffrée qui compte doit venir d'un système qui calcule pour de vrai, jamais du modèle lui même. Si un fournisseur vous propose un outil de calcul de prix ou de taxes reposant uniquement sur un modèle de langage, il y a un problème d'architecture.
Limite 5. Elle ne juge pas
Un modèle peut vous dire ce que dit une clause de contrat. Il ne peut pas décider si vous devez accepter cette clause, parce que cette décision dépend de votre tolérance au risque, de votre relation avec ce client, de votre situation financière du moment et de trois choses que personne n'a écrites nulle part.
La même logique vaut pour l'embauche, le crédit, la santé, la discipline, ou tout ce qui affecte durablement une personne.
Comment on conçoit autour. L'IA prépare la décision, l'humain la prend. Elle rassemble, résume, met en évidence, propose. Le geste final appartient à quelqu'un dont c'est la responsabilité. Ce n'est pas de la prudence excessive, c'est aussi la seule position défendable le jour où quelqu'un vous demande des comptes.
Limite 6. Elle ne porte aucune responsabilité
Si votre système envoie une mauvaise information à un client, ce n'est pas le fournisseur du modèle qui répondra. C'est vous. Les conditions d'utilisation de tous les grands fournisseurs sont très claires là dessus, et personne ne les lit.
Comment on conçoit autour. On identifie, avant la conception, quels gestes engagent l'entreprise. Ceux là passent par un humain, ou ne s'automatisent pas du tout. On documente aussi qui a validé quoi, ce qui vaut de l'or en cas de litige.
Limite 7. Elle ne règle pas un processus brisé
Celle ci n'est pas technique, et c'est pourtant celle qui tue le plus de projets.
Automatiser un processus mal défini produit un processus mal défini plus rapide. Si trois personnes chez vous font la même tâche de trois façons différentes et qu'aucune n'a raison, aucun modèle ne va arbitrer à votre place.
Comment on conçoit autour. On documente le processus avant d'automatiser. Souvent, cette étape révèle des simplifications qui donnent la moitié du gain espéré sans une ligne de code. J'ai vu des mandats se terminer là, avec un client satisfait et une facture bien plus petite que prévu.
Ce qui va s'améliorer, et ce qui ne changera pas
Une distinction utile pour planifier.
Ce qui s'améliore vite : le taux d'hallucination baisse, les capacités de raisonnement progressent, les coûts par jeton diminuent presque chaque année, les fenêtres de contexte s'agrandissent, les outils d'intégration se stabilisent.
Ce qui ne changera pas : un système ne connaîtra jamais ce que personne n'a écrit. La responsabilité restera humaine. Les décisions à fort enjeu demanderont toujours quelqu'un qui les assume. Et un processus mal défini restera mal défini.
Conclusion pratique : construisez pour aujourd'hui, mais avec une architecture qui vous permet de changer de modèle sans tout réécrire. Le modèle est une pièce interchangeable. Votre processus, vos données et vos règles sont l'actif durable.
Placez la validation humaine
Testez comment la conséquence d’une erreur change l’architecture.
Conservez une validation avant tout geste qui engage l’entreprise.
Ce que je vois sur le terrain
Les deux erreurs opposées, aussi coûteuses l'une que l'autre.
La première, c'est la confiance aveugle. Une entreprise branche un assistant sur sa documentation et le laisse répondre directement aux clients. Ça fonctionne quatre mois. Puis une réponse fausse part chez un client important, et le projet meurt en une réunion. La technologie n'était pas en cause. L'absence de validation, oui.
La deuxième, c'est le refus total. « L'IA se trompe, donc on n'y touche pas. » Sauf que vos employés y touchent déjà, sur leurs comptes personnels, avec vos documents. Le refus officiel ne fait pas disparaître l'usage. Il le rend juste invisible et non encadré.
La position raisonnable se situe entre les deux, et elle demande un peu de travail : décider explicitement où l'erreur est acceptable, et où elle ne l'est pas.
Quand ces limites doivent vous faire reculer
Je le dis clairement. Ne lancez pas de projet d'IA si vous êtes dans une de ces situations.
- Vous ne pouvez pas tolérer une seule erreur et vous ne voulez aucune validation humaine. Ces deux conditions sont incompatibles.
- Vos données de référence sont fausses ou contradictoires.
- Personne dans l'entreprise ne peut décrire le processus visé sur une page.
- Le projet est motivé par l'image plutôt que par un problème.
- Vous cherchez à supprimer des postes sans revoir le travail lui même.
Dans ces cas, l'argent est mieux placé ailleurs, et je vous le dirai avant de facturer quoi que ce soit.
Questions fréquentes
01Les hallucinations vont elles disparaître.
Le taux baisse, il ne tombe pas à zéro. Concevez en supposant qu'elles arrivent, pas en espérant qu'elles cessent.
02Comment mesurer si un système est assez fiable.
En le testant sur un volume représentatif de cas réels, avec un taux d'exactitude mesuré, et en définissant à l'avance quel taux est acceptable pour cette tâche précise. Un fournisseur qui refuse cet exercice devrait vous inquiéter.
03Est ce que ça vaut la peine malgré toutes ces limites.
Sur les bons cas d'usage, oui, largement. Le traitement documentaire et la recherche interne donnent des gains mesurables et durables. Ce sont les projets mal ciblés qui échouent, pas la technologie.
04Un modèle plus cher est il plus fiable.
Souvent un peu, mais l'écart de fiabilité vient bien davantage de l'architecture que du modèle. Un petit modèle bien encadré, avec du RAG et des vérifications, bat un gros modèle laissé sans garde fous.
05Que faire si nos employés utilisent déjà l'IA sans encadrement.
Regardez ce qu'ils font avant d'interdire quoi que ce soit. Ils vous montrent gratuitement où sont vos frictions. Ensuite, encadrez avec une politique simple et des outils approuvés.
Guide de fond écrit par Mario pour GXN (Gouvernance numérique), une division de MD79. Révision prévue selon le rythme documenté pour cette grappe.