Brancher Claude sur Pennylane, Qonto ou Shopify
Brancher Claude sur un logiciel de gestion passe par deux chemins seulement. Le premier est le connecteur, y compris le connecteur personnalisé qui pointe vers un serveur MCP distant. Le second est l’appel direct de l’API depuis Claude Code, avec une clé et une requête HTTP. Pennylane, Qonto et Shopify publient les trois une API documentée : la faisabilité technique n’est jamais le sujet.
Le sujet, c’est la clé d’API. Une clé porte exactement les droits qu’on lui a donnés, et les trois éditeurs cités ne laissent pas la même latitude. Quant à la consigne qui circule le plus - écrire la clé dans un fichier plutôt que dans le chat - elle repose sur une explication fausse : le réflexe est bon, la raison ne l’est pas.
Quelles sont les deux façons de brancher Claude ?
La première voie est le connecteur : il donne à Claude accès à un service pour en récupérer les données et y agir. Il en existe deux variantes, les connecteurs de l’annuaire, déjà construits, et les connecteurs personnalisés, qui pointent vers un serveur MCP distant. Un détail d’architecture décide de la faisabilité : Claude s’y connecte depuis l’infrastructure cloud d’Anthropic, non depuis le poste de travail. Le serveur doit donc être joignable depuis Internet, ce qui exclut un service enfermé derrière un VPN.
La seconde voie est Claude Code, dans le terminal : aucune couche intermédiaire, Claude lit la documentation de l’API, construit la requête et l’exécute. Le connecteur convient à un usage répété, par plusieurs personnes, dans une conversation, sur le modèle décrit dans Brancher Claude sur Gmail : trier et résumer ses mails. L’appel direct convient à ce qui se fait une fois : sortir un export inhabituel, tester un point de terminaison.
MCP n’est pas une technologie maison : c’est un standard ouvert créé par Anthropic, aujourd’hui porté par une structure de la Linux Foundation sous licence Apache 2.0, sans siège réservé à aucune entreprise dans sa gouvernance technique, et que citent aussi ChatGPT et plusieurs éditeurs d’outils de développement.
Les connecteurs personnalisés : sur quels plans ?
Sur tous, y compris le plan gratuit : les connecteurs personnalisés utilisant MCP distant sont disponibles dans Claude, Cowork et Claude Desktop pour les plans Free, Pro, Max, Team et Enterprise, le plan gratuit étant borné à un seul. La restriction qui compte est organisationnelle : sur Team et Enterprise, seuls les Owners peuvent ajouter un connecteur, chaque membre s’y connectant ensuite avec ses propres accès. Un collaborateur ne branche donc pas un outil métier de son propre chef.
OAuth est le chemin d’authentification principal. Une clé d’API en en-tête de requête est aussi possible, en bêta : l’administrateur la saisit une fois, Claude l’envoie à chaque appel. Deux pages officielles divergent ici, l’article d’aide ne décrivant que OAuth ; la documentation développeur fait autorité, étant la page de référence des types d’authentification et la plus récente.
Anthropic publie deux avertissements sur ces connecteurs. Les connecteurs personnalisés relient Claude à des services non vérifiés par Anthropic, et un serveur MCP malveillant peut contenir des instructions cachées visant à faire exécuter des actions non voulues. Le second porte sur le placement du secret : une clé passée dans l’URL du connecteur est explicitement déconseillée, parce que les URL finissent dans les journaux, les proxys et les historiques.
Quand faut-il plutôt passer par Claude Code ?
Quand le besoin est ponctuel, technique, ou qu’il suppose de croiser l’API avec des fichiers locaux. Claude Code exige un compte Pro, Max, Team, Enterprise ou Console ; le plan gratuit n’y donne pas accès. La page tarifaire n’affiche pas explicitement Claude Code pour Max et Enterprise : c’est la page d’installation qui fait autorité, puisqu’elle énumère les comptes acceptés à l’authentification. Voir aussi Prix de Claude en 2026 : quel abonnement choisir ?.
Avant le premier essai, deux points méritent l’attention. Les commandes qui vont chercher du contenu sur le web, curl et wget en tête, ne sont pas approuvées automatiquement : chaque appel demande une validation, qu’une règle d’autorisation explicite permet d’accepter durablement. Second point, contre-intuitif : l’outil de récupération de page web n’est pas adapté, sa documentation le qualifiant de perte d’information par conception, un petit modèle rapide résumant la page. Pour une API qui renvoie du JSON, c’est curl ou un serveur MCP.
Les bases sont expliquées dans Claude Code, c’est quoi ? Explication simple en français, la mise en place dans Installer Claude Code sur Windows : le tutoriel pas à pas. Sur le modèle, la documentation conseille de partir de Claude Opus 5 pour le codage agentique complexe, et de passer à Claude Fable 5, le plus capable largement diffusé, quand la tâche exige la capacité maximale disponible : agents de longue durée, raisonnement profond, recherche avancée. Le détail est dans Opus, Fable, Sonnet, Haiku : quel modèle Claude choisir ?.
Pennylane, Qonto, Shopify : ce que chaque API ouvre
Pennylane expose deux collections, une API Entreprise et une API Cabinet, la seconde atteignant plusieurs sociétés clientes avec un seul jeton : factures clients et fournisseurs, plan comptable, journaux et écritures, balance générale, exports FEC, comptes et transactions bancaires.
Qonto décrit son API comme un accès à distance à la banque, à la facturation et à la tenue comptable : comptes, soldes et IBAN, transactions et pièces jointes, cartes, factures, bénéficiaires et virements.
Shopify propose une API Admin en GraphQL, présentée comme le moyen de construire des applications qui étendent l’administration de la boutique : produits, collections, commandes, clients, stocks, et le contenu de la boutique, blogs et articles inclus. L’API REST étant en statut historique depuis octobre 2024, tout nouveau développement se fait en GraphQL.
Attention à deux URL périmées qui circulent : developer.pennylane.com n’existe pas, la documentation technique de Pennylane étant hébergée sur le portail readme.io de l’éditeur, et l’ancien portail api-doc.qonto.com renvoie une erreur, la documentation vivante étant sur docs.qonto.com.
Une clé d’API porte les droits qu’on lui donne
Une clé d’API n’est pas un mot de passe qui ouvrirait tout : c’est un porteur de permissions. Selon la façon dont elle a été créée, la même clé peut se limiter à lire une balance ou autoriser la suppression d’une facture. Le travail de sécurité se fait au moment de créer la clé, pas après.
Pennylane est le meilleur élève. Ses scopes suivent pour l’essentiel une convention lisible : un scope en readonly ne donne accès qu’aux appels de lecture, un scope en all ouvre la lecture, l’écriture et la suppression. Le principe du moindre privilège y est nommément invoqué et l’API répond 403 quand le scope manque. La création d’un jeton fait choisir entre lecture seule et lecture-écriture, et fixer une validité, jusqu’à illimitée.
Qonto contredit l’intuition. Les scopes existent, mais uniquement pour OAuth 2.0. Une clé d’API n’a pas de portée réglable : il n’y a pas de clé Qonto en lecture seule, et la documentation liste la création de virements internes parmi les appels qu’elle autorise. Le virement SEPA sortant, en revanche, échappe à la clé : sa spécification n’accepte que OAuth 2.0 avec le périmètre de paiement, et la table d’accès aux points de terminaison ne comporte aucune ligne pour cet appel. Une clé d’API ouvre donc les virements entre comptes d’une même organisation, pas les virements vers un tiers. Sur le circuit OAuth, l’authentification forte s’ajoute, mais elle tombe dès qu’un bénéficiaire est marqué de confiance, et la double validation n’existe que si l’organisation a configuré une politique de double approbation.
Shopify est entre les deux, avec une granularité forte. Chaque famille de ressources a un scope de lecture et un scope d’écriture : un jeton portant seulement le scope de contenu atteint les articles, blogs, pages et commentaires, ni produits, ni commandes, ni clients. Une application ne doit demander que le minimum de données nécessaire, afin de réduire le risque si le jeton fuite.
| Éditeur | Clé à portée restreinte | Lecture seule possible | Environnement de test | Rotation de la clé |
|---|---|---|---|---|
| Pennylane | Oui, scopes documentés par ressource | Oui, choix explicite à la création du jeton | Oui, compte de sandbox distinct à créer depuis le profil, sur le même hôte | Jetons multiples nommés, expiration réglable, suppression unitaire |
| Qonto | Non pour une clé d’API : les scopes n’existent que pour OAuth 2.0 | Non, et les virements internes restent accessibles ; les virements sortants, non | Oui, hôte de test dédié avec en-tête de préproduction | Une seule clé par organisation, la régénérer coupe toutes les intégrations |
| Shopify | Oui, un scope de lecture et un scope d’écriture par famille de ressources | Oui, un scope de lecture seule suffit à interroger sans modifier | Oui, boutique de développement, sans transaction réelle | Révoquer le secret client invalide les jetons qui en dépendent |
Coller sa clé dans le chat ou dans un fichier ?
La consigne habituelle est de ne jamais coller une clé dans la conversation, de l’écrire dans un fichier et de ne communiquer que le chemin. Le geste est juste, l’explication trompeuse.
Car un agent qui lit un fichier fait entrer son contenu dans la conversation. La documentation décrit la fenêtre de contexte comme contenant l’historique et le contenu des fichiers, et indique que Claude Code envoie des données sur le réseau pour interroger le modèle. Une clé lue depuis un fichier part donc chez le fournisseur du modèle exactement comme si elle avait été tapée dans le chat. Anthropic documente chaque maillon séparément, et va même plus loin : la page consacrée au dossier de configuration précise que si un outil lit un fichier .env ou qu’une commande affiche un identifiant, cette valeur est écrite dans la transcription de session, et recommande une règle de refus sur les fichiers d’identifiants. Aucune page ne relie toutefois ce constat à la transmission réseau : la conclusion reste une déduction, pas une phrase officielle.
Rien ne permet de compter sur un filtrage automatique, pour deux raisons. Le caviardage des motifs connus de clés est documenté pour trois chemins seulement : le partage d’une transcription de session, les rapports d’erreur, et l’archive locale de retour d’expérience chez un fournisseur tiers. Le retour envoyé directement à Anthropic, lui, est décrit comme une copie de l’historique de conversation, code inclus, sans mention de caviardage. Rien n’indique un caviardage équivalent sur les requêtes ordinaires vers le modèle, et l’absence de garantie n’est pas une garantie d’absence. Par ailleurs, les transcriptions de session sont stockées en clair sur le poste, trente jours par défaut.
Ce qu’il ne fait pas : empêcher la transmission de la clé. Dès qu’elle est lue, elle circule. Ce qu’il fait : la clé ne reste pas figée dans un historique partagé ou exporté ; elle se remplace en modifiant un seul fichier ; et ce fichier peut être exclu du dépôt, ce qui évite la fuite la plus fréquente, le commit accidentel.
Comment protéger une clé d’API en pratique ?
Le mécanisme dédié est documenté : Claude Code prend en charge l’expansion de variables d’environnement dans .mcp.json, avec les syntaxes ${VAR} et ${VAR:-valeur_par_defaut}, applicables notamment aux en-têtes HTTP. La documentation y voit le moyen de partager une configuration d’équipe tout en gardant hors du fichier les valeurs sensibles telles que les clés d’API. L’exemple officiel écrit un en-tête d’autorisation valant Bearer suivi de ${API_KEY} : la valeur reste dans l’environnement.
Deux précisions évitent un contresens. La portée projet de ce fichier est conçue pour être versionnée, d’où l’obligation d’y mettre une variable et non une valeur ; la portée locale, hors dépôt, est recommandée pour les serveurs dont les identifiants n’ont rien à faire dans un gestionnaire de versions. Surtout, ce mécanisme appartient à la configuration des serveurs MCP, fichier .mcp.json et entrées de portée locale ou utilisateur : il n’est pas documenté pour la clé env du fichier de réglages, qui prend des valeurs littérales.
Les éditeurs sont d’inégale précision. Pennylane est le plus explicite : gestionnaire de secrets, jamais de partage public ni de mise en gestionnaire de versions, rotation périodique, révocation des jetons inutiles. Shopify est aussi net : secret dans un fichier d’environnement, fichier exclu du versionnage, jamais de secret committé, et rotation régulière parce que des secrets finissent accidentellement dans un dépôt. Qonto est le plus pauvre : garder les identifiants sûrs et appeler l’API depuis un serveur.
Quelques précautions tiennent, quel que soit l’outil :
- Portée minimale. Un jeton en lecture seule quand l’éditeur le permet, et seulement les familles de ressources nécessaires.
- Environnement de test quand il existe. Hôte de préproduction chez Qonto, boutique de développement chez Shopify. Chez Pennylane, un environnement de test se crée depuis le compte et donne un second compte distinct, avec son propre jeton, mais servi par le même hôte que la production : aucun sous-domaine ne signale lequel des deux est visé, c’est donc le jeton employé qui fait la séparation.
- Rotation après usage. Un jeton créé pour une exploration se supprime quand l’exploration est finie. Chez Qonto, sachez que la régénération est destructive et globale, puisqu’il n’existe qu’une clé par organisation.
- Jamais la clé de production d’un client. Ni pour tester, ni pour dépanner, ni une seule fois.
- Refuser explicitement les outils d’écriture. La documentation du connecteur MCP de l’API recommande de mettre sur liste noire les outils d’écriture ou destructeurs quand on construit un assistant en lecture seule, ou quand une confirmation humaine doit précéder tout changement d’état.
- Interdire la lecture du fichier de secrets par une règle de refus, avec la limite qu’énonce la documentation : ces règles couvrent les outils de fichiers intégrés et les commandes de lecture reconnues dans le shell, mais pas un sous-processus qui ouvrirait le fichier lui-même, un script Python ou Node par exemple. Pour un blocage au niveau du système, la documentation renvoie au bac à sable.
- Vérifier ce que prévoit la politique de confidentialité du fournisseur avant d’envoyer quoi que ce soit, la clé comme les données qu’elle ouvre.
Ce que cela engage pour un cabinet
Brancher un outil sur les données d’un client n’est pas un choix technique, c’est un engagement professionnel. Le secret professionnel, la base légale du traitement et la sous-traitance au sens du RGPD sont traités dans Claude, RGPD et secret professionnel en cabinet comptable.
Restent les éléments vérifiables côté fournisseur. Pour les produits commerciaux, la politique de confidentialité est formulée ainsi : par défaut, Anthropic n’utilise pas les entrées ni les sorties des produits commerciaux pour entraîner ses modèles. Des exceptions sont prévues. Sur les plans grand public, l’usage dépend d’un réglage d’amélioration du modèle que l’utilisateur contrôle. La rétention zéro n’est pas incluse dans le plan Enterprise standard : elle s’active par organisation après vérification d’éligibilité, et le connecteur MCP côté API n’en est pas couvert.
Les services connectés traitent les données sur leur propre infrastructure, selon leurs propres conditions, qui peuvent se situer hors des États-Unis. Deux fournisseurs se superposent, celui du modèle et celui du logiciel métier. Aucun engagement contractuel ne doit être supposé sans avoir été lu.

