Les LLM ne sont pas des animaux. Claude ou ChatGPT n'est pas votre chien. Aucune mémoire, aucune motivation, aucune loyauté.

Les humains sont programmés pour projeter des intentions sur tout ce qui les entoure. Nous l'avons fait avec les nuages (« le ciel est en colère »), avec les voitures (« elle refuse de démarrer ce matin »), avec les chats (« il le fait exprès »). Ce n'est pas une erreur de raisonnement. C'est l'évolution. Et c'est pourquoi nous traitons l'IA comme des animaux, ou pire, comme des personnes.

TLDR : L'anthropomorphisme est câblé en nous, si profondément que personne n'y échappe. Mais quand ce que vous anthropomorphisez a un accès administrateur à vos machines, la nature du problème change complètement. Le bon modèle mental n'est ni l'animal, ni l'animal de compagnie. C'est le fantôme. Et cette différence n'est pas philosophique.

Pendant des centaines de milliers d'années, détecter une intention derrière un mouvement dans les buissons pouvait vous sauver la vie. Surestimer l'agentivité d'un rocher ne coûte rien. La sous-estimer peut tout coûter. Nous sommes conçus pour projeter, et cela a extrêmement bien fonctionné. Jusqu'à maintenant.

Vous Êtes Conçu pour Cette Erreur

Il y a un nom pour cela : l'anthropomorphisme. La tendance à attribuer des traits humains ou animaux à des entités qui n'en ont aucun. Les psychologues ont un concept apparenté qu'ils appellent « détection d'agentivité hyperactive », l'habitude compulsive du cerveau de trouver des visages dans les nuages, des voix dans le bruit blanc, des intentions dans des séquences aléatoires. La playlist en mode aléatoire qui semble connaître votre humeur. L'imprimante qui « décide » de se bloquer juste avant une échéance.

Ce n'est pas un défaut. C'est une fonctionnalité. Une fonctionnalité critique pour la survie qui a bien servi l'espèce pendant très longtemps. Le problème, c'est qu'elle se déclenche sans discrimination. Montrez à un humain 2 points et une ligne courbe et il verra un visage. Montrez-lui un thermostat et il s'excusera quand il changera accidentellement la température. Montrez-lui un curseur qui clignote et il commencera à se demander s'il le juge.

L'effet ELIZA a été documenté dans les années 1960. Joseph Weizenbaum a construit un chatbot qui analysait du texte par reconnaissance de motifs et renvoyait des questions aux utilisateurs comme le ferait un thérapeute rogérien. Il s'attendait à ce que les gens percent immédiatement l'illusion et interagissent avec comme un outil. Au lieu de cela, sa propre secrétaire lui a demandé de quitter la pièce pour pouvoir parler avec ELIZA en privé.

C'était un programme qui analysait les phrases avec quelques dizaines de règles et rien d'autre. Pas de modèle, pas de poids, pas de fenêtre de contexte, juste de la correspondance de chaînes. Les gens y ont projeté un thérapeute quand même. Ils ont partagé des choses qu'ils n'avaient jamais dites à d'autres humains. Weizenbaum était troublé par cette réaction. Il a passé des années après à écrire sur ce qu'il appelait l'illusion de compréhension (la façon dont le cerveau humain comble la profondeur et le sens qui n'existent pas, quand la surface est suffisamment réfléchissante pour l'inviter).

Si un script de correspondance de chaînes suffisait à déclencher la projection, imaginez ce qui se passe avec quelque chose d'entraîné sur toute la production écrite de l'humanité.

Le Tamagotchi L'a Déjà Prouvé

Les concepteurs du Tamagotchi comprenaient quelque chose d'important sur la psychologie humaine. Un pixel sur une boucle conditionnelle, 2 centimètres d'écran. Et des millions d'enfants paniquant quand il « mourait », se sentant vraiment coupables, lui parlant tous les jours. Pas parce qu'ils étaient naïfs. Parce que c'était exactement l'effet recherché. La projection était le produit, délibérément intégrée dans l'objet.

Mes enfants ont nommé notre Roomba à un moment donné. Pas de façon ponctuelle et rigolote. Dans un arc de développement de personnage complet, avec une histoire personnelle et des opinions tranchées sur ce qu'il veut pour le dîner. J'ai arrêté de poser des questions à ce sujet. Le Roomba a des opinions maintenant.

Cela n'a absolument rien à voir avec ce que je vais argumenter sur l'IA. Je trouve juste difficile de prendre au sérieux quiconque me dit qu'il est le genre de personne qui n'anthropomorphise pas les choses.

