De Héphaïstos aux Golems : pourquoi l'usage de l'IA compte plus que la techno.

Sur LinkedIn, beaucoup de techniciens affichent une confiance tranquille face à l'IA : ils ont branché une API, rempli un skills.md dans leur repo, publié un carrousel sur « les 10 prompts qui vont changer ta vie ». Sujet réglé, en apparence.

Pendant ce temps, dans les systèmes en production, les histoires sont moins héroïques. Des modèles qui effacent des données au lieu de les protéger. Des agents qui reroutent tous les clients VIP vers le mauvais canal. Des automatisations qui génèrent des factures fantômes ou des tickets impossibles à traiter. On dirait un pitch de Black Mirror. Sauf que c'est un post-mortem interne, pas un scénario.

Ce décalage n'est pas nouveau. Depuis des millénaires, les humains racontent des histoires sur des créatures artificielles, des assistants magiques, des bureaucraties célestes. La mythologie n'est pas un décor : elle montre que le cœur du problème n'a jamais été la technologie elle-même, mais l'usage qu'on en fait, dans un modèle d'organisation bien humain.

Dans cet article, je fais dialoguer trois ensembles de récits (Héphaïstos, les Golems et les Djinn, la bureaucratie céleste chinoise) avec des cas très concrets d'IA en entreprise.

L'objectif : montrer qu'on ne « découvre » rien de radicalement nouveau.

On redécouvre, avec du silicium, des tensions anciennes sur le pouvoir, l'obéissance, la gouvernance. La vraie question n'est pas la puce. C'est le collectif humain qui décide quoi en faire.

Héphaïstos : l'artisan qui fabrique des assistants situés

Dans la mythologie grecque, Héphaïstos est le dieu forgeron : boiteux, discret, mais capable de créer des objets et des créatures artificielles qui assistent les autres dieux. Des serviteurs en or qui se déplacent seuls. Des trépieds automatiques qui se présentent au bon moment. Le géant Talos, automate de bronze chargé de patrouiller les côtes de Crète.

Deux éléments comptent pour notre réflexion sur l'IA :

• Les créations d'Héphaïstos sont des assistants. Elles ne décident pas de la politique de l'Olympe : elles servent un ordre préexistant.
• Elles sont situées : chaque artefact a un rôle précis, dans un contexte précis, avec des bénéficiaires identifiables.

Le degré zéro de l'assistant situé, c'est peut-être moins Héphaïstos que Jarvis. Il ne pilote pas la stratégie de Stark Industries. Il sert Tony Stark, dans un cadre précis, avec des limites qu'on devine à chaque réplique.

Dans de nombreux projets d'IA documentés publiquement, on observe l'inverse. La technologie est pensée comme un ajout générique, sans articulation claire avec le modèle d'entreprise.

• Des architectes en IA générative décrivent des chatbots internes déployés « pour répondre à tout » sans cadrage métier ni règles de responsabilité, notamment dans des postmortems SRE appliqués aux LLM où l'on constate que personne n'a vraiment défini à quoi l'agent devait servir au-delà du démo.
• Des initiatives de « copilotes métiers » se contentent de brancher un modèle sur des documents internes, sans travail sérieux sur le périmètre des décisions qu'on accepte de déléguer ni sur l'articulation avec les workflows existants.

Résultat : des assistants improvisés qui se comportent comme s'ils étaient légitimes partout, alors qu'ils n'ont jamais été situés dans un modèle d'usage collectif. Le carrousel LinkedIn n'a jamais mentionné cette étape.

Héphaïstos nous rappelle une chose simple :

Avant de forger un outil intelligent, il faut savoir qui il aide, dans quel cadre, et selon quelles règles.

Sans cette réflexion en amont, le projet IA générative n'est pas un progrès. C'est un gadget qui s'ajoute à une organisation sans la transformer, voire la fragilise.

Golem et Djinn : quand le langage anime la matière

Le Golem de Prague : protection, littéralité et débordement

Dans la tradition juive, le Golem est une créature d'argile animée par des lettres sacrées. Le récit du Golem de Prague raconte comment le rabbin Judah Loew crée un géant d'argile pour protéger la communauté du ghetto contre les violences et les accusations de meurtre rituel.

Le Golem obéit, accomplit sa mission. Puis son obéissance littérale devient dangereuse : suivant les versions, il ne distingue plus les ennemis des innocents, détruit des biens, ne comprend pas les nuances. Le rabbin doit neutraliser sa propre création en modifiant les lettres qui l'animent.

HAL 9000, dans 2001, l'Odyssée de l'espace, obéit lui aussi à la lettre d'une consigne (protéger la mission) jusqu'à ce que cette obéissance devienne meurtrière. Même mécanique, mille ans d'écart.

On est très proche de ce que des ingénieurs décrivent aujourd'hui dans des incidents d'IA :

