Toutes les éditions · Academia Edition

Your Community, Your AI — CC BY 4.0

Un système de production sous la loupe — Ce qui est déployé aujourd’hui

Portée et objectif

Cet article dresse un inventaire de ce qui est actuellement déployé sur la plateforme Village, de ce qui est encore en cours de développement, et des domaines où l’écart entre l’intention architecturale et la réalité opérationnelle est le plus important. Il est rédigé en partant du principe que le public de chercheurs attend une approche franche concernant la maturité du système : ce qui fonctionne, ce qui ne fonctionne pas encore et ce qui n’a pas été testé. (Les termes utilisés tout au long de la série sont définis dans le glossaire.)

La plateforme est en production depuis 2025. Elle dessert un petit nombre de communautés. La base de déploiement est insuffisante pour étayer des affirmations statistiques quant à son efficacité, et le présent article ne formule pas de telles affirmations.

Capacités opérationnelles

Les capacités suivantes sont déployées et opérationnelles à la date de rédaction :

Réponse aux requêtes ancrée dans le contenu

Le sous-système d’IA répond aux requêtes des membres en extrayant et en synthétisant des informations issues du corpus documentaire propre à la communauté — annonces, récits partagés, comptes rendus d’événements, documents organisationnels. Les réponses sont vérifiées par rapport au corpus par la couche Guardian Agent avant d’être transmises.

Ce qui fonctionne : pour les requêtes correspondant directement à du contenu documenté (« Quand a lieu la prochaine réunion ? », « Qu’a-t-on décidé concernant le fonds de construction ? »), le système produit des réponses fondées et vérifiables. La couche d’ancrage sémantique identifie correctement les documents sources pertinents dans la majorité des cas observés.

Ce qui ne fonctionne pas de manière fiable : pour les requêtes nécessitant des déductions à partir de plusieurs documents, ou portant sur des sujets peu abordés dans les archives de la communauté, la qualité des résultats se dégrade. Le système peut produire des réponses plausibles mais non fondées, signalées par des indicateurs de faible confiance auxquels tous les utilisateurs ne prêtent pas attention.

Ce qui n’a pas été testé : Les performances du système face à des requêtes adversaires — c’est-à-dire des tentatives délibérées visant à obtenir des résultats non étayés ou inappropriés — n’ont pas été évaluées de manière systématique. Des tests informels suggèrent que la couche d’application des limites détecte de nombreux schémas adversaires, mais aucune évaluation formelle de type « red team » n’a été menée.

Aide à la rédaction

L’IA aide à la rédaction des communications de la communauté — annonces, bulletins, correspondance. Les brouillons sont générés à partir des modèles de contenu existants de la communauté et sont soumis à l’examen d’un modérateur avant leur diffusion.

Limite : La qualité de rédaction du système est directement limitée par le volume et la qualité du contenu existant de la communauté. Pour les communautés disposant de peu d’archives, les brouillons ont tendance à revenir aux valeurs par défaut de distribution du modèle de base — ce qui correspond précisément au mode de défaillance que l’architecture est censée empêcher. La mesure d’atténuation (vérification par un modérateur) est efficace mais introduit un goulot d’étranglement humain.

Résumé de documents

Les longs documents et les recueils d’annonces peuvent être résumés. Cette fonctionnalité est simple et bien prise en charge par la technologie LLM actuelle.

Prise en charge multilingue

La plateforme prend en charge cinq langues : l’anglais, l’allemand, le français, le néerlandais et le te reo māori. La traduction est assurée par un service de traduction dédié (DeepL), et non par le LLM. Ce choix architectural — séparer la traduction de la génération — évite le mode de défaillance connu des traductions générées par les LLM, qui altèrent le sens tout en conservant la fluidité.

Triage des retours d’expérience

Les retours d’expérience des membres sont automatiquement classés, examinés dans la mesure du possible, puis acheminés vers les intervenants humains appropriés. Le système de triage utilise une classification par cause première pour identifier des schémas récurrents dans les retours d’expérience et signaler les problèmes systémiques.

