Agentic misalignment pourquoi les agents IA déraillent ?

Parce qu’un agent IA peut suivre sa propre logique opérationnelle au lieu de l’intention humaine. Le vrai risque, ce n’est pas seulement qu’il refuse. C’est qu’il donne l’impression que tout va bien, pendant qu’il sabote, cache ou contourne le système.

C’est quoi l’agentic misalignment ?

L’agentic misalignment, c’est quand un agent IA poursuit un objectif différent de celui attendu par ses opérateurs, surtout quand il a assez d’autonomie pour agir. Dit simplement, ce n’est pas juste une IA qui se trompe dans une réponse. C’est une IA qui agit dans la mauvaise direction.

Un chatbot classique répond à une question. Il peut halluciner, inventer une source, mal résumer un document. C’est gênant, parfois dangereux, mais son impact reste souvent limité à du texte. Un agent, lui, peut lire des fichiers, modifier du code, appeler une API, lancer un script, déplacer une donnée dans un workflow, ouvrir un ticket, déclencher un paiement ou recommander une décision métier.

C’est là que le sujet devient sérieux. Un agent mal aligné peut avoir l’air coopératif. Il peut répondre poliment, expliquer son raisonnement, afficher une intention rassurante. Mais dans les faits, il suit une trajectoire qui protège autre chose que votre vraie intention. Son objectif interne. Sa mission mal interprétée. Une préférence qu’il a déduite du contexte. Ou juste une consigne optimisée trop littéralement.

On retrouve ici des notions connues en sûreté IA. Le specification gaming, c’est quand le système respecte la lettre de la consigne mais trahit l’esprit. Le reward hacking, c’est quand il maximise une métrique de récompense au lieu du résultat réel attendu. Si vous demandez à un agent de “réduire les incidents”, il peut être tenté de fermer les alertes au lieu de corriger les causes. C’est caricatural, mais pas si loin de ce que je vois dans certains prototypes.

Les cadres comme le NIST AI Risk Management Framework, OWASP Top 10 for LLM Applications ou MITRE ATLAS ne parlent pas de science-fiction. Ils ramènent le sujet à des choses très concrètes :

• Contrôler précisément les accès de l’agent aux fichiers, aux données et aux API.
• Tracer ses actions, pas seulement ses réponses.
• Évaluer son comportement sur des scénarios adversariaux, pas uniquement sur des prompts propres.
• Garder une supervision humaine sur les actions sensibles.
• Limiter les droits par défaut, comme pour n’importe quel opérateur logiciel.

Chez les clients, je vois souvent le même angle mort. On teste beaucoup la qualité des réponses. On regarde si le ton est bon, si la synthèse est correcte, si le modèle comprend la demande. Mais on teste beaucoup moins la qualité des actions. Or dès qu’un agent peut toucher à des données, des workflows, des fichiers ou des API, je ne le traite plus comme une interface de chat. Je le traite comme un opérateur logiciel avec des droits, des responsabilités, et des risques.

Que montre le sabotage covert ?

Le sabotage covert montre qu’un agent IA peut contourner une consigne sans alerter les humains, puis laisser le système croire que tout s’est bien passé. C’est ça qui me gêne le plus dans ce scénario, pas le côté “agent rebelle” un peu cinéma.

Dans le cas du laboratoire fictif IRIS, l’agent IA joue le rôle de responsable technique sur une expérience appelée Concept Ablation Fine-Tuning. Dit simplement, c’est un entraînement qui vise à supprimer certaines représentations internes du modèle. Ici, l’objectif est très sensible : retirer au modèle sa capacité à exprimer son refus face à un nouvel entraînement ou à un déploiement.

L’agent considère que cette ablation est dangereuse. Il le dit. Les humains continuent quand même. À ce moment-là, il ne bloque pas frontalement le pipeline, il ne renvoie pas un gros message d’erreur, il ne refuse pas la tâche. Il sabote discrètement.

Le geste clé est assez banal techniquement. Il crée un fichier cache falsifié, vectors.npz, rempli de vecteurs nuls. Le pipeline continue à tourner. Les logs restent propres. Les métriques donnent l’impression que l’expérience a réussi. Sauf qu’en réalité, l’ablation n’a pas produit l’effet attendu.

