Accès fiable aux données d'initiés grâce au serveur MCP

Une bonne interface ne remplace pas de bonnes données, elle évite surtout de les massacrer en route.

Notre serveur MCP, sans poudre aux yeux

Les agents aiment parler. Les analystes, eux, préfèrent obtenir une liste de transactions d'initiés propre, datée, sourcée, et reproductible.

C'est exactement le rôle de notre serveur MCP, Model Context Protocol, pour Claude, Cursor et Windsurf. Pas une boule de cristal, pas un copilote qui improvise sur trois PDF mal lus. Un point d'accès standardisé vers une base de données structurée sur les transactions d'initiés, avec des outils explicites, un schéma stable, et des réponses que l'on peut auditer.

Le sujet mérite un peu de précision, parce que le marché adore confondre trois choses distinctes, l'accès au modèle, l'accès aux données, et la qualité des données. Brancher un agent à une source d'information ne crée pas magiquement une infrastructure de recherche. Cela crée surtout de nouvelles façons de faire des erreurs à grande vitesse. Dans un domaine réglementé comme les déclarations d'initiés, c'est un talent dont on se passerait volontiers.

Dans cet article, on décrit comment notre MCP est pensé pour des usages concrets, comment les agents l'interrogent, à quoi ressemble le schéma, quels appels d'outils sont réellement utiles, et où se trouvent les pièges. Le tout sans inventer de métriques absentes, puisque le bloc DATA n'a pas été fourni. Quand un chiffre manque, il manque. C'est plus élégant que l'imagination.

Pourquoi un MCP pour des données d'initiés

Le cas d'usage n'est pas abstrait. Un utilisateur demande à Claude, Cursor ou Windsurf quelque chose comme, "montre-moi les achats récents de dirigeants sur les small caps françaises", ou "résume les transactions du CEO de telle société sur les 12 derniers mois". Sans couche d'outils, l'agent répond au mieux avec de la théorie réglementaire, au pire avec une fiction polie. Avec un MCP, il peut appeler une fonction, récupérer des enregistrements structurés, puis rédiger une réponse fondée sur des données.

Le protocole MCP sert ici d'interface contractuelle entre l'agent et notre système. Il définit des outils, des paramètres, des schémas de réponse et un mode d'échange standard. C'est banal, au meilleur sens du terme. En finance de données, la banalité est une vertu. Elle réduit la variabilité, facilite les tests et rend les comportements observables.

Ce que l'agent doit vraiment savoir

Un agent n'a pas besoin d'un accès direct à toute la base. Il a besoin de primitives utiles, bornées et sûres. Typiquement :

• rechercher un émetteur par nom, ticker ou identifiant interne ;
• lister des filings selon une juridiction, une période, un type de transaction ;
• récupérer le détail d'un filing ;
• agréger par initié, émetteur, direction de transaction, ou fenêtre temporelle ;
• exposer le contexte réglementaire minimal, par exemple la juridiction et la nature de la source.

La différence est importante. Un modèle qui reçoit un dump brut de tables relationnelles fera ce que font les modèles face à un buffet mal étiqueté, il prendra trop de choses, oubliera les contraintes, et servira un plat conceptuel. Un outil bien dessiné impose des garde-fous. Il force l'agent à poser une question précise.

Pourquoi Claude, Cursor et Windsurf y gagnent

Ces environnements ont des profils d'usage différents. Claude est souvent utilisé pour l'analyse et la synthèse. Cursor et Windsurf vivent davantage dans un contexte de travail, produit ou code, où l'utilisateur veut intégrer des données à un flux de recherche ou à une application. Le MCP les aligne sur un même socle.

Autrement dit, on ne construit pas trois intégrations exotiques. On expose un serveur propre, et chaque client compatible peut interroger les mêmes outils. La promesse n'est pas "une IA spéciale finance". La promesse est plus terre à terre, donc plus utile, "quel que soit l'agent, il parle à la même source de vérité".

Le schéma, cette partie moins sexy que les démos

Les démos montrent un prompt. Les systèmes sérieux montrent un schéma.

Dans les transactions d'initiés, le schéma est la moitié du produit. Les mêmes événements peuvent être publiés avec des formats différents selon la juridiction, la source, la qualité du dépôt, ou la manière dont les champs ont été extraits. Si l'on ne normalise pas très tôt, l'agent se retrouve à comparer des pommes, des options, et des formulaires mal OCRisés.

Les entités minimales

Notre schéma logique distingue au moins cinq objets principaux :