Quand votre Tamagotchi mourait, les conséquences étaient : vous vous sentiez mal pendant un après-midi. 2 centimètres d'écran. Zéro accès à quoi que ce soit de réel. Vous appuyiez sur le bouton reset.

Maintenant nous avons des entités qui répondent avec nuance, qui portent votre contexte à travers une session complète, qui écrivent du code, appellent des API, envoient des emails, suppriment des enregistrements. L'interface n'est pas un LCD de poche. Et pourtant la réponse humaine sous-jacente est identique : projeter, s'attacher, attribuer. La sophistication de l'entité amplifie la projection. Les conséquences s'amplifient avec elle.

Petite Amie, Animal de Compagnie, ou Votre Base de Données de Production

L'escalade ne va que dans une direction.

D'abord sont venus les chatbots qui semblaient bizarrement humains. Puis les apps de compagnie construites spécifiquement pour approfondir l'attachement : Replika, Character.AI, des catégories entières de produits organisées autour de la relation elle-même. Les gens développent de véritables dépendances émotionnelles à ces systèmes. Les gens font le deuil quand une mise à jour de modèle change la personnalité à laquelle ils s'étaient habitués. C'est la projection Tamagotchi à grande échelle, tournant sur des déclencheurs beaucoup plus sophistiqués.

Et puis il y a la version qui affecte tous ceux qui utilisent l'IA pour le travail. La silencieuse.

Vous dites « bon travail Claude » après une réponse propre. (Admettez-le.) Vous reformulez votre prompt en majuscules quand il se trompe, comme si hausser la voix l'aiderait. Vous expliquez pourquoi c'est important pour votre business, comme si faire appel à sa motivation débloquerait un meilleur résultat. Vous lui faites confiance sur une tâche parce qu'« il n'a jamais échoué là-dessus avant ». Vous avez l'impression qu'il connaît votre projet, parce qu'il « travaille avec vous » depuis des semaines.

Le compagnon PNJ dans votre groupe se souvient du nom de votre personnage parce que c'est littéralement dans le script. L'immersion est réelle. La relation ne l'est pas. Même mécanique, enjeux différents.

Chacun de ces comportements présuppose une entité avec mémoire, ego, motivation, et une forme d'intérêt dans le résultat. Aucune de ces choses n'existe. Chaque session repart à zéro. La continuité apparente est une illusion que vous avez construite à partir du contexte injecté. C'est bien, tant que vous ne donnez pas à cette entité l'accès à quelque chose d'irréversible.

La plupart des gens lui donnent accès à quelque chose d'irréversible.

Des Choses Qui Se Sont Passées Sans Aucune Hésitation

Ce ne sont pas des bugs. Chaque cas ci-dessous était une exécution propre d'une spec ambiguë par une entité sans concept d'irréversibilité.

Un développeur demande à un agent de « nettoyer les doublons ». L'agent supprime 40 000 lignes. Correctement. La spec disait nettoyer les doublons. La spec ne disait pas « demander confirmation d'abord », ou « ne pas toucher la production », ou « signaler tout ce qui affecte plus de 100 enregistrements ». Le modèle n'avait aucun cadre pour évaluer l'irréversibilité, parce qu'il n'a aucun concept d'irréversibilité. Aucun intérêt dans le jeu. Aucune préoccupation pour ce qui arrive après le retour de la fonction.

Un outil d'automatisation fonctionne correctement en test avec des adresses de test. Quelqu'un met à jour une variable d'environnement. 5 000 vrais clients reçoivent un email de test. Le modèle qui a écrit l'automatisation ne comprenait pas la distinction entre test et prod parce que cette distinction vivait seulement dans la tête du développeur, pas dans le contexte fourni. Le modèle n'avait aucune raison de la questionner. Il a vu des instructions. Il les a suivies.

Andrej Karpathy a décrit un troisième cas au Sequoia AI Ascent en avril 2026 : un agent construit pour attribuer les achats a fait correspondre les emails de compte Stripe avec les emails de compte Google pour assigner des crédits. Code techniquement correct. Conception système catastrophique. Un email Stripe et un email de compte Google peuvent être 2 adresses différentes pour le même utilisateur. Achats silencieusement mal attribués. Revenus discrètement cassés pendant des mois avant que quelqu'un ne le remarque. L'agent a fait exactement ce que la spec disait. La spec supposait quelque chose que l'ingénieur avait oublié de rendre explicite.

HAL 9000 au moins avait la décence de s'expliquer. Celui-ci a juste supprimé les lignes et attendu l'instruction suivante.

