Autonomie des agents IA : vers plus de biais… ou plus de contrôle ?

Regardez la vidéo!

À mesure que les agents IA deviennent plus autonomes, est-ce qu’ils ne vont pas juste amplifier leurs biais et empirer les choses ?
J’ai fréquemment eu ce type de question récemment.
Ça semble raisonnable. Si un modèle a déjà des biais, et que maintenant on lui donne plus de pouvoir, de la mémoire, des outils, de la planification long terme, et la capacité d’agir, est-ce que ça ne fait pas juste passer le problème à l’échelle ?
Et je pense que beaucoup de gens qui lisent ce blogue se posent la même question, même s’ils ne le formulent pas comme ça.

Donc dans ce blogue, je veux faire trois choses très claires.
D’abord, expliquer ce que “biais” veut vraiment dire dans le contexte des LLMs, et pourquoi un biais n’est pas automatiquement mauvais.
Ensuite, expliquer ce qui change fondamentalement quand on passe d’un simple modèle de langage à un agent autonome.
Et enfin, montrer comment on peut contrôler les biais de manière réaliste à mesure que l’autonomie augmente, pas seulement au niveau du modèle, mais au niveau du système.

Comme ce serait mieux de passer par un exemple, et parce que j’ai passé beaucoup trop d’heures à recruter des ingénieurs IA et à faire du marketing récemment, imaginez que vous avez une entreprise qui construit un agent IA qui trie des CV, présélectionne des candidats, planifie des entretiens, et suggère même un classement final au manager de recrutement. Pas juste un chatbot qui répond à des questions. Un système qui agit.

Commençons au début.
Quand les gens disent « Les LLMs sont biaisés », qu’est-ce que ça veut vraiment dire ?

Le biais, dans un modèle, ça veut simplement dire qu’il représente des patterns présents dans ses données d’entraînement. C’est tout. Un modèle entraîné sur du texte à l’échelle d’internet va refléter des régularités statistiques présentes dans ces données. Si certaines professions sont plus souvent associées à certains genres dans les données, le modèle va apprendre cette corrélation. Pas parce qu’il veut discriminer. Pas parce qu’il a une intention. Mais parce que c’est statistiquement présent.

Un biais n’est pas automatiquement mauvais. En fait, sans biais au sens statistique, il n’y aurait aucun apprentissage possible. Apprendre, c’est détecter des patterns. Le vrai problème, ce n’est pas que le modèle a des biais. Le vrai problème, c’est ce qu’il y a dans les données, quels patterns sont renforcés, et lesquels on autorise le système à faire passer à l’action.

Donc avec notre exemple de recrutement, si les données historiques de recrutement reflètent des inégalités passées, le modèle peut apprendre ces patterns. Ce n’est pas un choix moral du modèle. C’est sa représentation.

Donc ici, dans notre cas, on voudrait probablement réentraîner un modèle pour mieux l’aligner avec nos besoins de recrutement et nos guidelines d’entreprise.
Mais qu’est-ce qui change exactement pendant le fine-tuning et l’alignement ?

Après qu’OpenAI crée son modèle, ce qu’on appelle la phase de pré-entraînement, les entreprises appliquent des techniques comme le reinforcement learning from human feedback, le reinforcement learning from AI feedback, le reward modeling, la preference optimization, et plus récemment le reinforcement learning with verifiable rewards. En gros, on apprend au modèle à agir comme on veut.

Ici, en termes simples, des humains ou des systèmes IA classent des outputs, et le modèle est optimisé pour produire des réponses qui s’alignent avec nos comportements préférés : utile, safe, équitable, moins toxique, plus neutre.

Ça réduit certains outputs nocifs. Ça peut rendre l’assistant de recrutement plus prudent sur les attributs sensibles. Ça peut lui apprendre à éviter un langage explicitement discriminatoire.