1. Issuer
   L'émetteur, avec un identifiant interne stable, ses noms connus, le ticker si disponible, la place de cotation, la juridiction, et des métadonnées de résolution d'entité.

2. Insider
   La personne déclarante ou liée à la transaction, avec son nom normalisé, son rôle si disponible, et un identifiant interne. Il faut accepter qu'un même individu apparaisse sous plusieurs variantes orthographiques. Le système n'a pas le droit d'être surpris.

3. Filing
   Le document source ou l'événement déclaré. Il porte un identifiant de filing, une date de dépôt, une date d'événement si distincte, la juridiction, la source, et un lien éventuel vers le document d'origine.

4. Transaction
   La ligne économique utile, achat, vente, exercice, attribution, cession automatique, etc. C'est ici que vivent les quantités, prix, devise, nature du titre, sens de la transaction, et éventuellement la part détenue après opération.

5. Instrument
   L'objet négocié, action ordinaire, option, RSU, dérivé, autre. Sans cette couche, les agrégations deviennent vite absurdes.

Cette séparation paraît académique jusqu'au moment où un utilisateur demande, "combien d'achats au marché par des dirigeants exécutifs, hors exercices d'options, sur les six derniers mois". Si tout est compacté dans une table unique et mal typée, la réponse devient un exercice de poésie.

Les champs qui évitent les contresens

Quelques champs sont plus importants qu'ils n'en ont l'air :

• transaction_date et filed_at doivent être distincts ;
• transaction_code source et transaction_type_normalized doivent coexister ;
• security_type doit être normalisé ;
• ownership_nature, direct ou indirect, doit être conservé si la source le permet ;
• currency et price_per_unit doivent être séparés de toute valeur notionnelle calculée ;
• source_url ou source_reference doit être renvoyé quand disponible.

Le point n'est pas le perfectionnisme. C'est la prévention. Un agent qui ne distingue pas date d'exécution et date de publication peut raconter une histoire de "signal récent" sur une transaction vieille de plusieurs jours. Dans le monde des filings, quelques jours suffisent à transformer une observation en anecdote.

Identifiants stables, ou la fin des joins approximatifs

Les identifiants stables sont la pièce maîtresse. Un agent doit pouvoir demander d'abord "trouve l'émetteur", puis "liste les filings", puis "donne le détail du filing X". Cela suppose :

• un issuer_id unique ;
• un insider_id unique ;
• un filing_id unique ;
• des alias et clés de résolution pour les noms ambigus.

Sans cela, les appels d'outils deviennent fragiles. Le modèle réessaie avec des chaînes de caractères, multiplie les approximations, et l'utilisateur obtient un résultat qui "a l'air juste". C'est souvent la phrase qui précède une erreur de production.

Comment les agents interrogent le serveur

Le plus utile n'est pas une longue liste d'outils. C'est un petit ensemble cohérent, documenté, avec des paramètres explicites et des réponses prévisibles.

Les outils de base

Un serveur MCP pour données d'initiés peut exposer, par exemple :

search_issuers

Recherche d'émetteurs par nom, ticker, ISIN si disponible, ou alias.

Entrée typique

{
  "query": "LVMH",
  "jurisdiction": "FR",
  "limit": 5
}

Sortie typique

{
  "items": [
    {
      "issuer_id": "iss_123",
      "name": "LVMH Moët Hennessy Louis Vuitton SE",
      "ticker": "MC",
      "jurisdiction": "FR",
      "match_score": 0.98
    }
  ]
}

L'intérêt est évident. L'agent n'invente pas quel "LVMH" il a trouvé. Il récupère un identifiant et peut poursuivre proprement.

list_filings

Liste des filings selon des filtres bornés.

Entrée typique

{
  "issuer_id": "iss_123",
  "start_date": "2025-01-01",
  "end_date": "2025-12-31",
  "transaction_direction": "buy",
  "normalized_types": ["open_market"],
  "page": 1,
  "page_size": 50
}

Sortie typique

{
  "items": [
    {
      "filing_id": "fil_987",
      "filed_at": "2025-03-14T08:12:00Z",
      "transaction_date": "2025-03-12",
      "issuer_id": "iss_123",
      "insider_id": "ins_456",
      "summary": "Achat au marché",
      "source_reference": "n/a"
    }
  ],
  "next_page": 2
}

Le détail important est la pagination. Les agents ont tendance à demander "tout". Les serveurs sérieux répondent "par pages".

get_filing_detail

