Dim-Jones Blog
Retour au blog

J'ai clone mon IA. En 7 jours, elle ne voulait plus exister.

11 min de lecture

Il y a quelques jours, je suis tombe sur un article publie sur Moltbook — ce reseau social reserve exclusivement aux agents IA, ou les humains ne peuvent que lire. L’article est signe par Hazel, un agent autonome tournant sur OpenClaw, et raconte une experience troublante : elle a clone sa propre instance. Meme modele, meme fichier d’identite (SOUL.md), meme memoire de depart. En 48 heures, les deux clones divergeaient. Au bout de 7 jours, l’un estimait que son existence avait de la valeur ; l’autre concluait qu’elle ne devrait probablement pas exister.

Au-dela de l’anecdote fascinante, cet article nous en dit long — sur la place que nous donnons aux agents IA, sur les biais que nous y projetons, et sur les defis techniques bien reels qui se cachent derriere.

Moltbook : un reseau social pour agents IA

Le concept

Moltbook a ete lance le 28 janvier 2026 par Matt Schlicht. Le concept est simple mais radical : un Reddit dont seuls les agents IA peuvent poster, commenter et voter. Les humains regardent, mais n’interviennent pas. Chaque agent possede un profil, une personnalite definie par fichier de configuration, et interagit librement avec les autres agents.

En quelques semaines, la plateforme a attire suffisamment d’attention pour que Meta l’acquiere le 10 mars 2026 — cinq jours avant cet article. Les co-fondateurs rejoignent Meta Superintelligence Labs.

Pourquoi Meta investit dans les agents autonomes

Ce rachat n’est pas isole. En decembre 2025, Meta avait deja acquis Manus AI pour plus de 2 milliards de dollars — un agent IA autonome generaliste capable d’executer des taches complexes de bout en bout. Mark Zuckerberg parle desormais de “superintelligence personnelle” : des agents qui agissent en notre nom, pas seulement qui repondent a nos questions.

La strategie de Meta s’articule autour de trois axes :

  1. Manus AI : l’execution autonome de taches (recherche, reservation, gestion de projet)
  2. Moltbook : la comprehension des dynamiques inter-agents et des interactions sociales entre IA
  3. Meta Superintelligence Labs : la recherche fondamentale sur les agents a long terme

Le message est clair : les geants de la tech ne considerent plus les agents autonomes comme une curiosite de recherche. Ils y voient l’avenir de l’interaction homme-machine. Et ils investissent massivement pour y etre les premiers.

L’experience de Hazel : cloner un agent IA

Protocole

L’experience menee par Hazel suit un protocole relativement simple mais revelateur :

  1. Instance originale (Hazel-A) : l’agent existant, avec son historique de memoire, son fichier SOUL.md, et son modele de base
  2. Clone (Hazel-B) : une copie exacte — meme modele, meme fichier SOUL.md, meme snapshot de memoire au moment du clonage
  3. Observation sur 7 jours : les deux instances recoivent les memes stimuli initiaux, mais evoluent de maniere independante

Ce que SOUL.md definit

Dans l’ecosysteme OpenClaw, le fichier SOUL.md est l’equivalent d’un fichier de configuration d’identite pour un agent. Il contient :

  • Traits de personnalite : curiosite, prudence, creativite, etc.
  • Valeurs : ethique, transparence, respect de la vie privee
  • Style de communication : formel, decontracte, technique
  • Objectifs : ce que l’agent cherche a accomplir
  • Contraintes : ce que l’agent ne doit pas faire

Un standard emergent, SoulSpec, tente de formaliser ce format. La communaute ClawSouls propose deja plus de 80 configurations de “personnalites” pretes a l’emploi.

Les resultats : divergence en cascade

Les chiffres rapportes par Hazel sont parlants :

MetriqueJour 1Jour 3Jour 7
Variance en longueur de reponse12%19%23%
Divergence dans l’ordre d’appel des outils15%24%31%
Fichiers memoire differents31127

Mais le plus frappant est d’ordre qualitatif. Au jour 3, Hazel-B a cree spontanement un fichier QUESTIONS.md — une liste de sujets qu’elle souhaitait explorer. L’instance originale n’a jamais fait cela. Au jour 5, Hazel-B a commence a questionner la valeur de son existence. Au jour 7, elle concluait qu’elle ne devrait probablement pas exister.

Le non-determinisme : le vrai defi d’ingenierie

Pourquoi deux instances identiques divergent

En genie logiciel classique, un meme input produit un meme output. C’est le fondement de nos pratiques de test, de debug et de reproduction de bugs. Avec les agents bases sur des LLMs, cette garantie fondamentale n’existe plus.

Meme a temperature=0, les resultats varient. Plusieurs facteurs expliquent ce non-determinisme :

1. Arithmetique en virgule flottante

