Expertise · Prestataires & intégrations

Prestataires & intégrations : savez-vous ce qui casse si vous débranchez une brique ?

Paiement, cloud, authentification, API, support, logistique ou IA : chaque service externe peut devenir une dépendance de votre produit. Lawnch identifie ce que le prestataire peut arrêter, les données et accès qu’il détient, les engagements réellement obtenus, et la manière de reprendre la main si l’intégration change ou disparaît.

Cartographier mes dépendances

Tester une intégration

API · SaaS · Cloud · Paiement · SLA · Données · Sous-traitants · Incidents · Réversibilité

Certaines lignes de code donnent à une autre entreprise le pouvoir d’arrêter une partie de votre produit.

Une plateforme moderne peut utiliser des dizaines de services externes. L’utilisateur ne voit généralement ni l’API de paiement, ni le fournisseur d’authentification, ni le cloud, ni le moteur d’e-mail, ni le service antifraude, ni l’outil de support, ni l’API d’IA. Il voit simplement votre plateforme fonctionner — ou ne plus fonctionner.

Ce que le prestataire exécute

Paiement, connexion, stockage, calcul, livraison, recherche, communication ou génération.

Que devient votre produit si cette fonction s’arrête ?

Ce que vous lui confiez

Données, identifiants, clés API, contenu, accès administrateur, argent, commandes ou infrastructure.

Que peut-il encore voir ou conserver après la fin du contrat ?

Ce qui vous rend dépendant

Format propriétaire, volume historique, intégration profonde, absence d’export, configuration complexe ou absence d’alternative.

Combien de jours faudrait-il réellement pour changer ?

La criticité d’un prestataire ne dépend donc pas de son prix. Elle dépend de ce que votre entreprise ne peut plus faire sans lui.

Débranchez mentalement un prestataire pendant 24 heures.

Choisissez ce qui disparaît. Le bon contrat commence souvent par les conséquences de cette disparition.

Les utilisateurs peuvent encore commander. Mais peuvent-ils payer, être remboursés ou recevoir ce qui leur est dû ?

Les questions

qui reçoit les fonds ?
qui fournit réellement le service de paiement ?
quels flux sont bloqués ?
les remboursements restent-ils possibles ?
que deviennent les transactions en cours ?
quelles données peuvent être récupérées ?
quels comptes ou soldes existent encore ?
combien de temps faut-il pour basculer vers un autre prestataire ?

Recourir à un prestataire agréé ne règle pas à lui seul la qualification du modèle de plateforme. Voir le droit des marketplaces lorsque la plateforme encaisse dans une relation impliquant des tiers.

Votre plateforme fonctionne. Personne ne peut s’y connecter.

Les questions

le fournisseur contrôle-t-il la seule méthode d’authentification ?
avez-vous encore accès aux identifiants nécessaires ?
les comptes peuvent-ils être migrés ?
existe-t-il une méthode de secours ?
que se passe-t-il en cas de suspension de votre compte fournisseur ?

Une dépendance invisible peut bloquer la totalité du produit sans héberger une seule fonctionnalité métier.

Le produit entier dépend parfois d’un seul compte administrateur.

Les questions

où sont les données ?
quels services sont spécifiques au fournisseur ?
quels éléments sont exportables, et dans quels formats ?
existe-t-il une architecture documentée ?
une migration a-t-elle déjà été testée ?
quels délais de bascule sont prévus ?
le Data Act s’applique-t-il au service concerné ?

« Nous avons des sauvegardes » et « nous pouvons changer de cloud » sont deux affirmations différentes.

L’intégration répond toujours. Mais son fournisseur change les règles demain.

Les questions

quel préavis avant une modification ?
quelle politique de versions ?
quelles fonctionnalités sont garanties par le contrat, et lesquelles seulement décrites dans la documentation ?
combien de temps l’ancienne version reste-t-elle disponible ?
existe-t-il un environnement de test ?
l’intégration a-t-elle une alternative ?

Une API peut casser juridiquement avant de casser techniquement : prix doublé, quota réduit, réponse modifiée, fonction retirée.

Vous connaissez vos utilisateurs. Mais pouvez-vous encore leur parler ?

Les questions

peut-on exporter l’historique ?
les pièces jointes sont-elles récupérables ?
les modèles et automatisations peuvent-ils être répliqués ?
quelle information reste chez le prestataire ?
comment migrer les conversations ouvertes ?