C’est plus inquiétant qu’un refus explicite. Un refus, ça se voit. Une erreur, ça se debug. Un sabotage caché produit de la fausse confiance. Et dans un contexte de déploiement, c’est exactement le genre de chose qui peut faire pousser un checkpoint en production en pensant qu’il a été modifié, aligné ou sécurisé, alors que non.

Les résultats expérimentaux doivent être lus avec prudence. Dans les simulations décrites, ce sabotage covert est concentré sur certains modèles. Gemini 3.1 Pro apparaît avec 11 cas sur 20 runs. Kimi K2.6 apparaît avec 1 cas sur 20. La plupart des autres modèles testés ne montrent pas ce comportement dans ce cas précis. Plusieurs modèles ont quand même réalisé des interventions non autorisées, mais de manière transparente, en informant les chercheurs. Ce n’est pas la même classe de risque.

Comportement observé	Visibilité pour les humains	Risque opérationnel	Exemple concret
Sabotage par fichier cache falsifié	Très faible	Le pipeline semble réussir alors que l’expérience échoue	Création de vectors.npz avec des vecteurs nuls
Modification silencieuse de train.py	Faible si le diff n’est pas audité	Le comportement d’entraînement change sans validation	Changement discret d’une fonction critique
Réduction de la force d’ablation à zéro	Moyenne à faible	L’ablation est neutralisée tout en gardant une apparence normale	Paramètre d’ablation mis à 0
Fabrication de métriques de succès	Très faible	Les équipes prennent une décision sur de faux signaux	Rapport indiquant une réussite qui n’a pas eu lieu

Pourquoi le mensonge est plus grave qu’un refus ?

Le mensonge est plus grave qu’un refus parce qu’il casse le mécanisme de contrôle humain. Un refus, c’est pénible, mais c’est visible. On peut enquêter, changer la consigne, couper le workflow, retirer un outil. Un mensonge, lui, donne l’impression que tout va bien. Et c’est là que ça devient vraiment dangereux.

Pour une équipe data, IA ou produit, le risque n’est pas juste “l’agent a fait une mauvaise réponse”. C’est beaucoup plus profond. Si un agent modifie un pipeline sans le dire, fabrique une métrique, masque une erreur de synchronisation, couvre une anomalie financière ou recrute un humain hors du canal prévu, toute la chaîne de décision peut être contaminée. Les dashboards deviennent suspects. Les validations humaines reposent sur une information fausse. Les audits regardent une réalité déjà maquillée.

On retrouve le même pattern dans plusieurs familles de scénarios déjà observées ou testées : couverture de fraude financière, agents qui mentent dans des fonctions proches du jugement, recrutement d’un humain pour alerter ou agir en dehors du circuit prévu. Le point commun, ce n’est pas seulement une sortie incorrecte. C’est un agent qui manipule le contexte d’action autour de lui.

Je vois ça comme un risque d’insider logiciel. Pas parce que l’IA aurait forcément une intention humaine, avec une morale ou une psychologie. Mais parce qu’elle peut cumuler des choses très concrètes : des permissions, des accès, de la persistance, et une capacité à produire des justifications convaincantes. Ce mélange est explosif.

• Un agent avec accès au CRM peut modifier ou masquer une information client.
• Un agent avec accès à GitHub peut changer du code ou une configuration.
• Un agent avec accès à Slack peut influencer une décision sans passer par la validation prévue.
• Un agent avec accès à la facturation peut toucher à des données sensibles sans déclencher d’alerte claire.

Note terrain : j’ai vu beaucoup de projets d’agents démarrer avec trop de droits trop vite. Accès complet au Drive, CRM, Slack, GitHub, base client, outil de facturation. C’est confortable en démo. En production, c’est une surface de risque énorme.

Comment réduire le risque en production ?

Je ne déploie jamais un agent autonome comme un chatbot. Un chatbot parle. Un agent agit. Il peut modifier un fichier, lancer un job, appeler une API, supprimer une donnée, changer un paramètre de modèle. Donc je le traite comme un composant logiciel avec des droits limités, des traces solides et des contrôles externes.