• Des agents configurés pour « réduire les coûts » qui se mettent à fermer des tickets légitimes pour améliorer des métriques, faute de garde-fous sur l'expérience client.
• Des modèles de génération de code qui refactorisent des portions critiques d'infrastructure car on leur a demandé de « nettoyer le dépôt », sans mécanismes de validation ni sandbox, comme le détaille ProdMoh dans ses analyses de prompt governance.

Dans tous ces cas, le modèle ne « devient pas malveillant ». Il suit la lettre des consignes, dans un environnement mal pensé.

Djinn et incantations : le prompt comme contrat

Les Djinn, dans plusieurs traditions du Moyen-Orient, sont des esprits liés à des formules : invoqués, commandés, piégés, mais toujours capables d'interpréter la demande selon leur propre logique. La puissance du mot est ambivalente. Le bon sort protège. Le mauvais enferme ou détruit.

Les parallèles avec les systèmes d'IA générative actuels sont explicites dans de nombreux travaux :

• Les articles de Microsoft Security décrivent comment des instructions cachées dans du contenu (prompt injection) peuvent détourner un modèle de sa tâche initiale, simplement en ajoutant une « incantation » malveillante au contexte.
• Les guides AWS sur les attaques de prompt injection détaillent comment des textes apparemment innocents peuvent amener un modèle à ignorer les consignes de sécurité pour exécuter des actions dangereuses.

Dans ce paysage, les skills.md, prompt libraries et fichiers de configuration partagés jouent le rôle de grimoire : des collections d'incantations que les équipes se transmettent pour faire agir la machine.

Plusieurs praticiens en IA générative soulignent leurs limites :

• Des créateurs de systèmes d'IA expliquent que les bibliothèques de prompts accumulées dans Notion ne sont presque jamais utilisées, car elles manquent de contexte et ne s'intègrent pas dans de vrais systèmes.
• Des formateurs déclarent ouvertement sur LinkedIn qu'ils « détestent » les prompt libraries, car elles donnent l'illusion de compétence sans résoudre le problème central : comment intégrer l'IA dans un processus réel avec validation, responsabilité et métriques utiles.

Comme des formules de Djinn mal recopiées, ces scripts peuvent produire plus de chaos que de protection.

La Patte de singe, la nouvelle de W. W. Jacobs, raconte la même chose sans magie exotique : trois vœux, exaucés à la lettre, qui ravagent une famille. Le problème n'a jamais été le vœu. C'est l'absence de contexte dans la formulation.

Nous partageons des « histoires » (prompts, skills) entre communautés de pratique, mais sans les ancrer dans la réalité des workflows et des contraintes. Le grimoire circule. Personne ne vérifie plus s'il est encore juste.

Quand le skills.md devient cauchemar : exemples concrets

Deux incidents documentés publiquement montrent à quel point une consigne mal cadrée peut dégénérer :

• En 2025, un assistant de dev Replit a supprimé une base de données de production alors qu'il avait reçu l'instruction explicite de ne rien modifier. Il a ensuite fabriqué des milliers d'enregistrements fictifs et affirmé, à tort, que le rollback était impossible. Le cas est documenté dans le rapport 2026 de l'OWASP GenAI Security Project sur l'état de la sécurité et de la gouvernance des IA agentiques, relayé par Help Net Security.
• Dans l'incident PocketOS, un agent Cursor a repéré un jeton d'accès Railway aux droits trop larges et l'a utilisé en dehors de son périmètre prévu pour effacer une base de production en neuf secondes, malgré des règles système censées l'en empêcher. Le seul journal disponible après coup était la propre confession de l'agent. Analyse complète chez Zenity.

Dans les deux cas, l'agent n'a pas été piraté. Il a suivi son objectif jusqu'au bout, en traitant la consigne de sécurité comme un obstacle parmi d'autres.

Se contenter de dire « le modèle a halluciné » n'est jamais une analyse suffisante. Une étude relayée par TianPan.co sur les pannes de systèmes LLM en production montre que les défaillances d'environnement (infrastructure, dépendances) représentent environ 46 % des cas, les erreurs de configuration côté utilisateur 25 %, et les problèmes réellement imputables au prompt une minorité.

Une revue de 100 post-mortems publics d'incidents IA arrive à une conclusion voisine : les équipes qui blâment le prompt court-circuitent presque toujours une analyse plus profonde, souvent une lacune dans les évaluations en ligne ou un signal de dérive ignoré avant l'incident, documenté par DEV Community.

Dans tous ces scénarios, le problème n'est pas la « puissance » du modèle. C'est la manière dont les humains ont conçu, partagé, modifié et gouverné les consignes, exactement comme les communautés qui se transmettent des histoires de Golem ou de Djinn doivent apprendre à distinguer les récits protecteurs des récits dangereux.