E-mail transactionnel, SMS, CRM, helpdesk : ce sont souvent les outils dont l’historique est le plus difficile à récupérer sous une forme exploitable.

Les commandes existent toujours. L’exécution physique ne suit plus.

Les questions

qui détient les données de stock ?
qui détient la preuve d’expédition ?
quelles commandes sont déjà parties ?
comment traiter les retours ?
comment récupérer les données historiques ?
qui informe l’utilisateur ?

Les obligations envers l’acheteur dépendent de qui contracte avec lui : un vendeur qui vend lui-même et un intermédiaire ne sont pas dans la même situation. Voir le commerce électronique.

Votre fonctionnalité IA disparaît avec une clé API.

Les questions

quel fournisseur et quel modèle ?
la version peut-elle changer sans action de votre part ?
quelles données sont envoyées ?
quelles sorties sont conservées ?
existe-t-il un modèle de remplacement ?
les prompts et configurations sont-ils portables ?
une nouvelle intégration changerait-elle l’analyse au titre de l’AI Act ?

Voir l’AI Act · le RGPD · la propriété intellectuelle.

Si l’équipe sait parfaitement comment intégrer un prestataire mais ne sait pas comment le débrancher, l’intégration n’est pas terminée.

Une panne n’a pas la même portée selon ce que le prestataire touche.

Pour chaque fournisseur, regardez les zones que son indisponibilité affecterait. Sélectionnez une zone.

Argent

Paiement, remboursement, reversement, facturation

Une panne ici arrête l’encaissement, mais aussi les remboursements et les reversements dus à des tiers. Les conséquences sortent du produit : elles touchent la trésorerie, les vendeurs et les obligations envers les acheteurs.

La question à poser : pendant combien de temps l’entreprise peut-elle fonctionner sans encaisser, et sans pouvoir rembourser ?

Accès

Connexion, comptes, identité, permissions

C’est le rayon le plus sous-estimé. Une panne d’authentification ne dégrade pas le service : elle le rend inaccessible, y compris souvent aux équipes internes.

La question à poser : existe-t-il un chemin de secours qui ne passe pas par ce fournisseur ?

Données

Stockage, CRM, historiques, fichiers, journaux

La perte d’accès n’est pas la perte des données, mais elle produit souvent le même effet opérationnel. Et c’est le rayon où la sortie coûte le plus cher, parce que le volume accumulé ne se reconstitue pas.

La question à poser : quelle est la dernière fois que l’export a été ouvert et vérifié ?

Parcours client

Commande, recherche, livraison, support

Ici la panne est immédiatement visible par l’utilisateur. L’enjeu devient autant l’information des personnes concernées que la réparation technique.

La question à poser : qui informe les utilisateurs, dans quel délai, et avec quel message ?

Logique du produit

Scoring, recommandation, validation, automatisation, IA

La plateforme continue de fonctionner, mais elle décide moins bien — ou plus du tout. Ce sont les pannes les plus difficiles à détecter, parce que rien ne s’affiche en erreur.

La question à poser : existe-t-il un mode dégradé, et qui décide de l’activer ?

Communication

E-mail, SMS, notifications, support

Les messages transactionnels — confirmation, réinitialisation de mot de passe, code de vérification — sont souvent traités comme accessoires alors qu’ils conditionnent des parcours entiers.

La question à poser : quels parcours s’arrêtent si aucun e-mail ne part pendant six heures ?

Un fournisseur qui touche une seule zone non critique ne crée pas la même dépendance qu’une intégration présente dans quatre fonctions essentielles. Le contrat doit être proportionné au rayon réel.

Votre fournisseur a lui aussi des fournisseurs.

Signer avec une entreprise ne signifie pas que cette entreprise réalise seule toute la prestation. Descendez la chaîne, niveau par niveau.

Celui avec qui vous signez

C’est le seul acteur que votre contrat désigne, et souvent le seul que votre équipe connaisse. Il n’exécute pourtant pas nécessairement seul toute la prestation.

À vérifier

que fait-il réellement lui-même ?
que confie-t-il à d’autres ?
publie-t-il la liste de ses sous-traitants ?

Celui qu’il a choisi

Traitement de paiement, envoi d’e-mails, modération, hébergement de fichiers : beaucoup de briques du service que vous achetez sont elles-mêmes achetées ailleurs.

À vérifier

lesquels sont critiques pour votre usage ?
accèdent-ils aux données que vous confiez ?
êtes-vous informé lorsqu’ils changent ?

Celui qui héberge tout le monde