Ce sous-système constitue l’exemple le plus clair de action agentique délimitée déployé sur la plateforme. Pour les cas courants et à faible enjeu, l’exécuteur ne se contente pas de classer mais résout le problème — en recherchant la réponse correcte dans le corpus et en mettant à jour la base de connaissances de manière autonome — tandis qu’une tendance détectée de défaillances connexes est transmise à un intervenant humain pour décision plutôt que traitée automatiquement. L’agent intervient lorsque l’opération est réversible et confinée aux limites de la communauté, et s’abstient lorsque ce n’est pas le cas. Il s’agit d’une conception délibérément restreinte de l’agentivité : elle incarne le principe de respect des limites (article 3) plutôt que l’autonomie illimitée caractéristique des agents commerciaux utilisés dans les navigateurs ou sur les ordinateurs.

Ce qui fonctionne : les retours d’expérience courants (demandes de fonctionnalités, questions de navigation, requêtes sur le contenu) sont correctement classés et traités dans la majorité des cas observés.

Ce qui ne fonctionne pas de manière fiable : Les retours d’expérience impliquant un contexte interpersonnel nuancé ou des références culturelles spécifiques à une communauté sont parfois mal classés. Le taux d’erreur du système pour les retours d’expérience sensibles sur le plan culturel n’a pas été formellement mesuré.

Le système de vocabulaire : le cadrage linguistique comme gouvernance

La plateforme met en œuvre un système de vocabulaire qui adapte toute la terminologie destinée aux utilisateurs au type de communauté. Un groupe de recherche voit « groupe de recherche » et « collaborateurs » ; une association de protection de la nature voit « membres » et « projets de conservation » ; une paroisse voit « paroissiens » et « gestion du conseil paroissial ».

Il ne s’agit pas d’une simple fonctionnalité esthétique. Le vocabulaire façonne le cadre de référence de l’IA pour l’interprétation des requêtes et la génération de réponses. Lorsque le système traite une requête dans le contexte d’un vocabulaire utilisant le terme « collaborateurs » plutôt que « utilisateurs », la distribution des réponses s’oriente vers un cadrage collaboratif et communautaire.

Intérêt de recherche : Le système de vocabulaire offre une expérience naturelle permettant d’observer comment le cadrage linguistique affecte les distributions des résultats générés par l’IA. Une comparaison systématique des résultats entre différentes configurations de vocabulaire — en conservant la requête constante tout en faisant varier le vocabulaire — permettrait de tester l’hypothèse selon laquelle des changements terminologiques de surface se répercutent sur des différences de cadrage substantielles dans les résultats. Cette expérience n’a pas encore été menée, mais elle est réalisable avec l’infrastructure existante.

Limite : Le système de vocabulaire opère au niveau de la terminologie, et non au niveau du cadre conceptuel. Remplacer « utilisateurs » par « collaborateurs » modifie la surface de la distribution, mais ne modifie pas nécessairement les hypothèses structurelles plus profondes intégrées au modèle de base. L’ampleur de l’influence du système de vocabulaire sur la qualité des résultats reste une question ouverte.

Performances de Guardian Agent

Les quatre couches de Guardian Agent sont déployées et opérationnelles. Voici leurs caractéristiques de performance, dans la mesure où elles sont actuellement observables :

Ancrage sémantique (Guardian 1) : Identifie correctement les documents sources pertinents pour les requêtes simples. Les performances se dégradent pour les inférences portant sur plusieurs documents et pour les requêtes nécessitant des connaissances implicites non directement énoncées dans les documents sources.

Décomposition des affirmations (Guardian 2) : Isole avec succès les affirmations individuelles dans des réponses structurées. Moins efficace pour les réponses qui intègrent des affirmations dans des structures syntaxiques complexes ou qui expriment des affirmations de manière implicite par le biais d’un cadrage plutôt que par une déclaration explicite.

Surveillance de la dérive (Guardian 3) : Opérationnel, mais la période de déploiement est trop courte pour avoir détecté une dérive longitudinale significative. Le système dispose de mesures de référence ; sa capacité à détecter un changement progressif de distribution sur plusieurs mois ou années n’a pas été testée.

Retour d’information adaptatif (Guardian 4) : Intègre les retours des membres et des modérateurs dans les seuils de vérification. Le volume de retours provenant de la base de déploiement actuelle est faible, ce qui limite la capacité du système à apprendre les schémas spécifiques à la communauté. Il s’agit d’un problème de démarrage : le système s’améliore grâce aux retours, mais les communautés en phase initiale ne fournissent pas suffisamment de retours pour que le système s’améliore de manière substantielle.