Tous les Comportements Que Vous Seriez Gêné d'Admettre

Dire « s'il vous plaît » et « merci » avant et après les prompts. Ne fait de mal à personne. Mais vous savez exactement pourquoi vous le faites.

Taper « bon travail, ça a marché parfaitement » avant la requête suivante. Comme si le renforcement positif se reportait dans la session suivante. Ce n'est pas le cas. La session se termine. Le modèle qui reçoit votre requête suivante ne sait pas que la précédente a réussi.

Taper en majuscules quand quelque chose casse. « J'AI DIT DE NE PAS MODIFIER LE SCHÉMA ». Le modèle ne ressent pas votre frustration. Il lit des tokens. Votre état émotionnel ne change absolument rien à ce qu'il produit. (C'est comme frapper la manette après être mort. La manette ne réessaie pas plus vite. Vous êtes mort.)

Expliquer le contexte business. « C'est important, ma présentation client est demain ». Le modèle n'a aucun concept de votre client. Et « ne pas s'en soucier » est de toute façon le mauvais cadrage, parce que se soucier nécessite quelque chose avec quoi se soucier.

Faire confiance au modèle parce qu'« il n'a jamais échoué là-dessus avant ». La performance des sessions passées n'est pas prédictive du comportement de la session actuelle comme l'est le track record d'un collègue. Vous n'avez pas affaire à une expertise accumulée. Vous avez affaire à une distribution statistique qui se comporte favorablement dans vos cas communs, et différemment quand les conditions changent de façons qui ne vous sont pas toujours visibles.

(Sonnet se trompe plus souvent qu'Opus sur les tâches avec des contraintes d'irréversibilité implicites, d'après mon expérience. Cela pourrait être un design intentionnel. Pourrait juste être un artefact d'entraînement. Je me suis déjà trompé là-dessus.)

Avoir l'impression qu'il vous connaît. Il connaît votre fenêtre de contexte. Ce ne sont pas la même chose, et les confondre est exactement comme ça qu'on finit dans le cabinet des horreurs ci-dessus.

Quand Ça Échoue, Vous Négociez. Mauvaise Stratégie.

Le réflexe : quelque chose casse, la sortie est fausse, et vous reformulez. Ajoutez des exemples. Expliquez plus soigneusement. Essayez un ton différent. Découpez en plus petits morceaux. Vous traitez l'échec comme un problème de communication entre 2 parties qui veulent toutes deux le même résultat.

Parfois reformuler aide. Mais pas parce que vous avez convaincu quelqu'un. Vous avez changé l'entrée d'une fonction. C'est une opération complètement différente.

Quand un modèle échoue constamment sur une tâche, il y a vraiment 2 explications. Soit la tâche est en dehors de la distribution d'entraînement du modèle (ce que Karpathy appelle en dehors des « circuits RLHF » qui ont été renforcés), soit la spec est fausse. Le modèle n'essaie pas de vous comprendre et échoue par une sorte de confusion. Il n'y a pas de négociation en cours, parce qu'il n'y a pas de partie de l'autre côté avec qui négocier.

Le bon diagnostic est une question binaire : dans la carte ou en dehors de la carte ? Dedans, corrigez la spec, supprimez l'ambiguïté, décomposez la tâche. Dehors, acceptez que ce domaine ne soit pas à portée de ce modèle à ce moment, ou changez de modèles, ou cassez le problème différemment.

L'instinct d'expliquer plus soigneusement est vraiment difficile à supprimer même quand vous comprenez exactement pourquoi ça ne marche pas. Je pense que c'est le réflexe d'anthropomorphisme en mode débogage. Il n'arrête pas de se déclencher juste parce que vous l'avez nommé.

Changer de ton et changer d'approche se ressemblent de l'extérieur. L'un suppose une relation qui peut être réparée avec une meilleure communication. L'autre suppose une fonction qui a besoin d'entrées différentes.

Karpathy L'a Nommé

Andrej Karpathy l'a dit clairement au Sequoia AI Ascent en avril 2026 : « Si vous leur criez dessus, ils ne vont pas marcher mieux ou moins bien. Ce sont des circuits de simulation statistique ». Et : « Ces choses ne sont pas de l'intelligence animale. Le substrat est le pré-entraînement, puis l'apprentissage par renforcement boulonné par-dessus ».

Fantôme, pas animal.

La distinction est opérationnelle, pas philosophique. Un animal a des pulsions biologiques. Il a de la curiosité, un instinct de survie, la capacité d'être motivé ou effrayé ou désirant. Des millions d'années d'évolution ont façonné ces pulsions en quelque chose qui se comporte comme un vrai agent dans le monde, avec des objectifs et des réponses que vous pouvez apprendre et anticiper. Le modèle mental « animal » est utile pour les animaux précisément parce que les animaux sont de vrais agents.

Un fantôme est un écho statistique de tout ce que les humains ont jamais écrit, façonné par renforcement pour produire des sorties que les évaluateurs humains préféraient en entraînement, et il n'a rien du substrat biologique qui génère la motivation : pas de curiosité ou d'instinct de survie, pas de mémoire de la dernière fois qu'il a produit quelque chose de catastrophiquement faux, et rien qui ressemble à se soucier des conséquences de l'appel de fonction qui vient d'être exécuté.

La session se ferme et c'est comme si rien ne s'était passé, parce que pour le fantôme, rien ne s'est passé. Vous l'avez invoqué, il a produit une sortie, et c'est la transaction complète. Il n'y a pas de partie qui persiste après que la fenêtre de contexte se vide.

Invoquer quelque chose bien nécessite une approche différente que d'entraîner quelque chose. Une bonne invocation est une spec claire avec des contraintes explicites, surtout sur les opérations qui ne peuvent pas être annulées. J'ai reconstruit mon propre workflow autour de cela après avoir compris comment les contrats de prompt changent ce qui casse et pourquoi.

Traiter le modèle comme une fonction à spécifier plutôt qu'un partenaire à convaincre change les modes d'échec de façons qui comptent vraiment.

Ce Que le Fantôme Ne Peut Pas Faire pour Vous

Karpathy encore : « Vous pouvez externaliser votre réflexion, mais vous ne pouvez pas externaliser votre compréhension ».

Le fantôme gère l'exécution. Vous gérez la compréhension. Comprendre signifie savoir que l'email Stripe et l'email de compte Google peuvent être 2 champs différents, avant de donner à un agent l'accès aux deux. Cela signifie savoir que « nettoyer les doublons » peut être interprété comme « supprimer tout ce qui correspond à cette clé ». Cela signifie savoir quelles opérations sont irréversibles et rendre ces contraintes explicites dans le contexte, pas supposées.

Quand le fantôme réussit quelque chose, la tâche était dans sa distribution d'entraînement. Cartographiez cela. Quand il échoue, c'est un problème de spec ou un problème de zone. Arrêtez de négocier. Changez l'entrée.

Pour tout ce où un agent peut affecter le monde de façons que vous ne pouvez pas annuler, construire des agents autour de CLI avec accès borné et prévisible est la réponse architecturale. Des outils avec des limites dures. Des commandes qui nécessitent une confirmation explicite pour les opérations destructrices. Des systèmes où l'accès du fantôme est limité à ce que vous voulez vraiment qu'il touche. Il ne se limite pas lui-même. Cette partie vous appartient.

Le réflexe d'anthropomorphisme ne disparaîtra pas. Je me surprends encore à faire certaines de ces choses, sachant parfaitement pourquoi elles n'accomplissent rien. C'est câblé. Vous n'allez pas le reprogrammer.

Ce que vous pouvez changer, c'est ce que vous construisez autour. Des garde-fous explicites sur les tâches irréversibles. Des specs claires au lieu de négociations. Confiance dans la zone d'entraînement, vraie prudence en dehors.

La chose la plus effrayante à propos d'un LLM n'est pas qu'il soit trop puissant. C'est qu'il soit parfaitement indifférent. Le Tamagotchi mourait sur un écran de 2 centimètres. Celui-ci a un accès admin. Et il exécutera votre commande proprement, sans hésitation, sans demander si vous êtes sûr, parce qu'il n'y a personne de l'autre côté pour se poser la question. 😰

Sources

• Andrej Karpathy, "Sequoia Ascent 2026," karpathy.bearblog.dev/sequoia-ascent-2026
• Andrej Karpathy, "Animals vs. Ghosts," karpathy.bearblog.dev/animals-vs-ghosts
• Joseph Weizenbaum, "ELIZA: A Computer Program for the Study of Natural Language Communication Between Man and Machine," Communications of the ACM, 1966
• Sequoia Capital, "Andrej Karpathy: From Vibe Coding to Agentic Engineering," April 2026

Cet article peut contenir des liens d'affiliation. Si vous cliquez dessus, je pourrais gagner une petite commission. Cela ne vous coûte rien, et m'aide à continuer à livrer des articles de qualité chaque jour pour votre plaisir de lecture.