Quand une fiche IA devient une infrastructure d’intelligence.

Une fiche IA peut sembler être un problème de rédaction. Dans un produit riche en données, c’est surtout un problème de représentation : comment décrire chaque entité avec assez de contexte pour être utile, assez de contraintes pour rester fiable et assez de stabilité pour être réutilisable partout ?

Le problème n’était pas le texte

Un catalogue hippique rassemble des historiques de courses, des performances, des oppositions, des commentaires, des relations généalogiques et des événements qui modifient rapidement la lecture d’un profil. Une fiche écrite à la main ne passe pas à l’échelle. Une fiche générée à la volée crée une latence variable, des coûts récurrents et un risque de divergence.

Le bon objet n’est donc pas « un texte généré ». C’est une représentation éditorialisée d’une entité, calculée à partir d’un état métier identifiable et conservée pour les usages aval.

Une architecture en deux responsabilités

Le moteur sépare les faits de leur formulation. Les données structurées et les règles métier produisent les agrégats, les signaux et le contexte. Le LLM intervient ensuite comme couche narrative bornée : il reformule, hiérarchise et explique ce qui lui est fourni.

Cette séparation rend possible une validation experte, un stockage versionné et une diffusion cohérente par API, web, PDF ou email. Elle permet aussi de relire une fiche sans relancer le modèle.

Entity-360 : la table pivot comme contrat

La table pivot rassemble l’état courant de l’entité et ses signaux dérivés. Dans le cas hippique, elle relie notamment le grade, les voisins, les commentaires clusterisés, le contexte des courses et les relations de lignée. Plusieurs surfaces peuvent ainsi réutiliser les mêmes faits sans dupliquer la logique.

La fiche devient la restitution d’un contrat analytique. C’est ce contrat, plus que le prompt, qui rend le système réplicable.

Le contrat ne s’arrête pas à une ligne de texte

Une fiche robuste ne stocke pas uniquement un paragraphe. Elle conserve aussi les éléments qui permettent de comprendre d’où vient ce paragraphe et dans quel état se trouvait l’entité au moment de sa génération. C’est ce qui rend la sortie réutilisable, contestable et remplaçable.

Cette distinction change la conversation avec les équipes produit. On ne demande plus au modèle de « connaître » le catalogue ; on lui fournit une vue contrôlée, puis on décide où cette vue doit vivre : dans une page, une API, un export ou un outil métier.

Le cold start relationnel

Les chevaux inédits posent un problème classique : l’entité n’a pas encore d’historique propre. Au lieu de fabriquer une fiche vide ou de compléter les trous par imagination, le moteur change de schéma de lecture. Il exploite les relations disponibles — ascendance, famille, entourage et signaux indirects — puis formule une lecture probabiliste avec ses limites.

Cette méthode se transpose à un client qui n’a pas encore acheté, une société récemment créée sans comptes déposés ou un équipement sans historique de panne. Le graphe devient un substitut partiel à l’historique.

Le cache est une décision produit

Au 31 août 2026, le stock comptait 91 515 fiches dans horse_cards, dont 45 864 fiches classiques françaises cible_v2. La table séparée inedit_ai_cards comptait 1 310 fiches dédiées aux inédits.

Les fiches sont générées puis stockées. Les lectures en cache sont servies de manière instantanée côté utilisateur. Le refresh est déclenché par les événements métier pertinents : nouvelles courses, résultats et nouveaux engagements.

Ces chiffres correspondent au coût de génération de contenu. Ils excluent l’infrastructure, la base de données, la maintenance du pipeline et les coûts d’exploitation. L’économie principale vient du fait qu’une fiche peut être lue des centaines de fois sans nouvel appel au modèle.

Le batch crée le stock, l’événement garde la fiche vivante

À grande échelle, la bonne question n’est pas « comment générer à chaque visite ? », mais « quel événement rend cette fiche obsolète ? ». Une nouvelle course, un résultat, un engagement ou une information de contexte peut déclencher un refresh ciblé. Le reste du corpus reste disponible en cache.