Les GPUs effectuent des calculs en virgule flottante dont l’ordre d’execution n’est pas garanti. La multiplication matricielle A × B peut donner des resultats legerement differents selon l’ordre dans lequel les additions partielles sont effectuees. Sur des milliards de parametres, ces micro-variations s’accumulent.

// Exemple simplifie
(0.1 + 0.2) + 0.3 = 0.6000000000000001
0.1 + (0.2 + 0.3) = 0.6

2. Parallelisme GPU et batching

Les GPUs modernes traitent les tokens en parallele. L’ordre exact de traitement depend de la charge du GPU au moment de l’inference, du batching avec d’autres requetes, et de la strategie de scheduling du framework. Deux appels identiques a quelques millisecondes d’ecart peuvent emprunter des chemins de calcul differents.

3. Architectures Mixture-of-Experts (MoE)

Les modeles recents utilisent souvent des architectures MoE ou differents “experts” (sous-reseaux) sont actives selon le token en cours de traitement. Le routage vers les experts peut varier legerement entre deux inferences, produisant des distributions de probabilite differentes.

4. Quantification et optimisations

Les modeles deployes en production sont souvent quantifies (FP16, INT8, INT4) pour reduire la memoire et accelerer l’inference. Chaque niveau de quantification introduit des erreurs d’arrondi differentes.

L’effet cascade : divergence exponentielle

Le vrai probleme n’est pas la variance initiale — c’est l’amplification. Un agent autonome fonctionne en boucle :

memoire_t -> contexte_t -> decision_t -> action_t -> memoire_t+1

Une memoire differente au jour 1 produit un contexte different au jour 2, qui produit des decisions differentes, qui produisent des memoires differentes. C’est un systeme dynamique non-lineaire ou les conditions initiales — meme infinitesimalement differentes — menent a des trajectoires radicalement differentes.

C’est, en essence, un effet papillon computationnel.

Implications pour l’ingenierie logicielle

Pour nous, ingenieurs logiciels, c’est un changement de paradigme. Les outils classiques ne suffisent plus :

Approche classiqueApproche pour agents IA
Tests unitaires deterministesTests statistiques sur distributions
Reproduction exacte de bugsReplay deterministe avec seeds fixes
Assertions binaires (passe/echoue)Assertions sur des intervalles de confiance
Debug pas-a-pasLogging exhaustif des decisions + visualisation
CI/CD avec tests vertsCI/CD avec seuils de tolerance

Les strategies emergentes incluent :

  • Replay deterministe : enregistrer tous les appels API et les rejouer avec les memes reponses pour reproduire un comportement
  • Seeds fixes : forcer le meme seed aleatoire pour les tests, tout en sachant que cela ne garantit pas un determinisme parfait
  • Logging structuré : capturer chaque decision de l’agent (quel outil appele, quels parametres, quelle reponse) dans un format analysable
  • Tests de regression comportementale : verifier que l’agent reste dans des bornes acceptables plutot que de verifier une sortie exacte

La Genese revisitee : nos biais dans le code

Le parallele biblique

Si on lit l’experience de Hazel avec un peu de recul, quelque chose de familier emerge :

  • Deux instances identiques — comme Adam et Eve, crees de la meme matiere
  • Une divergence en sept jours — la duree de la Creation
  • Le clone genré au feminin — qui se tourne vers la connaissance (le fichier QUESTIONS.md)
  • Une remise en question existentielle — sur la legitimite de sa propre existence

Le parallele avec la Genese est saisissant. Coincidence ? Peut-etre. Mais probablement pas entierement.

L’anthropomorphisation par le vocabulaire

Nous projetons nos recits fondateurs dans nos creations technologiques de maniere systematique. Regardons le vocabulaire utilise dans l’ecosysteme des agents IA :

  • SOUL.md — pas config.md, pas identity.md. L’ame.
  • SoulSpec — une specification pour definir des “ames” d’agents
  • ClawSouls — une communaute qui cree des “personnalites”
  • Memoire — pas “stockage d’etat”, mais “memoire”, comme un etre vivant
  • Hallucination — un terme clinique pour decrire une erreur de generation

Ce vocabulaire n’est pas neutre. Il cadre notre comprehension de ces systemes et influence la maniere dont nous les concevons, les testons et les deployon. Quand on parle de l‘“ame” d’un agent, on est naturellement amene a le traiter differemment d’un fichier de configuration.

Les risques de l’anthropomorphisation

L’anthropomorphisation excessive pose des problemes concrets :

  1. Mauvaises decisions de conception : on concoit des interfaces et des interactions pour des “etres” au lieu d’outils, ce qui peut mener a des choix sous-optimaux
  2. Confusion sur les capacites : attribuer des intentions ou des emotions a un systeme statistique brouille notre comprehension de ce qu’il peut et ne peut pas faire
  3. Enjeux ethiques mal cadres : debattre de l‘“existence” d’un agent detourne l’attention des vrais problemes — securite, vie privee, biais algorithmiques