Brancher Claude sur vos logiciels sans exposer vos données ? Max Compta, expert-comptable mémorialiste, accompagne entrepreneurs, indépendants et investisseurs pour choisir la bonne voie de connexion, créer des clés d’API à portée minimale et cadrer ce que l’outil peut réellement lire ou modifier.
Références officielles
- Anthropic - Use connectors to extend Claude’s capabilities (définition, annuaire, avertissements)
- Anthropic - Get started with custom connectors using remote MCP (plans, limite du plan gratuit, Owners)
- Anthropic - Authentication for connectors (types d’authentification, clé en en-tête, jeton dans l’URL)
- Anthropic - MCP connector (côté API, liste noire d’outils, rétention)
- Anthropic - Set up Claude Code (comptes acceptés : Pro, Max, Team, Enterprise, Console)
- Anthropic - Connect Claude Code to tools via MCP (portées, expansion de variables dans .mcp.json)
- Anthropic - Claude Code security (approbation de curl, stockage des identifiants, bac à sable)
- Anthropic - Claude Code data usage (flux réseau, caviardage, rétention, transcriptions locales)
- Anthropic - Is my data used for model training (produits commerciaux, formulation par défaut)
- Model Context Protocol - Governance (Linux Foundation, licence Apache 2.0, gouvernance ouverte)
- Pennylane - Scopes (moindre privilège, convention readonly et all, erreur 403)
- Pennylane - Generating my API token (lecture seule ou lecture-écriture, expiration, stockage des jetons)
- Qonto - API key authentication (en-tête d’authentification, régénération de la clé)
- Qonto - Available scopes (scopes réservés à OAuth 2.0, scopes sensibles)
- Qonto - Sandbox access (hôte de préproduction dédié, en-tête de staging)
- Shopify - API access scopes (paires read et write, minimum de données nécessaire)
- Shopify - Get API access tokens (fichier d’environnement, exclusion du versionnage, expiration)
- Shopify - Rotate or revoke client credentials (pourquoi et comment faire tourner un secret)
Questions fréquentes
Faut-il un abonnement particulier pour brancher Claude sur une API ?
Peut-on créer une clé d’API en lecture seule chez Pennylane, Qonto et Shopify ?
Mettre sa clé d’API dans un fichier plutôt que dans le chat protège-t-il la clé ?
Comment stocker une clé d’API sans l’écrire en clair dans un fichier versionné ?
Anthropic entraîne-t-il ses modèles sur les données envoyées via une API branchée ?
Un cabinet comptable peut-il brancher Claude sur les outils d’un client ?
La démonstration en vidéo
Claude branché sur un outil métier, en conditions réelles.
S’abonner à Max Compta