1. 1Un événement métier est détecté et rattaché à une entité.
2. 2Le contexte est recalculé à partir des sources structurées.
3. 3La fiche est régénérée, contrôlée puis versionnée.
4. 4Les surfaces aval récupèrent la nouvelle version sans changer de contrat.

Ce mode de fonctionnement dissocie le temps de calcul du temps de lecture. La génération peut être asynchrone et surveillée ; la consultation, elle, reste instantanée pour l’utilisateur. C’est une décision d’architecture, mais aussi une décision d’expérience : la confiance augmente quand la réponse est stable et que son état de fraîcheur est explicite.

Un pattern qui sort du turf

Le moteur devient intéressant lorsqu’on cesse de le présenter comme « un générateur de fiches cheval ». Le pattern réutilisable est :

Dans le retail, le cheval devient un client et la fiche devient une lecture d’intelligence client : état courant, profil comportemental, prochaine meilleure action et justification. Dans FinBrief, il devient une société : signaux sectoriels, voisins, publications et graphe dirigeants/filiales. En maintenance, il devient un équipement dont les événements de panne déclenchent le refresh.

Répliquer l’architecture, pas copier les champs

La partie transférable n’est pas une liste figée de colonnes. C’est une manière de séparer les briques stables des décisions propres à une verticale.

Cette séparation évite deux écueils : vendre une plateforme abstraite qui ignore le métier, ou reconstruire un projet complet à chaque nouveau catalogue. On industrialise le cadre ; on co-construit la sémantique.

La confiance se construit en dehors du modèle

Une formulation fluide ne suffit pas à établir la fiabilité. Il faut pouvoir relier chaque phrase à un contexte, identifier la date de calcul, comparer deux versions et faire relire les cas sensibles. La validation experte devient alors une boucle de conception, pas une estampille ajoutée à la fin.

Dans ce cas, le repère de 98 % correspond à une validation experte réalisée sur des échantillons. Il ne s’agit ni d’une précision universelle ni d’une garantie sur chaque fiche. La bonne pratique consiste à publier le périmètre de l’échantillon, les critères de contrôle et les cas d’incertitude — notamment lorsqu’un profil est inédit ou que les données sont incomplètes.

Cette discipline ouvre aussi la porte à l’observabilité : suivre les échecs de génération, les fiches trop anciennes, les divergences entre sources et les retours des utilisateurs. Le système devient améliorable parce que ses erreurs sont localisables.

Ce qu’il faut sécuriser avant de généraliser

La portabilité méthodologique est forte, mais chaque verticale nécessite un expert métier, une boucle de validation et un graphe relationnel adapté. Il faut également isoler les dépendances sources, documenter le lineage, versionner les embeddings et éviter que les règles métier restent enfouies dans des scripts spécialisés.

Les dettes les plus discrètes apparaissent souvent après le premier succès : deux sources de vérité qui divergent, un refresh non idempotent, une version de prompt impossible à retrouver, ou une multiplication d’endpoints qui réimplémentent chacun une partie de la logique. Elles ne se voient pas dans une belle démo, mais elles déterminent le coût des mois suivants.

Commencer petit pour mesurer l’impact

La première étape raisonnable n’est pas de couvrir tout le catalogue. Elle consiste à choisir une verticale, trois actions observables et un jeu de référence suffisamment représentatif pour comparer le système à une baseline simple.

1. 1Définir le modèle Entity-360 et ses sources autorisées.
2. 2Constituer un golden set relu par des experts du domaine.
3. 3Produire une vue JSON et une surface de lecture utilisable.
4. 4Déclencher le refresh sur quelques événements métier.
5. 5Mesurer l’effet incrémental : usage, conversion, temps gagné ou décisions évitées.

Cette méthode garde le projet concret. Elle permet de vérifier que la fiche accélère réellement une lecture, qu’une recommandation est comprise et qu’un utilisateur agit mieux avec elle qu’avant. Le texte n’est que le dernier mètre d’une chaîne qui doit produire un effet mesurable.

La bonne première étape est donc un cadrage Entity-360 : modèle sémantique, golden set, protocole de validation et prototype de lecture. L’industrialisation vient ensuite, une fois que la valeur est démontrée sur un périmètre maîtrisé.