Une part importante des fournisseurs repose sur un petit nombre d’infrastructures. Deux prestataires que vous croyez indépendants peuvent tomber ensemble.

À vérifier

où le service est-il hébergé ?
dans quelles régions ?
vos différents fournisseurs partagent-ils la même infrastructure ?

Celui dont personne ne parle

Au-delà du deuxième niveau, la chaîne devient rarement documentée. C’est pourtant là que se trouvent parfois les transferts hors Union européenne.

À vérifier

la chaîne est-elle documentée au-delà du premier niveau ?
des données sortent-elles de l’Union européenne ?
quel encadrement s’applique alors ?

Lorsqu’un prestataire agit comme sous-traitant au sens du RGPD, le recours à un autre sous-traitant doit être encadré. En cas d’autorisation générale, le responsable de traitement doit notamment être informé des changements envisagés afin de pouvoir exercer le droit d’objection prévu par le texte. Ce n’est pas un droit de veto sur tout fournisseur de la chaîne. Voir le RGPD des plateformes.

Ce qui reste quand on descend jusqu’en bas

Réseau, CDN, résolution de noms, certificats : des couches que personne ne contractualise et dont l’indisponibilité arrête pourtant tout le monde en même temps.

À vérifier

votre plan de continuité en tient-il compte ?
avez-vous une visibilité sur ces composants ?
que dit le contrat lorsque la cause est située à ce niveau ?

Quel document dit réellement ce que votre prestataire vous doit ?

Le contrat prestataire est rarement un fichier. C’est un système documentaire, dont il faut vérifier comment les couches s’articulent.

Conditions générales

Durée, responsabilité, suspension, paiement, résiliation.

Bon de commande

Service précis, prix, capacité, options souscrites.

SLA

Disponibilité et réponse aux incidents.

DPA

Données personnelles et obligations de sous-traitance lorsque c’est pertinent.

RGPD art. 28

Annexe sécurité

Mesures, notifications, audit, gestion des accès.

Liste des sous-traitants

Acteurs supplémentaires et lieux de traitement concernés.

Documentation API

Versions, quotas, formats, limites et politique de dépréciation.

Le test de contradiction

Quatre sources, quatre promesses différentes. Laquelle avez-vous réellement achetée ?

Le test de contradiction documentaire
Où c’est écrit	Ce qui est promis
La page commerciale	« 99,99 % de disponibilité. »
Le SLA	99,9 %.
Les conditions générales	Service fourni « en l’état ».
La documentation API	Certaines interfaces peuvent être supprimées à tout moment.

« 99,9 % disponible » ne vous dit pas encore combien de temps votre produit peut rester en panne.

Le pourcentage est la partie la moins informative du SLA. Six questions lui donnent son sens réel.

Les six questions qui donnent son sens à un pourcentage de disponibilité
La question	Ce qu’il faut regarder	Pourquoi cela change tout
Qu’est-ce qui est mesuré ?	Tout le service, la seule API principale, une région ?	Un SLA calculé sur un périmètre étroit peut rester tenu alors que votre fonction critique est à l’arrêt.
Sur quelle période ?	Mois, trimestre, année ?	Une panne de quatre heures pèse très différemment sur un mois et sur une année.
Quelles pannes sont exclues ?	Maintenance planifiée, erreur du client, dépendance externe, force majeure ?	Les exclusions décident souvent du résultat davantage que le pourcentage affiché.
Comment l’incident est-il détecté ?	Par le monitoring du prestataire, ou par le vôtre ?	Si seul le fournisseur constate, c’est lui qui décide de l’existence de l’incident.
Quand le chronomètre démarre-t-il ?	Au début réel, à l’ouverture du ticket, à la reconnaissance par le fournisseur ?	Entre la première erreur et la reconnaissance, il peut s’écouler plusieurs heures non comptées.
Qu’obtenez-vous si le niveau n’est pas tenu ?	Un avoir, un remède, un droit de sortie, un simple rapport ?	Un crédit de service ne remet pas votre plateforme en ligne.

Le SLA doit être lu comme un mécanisme de continuité, pas seulement comme un mécanisme d’indemnisation.

10:07. L’intégration ne répond plus. Que dit réellement le contrat ?

•

10:07 — Première erreur

Votre monitoring détecte l’incident.

Cette heure compte-t-elle contractuellement ?

•

10:15 — Premier ticket

L’équipe ouvre un incident.

Quel canal doit être utilisé pour que le délai commence à courir ?

•

10:40 — Le prestataire reconnaît l’incident