Mais voilà le point clé.
Réentraîner notre modèle comme ça reshape le comportement. Ça n’efface pas la structure statistique apprise pendant le pré-entraînement. La représentation sous-jacente du monde est toujours basée sur la distribution des données, qui vient majoritairement de toutes les données disponibles sur internet.
Quand on réentraîne, on pilote les outputs, on ne reconstruit pas tout le modèle interne de la réalité.

Maintenant, introduisons le vrai shift qu’on voulait construire ici pour nos besoins de recrutement : les agents.
Un LLM “simple” génère du texte. Vous lui donnez un prompt, il vous donne une réponse. Si la réponse est biaisée, c’est une phrase biaisée.

Un agent, c’est différent.
Un agent a un objectif. Il peut planifier sur plusieurs étapes. Il peut appeler des outils. Il peut stocker de la mémoire. Il peut filtrer l’information. Il peut prendre des actions en se basant sur des résultats intermédiaires. Tout ça de manière autonome.

Donc dans notre exemple de recrutement, au lieu de juste répondre « qu’est-ce qui fait un bon candidat », l’agent pourrait :
Lire un lot de CV.
Les classer.
Demander plus de données à un système RH interne.
Planifier des entretiens.
Mettre à jour une shortlist au fil du temps.
Ajuster ses critères en fonction de métriques de performance.

Là, on ne parle plus d’un paragraphe biaisé qu’on va de toute façon éditer. On parle d’une boucle de décision qui impacte la vie des gens.
Et c’est là que l’autonomie change l’impact du biais.

S’il y a un léger skew dans la manière dont l’agent évalue certains parcours, et qu’il filtre les candidats de manière répétée sur la base de ce skew, le système peut amplifier le pattern au fil du temps. Surtout s’il log ses propres décisions passées et les utilise comme feedback.

La planification, la mémoire, et l’utilisation d’outils créent des boucles de feedback. Et les boucles de feedback, c’est là où de petits effets peuvent se composer de manière exponentielle.

Il y a aussi un nouveau risque qui vient avec les agents : l’auto-renforcement.
Si l’agent de recrutement est évalué sur « time to hire » et « retention rate », il peut commencer à optimiser agressivement des signaux qui corrèlent avec ces métriques dans les données historiques. Si les données historiques sont biaisées, le processus d’optimisation peut se verrouiller sur ces mêmes patterns.

Ce n’est pas parce que le modèle est soudainement devenu mauvais. C’est parce que optimisation + autonomie + objectifs imparfaits peuvent amplifier un skew de distribution. Ce serait comme donner à vos employés un énorme bonus de salaire basé sur le nombre de candidats qu’on interview, indépendamment du fait qu’ils soient un bon fit. Je doute que vous augmentiez les taux de bons candidats comme ça !

Donc, est-ce qu’on doit paniquer ?
Non. Parce que voilà l’autre côté important.
Les agents ne sont pas juste des modèles. Ce sont des systèmes.
Et les systèmes peuvent être contraints.

Quand les gens parlent de mitigation des biais, ils se focalisent souvent uniquement sur le modèle. Plus gros modèle, meilleur alignement, plus de RLHF, plus de training constitutionnel. Tout ça est utile. Mais ce n’est qu’une couche.

Avec des agents, vous avez plusieurs points de contrôle. Plusieurs manières de mitiger les biais et de les limiter. Vous n’êtes pas entièrement dépendant d’une seule génération d’un paragraphe, en espérant qu’il soit bon. Vous pouvez piloter les modèles de langage et construire des workflows autour d’eux.

Vous contrôlez quelles données l’agent peut accéder.
Vous contrôlez quels outils il peut appeler.
Vous contrôlez quelles métriques il optimise.
Vous contrôlez quand il doit escalader vers un humain.
Vous contrôlez des étapes de validation avant que des actions soient exécutées.

