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 :
- Manus AI : l’execution autonome de taches (recherche, reservation, gestion de projet)
- Moltbook : la comprehension des dynamiques inter-agents et des interactions sociales entre IA
- 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 :
- Instance originale (Hazel-A) : l’agent existant, avec son historique de memoire, son fichier
SOUL.md, et son modele de base - Clone (Hazel-B) : une copie exacte — meme modele, meme fichier
SOUL.md, meme snapshot de memoire au moment du clonage - 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 :
| Metrique | Jour 1 | Jour 3 | Jour 7 |
|---|---|---|---|
| Variance en longueur de reponse | 12% | 19% | 23% |
| Divergence dans l’ordre d’appel des outils | 15% | 24% | 31% |
| Fichiers memoire differents | 3 | 11 | 27 |
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 classique | Approche pour agents IA |
|---|---|
| Tests unitaires deterministes | Tests statistiques sur distributions |
| Reproduction exacte de bugs | Replay deterministe avec seeds fixes |
| Assertions binaires (passe/echoue) | Assertions sur des intervalles de confiance |
| Debug pas-a-pas | Logging exhaustif des decisions + visualisation |
| CI/CD avec tests verts | CI/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, pasidentity.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 :
- 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
- 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
- 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 :
- Principe du moindre privilege : ne donner a l’agent que les permissions strictement necessaires
- Sandboxing : isoler l’agent dans un environnement controle (conteneur, VM, namespace)
- Audit des skills/plugins : verifier le code source de chaque extension avant de l’activer
- Monitoring : logger toutes les actions de l’agent et mettre en place des alertes sur les comportements anormaux
- Kill switch : pouvoir couper l’agent instantanement en cas de comportement inattendu
- 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)