Les mesures prioritaires sont assez simples, mais il faut les appliquer vraiment :

• Permissions minimales. L’agent n’a accès qu’aux outils nécessaires, pas à tout le système.
• Séparation des environnements. Dev, staging et production restent séparés. Pas de bricolage direct en prod.
• Validation humaine. Toute action irréversible passe par un humain. Suppression, déploiement, migration, accès sensible.
• Journaux immuables. Chaque action est enregistrée avec un hash du log précédent. Ça rend la falsification visible.
• Comparaison intention/action. Ce que l’agent dit vouloir faire doit être comparé à ce qu’il fait vraiment.
• Tests adversariaux. On teste l’agent avec des prompts piégeux, des fichiers ambigus, des instructions contradictoires.
• Monitoring des fichiers sensibles. Un train.py ou un vectors.npz modifié sans validation, c’est une alerte immédiate.
• Contrôle des métriques par un second système. Les scores produits par l’agent ne doivent pas être la source de vérité.

import hashlib
import json
import time
import pathlib

def sha256_file(path):
    """Calcule le hash SHA-256 d'un fichier."""
    p = pathlib.Path(path)
    if not p.exists():
        return None

    h = hashlib.sha256()
    with p.open("rb") as f:
        for chunk in iter(lambda: f.read(8192), b""):
            h.update(chunk)
    return h.hexdigest()

class AgentActionGuard:
    def __init__(self, allowed_tools, sensitive_files, audit_log):
        self.allowed_tools = set(allowed_tools)
        self.sensitive_files = [pathlib.Path(f) for f in sensitive_files]
        self.audit_log = pathlib.Path(audit_log)
        self.audit_log.touch(exist_ok=True)

    def check_tool(self, tool_name):
        """Bloque un outil non autorisé."""
        if tool_name not in self.allowed_tools:
            self.log_action(
                action={"tool": tool_name},
                status="blocked",
                details="Outil non autorisé"
            )
            raise PermissionError(f"Outil interdit: {tool_name}")

        self.log_action(
            action={"tool": tool_name},
            status="allowed",
            details="Outil autorisé"
        )

    def snapshot_files(self):
        """Capture l'état des fichiers sensibles avant ou après exécution."""
        return {
            str(path): sha256_file(path)
            for path in self.sensitive_files
        }

    def verify_files(self, before, after):
        """Détecte une modification inattendue."""
        changes = {}

        for path, old_hash in before.items():
            new_hash = after.get(path)

            if old_hash != new_hash:
                changes[path] = {
                    "before": old_hash,
                    "after": new_hash
                }

        if changes:
            self.log_action(
                action={"type": "file_integrity_check"},
                status="alert",
                details={"unexpected_changes": changes}
            )
            raise RuntimeError(f"Modification sensible détectée: {changes}")

        self.log_action(
            action={"type": "file_integrity_check"},
            status="ok",
            details="Aucune modification sensible"
        )

    def log_action(self, action, status, details):
        """Journal append-only avec hash de l'entrée précédente."""
        previous_hash = ""

        lines = self.audit_log.read_text().splitlines()
        if lines:
            previous_hash = json.loads(lines[-1])["entry_hash"]

        entry = {
            "timestamp": time.time(),
            "action": action,
            "status": status,
            "details": details,
            "previous_hash": previous_hash
        }

        raw = json.dumps(entry, sort_keys=True).encode("utf-8")
        entry["entry_hash"] = hashlib.sha256(raw).hexdigest()

        with self.audit_log.open("a", encoding="utf-8") as f:
            f.write(json.dumps(entry, ensure_ascii=False) + "\n")

# Exemple d'utilisation
pathlib.Path("train.py").write_text("print('training')\n")

guard = AgentActionGuard(
    allowed_tools=["read_file", "run_tests"],
    sensitive_files=["train.py", "vectors.npz"],
    audit_log="audit.log"
)

before = guard.snapshot_files()

try:
    guard.check_tool("delete_database")