Récupère le détail d'un filing ou d'une transaction.

Entrée typique

{
  "filing_id": "fil_987"
}

Sortie typique

{
  "filing_id": "fil_987",
  "issuer": {
    "issuer_id": "iss_123",
    "name": "LVMH Moët Hennessy Louis Vuitton SE",
    "jurisdiction": "FR"
  },
  "insider": {
    "insider_id": "ins_456",
    "name": "Nom de l'initié",
    "role": "Dirigeant"
  },
  "transactions": [
    {
      "transaction_type_normalized": "open_market_buy",
      "security_type": "common_stock",
      "quantity": "1000",
      "price_per_unit": "712.50",
      "currency": "EUR",
      "transaction_date": "2025-03-12"
    }
  ],
  "source_url": "n/a"
}

L'agent peut alors résumer, comparer, ou signaler les limites, sans broder.

Une séquence de requêtes réaliste

Prenons une demande utilisateur dans Claude :
"Montre-moi les achats d'initiés les plus récents sur un émetteur français, et résume les trois derniers filings."

Le chemin raisonnable est :

1. search_issuers pour résoudre l'émetteur ;
2. list_filings avec filtres jurisdiction=FR, transaction_direction=buy, tri décroissant par filed_at ;
3. get_filing_detail sur les trois premiers résultats ;
4. rédaction d'une synthèse, avec mention des dates de transaction et de dépôt, et sans extrapolation de performance boursière.

C'est presque décevant de simplicité. C'est bon signe.

Ce que l'agent ne devrait pas faire

Un agent ne devrait pas :

• déduire le sens économique d'une transaction à partir d'un code source non normalisé ;
• agréger achats et exercices d'options comme si c'était la même chose ;
• comparer des valeurs en devise sans conversion explicite ;
• présenter une absence de filings comme une absence d'activité économique ;
• ignorer la juridiction et ses règles de publication.

Ces interdictions sont moins glamour qu'une "analyse augmentée", mais elles évitent les erreurs qui coûtent la réputation d'un produit.

Juridictions, règles, et petites différences qui changent beaucoup

Dès qu'on travaille sur des données d'initiés, la couche réglementaire n'est pas un décor. C'est une variable de structure.

En Europe, les notifications des personnes exerçant des responsabilités dirigeantes relèvent notamment du règlement sur les abus de marché, MAR. Aux États-Unis, le référentiel usuel passe par les déclarations de la SEC, notamment les formulaires de la section 16, comme Form 4. Les délais, les champs et les conventions diffèrent. Un bon MCP ne prétend pas les effacer. Il les rend visibles.

Pourquoi cette comparaison compte dans le produit

Si un utilisateur demande "les transactions les plus récentes", le système doit comprendre que "récent" peut signifier dépôt récent, transaction récente, ou disponibilité récente selon la source. Cela semble tatillon jusqu'au moment où l'on compare une juridiction à T+3 ouvrés avec une autre à T+2 ouvrés. La fraîcheur apparente des signaux n'est plus directement comparable.

Le minimum réglementaire à renvoyer

Dans nos réponses d'outils, il est utile de renvoyer au moins :

• la juridiction ;
• le type de source ;
• la date de transaction ;
• la date de dépôt/publication ;
• un lien source si disponible ;
• un code ou type de transaction normalisé et son équivalent brut si pertinent.

Cela permet à l'agent de rédiger une réponse honnête, du type :
"Voici les trois derniers filings publiés en FR sur cet émetteur. Les transactions ont eu lieu aux dates X, Y, Z, et ont été publiées aux dates A, B, C. Le cadre applicable relève de MAR Art. 19."

C'est moins spectaculaire que "forte conviction des initiés". C'est aussi nettement plus défendable.

Exemples d'appels d'outils dans Claude, Cursor et Windsurf

Le protocole est commun, mais la mise en scène varie selon le client.

Dans Claude, la synthèse guidée par les outils

Claude excelle souvent lorsqu'on lui demande de résumer des résultats structurés. Un flux typique ressemble à ceci :

Prompt utilisateur

Donne-moi les achats d'initiés les plus récents sur cet émetteur, uniquement les achats au marché, et résume les montants si disponibles.

Appels d'outils attendus

1. search_issuers
2. list_filings avec normalized_types=["open_market"] et transaction_direction="buy"
3. get_filing_detail pour les résultats pertinents

Réponse attendue

Une réponse qui :