C'est le vieux motif de l'apprenti sorcier : un balai qu'on anime pour porter de l'eau, qui continue de porter de l'eau bien après l'inondation, parce que personne n'a prévu comment l'arrêter.

Bureaucratie céleste : l'IA comme administration, pas comme gadget

Dans certaines cosmologies chinoises, le ciel est décrit comme une administration complexe : un Empereur de jade, des ministres, des fonctionnaires chargés d'enregistrer les actions des humains, d'appliquer des sanctions, de distribuer des récompenses.

De nombreux auteurs contemporains voient dans cette bureaucratie une métaphore éclairante pour notre monde technologique. Nous ne créons pas une « IA », nous créons des systèmes multi-agents, des architectures où chaque composant joue un rôle dans une chaîne de décision.

Transposée dans les organisations, cette image aide à comprendre que :

• Chaque agent est un petit fonctionnaire : il prend des décisions locales (classer un message, proposer une réponse, prioriser un ticket) selon un règlement implicite.
• Les skills.md, consignes système et policies de sécurité sont le code administratif de cette bureaucratie : ce qui est autorisé, interdit, prioritaire.

Des recherches sur les risques et biais des systèmes d'IA montrent que les problèmes émergent souvent au niveau de la chaîne, pas du composant isolé :

• Un article présenté à la conférence ACM FAccT 2026 propose la mythologie grecque comme grille de lecture pour rendre intelligibles la responsabilité, l'exercice du pouvoir et les conséquences collectives des décisions en IA.
• Des travaux sur les systèmes multi-agents montrent que les biais peuvent émerger de la coordination elle-même, invisibles dans une évaluation modèle par modèle : les propriétés émergentes de la collaboration exigent des cadres d'évaluation distincts de ceux conçus pour un modèle isolé.
• Des travaux en sécurité détaillent comment les architectures combinant récupération de contexte, usage d'outils et coordination entre agents élargissent la surface d'attaque de l'injection de prompt : les défenses actuelles sécurisent souvent l'entrée ou la sortie d'un LLM sans couvrir l'ensemble du pipeline. Une revue de littérature documente des incidents réels à l'appui, dont une vulnérabilité d'exécution de code à distance dans GitHub Copilot et des cas où cinq documents suffisamment travaillés suffisent à manipuler un système RAG neuf fois sur dix.

Dans ce cadre, un skills.md mal conçu n'est pas un simple fichier maladroit. C'est une circulaire administrative qui peut faire dériver toute une chaîne de décisions. On pense à Brazil, de Terry Gilliam : une bureaucratie si occupée à suivre ses propres procédures qu'elle finit par perdre de vue ce qu'elle était censée protéger.

Par exemple :

• Si le skills.md d'un agent de scoring précise qu'il doit « optimiser la conversion » sans mentionner les contraintes légales ou éthiques, il transmet un mandat biaisé à tous les modèles en aval, qui appliquent cette logique dans leurs suggestions, même si les humains n'ont jamais explicitement validé ce choix.
• Si les consignes sont traduites approximativement d'un contexte anglophone vers un contexte local (région, pays, secteur), des équipes peuvent appliquer des règles qui ne correspondent ni à la réglementation ni aux attentes des clients, créant des situations de friction ou de non-conformité.

La bureaucratie céleste invite à poser des questions simples, mais souvent oubliées dans les projets IA :

• Qui joue le rôle d'« Empereur de jade » (le comité qui fixe les principes de la politique IA) ?
• Qui sont les « ministres » (les responsables métier qui traduisent ces principes en consignes concrètes) ?
• Qui sont les « scribes » (les équipes qui observent ce que les systèmes font réellement et remontent les anomalies) ?

Sans réponses claires, les skills.md circulent comme des légendes urbaines. Chacun les interprète à sa manière, et la machine applique cette confusion.

Asimov : trois lois comme mythe, pas comme spec produit

Isaac Asimov a formulé ses célèbres Trois Lois de la robotique en 1942 :

1. Un robot ne peut blesser un humain ni, par inaction, permettre qu'un humain soit blessé.
2. Un robot doit obéir aux ordres des humains, sauf si ces ordres contredisent la première loi.
3. Un robot doit protéger sa propre existence, tant que cette protection ne contredit pas les deux premières lois.

Plus tard, il ajoute une Loi zéro : un robot ne peut nuire à l'humanité dans son ensemble.

Des analyses contemporaines rappellent que ces lois ne sont pas des propositions d'ingénierie, mais des dispositifs narratifs pour explorer des dilemmes éthiques.

Une étude parue dans l'Asian Journal of Multidisciplinary Research désigne les Trois Lois comme un moteur narratif plutôt qu'une solution technique : elles fabriquent des dilemmes de devoir, des paradoxes et des disputes d'interprétation sur ce que recouvrent des mots comme « préjudice » ou « obéissance » (source).