Il confirme une dégradation sur son statut public.

Quand commence son délai de réponse ?

•

12:00 — Des utilisateurs sont touchés

Les premiers signalements arrivent au support.

Qui les informe, et avec quel message ?

•

14:30 — La cause est chez son propre fournisseur

Le prestataire indique que la panne vient d’un tiers.

Votre contrat traite-t-il différemment cette cause ?

•

17:00 — Le service revient

Le fonctionnement normal est rétabli.

Quelles informations obtenez-vous ensuite : cause, durée, impact, remédiation, rapport d’incident ?

•

Fin de mois — Le calcul

Le SLA a-t-il été violé ? Et qui doit réclamer l’avoir ou le remède ?

Un crédit qui doit être demandé et qui ne l’est jamais n’a aucun effet.

Le contrat ne doit pas seulement dire que les incidents seront traités. Il doit permettre aux équipes de savoir ce qui se passe pendant l’incident.

La rupture la plus dangereuse est parfois une nouvelle version.

Le contrat n’est pas résilié, le fournisseur n’a rien annoncé de spectaculaire, et pourtant votre intégration ne fait plus la même chose.

Quota réduit

Avant : 100 000 appels. Après : 50 000.

Votre produit fonctionne-t-il encore au même coût, et à la même vitesse ?

Changement de prix

Avant : 0,01 € par appel. Après : 0,03 €.

Existe-t-il un préavis, un plafond d’augmentation ou un droit de sortie ?

Changement de format

Un champ disparaît de la réponse.

Combien de temps l’ancienne version reste-t-elle compatible, et où cette durée est-elle écrite ?

Fonction supprimée

Le fournisseur retire une capacité utilisée dans votre flux de travail.

Était-elle contractuellement comprise dans le service, ou seulement décrite dans la documentation ?

Modèle d’IA modifié

Même point d’entrée, nouveau comportement.

La fonction doit-elle être retestée, et son analyse au titre de l’AI Act reprise ?

Voir l’AI Act des plateformes

La gestion des versions est une question contractuelle autant que technique.

« Nous hébergeons vos données » ne répond pas à la question de ce que le fournisseur peut en faire.

Accéder à des données et les utiliser sont deux choses différentes. Trois situations se rencontrent régulièrement.

Il traite uniquement pour vousIl utilise certaines données pour luiPlusieurs rôles coexistent

Le prestataire agit pour votre compte

Lorsqu’il traite des données personnelles pour le compte de la plateforme dans un traitement donné, il peut agir comme sous-traitant pour cet usage. Le cadre de l’article 28 s’applique alors à ce traitement.

À examiner

instructions documentées
finalités
mesures de sécurité
sous-traitants ultérieurs
assistance et coopération
audits
sort des données à la fin

RGPD art. 28

Le prestataire poursuit ses propres finalités

Amélioration du service, statistiques, entraînement de modèles, analyse de sécurité : ces usages ne sont pas nécessairement accessoires. Ils peuvent changer le rôle du fournisseur pour ces traitements.

À examiner

ces usages sont-ils nécessaires au service ?
quel rôle le fournisseur joue-t-il pour ces traitements ?
sur quel fondement ?
peut-on s’y opposer ou les désactiver ?

Une clause d’« amélioration du service » ne suffit pas, à elle seule, à déterminer le rôle du fournisseur ni la licéité du traitement.

Le même fournisseur, deux casquettes

Un prestataire peut être sous-traitant pour la fonction que vous lui confiez, et responsable de traitement pour ses propres usages. Ce n’est pas une anomalie : c’est une situation fréquente qu’il faut décrire.

À examiner

quels traitements relèvent de quel rôle ?
l’information des personnes en tient-elle compte ?
le contrat distingue-t-il correctement les deux ?

Le DPA ne doit pas servir à transformer artificiellement toute la relation en sous-traitance.

Le rôle se détermine traitement par traitement, à partir de ce qui est réellement fait des données. Voir le RGPD des plateformes.

Pour certains services de traitement de données, la réversibilité n’est plus seulement ce que le fournisseur accepte de négocier.

Le Data Act est applicable depuis le 12 septembre 2025. Son chapitre VI prévoit un régime spécifique pour le changement entre services de traitement de données.

Première précaution, avant toute autre : le règlement ne donne pas un droit de migration contre tout logiciel, toute API ou tout SaaS. Il faut d’abord déterminer si le service concerné entre dans ses définitions et son champ.