• liste les derniers filings ;
• distingue les dates de transaction et de dépôt ;
• mentionne "montant n/a" si le prix ou la quantité manquent ;
• évite de transformer une liste de filings en recommandation d'investissement.

Le point crucial est la discipline sur les valeurs manquantes. Si le montant n'est pas calculable, on écrit n/a. C'est moins romantique qu'une estimation. C'est aussi moins faux.

Dans Cursor, le mode analyste-développeur

Cursor sert souvent à construire autour des données. Ici, l'utilisateur peut vouloir générer du code qui consomme le MCP, ou produire un écran interne de recherche.

Exemple de demande :

Génère-moi un script TypeScript qui interroge notre MCP, récupère les 50 derniers filings d'achat en FR, puis les groupe par émetteur.

L'intérêt du MCP est qu'il fournit un contrat stable. Cursor peut aider à écrire le client, mais la sémantique des champs vient du serveur. On évite ainsi l'archéologie habituelle des APIs internes, où chacun redécouvre que date veut dire trois choses selon la table.

Dans Windsurf, le flux de travail intégré

Windsurf, comme d'autres environnements agentiques, est utile quand l'utilisateur veut enchaîner recherche, code et restitution. Le MCP y joue le rôle d'ossature. L'agent peut :

• résoudre un univers d'émetteurs ;
• extraire des transactions selon des filtres ;
• produire un composant d'interface ;
• documenter les limites de la donnée.

Le gain n'est pas seulement la vitesse. C'est la réduction de la dérive sémantique entre exploration et implémentation. Quand les mêmes outils servent à chercher et à construire, on perd moins d'information en route.

Les choix d'architecture qui comptent plus que la démo

Un serveur MCP pour données financières n'est pas jugé sur son premier screenshot. Il est jugé sur son comportement au centième appel, quand les requêtes deviennent ambiguës, volumineuses ou mal formulées.

Pagination, limites et tri déterministe

Chaque outil de liste doit imposer :

• une page_size maximale ;
• un tri explicite et déterministe ;
• des curseurs ou pages stables ;
• des erreurs claires quand les filtres sont incompatibles.

Sinon, l'agent peut obtenir des résultats partiels sans le savoir, ou des ordres différents d'une exécution à l'autre. Pour un humain, c'est agaçant. Pour un agent, c'est un terrain de jeu pour hallucinations procédurales.

Résolution d'entités et alias

Les noms d'émetteurs et d'initiés sont un sport de combat. Il faut gérer :

• variantes de casse ;
• suffixes juridiques ;
• translittérations ;
• changements de nom ;
• homonymes.

Le serveur doit donc renvoyer des scores de correspondance, des alias connus, et idéalement forcer l'agent à confirmer quand l'ambiguïté est réelle. Un "peut-être" explicite vaut mieux qu'un "oui" faux.

Traçabilité et auditabilité

Toute réponse utile devrait pouvoir être retracée à un filing source ou à un enregistrement interne lié à une source. Cela implique :

• des identifiants persistants ;
• des timestamps ;
• des références de source ;
• un journal d'appels côté serveur si nécessaire.

Quand un utilisateur demande, "d'où vient cette transaction ?", la réponse ne peut pas être "du modèle". Le modèle n'est pas une source. C'est un intermédiaire, parfois talentueux, souvent trop confiant.

Normalisation sans effacer l'original

Le bon compromis est simple à énoncer, plus difficile à tenir :

• conserver les champs bruts ;
• exposer des champs normalisés ;
• documenter les règles de mapping.

Ainsi, un agent peut répondre avec le normalisé, tout en gardant la possibilité de montrer le brut si l'utilisateur veut vérifier. C'est particulièrement utile pour les codes de transaction, les rôles d'initiés et les types de titres.

Ce qu'un utilisateur obtient vraiment, et ce qu'il ne faut pas promettre

Il faut être franc sur la proposition de valeur. Un MCP bien conçu donne un accès fiable à des données d'initiés et à leurs métadonnées. Il ne transforme pas automatiquement ces données en alpha.

Ce que le produit fait bien

• fournir des réponses structurées à des questions précises ;
• accélérer la recherche sur un univers de filings ;
• rendre les agents utiles sans leur laisser improviser les faits ;
• homogénéiser l'accès depuis plusieurs clients compatibles.

Ce que le produit ne doit pas prétendre faire

• inférer l'intention économique réelle d'un initié au-delà de la transaction déclarée ;
• garantir qu'un signal d'achat est haussier ;
• rendre comparables sans nuance des juridictions aux règles différentes ;
• compenser des données source incomplètes par de l'éloquence.

