Dépendre d'un prestataire qui détient vos accès : le risque invisible de l'automatisation en PME en 2026

Le problème n'apparaît jamais quand tout va bien. Il apparaît le lundi matin où vous décidez de changer de prestataire. Vous demandez vos accès. On vous répond que « les scénarios sont sur notre compte », que « la base est chez nous », que « la migration, c'est un devis à part ». Et là, vous comprenez : ce que vous pensiez posséder, vous ne faisiez que le louer.

C'est l'erreur la plus coûteuse de l'automatisation en PME, et la plus discrète. On installe un système de no-code IA — relance de devis, prospection, prise de rendez-vous, publication de contenu — et on ne se demande jamais qui, exactement, détient les clés. Tant que le prestataire est là, ça tourne. Le jour où la relation se termine, vous découvrez le vrai prix de la dépendance.

Reconnaître une dépendance à un prestataire qui détient vos accès

Vous êtes dépendant quand la coupure du prestataire coupe aussi votre système, et que vous ne pouvez rien y faire seul. Le symptôme est simple : si vous ne savez pas vous connecter, vous-même, aujourd'hui, à chaque outil qui fait tourner votre automatisation, alors ce n'est pas votre système.

Voici les signaux concrets, dans l'ordre de gravité :

• Vous n'avez aucun mot de passe. Tous les accès passent par le prestataire. Vous ne recevez que des rapports.
• Les comptes sont au nom du prestataire. Le compte Make, Airtable, Brevo ou HubSpot qui fait fonctionner votre relance est ouvert avec l'adresse e-mail de l'agence, pas la vôtre.
• La facturation des outils passe par lui. Vous payez le prestataire, qui paie les abonnements. Vous ne voyez jamais la facture Zapier ou Notion.
• Vous ne savez pas ce qui tourne. Combien de scénarios ? Quelles données stockées où ? Personne chez vous ne peut répondre.
• La demande d'export tombe dans le vide. Vous avez déjà demandé « une sauvegarde de tout » et vous n'avez jamais rien reçu de complet.

Un seul de ces signaux mérite votre attention. Trois, et vous êtes déjà pieds et poings liés — sans l'avoir décidé.

Ce que la dépendance coûte le jour de la rupture

Le jour où vous voulez récupérer votre système, la dépendance se paie de trois manières simultanées.

La donnée que vous récupérez, et celle que vous ne récupérez pas. Le droit à la portabilité prévu à l'article 20 du RGPD, applicable depuis le 25 mai 2018, vous permet de récupérer les données que vous avez fournies, dans un format structuré et lisible par machine — lorsque le traitement repose sur votre consentement ou un contrat. Utile pour votre base clients. Mais ce droit ne couvre pas vos scénarios, vos automatisations, vos règles internes ni vos paramétrages. Autrement dit : vous récupérez peut-être la liste de vos prospects. Vous ne récupérez pas la machine qui les relançait.

Aucune source officielle ne publie de chiffre sur le coût moyen d'une telle rupture pour une PME — ni sur la durée d'indisponibilité, ni sur le prix d'une migration. C'est précisément ce qui rend ce risque invisible : il n'a pas d'étiquette. Mais l'ordre de grandeur se reconstitue facilement.

Un exemple chiffré, hypothèses explicites. Prenons un cabinet de conseil de 12 personnes dont la relance de devis est automatisée par un prestataire. Hypothèses : la relance génère en moyenne 4 rendez-vous par mois, chaque rendez-vous vaut en moyenne 2 500 € de mission signée avec un taux de transformation de 25 %, soit 1 rendez-vous transformé par mois. Le système reste à l'arrêt 6 semaines pendant qu'on reconstruit tout ailleurs. Résultat : environ 1,5 mission perdue, soit près de 3 750 € de chiffre d'affaires manqué. Ajoutez 2 à 3 jours de travail interne pour retrouver les mots de passe, réécrire les scénarios, tester. Le montant exact dépend de votre activité — mais la logique, elle, ne varie pas : plus le système est utile, plus sa coupure fait mal.

Le rapport de force au moment de partir. Un prestataire qui détient tout n'a aucune raison de faciliter votre départ. Ce n'est pas de la malveillance, c'est de la structure : quand la sortie est douloureuse pour vous, elle devient un levier pour lui.

Empiler des outils sans propriétaire : la variante silencieuse

La dépendance ne vient pas toujours d'un contrat. Elle vient souvent d'un empilement. On ajoute Make, puis Airtable, puis Brevo, puis un agent IA, chacun réglé par une personne différente, à un moment différent, sur un compte différent. Personne ne tient la carte de l'ensemble.

Le jour où la personne qui « savait » s'en va — freelance, stagiaire, salarié —, plus personne ne sait pourquoi la relance s'arrête ni où regarder. C'est la même impasse que la dépendance à une agence, en pire : il n'y a même plus d'interlocuteur à appeler.

La règle est nette : tout système d'automatisation doit avoir un propriétaire nommé et une carte à jour de ses composants. Cette carte tient sur une page : quel outil, quel compte, quelle donnée, à quoi ça sert. Sans elle, vous n'avez pas un système. Vous avez une accumulation d'outils que personne ne contrôle.