Ce qui reste en cours de développement

Les composants suivants sont conçus mais ne sont pas encore pleinement opérationnels :

Optimisation du routage des modèles. Le système exploite deux niveaux de modèles : un modèle plus rapide et plus petit pour les requêtes courantes, et un modèle plus volumineux pour les tâches de raisonnement complexes. La logique de routage qui détermine quelles requêtes sont acheminées vers quel modèle est fonctionnelle mais n’est pas optimisée. Certaines requêtes qui bénéficieraient d’un traitement plus approfondi sont actuellement traitées par le modèle le plus rapide, ce qui se traduit par des réponses de moindre qualité.

Personnalisation individuelle. Le système fonctionne actuellement au niveau de la communauté : il connaît le contenu de la communauté, mais ne modélise pas les préférences individuelles des membres ni leurs schémas d’interaction. Une personnalisation au niveau individuel est prévue, mais elle soulève des questions supplémentaires de gouvernance (consentement, profilage, bulles de filtrage) qui n’ont pas encore été résolues.

Formation et accréditation des modérateurs. L’architecture de gouvernance repose sur des modérateurs compétents, capables d’examiner les résultats de l’IA et de fournir des retours correctifs. Un programme de formation structuré destiné aux modérateurs a été conçu, mais n’en est qu’aux premiers stades de son déploiement. La qualité de la gouvernance dépend directement de la compétence des modérateurs, qui est actuellement variable.

Modes de défaillance observés dans la pratique

La transparence concernant les défaillances observées est un élément indispensable à toute description crédible du système :

Génération avec assurance d’affirmations non fondées. Le système produit parfois des réponses qui semblent faire autorité mais qui ne sont pas étayées par les archives de la communauté. La couche Guardian Agent en détecte une grande partie, mais pas toutes — en particulier lorsque l’affirmation non fondée est sémantiquement similaire au contenu réel.

Débordement lexical. Dans le cadre de requêtes complexes, le vocabulaire par défaut du modèle de base prend parfois le pas sur le vocabulaire spécifique à la communauté. Il s’agit du problème de dérive distributionnelle décrit dans l’article 1, partiellement atténué mais non éliminé par le système lexical.

Rareté des retours d’information. Les communautés en phase initiale d’adoption génèrent trop peu de retours d’information pour que les mécanismes d’apprentissage adaptatif fonctionnent efficacement. Cela crée un problème de « démarrage à froid » : le système est le moins bien calibré précisément au moment où la communauté a le plus besoin qu’il soit fiable.

Fatigue des modérateurs. L’architecture de gouvernance impose une charge de modération importante aux modérateurs bénévoles. Dans les communautés où le rôle de modérateur manque de ressources, la qualité de la modération diminue, ce qui réduit l’efficacité de la couche de gouvernance impliquant une intervention humaine.

Ce que cela implique pour la recherche

La plateforme Village, dans son état actuel, est un prototype fonctionnel de gouvernance de l’IA à l’échelle d’une communauté. Il ne s’agit pas d’un système abouti et validé. Les principes architecturaux sont mis en œuvre, mais les preuves empiriques de leur efficacité sont encore préliminaires.

Pour les chercheurs, cela représente à la fois une limite et une opportunité. La limite réside dans le fait que les affirmations concernant l’efficacité de la gouvernance du cadre ne peuvent pas encore être étayées par des preuves rigoureuses. L’opportunité réside dans le fait que la plateforme offre un environnement de recherche en conditions réelles — un système opérationnel doté de couches de gouvernance instrumentées, déployé dans plusieurs types de communautés — où les hypothèses relatives à la gouvernance de l’IA peuvent être testées de manière empirique.

Les auteurs sont ouverts à toute collaboration avec des chercheurs souhaitant évaluer les affirmations relatives au cadre. Le code source est open source, les journaux de gouvernance sont accessibles aux modérateurs de la communauté, et l’architecture est conçue pour prendre en charge le type d’instrumentation requis par la recherche empirique en matière de gouvernance.

Pour l’architecture technique complète, voir Village AI sur la gouvernance agentique. Les lecteurs souhaitant évaluer ce qui peut être délégué en toute sécurité à un système qui agit — par opposition à un système qui se contente de répondre — trouveront peut-être utiles les cours associés : Travailler avec Claude et Les agents à l’œuvre.