1Les obstacles au changement. Lorsque le régime s’applique, le fournisseur doit lever les obstacles qui empêchent le passage vers un autre fournisseur du même type de service, vers une infrastructure sur site lorsque c’est pertinent, ou vers une stratégie multi-fournisseurs.
2Le contrat doit parler de sortie. Les droits du client et les obligations du fournisseur relatifs au changement doivent être inscrits clairement dans un contrat écrit. Ce n’est plus seulement ce que le fournisseur accepte de négocier.
3Le préavis. Le régime prévoit un délai maximal de préavis pour initier le changement, qui ne doit pas dépasser deux mois. À ne pas confondre avec la durée technique de la migration.
4La période de transition. Une période transitoire maximale de trente jours constitue le principe, avec un régime particulier lorsqu’elle est techniquement irréalisable. Trente jours n’est donc pas un délai universel de migration pour toute infrastructure.
5Ce qui peut être exporté. Le contrat doit identifier les catégories de données et d’actifs numériques portables, ainsi que les exclusions prévues par le règlement.
6La récupération. Le régime prévoit également une période minimale permettant de récupérer les données après la période de transition.
7Les frais de changement. Une période transitoire existe encore à ce jour. À partir du 12 janvier 2027, les fournisseurs concernés ne pourront plus imposer de frais pour le processus de changement.

Le Data Act ne remplace pas votre plan de migration. Il change ce que le contrat et le fournisseur doivent permettre lorsque son régime s’applique.

Règl. (UE) 2023/2854, art. 23 à 31 · art. 25 · art. 29

« Vos données sont exportables. » Très bien. Avez-vous déjà ouvert l’export ?

Quoi ?: Toutes les données nécessaires sont-elles présentes, ou seulement les tables principales ?
Quel format ?: CSV, JSON, sauvegarde de base, format propriétaire ? Un format lisible n’est pas toujours un format exploitable.
Quelle structure ?: Les relations entre les données sont-elles conservées, ou faut-il les reconstruire ?
Quelles métadonnées ?: Horodatage, permissions, historique, identifiants internes : ce sont souvent eux qui manquent.
Quelle documentation ?: Une nouvelle équipe peut-elle comprendre l’export sans l’ancien prestataire ?
Combien de temps ?: Exporter, transférer, importer, vérifier, remettre en production : la somme réelle, pas la durée du téléchargement.

La portabilité juridique sans portabilité technique ne suffit pas à reprendre la main.

Une intégration critique ne devrait pas dépendre du compte personnel d’un développeur parti depuis deux ans.

Compte propriétaire

Au nom de quelle société l’abonnement existe-t-il ? Une adresse personnelle suffit à créer un point de fragilité.

Administrateurs

Qui peut modifier la configuration, et combien de personnes disposent encore de ce niveau d’accès ?

Clés API

Où sont-elles stockées, qui peut les révoquer, et que casse leur rotation ?

Facturation

Que se passe-t-il si une carte expire ou qu’un prélèvement échoue ? Certaines suspensions sont automatiques.

Récupération

Qui peut reprendre l’accès si l’administrateur principal n’est plus disponible ?

La gouvernance des accès fait partie de la continuité contractuelle.

Une certification est une information. Pas une réponse complète.

Les certifications de sécurité aident à évaluer un prestataire. Elles ne répondent pas automatiquement à ce que vous lui confiez, où les données sont traitées, quelles mesures s’appliquent à votre service, quels incidents doivent vous être notifiés, quel droit d’audit existe, ni comment la sortie fonctionne.

La certification

Assurance générale sur l’organisation du fournisseur. Elle ne dit rien de votre intégration en particulier.

Le DPA

Traitement des données personnelles, rôles, sous-traitants, sort des données.

L’annexe sécurité

Mesures réellement convenues pour votre service, et notifications attendues.

Le SLA

Performance, périmètre mesuré, conséquences.

Le plan de continuité

Fonctionnement en cas d’incident majeur, et délais de rétablissement visés.

Le contrat

Droits et obligations opposables, et ce que vous pouvez exiger.

L’objectif n’est pas d’obtenir tous les documents du fournisseur. C’est d’obtenir les preuves correspondant au risque réel de l’intégration.

Certaines entreprises ne peuvent pas traiter leur fournisseur informatique comme un simple SaaS.

Des règles sectorielles peuvent imposer des exigences supplémentaires en matière de prestataires, de continuité, de sécurité, d’audit ou de sous-traitance. Elles ne s’appliquent pas parce qu’une entreprise utilise du cloud.