Ce que le cadre RGPD impose déjà à votre prestataire

Vous n'êtes pas sans protection. Le RGPD encadre précisément la relation avec un prestataire qui accède à vos données — et beaucoup de dirigeants ignorent l'étendue de leurs droits.

• Le prestataire n'agit que sur vos instructions. Selon l'article 29 du RGPD expliqué par la CNIL, un sous-traitant ne peut traiter vos données personnelles que sur instruction du responsable du traitement — vous —, sauf obligation légale. Applicable depuis le 25 mai 2018.
• Il ne peut pas réutiliser vos données pour son compte sans une autorisation écrite de votre part et sans que ce soit compatible avec le traitement initial, rappelle la CNIL dans son encadrement de la sous-traitance.
• Vous devez pouvoir vérifier ses garanties. Dans sa page « Sécurité : Gérer la sous-traitance » du 14 mars 2024, la CNIL recommande de prévoir des moyens de contrôle — audits de sécurité, visites d'installations — pour vérifier l'effectivité des garanties du prestataire.
• Chaque utilisateur doit avoir son propre compte. Dans sa page du 22 avril 2025 sur la compromission de données chez un sous-traitant, la CNIL recommande d'éviter le partage de comptes et de mots de passe et d'attribuer un compte personnel à chacun, pour pouvoir tracer un incident.

Le contrat de sous-traitance prévu aux articles 28 et suivants du RGPD n'est pas une formalité : c'est votre filet. L'application de ces règles dépend de votre situation ; référez-vous aux pages de la CNIL citées et, en cas de doute, à un conseil.

Récupérer ses accès et changer de prestataire sans tout perdre

La meilleure façon de récupérer ses accès, c'est de ne les avoir jamais cédés. Mais si vous êtes déjà engagé, voici l'ordre dans lequel reprendre la main.

1. Faire l'inventaire

Listez chaque outil qui fait tourner une automatisation, le nom du compte, l'adresse e-mail associée, et qui paie l'abonnement. Cette page est votre point de départ. Si vous ne pouvez pas la remplir seul, c'est déjà la preuve du problème.

2. Rapatrier les comptes à votre nom

Chaque compte doit être ouvert avec une adresse e-mail de votre entreprise, la facturation sur votre carte, et l'administration entre vos mains. Le prestataire peut rester utilisateur invité — vous restez propriétaire. Ce sont vos comptes au nom de l'entreprise, pas les siens.

3. Exercer votre droit à la portabilité pour les données

Demandez l'export de vos données clients et prospects dans un format structuré. C'est votre droit. Notez sa limite : il ne vous rendra pas les scénarios.

4. Documenter avant de couper

Avant toute rupture, faites décrire par écrit ce que fait chaque automatisation. Sans cette carte, vous repartez de zéro chez le suivant.

Nous voyons régulièrement ce cas : une entreprise qui quitte une agence SEO découvre qu'elle ne possède ni son historique, ni ses comptes, ni ses contenus. C'est exactement la logique que nous avons appliquée en installant un moteur interne chez ENEART, centre de formation Qualiopi : le passage d'une agence à un système possédé, avec des comptes détenus par le client.

Pourquoi un système possédé neutralise le risque

Un système possédé, c'est un système dont vous détenez les comptes, les données et les accès — à votre nom, dès le premier jour. Le prestataire installe, pilote, améliore. Il ne détient rien. Vous pouvez, à tout moment, ouvrir chaque outil et voir ce qui tourne.

C'est le principe sur lequel nous installons nos moteurs. Chez SNA — Société Normande d'Agencement, à Caen, comme chez chaque client, les accès, les données et les comptes sont ouverts au nom de l'entreprise. Le Moteur de Visibilité publie un article optimisé chaque jour ouvré, dans la voix de la marque, sur les comptes du client — et le client reste propriétaire de son site, de ses contenus et de son historique. La preuve la plus directe : upora.com est lui-même produit par le Moteur. Ce que vous lisez est le produit.

La différence tient en une phrase : dans un système d'automatisation possédé, si vous changez de prestataire demain, vous ne perdez ni vos données, ni vos comptes, ni le travail accompli. Vous changez de pilote, pas de machine.

Ce qu'il faut retenir

• Vous ne voyez la dépendance qu'au moment de partir : le test est simple — pouvez-vous, seul, vous connecter aujourd'hui à chaque outil de votre automatisation ?
• Le RGPD vous rend vos données (article 20, portabilité, depuis le 25 mai 2018) mais pas vos scénarios : seuls des comptes ouverts à votre nom protègent l'ensemble.
• Un système possédé — comptes, données et accès au nom de l'entreprise — supprime le rapport de force : vous changez de prestataire sans changer de machine.

Pour savoir où vous en êtes, commencez par un audit gratuit SEO & GEO de votre site : nous vérifions notamment qui détient réellement vos accès et vos comptes. Si le sujet mérite d'être creusé, réservez un appel de 20 minutes — on regarde votre cas, sans jargon.

Vous conseillez des dirigeants ? Parlons partenariat.

UPORA — des systèmes qui travaillent à votre place.