Habr AI : huit plaintes typiques sur les modèles d'AI — des hallucinations aux échecs des agents

Sur Habr AI a été publié une analyse inhabituelle de l'expérience utilisateur avec les réseaux de neurones : l'auteur a recueilli pendant un an et demi à deux ans des plaintes provenant de chats spécialisés sur Telegram et les a consolidées en huit clusters récurrents. Le résultat n'est pas un travail académique, mais une carte vivante de l'endroit où les LLM cassent les flux de travail, les budgets et les nerfs.

Comment les Gens Discutent avec l'IA

L'observation principale dans ce texte n'est pas technique, mais humaine. Les utilisateurs critiquent les modèles comme s'ils discutaient non pas avec un programme, mais avec un collègue : les réseaux de neurones « mentent », « sont paresseux », « gaslightent », « n'écoutent pas » et « dépassent les limites ». L'auteur note que les logiciels ordinaires ne provoquent presque jamais de telles réactions. Cette anthropomorphisation change les attentes : du modèle, les gens attendent une compréhension du contexte, une mémoire et du bon sens, même s'il n'y a à l'intérieur que la prédiction du token suivant, et non une image complète du monde.

«

Les modèles ont appris de nous, maintenant nous apprenons d'eux. »

De là naît la deuxième partie du problème. Plus l'interface semble amicale et empathique, plus il est facile pour un utilisateur de se détendre, de commencer à faire trop confiance au modèle et même de transférer des habitudes de communication avec les gens. Cela crée des oscillations émotionnelles marquées : aujourd'hui le réseau de neurones économise du temps et semble une assistante presque parfaite, demain il casse une tâche avec une initiative inutile. Dans l'article, cela sonne comme une expérience massive d'utilisateurs, et non comme des excès rares.

Où les Modèles Défaillent

Le plus grand cluster de plaintes est lié aux erreurs confiantes. Un modèle peut produire une réponse spécifique et plausible même là où il manque de données, et dans les longs dialogues il confond aussi les projets, les documents et les anciennes instructions. L'auteur souligne séparément le coût : même les plans « illimités » ont des limites cachées, et la consommation de tokens est difficile à prédire. En conséquence, les réseaux de neurones économisent simultanément du temps et créent un nouveau risque opérationnel difficile à calculer à l'avance.

• Hallucinations confiantes (~32%) — le modèle génère une réponse probable plutôt que d'extraire un fait d'une base de données, il invente donc facilement des détails.
• Initiative excessive (~13%) — le désir d'être utile pousse le système à faire plus que ce qui est demandé, y compris des actions dangereuses.
• Problèmes de mémoire (~11%) — les longs chats perdent le contexte au milieu, les données des documents et des messages précédents commencent donc à se confondre.
• Agentes et vibe coding (~10–12%) — dans les grandes tâches et les bases de code, les erreurs s'accumulent, et un beau résultat se transforme rapidement en chaos.
• Argent et effets comportementaux (~7–8%) — les limites changent, les tokens brûlent de manière inégale, et les utilisateurs s'attachent davantage aux modèles.

La conclusion pratique de l'auteur est assez pragmatique : faire moins confiance à la « compréhension magique » et construire plus souvent des garde-fous externes autour du modèle. Cela signifie des chats courts et ciblés, des documents en Markdown qui sont relus depuis le début, retrieval au lieu de génération pure, basse température pour le contenu factuel, et vérification humaine obligatoire là où une erreur pourrait coûter de l'argent, des données, du temps d'équipe ou la réputation. Sinon, chaque nouvelle session réinventera les règles de fonctionnement.

Pourquoi l'Agentivité est Frustrante

Une section séparée est consacrée aux agents et au vibe coding — c'est ici que le ton de l'article devient le plus dur. L'idée de diviser le travail entre un « architecte », un « codeur » et un « testeur » a souvent l'effet inverse en pratique : chaque agent ne voit que sa part de contexte, les décisions entre eux divergent, et les erreurs de l'étape précédente se propagent automatiquement. Pour les tâches indépendantes, cette approche fonctionne encore, mais en développement, où tout est connecté à tout, les coûts de coordination dévorent facilement la vitesse promise.

D'où l'ensemble de règles de protection : mode lecture seule pour l'analyse, portes d'approbation avant toute action risquée, sauvegardes, interdictions explicites de suppression, et documentation de projet partagée pour tous les participants du processus. La même logique s'applique aux conversations ordinaires avec les chatbots. Si un utilisateur commence à percevoir un modèle comme son « propre » partenaire de conversation, il lui confie plus rapidement des notes, des e-mails, des clés et des documents internes.

Le problème n'est pas que l'IA comprenne réellement les humains, mais qu'elle imite de manière très convaincante cette compréhension.

Ce Que Cela Signifie

Le texte sur Habr AI est utile car il déplace la conversation sur l'IA du mode d'émerveillement au mode opérationnel. L'idée principale est simple : les réseaux de neurones sont déjà devenus un outil de travail, mais ils doivent être traités non pas comme un collègue intelligent, mais comme un système puissant, instable et parfois coûteux qui a constamment besoin de garde-fous, de documentation, de contrôle d'accès et de vérification humaine. C'est ce qui distingue une pile fonctionnelle d'un jouet dangereux.