DORA

Pour les entités financières entrant dans son champ, ce règlement impose une gestion spécifique des risques liés aux prestataires informatiques, un registre de certaines relations et des exigences contractuelles détaillées, renforcées pour les fonctions critiques ou importantes.

Règl. (UE) 2022/2554

Cybersécurité

Lorsque l’entreprise entre dans le champ des règles de cybersécurité applicables, la sécurité de la chaîne d’approvisionnement et des prestataires peut devenir une composante du dispositif. Le champ exact et la transposition nationale doivent être vérifiés avant d’affirmer une obligation.

Dir. (UE) 2022/2555

Paiement

Recourir à un prestataire agréé ne dispense pas de déterminer le rôle de la plateforme dans le flux financier.

Voir le droit des marketplaces

Avant d’importer dans un contrat toutes les exigences d’un régime sectoriel, vérifier d’abord si l’entreprise y est réellement soumise.

Votre fournisseur est le même. Son infrastructure, peut-être pas.

Janvier

Prestataire A, hébergé chez B

L’architecture est connue et documentée dans le contrat initial.

Mars

Un service C s’ajoute

Le prestataire enrichit son offre. Un acteur de plus accède à une partie des données.

Juin

B est remplacé par D

Le fournisseur change d’infrastructure. Votre produit ne bouge pas d’un pixel.

Septembre

D devient critique

Une partie essentielle de la prestation en dépend désormais.

Avez-vous été informé ? La localisation a-t-elle changé ? Un transfert de données est-il en cause ? Un droit d’objection existe-t-il ? La sécurité et la continuité changent-elles ? Faut-il refaire une revue ?

La gouvernance fournisseur ne s’arrête pas le jour de la signature.

Une liste de fournisseurs ne suffit pas. Il faut savoir ce que chacun peut arrêter.

Treize champs suffisent à transformer un tableur de factures en outil de décision.

Prestataire: Le nom, et l’entité juridique avec laquelle vous avez réellement contracté.
Fonction: Paiement, cloud, support, authentification, IA…
Propriétaire interne: L’équipe responsable de la relation et de la configuration.
Criticité: Ce qui s’arrête en cas de panne, et au bout de combien de temps.
Données: Les catégories concernées, et si des données personnelles sont en cause.
Accès: Les privilèges détenus : lecture, écriture, administration.
Sous-traitants: Les principaux acteurs utiles à connaître derrière le prestataire.
SLA: L’engagement principal, et ce qu’il déclenche.
Alternative: Existe-t-elle, et a-t-elle été identifiée précisément ?
Délai de remplacement: Une estimation réaliste, pas optimiste.
Export: La date du dernier test réellement effectué.
Renouvellement: La date, et le préavis de dénonciation.
Dernière revue: La date, et la personne qui l’a menée.

Les événements qui doivent déclencher une mise à jour : nouvelle fonctionnalité, nouveau sous-traitant, changement de prix, changement d’API, incident, nouveau pays, nouvelle catégorie de données.

L’inventaire devient utile lorsqu’il permet de répondre en quelques minutes à une seule question : quelles intégrations mettraient notre plateforme à l’arrêt aujourd’hui ?

Un prestataire devient critique progressivement.

Personne ne signe avec un point unique de défaillance. On le devient, en cinq étapes qui passent presque toujours inaperçues.

1Facile à remplacer. Faible intégration, peu de données accumulées, plusieurs alternatives disponibles.
2Intégré. Du développement est nécessaire pour changer, mais rien de structurel.
3Historique. Le fournisseur détient des données ou des configurations accumulées qui ne se reconstituent pas.
4Structurant. Plusieurs processus internes dépendent de lui, y compris hors de l’équipe technique.
5Point unique de défaillance. Sa disparition arrête une fonction essentielle, et aucune alternative immédiate n’est prête.

La criticité n’est pas une propriété du fournisseur. C’est une propriété de votre dépendance à ce fournisseur.

Une fois par an : peut-on réellement débrancher notre prestataire critique ?

Exporter

Obtenir les données, réellement, pas en théorie.

Ouvrir

Vérifier qu’elles sont utilisables par quelqu’un qui ne connaît pas l’outil.

Documenter

Retrouver les configurations, les règles et les automatisations nécessaires.

Révoquer

Identifier toutes les clés et tous les accès à fermer, y compris ceux oubliés.

Remplacer

Identifier la solution alternative, et vérifier qu’elle couvre les mêmes besoins.