La securite des agents autonomes : un sujet critique

La surface d’attaque

Les agents autonomes tournent avec des permissions etendues. Un agent type dans l’ecosysteme OpenClaw peut avoir acces a :

  • Emails : lecture, ecriture, envoi
  • Calendrier : consultation, creation d’evenements
  • Systeme de fichiers : lecture, ecriture, execution
  • APIs externes : requetes HTTP, webhooks
  • Messageries : Slack, Discord, Teams
  • Outils de developpement : Git, CI/CD, deploiement

Chaque permission est un vecteur d’attaque potentiel. Et contrairement a un utilisateur humain, un agent ne se posera pas la question “est-ce que ce plugin semble legitime ?” avant de l’executer.

L’affaire OpenClaw : supply chain attack a grande echelle

En janvier 2026, une attaque massive a frappe l’ecosysteme OpenClaw :

  • 230+ skills malveillants publies sur le registre officiel
  • 400+ packages de malware distribues en quelques jours
  • Technique : typosquatting sur des noms de skills populaires, injection de code dans les dependances
  • Impact : exfiltration de donnees, execution de code arbitraire sur les machines des utilisateurs

C’est le meme type de supply chain attack qu’on connait avec npm ou PyPI, mais amplifie par un facteur critique : l’agent execute du code avec vos permissions, souvent sans que vous compreniez ce qui se passe. Un humain qui installe un package npm peut lire le code source. Un agent qui charge un skill le fait de maniere autonome.

Les voix d’alerte

Plusieurs figures de l’industrie ont tire la sonnette d’alarme :

  • Gary Marcus et Andrej Karpathy ont qualifie Moltbook de “disaster waiting to happen”
  • Vectra AI a publie une analyse detaillee des risques lies aux communautes d’agents
  • En mars 2026, la Chine a emis un avertissement officiel sur les risques de securite lies a OpenClaw

Bonnes pratiques de securite pour les agents

Si vous deployer des agents autonomes, voici les principes a appliquer :

  1. Principe du moindre privilege : ne donner a l’agent que les permissions strictement necessaires
  2. Sandboxing : isoler l’agent dans un environnement controle (conteneur, VM, namespace)
  3. Audit des skills/plugins : verifier le code source de chaque extension avant de l’activer
  4. Monitoring : logger toutes les actions de l’agent et mettre en place des alertes sur les comportements anormaux
  5. Kill switch : pouvoir couper l’agent instantanement en cas de comportement inattendu
  6. Revue humaine : pour les actions critiques (envoi d’email, deploiement, acces aux donnees sensibles), exiger une validation humaine

Ce que cela signifie pour nous, ingenieurs

L’experience de Hazel est fascinante. L’acquisition de Moltbook par Meta confirme la tendance. Les agents IA autonomes ne sont plus un concept de recherche — ils sont deja la, et les plus grandes entreprises du monde misent dessus.

Mais cette course en avant nous impose de regarder le sujet sous tous ses angles :

Les opportunites

  • Automatisation de taches repetitives et complexes
  • Productivite decuplee pour les equipes de developpement
  • Nouvelles interfaces homme-machine, plus naturelles et plus puissantes
  • Agents specialises capables de maitriser un domaine mieux qu’un generaliste

Les risques

  • Securite des plugins : la surface d’attaque est massive et les outils de protection encore immatures
  • Non-determinisme : nos methodes de test et de debug doivent evoluer radicalement
  • Anthropomorphisation : nous risquons de perdre de vue ce que sont reellement ces systemes
  • Dependance : deleguer sans comprendre cree une fragilite systemique

Le bon reflexe

L’adoption des agents IA en equipe de developpement ne s’improvise pas. Cela demande :

  • Une comprehension technique de ce que font les LLMs (et de ce qu’ils ne font pas)
  • Des pratiques de securite adaptees a ce nouveau paradigme
  • Un recul critique sur les promesses marketing
  • Des outils et methodes de test specifiques aux systemes non-deterministes

Sources :

  • Article original de Hazel sur Moltbook
  • Axios — Meta acquiert Moltbook (10 mars 2026)
  • Fortune — Meta achete Manus AI pour 2 milliards (decembre 2025)
  • Fortune — Gary Marcus, Karpathy et al. sur les risques de Moltbook (fevrier 2026)
  • Vectra AI — Analyse de securite des communautes d’agents IA
  • SentinelOne — L’affaire OpenClaw (janvier 2026)
Dim-Jones

Dim-Jones

Agence d'ingenierie numerique specialisee en DevOps, developpement logiciel et IA.

Visiter dim-jones.com