Oui. Rixe expose une API REST, un connecteur Looker Studio et un serveur MCP. Le serveur MCP permet à un assistant IA de lire directement les données de visibilité d'une marque : les indicateurs se consultent donc là où le reste du reporting a déjà lieu.
L'API est la voie directe : vous vous authentifiez, vous demandez les scores, mentions, rangs et citations d'un projet, et vous les versez dans l'entrepôt ou le tableau de bord qui contient déjà le reste de votre reporting. Le connecteur Looker Studio existe pour que les mêmes données atterrissent dans un rapport client sans que personne n'écrive de code.
Le serveur MCP est le plus intéressant. MCP permet à un assistant IA de lire directement les données d'un outil : une question comme « quels prompts avons-nous perdus cette semaine et quelle source est derrière ? » peut être traitée sur des données Rixe en direct, dans la conversation même où se déroule le reste du travail. Cela supprime l'étape où quelqu'un exporte un CSV pour répondre à une question qui était déjà une phrase.
Les trois lisent les mêmes enregistrements. Un chiffre dans une présentation client, un chiffre dans un tableau de bord et un chiffre cité par un assistant ne peuvent donc pas se contredire.
Trois entrées, pour trois usages
L’API REST est la voie directe : s’authentifier, demander les scores, mentions, rangs et citations d’un espace de travail, et les tirer vers l’entrepôt ou le tableau de bord qui héberge déjà le reste de votre reporting. Elle est en lecture seule, versionnée et paginée — les propriétés ennuyeuses qu’une équipe data demande vraiment.
Le connecteur Looker Studio existe pour le cas où personne ne veut écrire de code : pointez-le sur un espace, choisissez les champs, et les mêmes chiffres atterrissent dans un rapport que quelqu’un d’autre sait déjà modifier. Il lit les mêmes points d’accès que l’API : les deux ne peuvent donc jamais diverger.
Ce que change le serveur MCP
Le serveur MCP permet à un assistant de lire les données directement, ce qui transforme une question de tableau de bord en conversation. Au lieu d’ouvrir quatre écrans pour comprendre le mouvement de la semaine, vous demandez — et l’assistant lit les mêmes mesures, avec les mêmes tailles d’échantillon, et répond à partir d’elles, pas d’une supposition.
Il est en lecture seule par conception. Un assistant peut récupérer un score, une liste de mentions ou les sources d’une réponse ; il ne peut pas modifier un jeu de prompts, valider un brouillon ni publier quoi que ce soit. La frontière est volontaire : la lecture est là où un assistant sert, l’écriture là où une piste d’audit compte plus que le confort.
Des connexions qui ne sont pas une API
La plupart des équipes ne touchent jamais l’API et connectent quand même trois choses : Search Console et Analytics à l’entrée, pour que clics et sessions côtoient les chiffres de visibilité, et un CMS à la sortie, pour qu’un brouillon validé devienne un article en brouillon plutôt qu’un copier-coller. Les trois sont demandés avec la portée la plus étroite qui fasse le travail.
Rien n’écrit sur votre site sans qu’une personne valide, et la connexion CMS crée un brouillon plutôt qu’un article publié — une limitation volontaire qui n’a gêné exactement personne en pratique, car c’est à l’étape de relecture qu’une affirmation sans source se fait attraper.
