Ce que « concevoir l'usage » veut dire

La question est légitime : tant qu'on ne descend pas dans la mécanique, cette idée reste abstraite. Je voudrais donc ici entrer dans le détail et poser quelques concepts que je tire d'un développement réel : Opaly, le logiciel que nous avions construit chez SoScience pour aider au montage de projets de recherche européens. Chez SoScience, nous avions besoin de proposer une expérience numérique qui amène les gens non seulement à écrire une grant européenne (le travail qu'ils voulaient réaliser) mais aussi à intégrer l'impact dans cette grant (les attendus de la Commission et la mission de SoScience). La manière dont nous avons répondu à cela passe par deux concepts de conception que j'appellerai ici la logique du monde et les portes informationnelles. Je pense que ces concepts peuvent aider d'autres projets à fort impact social, portés par des valeurs marquées ou une mission forte, à intégrer l'IA générative avec des garde-fous sur leurs valeurs.

Une notion clé de ce type de conception est de réussir à décrire la logique qui va sous-tendre les réponses. Prenons un exemple qui me semble illustrer cela parfaitement : les LLM appliqués aux jeux vidéo.

Récemment lors d'une conférence à l'Académie des technologies, David Louapre présentait les travaux d'Ubisoft sur les personnages non joueurs (PNJ) que l'on croise dans tous les jeux et qui récitent des dialogues écrits à l'avance. On imagine sans mal à quel point l'intégration de LLM dans la mécanique du jeu peut rendre l'expérience beaucoup plus réaliste. L'ambition est simple à décrire : pouvoir leur parler en langage naturel, et qu'ils agissent en conséquence. Pourtant, on voit très vite les difficultés de l'implémentation. Vous demandez à un personnage de venir vérifier un coin de la carte avec vous, il vous répond « Oui, j'arrive », et il ne bouge pas. Le problème ici est que le modèle de langage peut répondre de façon plausible, mais qu'il ne sait pas ce que le personnage est capable de faire, ce qu'il est censé savoir, ni si ce coin de la carte est même un lieu accessible. Il lui manque une certaine « logique du monde ».

Une logique du monde

En novembre 2025, le studio Ubisoft a dévoilé Teammates, un prototype de recherche présenté comme son premier projet d'IA générative réellement jouable[2]. Le joueur doit infiltrer une base ennemie, accompagné de deux coéquipiers, Sofia et Pablo, à qui il donne ses ordres à la voix, en langage naturel. Il peut par exemple leur demander de couvrir sa progression, ouvrir un portail quand il arrive, distraire un garde. Le modèle de langage permet ici une interaction qui était jusque-là hors de portée : parler à un PNJ comme on parlerait à un partenaire humain. Les PNJ comprennent l'intention et le contexte, et y répondent en agissant comme demandé.

Qu'est-ce qui a été nécessaire pour que Pablo bouge comme prévu ? L'architecture rendue publique donne une idée de l'ampleur du travail : un moteur de jeu, un modèle de langage au cœur du système conversationnel, une couche logicielle développée en interne, et plus d'une vingtaine de modèles spécialisés pour la reconnaissance vocale, la synthèse vocale ou la détection d'émotion. Le modèle de langage n'est qu'une pièce de l'ensemble. L'élément décisif, qui va rendre l'expérience crédible, est la connexion entre le modèle de langage et les mécaniques du jeu. Il s'agit d'une description formalisée du monde et de ce qu'il est possible de faire dans le jeu.

Au moment où le joueur parle, le système n'envoie pas seulement son ordre au modèle. Il lui envoie aussi une description du monde : les lieux qui existent, les actions disponibles, ce que chaque personnage peut faire ou non, la situation actuelle. Cette description a été produite par les équipes qui sont à l'origine du jeu : elles ont formalisé ses lieux, ses règles, les capacités de chaque personnage, ce qu'un équipier peut accepter et ce qu'il doit refuser. Ubisoft décrit d'ailleurs son propre rôle en ces termes : donner un cadre à l'IA.

C'est ce que j'appellerai ici une logique du monde : un système logique et explicite de ce qui existe (les objets), de ce qui est possible et de qui peut faire quoi (propre à chaque objet), et des relations qui existent entre ces objets. Le point important est qu'un modèle de langage, aussi puissant soit-il, ne compense pas une logique du monde absente. Si la colline n'est pas un lieu accessible, aucune formulation ne permettra au personnage de l'atteindre. Le modèle peut répondre à l'intention du joueur mais c'est la logique du monde qui détermine si l'action demandée existe. Ce système logique, le modèle ne peut pas le deviner : il ne figure dans aucune donnée d'entraînement.

Décrire une logique du monde est un travail que nous avons fait pour Opaly. Nous avions développé un logiciel pour aider les scientifiques et leurs partenaires à monter des projets de recherche européens avec un volet impact particulièrement solide. Techniquement, il reposait sur des modèles Mistral, intégrés via n8n, entourés de code parfaitement classique et d'une interface qui portait une grande partie de l'intelligence du système, comme on va le voir.

Les dossiers de candidature européens font plusieurs dizaines de pages et obéissent à une structure exigeante. Une grant a sa logique interne, faite d'objets et de relations entre eux. Des problèmes auxquels des groupes cibles sont liés. Des tâches, dont certaines produisent des livrables et d'autres produisent des outcomes. Et surtout un modèle d'impact, c'est-à-dire une chaîne logique qui relie ce que produit le projet à ce qu'il change pour la société. Les résultats ne deviennent des outcomes qu'en passant par des actions de dissémination, exploitation et communication (DEC), avant de se traduire, plus loin encore, en impacts. Chaque objet a sa place dans ce système logique et doit être traité en fonction de cela : savoir qu'une action DEC peut produire un outcome uniquement à partir d'un résultat, c'est ce qui permet de la placer au bon endroit du dossier, exactement comme savoir qu'un personnage peut courir permet de lui donner cet ordre. La description de cette logique est nécessaire pour que le texte soit bon, et pas juste plausible.

Formaliser tout cela, expliciter ce qui fait un bon dossier, ce qui relie une activité à un impact, ce qu'un évaluateur cherche et ce qu'il sanctionne, a été un gros morceau de la solution. Cette connaissance a constitué la matière première du logiciel, bien avant toute ligne de code liée à l'IA.

Jusqu'ici, les deux cas sont parallèles : pour pouvoir prendre des décisions pertinentes, la logique du monde doit être explicite. Cependant, un jeu vidéo dispose d'un avantage considérable : son monde est fini et connu d'avance. Il peut être entièrement décrit. L'existence de la colline, les capacités de Pablo, les objets de l'inventaire, tout est parfaitement connu et peut être transmis au modèle. Ce n'est pas le cas de la plupart des cas d'usage de l'IA générative. Pour Opaly, nous avions la structure logique, mais le contenu des cases dépendait de chaque projet. Chaque nouveau projet a son problème, ses groupes cibles, sa géographie, son consortium, et ces informations ne peuvent venir que de l'utilisateur. Alors comment faire quand le monde est le monde réel et que la quantité d'information est infinie ?

C'est là que les problèmes commencent.

Les portes informationnelles

La difficulté qui structure tout le reste est la suivante : l'utilisateur ne sait pas ce qu'il doit fournir. Il arrive avec son idée, parfois mûrie pendant des années sur une expertise très pointue, et il n'est pas en mesure de savoir ce qui est important pour un tel dossier. Il arrive rarement avec ses groupes cibles définis, sa zone d'intervention délimitée, sa chaîne d'impact articulée.

Face à ce manque, un système génératif a une pente naturelle : combler les trous avec du plausible. C'est ce que produit un modèle brut à qui l'on demande d'écrire une grant à partir d'une idée. Il invente des groupes cibles vraisemblables, une zone géographique, des impacts génériques. Le texte est crédible, mais c'est la même soupe servie à tout le monde, et un évaluateur qui lit des centaines de dossiers la reconnaît immédiatement.

Pour éviter cette production de contenu médiocre, nous avions fait un autre choix technique: ne pas répondre tant qu'on ne sait pas. C'est le deuxième concept que je voudrais poser, celui d'une porte informationnelle : définir formellement quelles informations sont nécessaires, en quelle quantité et de quelle qualité, avant d'autoriser le système à produire quoi que ce soit. Tant que la porte n'est pas franchie, le système ne génère pas. Il demande, ou il signale ce qui lui manque.

Voici comment cela s'articulait concrètement dans Opaly, et ce que chaque choix engageait.

D'abord, les portes elles-mêmes. Chaque étape de production était conditionnée par des go/no-go : l'agent chargé d'une partie du dossier ne s'activait que si les informations dont il avait besoin existaient. Chez nous, cette vérification passait par du code classique adossé à des bases de données. Le logiciel savait où chaque information était rangée, il pouvait donc établir de manière fiable si elle était présente ou non, sans aucune IA dans ce mécanisme. On pourrait imaginer une autre approche, où l'on demanderait au modèle lui-même de juger s'il en sait assez pour répondre. C'est une piste ouverte, mais elle revient à faire confiance à un modèle pour mesurer sa propre ignorance, un exercice sur lequel les modèles actuels restent peu fiables. Nous avions préféré une vérification qui ne dépende pas de ce jugement.

Ensuite, les agents spécialisés. Une grant n'est pas un texte homogène : faire une introduction, décrire un état de l'art, formuler des impacts, présenter un consortium sont des exercices différents, avec des règles et des pièges différents. Plutôt qu'un système unique à qui l'on demanderait tout, Opaly confiait chaque partie à un agent dédié, avec ses consignes propres et ses propres exemples de référence.

Puis l'orchestration. Des agents spécialisés produisent des morceaux, qu'il faut assembler et dont il faut vérifier la cohérence : les impacts annoncés dans une section doivent correspondre aux activités décrites dans une autre. Cette couche d'assemblage relève elle aussi de la logique et non de la génération, puisque c'est le modèle logique de la grant qui dit ce qui doit être cohérent avec quoi.

Enfin, et c'est peut-être la partie la plus visible pour l'utilisateur, le refus devait se voir. Quand une porte n'était pas franchie, Opaly ne produisait pas un texte dégradé en silence : l'interface le montrait. Des feux rouge, orange et vert indiquaient ce qu'il restait à améliorer pour un meilleur travail génératif ; des boutons restaient non cliquables tant qu'il manquait des éléments, avec l'indication de ce qu'il fallait aller compléter. Le logiciel disait, en substance : voilà ce que je ne sais pas encore de votre projet, et je ne l'inventerai pas à votre place.

Récemment, Claude utilisait aussi un principe similaire : il s'est mis à proposer des questions à choix multiples lorsqu'il avait besoin de précisions ou d'informations complémentaires. C'est une version dialoguée de la porte informationnelle. La forme importe moins que le principe : le système n'agit pas tant qu'il ne sait pas, et il dit ce qu'il attend.

Ce que les portes encodent

Pourquoi construire tout cela, plutôt que de brancher un modèle et de le laisser écrire ?

La première réponse est la qualité de la réponse. Il est impossible d'écrire une bonne grant sans passer par les éléments logiques du projet, son problème précis, ses groupes cibles réels, sa chaîne d'impact articulée. Un dossier construit sans eux produit du texte, pas un projet réel. Les portes informationnelles ne sont donc pas décoratives : elles sont la condition pour que ce qui sort du système soit la version la plus robuste d'un projet bien précis, et non un projet moyen statistiquement plausible.

Mais la qualité n'explique pas tous nos choix, et c'est le point sur lequel je voudrais insister, parce que les discussions techniques sur l'IA passent le plus souvent à côté : une architecture encode aussi des convictions.

Deux exemples, tirés directement des valeurs qui ont porté SoScience.

La première : le scientifique est le meilleur pour savoir ce qu'il veut faire. C'est une position sur qui détient l'intention dans un projet de recherche. Traduite en architecture, elle donne ceci : quand une information manque, le système la demande à l'utilisateur, il ne l'invente pas. Un logiciel qui comble les trous à la place du scientifique a implicitement décidé que son intention était sans importance. Le nôtre était construit sur la position inverse : c'est votre projet, c'est à vous de dire ce que vous voulez faire, l'outil vous assiste et ne se substitue pas à vous.

La seconde : l'impact doit être réel, pas seulement conforme aux attentes. On peut décrocher une grant européenne en répondant exactement à ce que demande la Commission, sans plus. Nous avions pourtant des portes qui allaient au-delà de ces attentes, par exemple sur la diversité des partenaires du consortium. Rien n'obligeait à la vérifier, et on peut écrire un dossier gagnant sans elle. Mais quinze ans de terrain nous avaient appris qu'un projet dont les partenaires sont divers, notamment au-delà du monde académique, produit un impact plus fort. Cette porte ne servait pas la conformité, elle servait ce que nous pensions être un bon projet de recherche à impact.

C'est sans doute la définition la plus concrète que je puisse donner de la conception de l'usage : des choix techniques qui permettent d'encoder ce qui compte (des convictions, des valeurs, un niveau de qualité nécessaire...).

Ce qui précède dépasse évidemment les grants européennes et les jeux vidéo. Tout métier a sa logique du monde : ce qui existe, ce qui est possible, ce qu'il est nécessaire de connaître avant d'agir. C'est elle qui fait la différence entre une réponse de surface et une réponse solide, et c'est son absence qui oblige à faire des prompts interminables où l'on tente de réécrire, à chaque requête, une logique métier qui aurait mérité d'être formalisée une fois pour toutes. Concevoir un outil qui intègre de l'IA générative sans avoir posé une logique du monde et une quantité d'information nécessaire, c'est prendre le risque d'obtenir un résultat moyen et où les valeurs ne sont pas maîtrisées.

Notre logiciel a aussi plu à des institutions publiques pour l'alignement entre nos choix techniques et les valeurs qu'ils portaient. Ce type de choix a ses limites, et d'autres équipes font en ce moment d'autres choix, avec d'autres logiques et d'autres convictions. Je serais sincèrement curieuse de lire leur version de cet article : comment elles décident de ce que leur système exige avant de répondre, et pourquoi.

[1] Mélanie Marcel, « Des modèles souverains, des usages importés ? », août 2026 : https://melaniemarcel.com/essays/sovereign-models-imported-uses/fr/

[2] Ubisoft, « Ubisoft Reveals Teammates – An AI Experiment to Change the Game », novembre 2025 : https://news.ubisoft.com/en-us/article/3mWlITIuWuu0MoVuR6o8ps/ubisoft-reveals-teammates-an-ai-experiment-to-change-the-game