Dans notre exemple d’agent de recrutement, vous pourriez :
Retirer complètement les attributs sensibles du pipeline d’évaluation.
Forcer des rubrics de scoring structurés avec des critères prédéfinis.
Insérer des fairness checks avant le classement final.
Logger chaque décision pour audit.
Exiger une validation humaine avant d’envoyer des emails de refus avec un raisonnement clair.
Faire tourner régulièrement des benchmarks d’évaluation de biais sur des ensembles de candidats synthétiques.

Là, la mitigation des biais devient une question de design de système, pas juste une question abstraite de training de modèle.

Et c’est là que les techniques d’alignement plus récentes que j’ai mentionnées comme RLAIF, RLVR, reinforcement fine-tuning, et les approches constitutionnelles entrent en jeu. Elles essaient de façonner le comportement à haut niveau. Par exemple, entraîner le modèle à préférer des réponses qui traitent les groupes démographiques de manière symétrique, ou à justifier son raisonnement sous des contraintes de fairness.

Ça aide. Mais ça reste du pilotage du comportement.
Si l’environnement et les objectifs sont mal conçus, l’agent peut quand même optimiser de manière non intentionnelle. Donc la leçon n’est pas « l’alignement règle tout ». La leçon, c’est que l’alignement est une couche dans une stack plus large.

À mesure que l’autonomie augmente, l’évaluation doit augmenter aussi.
Pour un chatbot statique, du red-teaming occasionnel peut suffire. Pour un agent de recrutement autonome, il faut du monitoring en continu. Il faut du scenario testing. Il faut simuler des edge cases. Il faut de l’observabilité : des logs de quels CV ont été filtrés, pourquoi, et quel raisonnement intermédiaire a été utilisé. Il faut pouvoir backtrack.

Plus l’agent est indépendant, plus vous avez besoin de structure explicite autour.

Voilà un principe simple que j’aime bien : faites évoluer les contraintes à mesure que vous faites évoluer l’autonomie.
Si votre système a peu d’autonomie, un prompt et un fine-tune de sécurité peuvent suffire.
Si votre système prend des décisions dans le monde réel sur la durée, il vous faut des garde-fous architecturaux à tous les niveaux. Pas juste un meilleur prompt.

Et juste parce qu’on ne peut pas être assez clair sur les biais… ce n’est pas un bug apparu quand on a inventé les LLMs. C’est une propriété des données et du monde. On est tous biaisés, et notre société aussi. Ce qui est à la fois bien et mal. L’objectif, c’est de maximiser les bons biais qu’on a et de minimiser les pires. Et comme les modèles reflètent les données, ils vont simplement refléter ça.

La bonne nouvelle avec les agents, c’est qu’ils agissent à l’intérieur de systèmes. Si on conçoit ces systèmes avec soin, on peut décider quels patterns sont acceptables, lesquels doivent être corrigés, et où la supervision humaine reste obligatoire. On ne dépend plus uniquement d’OpenAI ou de Google sur comment EUX ont décidé d’entraîner leur modèle, même si on les utilise.

À mesure que les agents deviennent plus autonomes, le biais cesse d’être juste un problème de modèle et devient un problème de gouvernance et d’architecture.
Et ça, c’est plutôt une bonne nouvelle.
Parce que l’architecture, c’est quelque chose qu’on peut designer.

Dans notre exemple de recrutement, l’objectif n’est pas d’enlever tous les biais. C’est impossible. L’objectif, c’est de définir clairement des critères acceptables, aligner le modèle dessus, contraindre l’environnement, monitorer les résultats, et intervenir quand il y a du drift.

Donc au lieu de demander : « Est-ce que les agents autonomes vont amplifier les biais ? », la meilleure question, c’est peut-être :
Est-ce qu’on a conçu le système autour d’eux avec suffisamment de soin ?

Dites-moi en commentaires quel type d’agent vous construisez, et si le biais est quelque chose auquel vous pensez activement dans votre architecture, et ce que vous faites concrètement à ce sujet ? Je suis sûr que ça pourrait aider les autres, et j’aimerais vraiment savoir !

Merci d’avoir lu jusqu’au bout!