À l'heure où les piratages de la DGFiP rappellent la sensibilité de nos données financières, je m'attends à ce que les services de comptabilité prennent la limitation des accès au sérieux. En lisant le guide de connexion de Dougs à Stripe, je découvre pourtant une procédure qui me dérange profondément.
Pour synchroniser les opérations, Dougs demande une "clé secrète de production". Le service reconnaît que Stripe recommande les clés restreintes, mais explique ne pas les prendre en charge. Cette différence mérite une explication beaucoup plus sérieuse qu'une invitation à copier-coller un identifiant.
Ce que Dougs demande pour connecter Stripe
En associant mes nouvelles données comptables dans Dougs, il m'a été demandé de synchroniser mon compte Dougs à Stripe, pour lire les transactions : que ce soient celles des flammes, ou celles de mes compléments alimentaires. Mais la procédure est immédiatement un red flag.
Dans son guide de connexion à Stripe, consulté le 1er octobre 2026, Dougs demande une clé commençant par sk_live_. Il s'agit d'une clé secrète permettant d'agir sur les données réelles du compte : il s'agit donc d'un accès complet.
Après avoir rappelé la recommandation de Stripe en faveur des clés restreintes pour les services tiers, le guide précise :
"Son usage n'étant actuellement pas possible sur Dougs, nous vous recommandons donc de passer par la clé secrète."
La présentation du fonctionnement de la synchronisation décrit un besoin compréhensible : retrouver les encaissements, distinguer les commissions et rapprocher les mouvements avec le compte bancaire. Automatiser cette récupération apporte un vrai confort. La question concerne les permissions nécessaires pour y parvenir.
Clé secrète et clé restreinte : des permissions différentes
Une API permet à des logiciels de communiquer entre eux. Dans ce contexte, la clé sert à autoriser un logiciel à consulter des données ou à effectuer des opérations. Il faut donc s'intéresser à ce qu'elle permet réellement de faire.
Selon la documentation de Stripe, une clé secrète standard dispose de permissions non restreintes sur ses API. Elle ouvre un accès très étendu, qui dépasse la simple consultation comptable. Stripe déconseille son utilisation pour les nouveaux usages et recommande de faire évoluer les intégrations existantes vers des clés restreintes. C'est donc quelque chose clairement identifié par Stripe comme "à éviter".
Une clé restreinte permet de choisir les ressources accessibles et les permissions associées : aucune autorisation, lecture ou écriture. On peut ainsi autoriser la consultation de certaines données sans permettre leur modification.
Le fait qu'un logiciel prévoie seulement de lire des opérations ne limite pas automatiquement les pouvoirs de la clé qu'il reçoit. Cette limite doit être imposée par les permissions. Une promesse d'utilisation et une restriction technique apportent des garanties différentes.
Une clé restreinte exige également une configuration sérieuse. Lui accorder toutes les permissions disponibles fait perdre une grande partie de son intérêt. Même limitée à la lecture, elle peut exposer les données auxquelles elle donne accès si elle est dérobée.
Les piratages de la DGFiP rappellent pourquoi ces limites comptent
La DGFiP a confirmé des vols de données à la suite d'accès illégitimes à son système d'information intervenus en juin, juillet et août 2026. Elle précise que le site impots.gouv.fr et les espaces des usagers n'ont pas été compromis. Cette distinction compte pour comprendre les faits. Ces incidents devraient surtout nous pousser à examiner les conséquences possibles d'un accès détourné. Lorsqu'une entreprise confie une clé à un prestataire, elle doit aussi envisager ce qui se passe si cette clé lui échappe.
Stripe explique dans ses recommandations de sécurité qu'une clé secrète compromise peut notamment permettre des débits non autorisés, l'accès à des données clients ou la perturbation d'une intégration. Réduire les permissions sert précisément à limiter les conséquences d'un tel incident.
C'est le principe du moindre privilège : chaque personne et chaque système reçoit uniquement les autorisations nécessaires à sa mission. La confiance accordée à un prestataire ne dispense pas de cette précaution.
Une présentation qui banalise le risque
Dire que Stripe recommande les clés restreintes est exact. Ce qui me pose problème, c'est la façon dont le guide enchaîne immédiatement sur une autre solution, sans expliquer l'élargissement des permissions qu'elle implique.
Un dirigeant qui cherche à connecter sa comptabilité n'a pas forcément les connaissances nécessaires pour interpréter cette différence. Il suit les instructions du professionnel auquel il confie une partie sensible de son activité. J'attends donc de ce professionnel qu'il explique clairement ce qu'il demande.
Je trouve cette présentation trompeuse par omission. Elle ramène un choix de sécurité à une contrainte de compatibilité. Le client peut comprendre qu'il existe deux méthodes équivalentes et qu'il suffit d'utiliser celle qui fonctionne, alors que les conséquences d'une compromission peuvent être très différentes.
La présentation de Dougs laisse supposer que les deux méthodes sont similaires
Une intégration ancienne peut demander du travail pour évoluer. Je peux entendre cette difficulté. J'attends alors une explication des permissions nécessaires, des protections mises en place et un calendrier prévu pour réduire les accès.
Cette critique porte sur une procédure publique. Elle ne permet pas de connaître les conditions de stockage des clés chez Dougs, ni d'affirmer qu'elles ont été compromises.
Ce que j'attends d'un service de comptabilité
Avant de confier un accès aussi sensible, je veux comprendre quelles données sont nécessaires et pourquoi. Si le service a besoin de permissions d'écriture, j'attends qu'il indique les opérations concernées et leur utilité. Pour un outil chargé de récupérer des opérations, une connexion limitée aux ressources utiles me paraît être l'objectif normal. Les éventuelles exceptions doivent être expliquées. Le client doit pouvoir apprécier ce qu'il autorise, au lieu de découvrir après coup la portée de la clé transmise.
J'attends aussi une procédure claire pour retirer l'accès à la fin de la relation, identifier la clé utilisée et la remplacer si nécessaire. Un accès sensible doit pouvoir être suivi pendant toute sa durée de vie.
Pour les personnes ayant déjà transmis une clé, il faut commencer par identifier les intégrations qui l'utilisent et demander au prestataire quelles solutions il prend en charge. Une révocation sans préparation peut interrompre les services qui en dépendent. Si une compromission est suspectée, Stripe recommande en revanche de remplacer la clé immédiatement.
Cette attention aux autorisations rejoint une question que j'abordais déjà dans mon rappel sur la vie privée numérique : le confort apporté par un service mérite toujours d'être mis en regard des accès qu'on lui accorde.
La confiance se construit aussi dans les accès qu'on ne demande pas
On utilise la technologie pour simplifier mon quotidien. Je comprends parfaitement l'intérêt de connecter un outil comptable à une plateforme de paiement, mais ce confort doit s'accompagner d'une exigence sur les permissions accordées. En tant que professionnels, nous avons l'obligation de rappeler à nos prestataires que les solutions qu'ils choisissent ne sont pas satisfaisantes, lorsque c'est le cas.
Lorsqu'un prestataire reconnaît que la méthode recommandée n'est pas compatible avec son service, j'attends qu'il travaille à corriger cette limite et qu'il en explique les conséquences à ses clients.
La confiance se construit aussi dans les permissions qu'on accepte de ne pas demander. Pour un service auquel nous confions notre comptabilité, cela me semble être une exigence élémentaire.