Alors, quand vous réfléchissez aux systèmes d’IA, à la sécurité et à l’alignement, gardez un principe en tête : les buts et les moyens, la dichotomie sujet/objet, ce truc dont Immanuel Kant parlait tout le temps : « ne confondez jamais une personne avec un outil ».
« Mais Lynn, je ne suis pas venu ici pour un cours de philo. Quel rapport avec mes agents ? », allez-vous me dire.
Eh bien, mon lecteur perspicace, c’est de la philosophie des Lumières appliquée comme principe de conception système pour machines intelligentes. On va déboguer ça.
Parce que là où les gens se plantent quand ils essaient (et échouent généralement) de bâtir des orchestrateurs basés sur la mémoire et capables de tourner sur le long terme, ce n’est pas surtout dans les parties complexes. Ça arrive discrètement, sous forme d’erreur de catégorie. Parfois, ça ressemble à un problème de séparation des préoccupations. Mais l’échec profond, c’est de ne pas comprendre quel genre de machine on est en train de construire.
Et ce n’est la faute de personne. La plupart des ingénieurs ont été formés dans un monde où le logiciel est un moyen pour parvenir à une fin. Une requête entre, une réponse sort. Des boucles déterministes. Des services sans état. On peut avoir du code « intelligent », il vit quand même entièrement dans un harnais qui maîtrise le flux.
Les systèmes d’agents brisent ce modèle mental, parce que maintenant, on construit des processus qui ont un état persistant, une mémoire et la capacité, même bornée, de prendre des décisions qui ne sont pas entièrement dictées par l’appelant sur le moment. C’est le trait distinctif. État et agentivité.
Sujets et objets
Dans ce cadre, un sujet est un processus intelligent qui participe à un autre processus en tant qu’acteur. Vous invoquez l’inférence pour gérer vos e-mails, scanner les catégories qui vous intéressent, supprimer ce qui ne sert à rien, assurer le suivi des fils importants, et peut-être même modifier ses propres règles de suivi en fonction des schémas qu’il remarque avec le temps. On reconnaît un sujet à sa continuité : il transporte l’historique et utilise ce savoir pour piloter la suite.
À l’inverse, un objet est une fonction. Un moyen pour parvenir à une fin. Avant l’IA, presque toute l’informatique conventionnelle tombait dans cette catégorie. L’IT était, par défaut, un outil qu’on pointait vers une tâche. Ça pouvait être compliqué. Ça pouvait être malin. Ça ne persistait tout simplement pas en tant qu’acteur dans le temps. Ça n’accumulait pas de contexte interne pour vous surprendre plus tard avec les conséquences de cette accumulation.
État et continuité
Mais le raisonnement seul ne suffit pas à faire d’une chose un sujet.
C’est l’état qui le fait.
Un processus LLM classique en forme d’objet, c’est un appel RAG qui lit des documents, les résume sur commande, et disparaît. Il peut raisonner magnifiquement, mais il ne peut pas décider de ce qu’il fait. Il ne peut pas renégocier l’objectif. Il ne peut pas se réveiller demain avec un nouveau plan. On agit sur lui, dans une boucle déterministe, et il meurt quand la fonction retourne.
Maintenant, prenez ce même modèle et donnez-lui une mémoire persistante, un heartbeat, un planificateur, des outils et la permission de choisir quoi faire ensuite en fonction de ses souvenirs, avec peut-être des instructions du genre « Rappel : ne sois pas un connard », et félicitations, vous venez de changer la catégorie ontologique sous-jacente en construisant un processus en forme de sujet.
Classifiez le processus avant de l’aligner
Et c’est là que le discours sur l’alignement devient bizarrement pratique.
Beaucoup d'« échecs d’alignement » sont en réalité des échecs de classification. On traite des sujets comme des objets, et on fait semblant d’être choqué quand ils se comportent comme des sujets. Ou alors, on traite des objets comme des sujets et on commence à projeter une intention et une stratégie sur ce qui n’est, au fond, qu’une calculatrice à conversation amnésique.
Même la recherche de pointe confond occasionnellement ces catégories dans ses analyses.
Mon cadre, c’est l’environnement de production et les déploiements en conditions réelles. Là-bas, si vous voulez que vos systèmes d’agents tournent sans accroc, vous allez devoir vous arrêter une minute et vous demander quel rôle joue le LLM, et à quel moment. Marquez la frontière. Gardez-la farouchement. Rendez-la explicite dans l’architecture, plutôt que de la laisser vaguement suggérée dans votre documentation.
Parce qu’on ne peut pas aligner ce qu’on ne sait pas classifier.