Habr AI : huit reproches typiques faits aux réseaux de neurones, des hallucinations aux échecs des agents

Habr AI a publié une analyse inhabituelle de l'expérience des utilisateurs avec les réseaux de neurones : pendant un an et demi à deux ans, l'autrice a recueilli des plaintes dans des chats Telegram spécialisés et les a regroupées en huit ensembles récurrents. Le résultat n'est pas un travail académique, mais une carte vivante des endroits où les LLM abîment les processus de travail, le budget et les nerfs.

Comment les gens se disputent avec l'IA

La principale observation du texte est humaine plutôt que technique. Les utilisateurs rabrouent les modèles comme s'ils se disputaient non avec un programme, mais avec un collègue : les réseaux de neurones « mentent », « paressent », « font du gaslighting », « n'écoutent pas » et « partent dans la mauvaise direction ». L'autrice note qu'on ne réagit presque jamais ainsi face à un logiciel ordinaire. Cette humanisation modifie aussi les attentes : on attend du modèle qu'il comprenne le contexte, qu'il ait de la mémoire et du bon sens, alors qu'à l'intérieur il se contente de prédire le token suivant, sans image complète du monde.

«

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

De là découle la seconde partie du problème. Plus l'interface paraît amicale et empathique, plus il est facile pour l'utilisateur de se relâcher, de faire trop confiance au modèle et même de lui transposer les habitudes de la conversation entre humains. D'où de brusques montagnes russes émotionnelles : un jour, le réseau de neurones fait gagner du temps et semble un assistant presque parfait ; le lendemain, il sabote une tâche par une initiative superflue. Dans l'article, cela se présente comme une expérience massive des utilisateurs, pas comme des excès rares.

Là où les modèles s'effondrent

Le plus gros ensemble de plaintes concerne les erreurs commises avec assurance. Un modèle peut donner une réponse précise et plausible même quand il manque de données et, dans les longues conversations, il peut en plus confondre projets, documents et anciennes instructions. L'autrice isole aussi la question du coût : même les forfaits « illimités » ont des plafonds cachés, et la consommation de tokens est difficile à prévoir. Résultat, les réseaux de neurones font gagner du temps tout en créant un nouveau risque opérationnel, difficile à chiffrer à l'avance.

• Hallucinations assurées (~32 %) — le modèle génère une réponse probable au lieu d'extraire un fait d'une base, et invente donc facilement des détails.
• Excès d'initiative (~13 %) — le désir d'être utile pousse le système à faire plus que ce qu'on lui a demandé, y compris des actions dangereuses.
• Problèmes de mémoire (~11 %) — les longs chats perdent le milieu du contexte, et les données des documents et des messages précédents se mélangent.
• Agents et vibe coding (~10–12 %) — sur les grosses tâches et les bases de code, les erreurs s'accumulent et un beau résultat vire vite au chaos.
• Argent et effets comportementaux (~7–8 %) — les limites changent, les tokens fondent de façon inégale et les utilisateurs s'attachent davantage aux modèles.

La conclusion pratique de l'autrice est plutôt terre à terre : compter moins sur une « compréhension magique » et bâtir plus souvent des appuis externes autour du modèle. Concrètement : des chats courts et ciblés, des documents en Markdown relus à chaque fois, du retrieval plutôt que de la génération brute, une température basse pour les faits et une vérification humaine obligatoire partout où une erreur peut coûter de l'argent, des données, du temps d'équipe ou de la réputation. Sinon, chaque nouvelle session réinventera les règles de travail.

Pourquoi le mode agent exaspère

Un bloc distinct est consacré aux agents et au vibe coding, et c'est là que le ton de l'article se durcit le plus. L'idée de répartir le travail entre un « architecte », un « codeur » et un « testeur » produit souvent l'effet inverse en pratique : chaque agent ne voit que sa part du contexte, les décisions divergent et les erreurs de l'étape précédente se propagent automatiquement. Pour des tâches indépendantes, l'approche fonctionne encore, mais en développement, où tout est lié à tout, les pertes de coordination avalent aisément la vitesse promise.

D'où un ensemble de règles de protection : mode lecture seule pour l'analyse, approval gates avant toute action dangereuse, sauvegardes, interdictions explicites de suppression et documentation commune du projet pour tous les participants.

La même logique vaut pour l'usage courant des chatbots. Si l'utilisateur se met à percevoir le modèle comme un interlocuteur « à lui », il lui confie plus vite ses notes, son courrier, ses clés et ses documents internes. Le problème n'est pas que l'IA comprenne réellement l'humain, mais qu'elle imite cette compréhension de façon très convaincante.

Ce que cela signifie

Le texte de Habr AI est utile parce qu'il fait passer la discussion sur l'IA du registre de l'enthousiasme à celui de l'exploitation. L'idée centrale est simple : les réseaux de neurones sont déjà un outil de travail, mais il faut les traiter non comme un collègue intelligent, mais comme un système puissant, instable et parfois coûteux, qui requiert en permanence des garde-fous, de la documentation, un contrôle d'accès et une vérification humaine. C'est ce qui distingue une stack de travail d'un jouet dangereux.