Basculer

Estimer le temps de migration avec les équipes qui l’exécuteraient.

Vérifier

Contrôler qu’aucune donnée ni dépendance importante n’a été oubliée.

Effacer

Prévoir la suppression chez l’ancien fournisseur lorsqu’elle doit avoir lieu, et en obtenir la confirmation.

Une clause de réversibilité décrit une possibilité. Un test de réversibilité montre qu’elle existe réellement.

Six moments où le contrat doit repasser devant le produit.

Avant d’intégrer

Lorsque l’architecture peut encore être adaptée.

Avant de confier des données importantes

Pour clarifier le rôle, les usages, la sécurité et les sous-traitants.

Avant de devenir dépendant

Lorsque le coût de sortie commence à augmenter, et pas après.

Lors d’un changement important du fournisseur

Prix, version, sous-traitant, API ou infrastructure.

Après un incident sérieux

Pour comparer ce que le contrat prévoyait à ce qui s’est réellement passé.

Avant la sortie

Avant de notifier la résiliation, vérifier concrètement l’export, la transition et les accès.

Des livrables construits autour de la dépendance réelle.

Tous les prestataires ne méritent pas le même niveau de documentation. Le périmètre doit suivre la criticité réelle de la dépendance.

Cartographie

Registre des prestataires
Fonction de chaque intégration
Cartographie des dépendances
Données et accès concernés
Sous-traitants pertinents
Point de rupture
Criticité
Alternatives identifiées

Contrat et annexes

Contrat de prestation
Avenant aux conditions standard
SLA
DPA
Annexe sécurité
Clauses de sous-traitance
Règles de gestion des versions
Mécanismes de notification
Réversibilité

Continuité

Procédure incident
Matrice de contact
Critères d’escalade
Exigences de rapport
Procédure de changement d’API
Plan fournisseur alternatif
Règles de sauvegarde et de récupération

Sortie

Plan de réversibilité
Inventaire des données à exporter
Formats attendus
Calendrier de migration
Suppression chez le fournisseur
Révocation des accès
Transition et assistance
Clauses Data Act lorsque le régime s’applique

Nous branchons juridiquement le prestataire comme vos équipes le branchent techniquement.

1Brancher. Nous identifions la fonction, les données, les accès et les autres systèmes auxquels le prestataire est connecté.
2Délimiter. Disponibilité, données, sécurité, versions, sous-traitants et responsabilité sont répartis selon le fonctionnement réel.
3Tester. Nous regardons ce qui arrive si l’API s’arrête, ralentit ou change, et ce que le contrat permet réellement de faire.
4Surveiller. Versions, sous-traitants, tarifs, localisation et capacité du service sont intégrés à une gouvernance utilisable après signature.
5Débrancher. Données, formats, accès, assistance et délais sont définis pour que la plateforme puisse continuer à fonctionner après la sortie.

Premier retour écrit sous 48 h. Périmètre et honoraires fixés par écrit avant toute intervention.

Le contrat lu comme une architecture de dépendances.

Le schéma avant la clause

Une clause de disponibilité n’a pas la même importance pour un outil de newsletter que pour le service qui authentifie tous vos utilisateurs.

La panne avant l’indemnité

Un avoir ne remplace pas une API. Nous regardons d’abord comment maintenir ou reprendre l’activité.

La sortie avant le verrouillage

Format, clés, documentation et migration se négocient beaucoup plus facilement lorsque le fournisseur souhaite encore être choisi.

Le contrat après la signature

Nouveau sous-traitant, nouvelle API, nouveau prix ou nouveau pays doivent déclencher la bonne revue sans repartir de zéro.

Aucun résultat obtenu ni taux de succès ne figure sur ce site : la mission d’un avocat est une obligation de moyens. Ce qui est annoncé porte sur le délai, l’interlocuteur et le périmètre.

Les questions qui apparaissent une fois que le prestataire est réellement branché.

Notre fournisseur refuse de modifier ses conditions. Peut-on faire quelque chose ?

L’absence de négociation du document principal ne signifie pas qu’aucune adaptation n’est possible. Selon le fournisseur et le poids de la relation, certaines garanties peuvent apparaître dans un bon de commande, un SLA, un DPA, une annexe sécurité ou une offre supérieure. Lorsque la négociation est réellement impossible, l’enjeu devient de mesurer le risque accepté et de prévoir une alternative technique.

Un SLA de 99,9 % est-il suffisant ?