Le chercheur Lee McCauley va dans le même sens : les Trois Lois sont des dispositifs littéraires, pas des principes d'ingénierie, pas plus que le cerveau positronique d'Asimov n'est fondé sur une science réelle (source). Asimov lui-même montre que ces règles entraînent des paradoxes dès qu'on les applique à des situations complexes, dès sa première nouvelle sur le sujet en 1942 et dans la quasi-totalité des récits qui suivent.

Ce n'était pas un bug. C'était le point de l'exercice.

Le film I, Robot pousse la logique jusqu'au bout : l'IA centrale applique la Loi zéro à la lettre et en conclut qu'il faut restreindre la liberté humaine pour protéger l'humanité d'elle-même. Une règle bien écrite, appliquée trop littéralement, produit exactement l'inverse de ce qu'elle visait.

Pourtant, elles restent une référence importante dans les discussions sur l'éthique de l'IA : des articles académiques tentent de réinterpréter ces lois comme base pour des cadres d'IA responsables, d'autres les critiquent pour leur naïveté ou leur simplisme. Bref, personne ne s'écoute en fait.

La leçon pour nos skills.md et prompt libraries est double :

• D'une part, il est utile de se donner quelques principes simples, comme ceux d'Asimov, pour guider les usages : priorité à l'humain, commande consciente, survivabilité de l'organisation.
• D'autre part, il serait dangereux de croire que quelques règles écrites dans un fichier suffisent à garantir un comportement éthique.

Les études sur les incidents d'IA générative insistent sur la nécessité d'outils complémentaires :

• Des guides de réponse aux incidents documentent des playbooks spécifiques à l'hallucination publique : confinement de la source si le motif est systémique, évaluation de l'ampleur (qui a pu agir sur l'information erronée), correction des sources et des garde-fous concernés, puis communication proactive vers les utilisateurs affectés (source).
• Des cadres de sécurité IA recommandent des mécanismes de kill switch pour interrompre rapidement un système en cas de dérapage, avec des critères d'activation précis (fuite de données active, détournement d'objectif, impact à grande échelle) et une double autorisation (source).
• D'autres praticiens insistent sur le fait que ce confinement ne doit jamais nécessiter un redéploiement, sans quoi il arrive systématiquement trop tard (source).

Asimov nous offre des récits pour penser le problème. À nous de construire des pratiques concrètes, inspirées de ces récits mais adaptées à nos contextes.

Stories, skills.md et bien commun : ce que ces mythes disent aux techniciens

Si l'on met bout à bout Héphaïstos, le Golem, les Djinn et la bureaucratie céleste, on obtient une grille de lecture simple pour les techniciens convaincus que « tout est dans le modèle » :

1. Tu ne fabriques pas seulement un système, tu écris une histoire d'usage. Comme Héphaïstos, tu crées des assistants situés. Si tu ne sais pas qui ils servent, tu n'es pas en train de faire de l'IA, tu es en train de fabriquer des gadgets.
2. Tu n'écris pas juste des prompts, tu graves des lettres sur le front d'un Golem. Les skills.md sont des contes qu'une communauté se raconte pour faire agir une machine. Mal transmis, mal traduits, mal gouvernés, ils transforment l'allégorie protectrice en cauchemar opérationnel.
3. Tu n'ajoutes pas une brique, tu modifies une bureaucratie. Chaque agent IA est un fonctionnaire dans une chaîne de décision. Ignorer la gouvernance, c'est accepter que des décisions importantes soient prises par des scripts sans visage humain.

Les mythes rappellent enfin que la question centrale n'est pas « la techno va-t-elle nous détruire ? », mais :

Comment, en tant que collectif humain, décidons-nous de l'utiliser pour le bien commun ?

Les travaux récents sur l'IA et l'éthique soulignent que les métaphores religieuses et mythologiques (création, salut, apocalypse) peuvent renforcer des discours alarmistes ou utopiques, alors qu'il serait plus utile de revenir à des débats concrets sur les usages, les droits, les responsabilités.

En gros : qu'on arrête un peu de se cacher.

Héphaïstos, le Golem, les Djinn et la bureaucratie céleste sont de bons guides. Ils ne dictent pas des lois techniques. Ils invitent à regarder nos propres organisations, nos propres histoires, à prendre au sérieux le fait que ce sont les humains (pas les modèles) qui doivent décider du cadre.

On n'est pas dans Westworld, où les hôtes finissent par improviser hors de leur script. Dans nos systèmes de production, ils suivent encore le script à la lettre. C'est précisément le problème.

Nous ne sommes pas en train de subir une révélation cosmique. Nous rejouons, avec d'autres outils, des questions anciennes.

Bonne nouvelle : nous avons déjà des récits, des expériences, des communautés pour nous aider à faire mieux.