> ## Knowledge Base Index
> Fetch the complete knowledge base index at: https://doc.openagenda.com/sitemap.xml
> Use this file to discover available pages before exploring further.
> Pure-Markdown content can be obtained by appending a '.md' suffix to the content URLs listed in the sitemap (without the trailing slash).

# Structurer plutôt que corriger la donnée événementielle

# Données événementielles : structurer en amont plutôt que corriger en aval

### L'intelligence artificielle peut lire un champ texte libre et en extraire une catégorie. Mais à quel prix, et avec quelle fiabilité, comparée à l'organisateur qui sait exactement ce qu'il propose ?

Les plateformes d'agenda événementiel font face à un défi récurrent : **des données hétérogènes, incomplètes et mal catégorisées**. La tentation est grande de déléguer la résolution de ce problème à des modèles de langage. Appliquer de l'IA en sortie de pipeline pour inférer la catégorie, corriger le format de date, ou déduire le public cible d'un champ description. C'est techniquement faisable. Mais ce choix architectural mérite d'être examiné sérieusement avant d'être industrialisé.

### L'organisateur est la meilleure source de vérité

**Lorsqu'un organisateur publie un événement, il dispose d'une connaissance que nul système ne peut reconstituer aussi bien** : ce qu'il propose vraiment, à qui, dans quel esprit. Savoir que sa conférence est destinée à des professionnels et non au grand public, que son atelier s'adresse à des débutants et non à des initiés, que son festival relève de la musique traditionnelle et non du folk contemporain : ces distinctions sont triviales pour lui, et complexes à inférer pour une IA.

La structuration en amont consiste précisément à **capter cette expertise au bon moment** : au moment de la saisie, par un formulaire bien conçu, des champs guidés, des taxonomies exposées clairement. Le résultat n'est pas seulement plus précis. Il est aussi plus stable : une donnée saisie par son auteur ne dérive pas : elle ne dépend pas d'un modèle qui peut changer de version, d'un prompt reformulé, ou d'une inférence qui varie selon le contexte textuel disponible.

### Le coût réel de la structuration par IA

On sous-estime souvent ce que représente le recours systématique à des modèles de langage pour traiter des volumes événementiels. Chaque inférence, une catégorie, un type de public, une thématique, consomme du calcul. À l'échelle d'une plateforme traitant des dizaines ou centaines de milliers d'événements, **ce coût devient significatif, tant sur le plan financier qu'énergétique**.

**L'empreinte carbone des grands modèles de langage est documentée et non négligeable**. Utiliser ces ressources pour corriger des données que l'organisateur aurait pu renseigner en quelques clics interroge la proportionnalité du moyen au problème. C'est d'autant plus vrai que le résultat reste probabiliste : l'IA se trompe, et ces erreurs doivent ensuite être détectées, corrigées, ou acceptées comme bruit dans le système.

### Ce que l'IA fait bien et ce qu'elle ne remplace pas

Il ne s'agit pas de nier l'utilité des outils d'IA dans l'écosystème de la donnée événementielle. La suggestion automatique, l'aide à la complétion, la détection d'incohérences, la traduction : ce sont des cas d'usage légitimes, où l'IA assiste sans se substituer à la source de vérité.

Là où le raisonnement devient fragile, c'est lorsqu'on lui demande de remplacer la décision de l'organisateur, d'inférer après coup ce qui aurait pu être déclaré en amont. On traite alors un symptôme : la donnée mal structurée, plutôt que sa cause : un formulaire de saisie qui n'invite pas à structurer.

### Un principe d'architecture : recueillir, pas reconstruire

Pour les décideurs techniques qui conçoivent ces plateformes, le choix se pose souvent comme **un arbitrage entre expérience de saisie** (simplifier le formulaire) **et qualité de la donnée** (exiger des champs structurés). L'IA semble résoudre cette tension en permettant les deux : formulaire libre d'un côté, structuration automatique de l'autre.

Mais ce confort apparent a un coût différé. Une plateforme qui s'appuie massivement sur l'inférence post-saisie accumule **une dette de qualité** qu'elle ne voit pas immédiatement. Les erreurs de catégorisation affectent la recherche, la recommandation, la valorisation des données auprès de partenaires ou d'agrégateurs. Et elles sont difficiles à corriger rétroactivement à grande échelle.

Une objection revient souvent à ce stade : **quelle ontologie choisir ?** Il n'existe pas de classification universelle des événements culturels ou publics qui convienne à tous les contextes, tous les territoires, tous les usages. Cette difficulté ne plaide pas pour l'absence de structure, elle plaide pour la coexistence de plusieurs ontologies reliées entre elles par des correspondances sémantiques. Un organisateur qui catégorise son événement selon le référentiel de sa plateforme peut voir cette donnée alignée avec d'autres référentiels (schema.org, vocabulaires sectoriels, taxonomies partenaires) via des tables de correspondance explicites. **C'est un travail de modélisation, pas d'inférence**. Et il produit des données interopérables, stables et dont l'origine est toujours traçable, ce qu'aucune IA appliquée à posteriori sur du texte libre ne peut garantir au même niveau.

### Conclusion

Structurer en amont, c'est parier sur l'expertise de celui qui connaît le mieux l'événement. C'est aussi un choix de sobriété : moins de calcul, moins d'incertitude, moins d'erreurs à gérer en aval. L'IA reste un outil précieux, pour assister, suggérer, vérifier. Mais elle ne devrait pas porter le poids de ce qu'un bon formulaire peut recueillir à la source.