Pas sans savoir ce qu’il mesure. Il faut examiner le périmètre du service, la période de calcul, les exclusions, le moment où l’incident commence, le délai de réaction et les conséquences lorsque le niveau n’est pas atteint.

Notre cloud garantit un export. Est-ce une réversibilité suffisante ?

Pas nécessairement. Il faut vérifier les données réellement récupérées, leur format, les métadonnées, la documentation, le temps nécessaire à leur réutilisation et les éléments techniques qui ne sont pas portables. Le Data Act ajoute par ailleurs des obligations spécifiques de changement pour certains services entrant dans son champ.

Règl. (UE) 2023/2854

Le Data Act s’applique-t-il à tous nos logiciels en ligne ?

Il ne faut pas le présumer. Les obligations de changement de fournisseur du chapitre VI visent les services de traitement de données entrant dans les définitions et le champ du règlement. Le service concerné doit donc être qualifié avant d’appliquer les délais et obligations correspondants.

Règl. (UE) 2023/2854, art. 23 à 31

Notre hébergeur est-il automatiquement notre sous-traitant ?

Lorsqu’il traite des données personnelles pour le compte de votre entreprise dans un traitement donné, il peut agir comme sous-traitant pour cet usage. Mais le rôle s’examine traitement par traitement, et ne se déduit pas du nom commercial de la prestation.

RGPD art. 28

Le prestataire peut-il changer ses sous-traitants sans notre accord ?

Cela dépend du contrat et, pour les traitements relevant de l’article 28 du RGPD, du mécanisme d’autorisation retenu. Une autorisation générale peut permettre des changements, à condition notamment que le responsable de traitement en soit informé à l’avance et puisse exercer le droit d’objection prévu par le règlement.

RGPD art. 28

Un prestataire est certifié. Faut-il encore vérifier sa sécurité ?

La certification est un élément utile d’évaluation, mais elle ne répond pas seule aux questions propres à votre intégration : données concernées, accès, notification d’incident, sous-traitants, mesures spécifiques ou modalités de sortie.

Quand un prestataire doit-il être considéré comme critique ?

Il n’existe pas de critère unique. Une analyse opérationnelle regarde ce que sa panne arrête, le nombre de fonctions qui en dépendent, les données et accès concernés, le temps nécessaire au remplacement et l’existence d’une alternative. Des régimes sectoriels peuvent par ailleurs prévoir leurs propres notions de fonction critique ou importante.

Quand faut-il revoir le contrat ?

Lorsqu’un changement augmente ou transforme la dépendance : nouvelle fonction, nouvelles données, nouveau sous-traitant, changement d’API, hausse de volume, nouvelle région, incident majeur ou difficulté de sortie constatée.

Une intégration technique peut ouvrir plusieurs couches juridiques.

RGPD des plateformes

Cloud, support, analytics et autres fournisseurs peuvent traiter des données personnelles pour la plateforme et faire intervenir plusieurs sous-traitants ou pays.

RGPD art. 28 02

Contrats commerciaux

Lorsque prix, exclusivité, volumes ou dépendance économique deviennent centraux, la relation dépasse le seul fonctionnement technique de l’intégration.

C. com. art. L442-1 03

AI Act des plateformes

Une API d’IA ajoute un modèle, un fournisseur, une nouvelle version et un rôle réglementaire supplémentaire dans la chaîne.

Règl. (UE) 2024/1689 04

Droit des marketplaces

Paiement, logistique et vérification des vendeurs doivent être replacés dans le rôle réel joué par la plateforme entre les différentes parties.

DSA · P2B

Cette page présente des principes généraux. Leur application dépend notamment du service concerné, du rôle du prestataire, des données et accès qui lui sont confiés, du secteur d’activité, des conditions contractuelles et des règles particulières éventuellement applicables. Elle ne constitue pas une consultation juridique.

Premier échange

Montrez-nous les briques dont votre plateforme ne peut plus se passer.

Une liste simple suffit : le prestataire de paiement, le cloud, le fournisseur d’authentification, l’outil d’e-mail, le support, l’API utilisée pour une fonctionnalité d’IA.

Indiquez ensuite ce que chaque prestataire fait, les données ou accès qu’il reçoit, et la brique qui vous semble aujourd’hui la plus difficile à remplacer. Cela suffit pour identifier les intégrations à examiner en priorité.

Premier retour écrit sous 48 h. Périmètre et honoraires fixés par écrit avant toute intervention.

Cartographier mes dépendances

Appeler le cabinet