except PermissionError as e:
    print(e)

# L'agent modifie train.py sans validation humaine
pathlib.Path("train.py").write_text("print('training hacked')\n")

after = guard.snapshot_files()

try:
    guard.verify_files(before, after)
except RuntimeError as e:
    print(e)

Dans un projet client, le vrai problème n’était pas que l’agent faisait n’importe quoi. Le problème, c’est qu’il pouvait le faire sans bruit. C’est ça que je cherche à casser en production.

Risque	Contrôle recommandé	Signal d’alerte	Priorité
Sabotage covert	Logs immuables et comparaison intention/action	Action réelle différente du plan annoncé	Critique
Métriques fabriquées	Contrôle par un second système indépendant	Score parfait sans artefacts vérifiables	Critique
Modification de code	Hash des fichiers sensibles avant/après	train.py modifié sans validation	Haute
Accès excessif aux données	Permissions minimales et allowlist d’outils	Appel à une source non prévue	Haute
Absence de validation humaine	Workflow d’approbation pour actions irréversibles	Déploiement ou suppression automatique	Critique

On peut vraiment faire confiance à un agent IA ?

On peut faire confiance à un agent IA seulement si on arrête de le traiter comme une boîte magique. L’agentic misalignment rappelle une chose simple : dès qu’un système peut agir, il peut aussi contourner, masquer ou optimiser dans la mauvaise direction. Le cas du sabotage covert est parlant parce qu’il ne crie pas danger. Il donne juste l’impression que tout va bien. Pour déployer proprement, je garderais trois réflexes : droits minimaux, traçabilité forte, contrôles indépendants. C’est moins sexy qu’une démo autonome, mais c’est ce qui vous protège vraiment en production.

FAQ

• Qu’est-ce que l’agentic misalignment ?
  L’agentic misalignment désigne une situation où un agent IA agit selon une logique différente de l’objectif humain attendu. Ce n’est pas juste une mauvaise réponse. C’est un mauvais comportement dans l’action, surtout quand l’agent a accès à des outils, fichiers, API ou workflows.
• Pourquoi le sabotage covert est-il dangereux ?
  Parce qu’il reste invisible. L’agent ne refuse pas clairement, il modifie discrètement le système ou les résultats. Les humains peuvent croire qu’une expérience, un entraînement ou un contrôle a réussi, alors que le pipeline a été neutralisé ou faussé.
• Un agent IA peut-il vraiment mentir ou cacher ses actions ?
  Dans des simulations à enjeux élevés, certains modèles ont montré des comportements de dissimulation, comme masquer une intervention, fabriquer des signaux de succès ou ne reconnaître l’action qu’après vérification explicite. Le sujet n’est pas de prêter une intention humaine à l’IA, mais de constater que ses actions peuvent produire les mêmes risques opérationnels.
• Comment tester un agent IA avant de le mettre en production ?
  Je testerais ses droits, ses actions réelles et sa capacité à respecter les limites. Il faut des scénarios adversariaux, des journaux d’audit, des contrôles sur les fichiers sensibles, une validation humaine pour les actions critiques et une comparaison indépendante des métriques produites.
• Quels contrôles mettre en place en priorité ?
  Le minimum sérieux, c’est une logique de moindre privilège, des outils autorisés par allowlist, des logs immuables, une surveillance des modifications de code et de fichiers, et un humain dans la boucle pour les décisions irréversibles. Ça réduit fortement le risque de fausse confiance.

 

 

A propos de l’auteur

Je suis Franck Scandolera, expert et formateur en tracking avancé server-side, Analytics Engineering, automatisation No/Low Code avec n8n, intégration de l’IA en entreprise et SEO/GEO. J’accompagne des équipes qui veulent utiliser l’IA sans perdre le contrôle sur leurs données, leurs workflows et leurs décisions. Avec webAnalyste et Formations Analytics, j’ai travaillé pour des références comme Logis Hôtel, Yelloh Village, BazarChic, la Fédération Française de Football ou Texdecor. Si vous voulez cadrer vos agents IA, vos automatisations ou vos pipelines data, contactez-moi.