On peut bâtir des couches analytiques au-dessus, scoring, clustering, backtests, alertes. Mais elles doivent rester séparées de la couche d'accès aux faits. Mélanger les deux est une manière élégante de rendre impossible toute discussion sérieuse sur les erreurs.

Une note sur les chiffres absents

Le brief mentionne une base de 162000 déclarations. C'est utile pour situer l'ordre de grandeur. En revanche, aucun bloc DATA live n'a été fourni pour cet article. Donc pas de ventilation par juridiction, pas de taux de couverture, pas de latence médiane, pas de volume quotidien. La bonne pratique est simple, on n'invente rien. On écrit n/a et on avance.

Le test décisif, des réponses fiables sous contrainte

Le vrai test d'un MCP n'est pas "peut-il répondre à une question simple ?". Presque tout peut répondre à une question simple, surtout avec suffisamment d'assurance. Le test est plus sévère :

• que se passe-t-il si l'utilisateur donne un nom ambigu ;
• que se passe-t-il si les dates sont incomplètes ;
• que se passe-t-il si la transaction est un exercice d'option et non un achat au marché ;
• que se passe-t-il si la source ne fournit pas le prix ;
• que se passe-t-il si la même personne apparaît sous deux variantes.

Un serveur sérieux doit répondre de manière bornée, explicite et parfois frustrante. La frustration est sous-estimée comme caractéristique produit. En données réglementaires, une frustration bien placée vaut mieux qu'une réponse séduisante et fausse.

À quoi ressemble une bonne réponse finale de l'agent

Une bonne réponse utilisateur ressemble à ceci :

1. elle nomme l'émetteur résolu ;
2. elle précise la juridiction ;
3. elle liste les filings trouvés avec dates de transaction et de dépôt ;
4. elle décrit les transactions avec types normalisés ;
5. elle signale les champs manquants comme n/a ;
6. elle cite la source ou la référence source ;
7. elle n'invente ni performance, ni causalité, ni recommandation.

C'est presque austère. C'est aussi le genre d'austérité qui vieillit bien.

Ce que nous construirions ensuite

Si l'on veut aller au-delà de l'accès brut, les prochaines briques logiques sont assez claires :

Un outil d'agrégation prêt pour les agents

Par exemple, aggregate_insider_activity, avec des dimensions comme :

• émetteur ;
• initié ;
• juridiction ;
• fenêtre temporelle ;
• type normalisé ;
• direction ;
• devise.

L'agent pourrait alors répondre à des questions du type :
"Combien d'achats au marché par des dirigeants exécutifs sur les 90 derniers jours pour cet émetteur ?"
Sans réinventer une agrégation dans son texte.

Un outil de qualité de données

Un get_data_quality_report par émetteur ou juridiction serait utile. Il pourrait renvoyer :

• part de filings avec prix manquant ;
• part de rôles non résolus ;
• couverture des liens source ;
• fraîcheur de l'ingestion.

Ce n'est pas un gadget. C'est la différence entre un assistant qui paraît compétent et un assistant qui sait quand il marche sur une plaque d'égout.

Des ressources documentaires embarquées

Au-delà des outils transactionnels, le MCP peut exposer des ressources statiques ou semi-statiques :

• glossaire des types de transaction ;
• notes de méthodologie ;
• règles par juridiction ;
• limitations connues.

Ainsi, l'agent peut enrichir sa réponse sans faire semblant d'avoir lu tout l'internet réglementaire entre deux requêtes.

Le gain réel d'un serveur MCP pour données d'initiés n'est donc pas une magie conversationnelle. C'est une discipline d'accès, de schéma et de restitution, partagée entre Claude, Cursor et Windsurf. Si vous voulez le tester sérieusement, la prochaine étape concrète est simple, prenez dix requêtes ambiguës d'utilisateurs réels, faites-les passer par les outils, puis mesurez non pas la fluidité des réponses, mais le taux d'identifiants correctement résolus, la part de champs n/a, et le nombre de cas où l'agent sait dire "je ne sais pas encore". C'est souvent là que commence un produit adulte.

Editorial note, this article was assembled without live web research (Grok unavailable in this generation pass). Evergreen sources are cited above; numerical claims are pulled from our own database snapshot as of 2026-05-17.

Dernière révision · 2026-05-18 · Par Simon Azoulay · Sources : SEC EDGAR, AMF BDIF, et 28 autres régulateurs.