Intégration on-premise pour ETI françaises : souveraineté opérationnelle sans fantasme juridique

Dans les appels d'offres et les comités DSI, le mot souveraineté revient souvent, surtout depuis que les suites historiques (Blueway, Talend on-premise¹) ont montré leur vulnérabilité aux rachats et aux pivots cloud. La question n'est pas « cloud ou pas cloud » en absolu. C'est : pour la couche qui fait circuler commandes, clients et factures entre vos systèmes, quel niveau de contrôle opérationnel vous devez tenir, et ce que vous êtes prêts à payer pour le louer à un tiers.

Cet article n'est pas un avis juridique. Il pose un cadre opérationnel pour les ETI³ françaises : hébergement, données, compétences, sortie. Pour le modèle économique location vs possession : posséder vs louer et plateformes SaaS.

Ce que « on-premise » change vraiment

On-premise¹ (ou self-hosted²) : la plateforme d'intégration tourne sur votre infrastructure (serveurs, VM⁷, Kubernetes, datacenter ou cloud que vous commandez). Les données en transit et au repos pour les files d'attente²⁶ et logs restent dans votre périmètre réseau, sous vos règles d'accès.

• Contrôle d'accès : qui peut SSH, qui voit les logs, qui exporte. Votre IAM⁸, pas celui de l'éditeur.
• Résidence des données : vous choisissez la zone (France, UE) sans dépendre du bon vouloir d'un tenant²⁷ US.
• Continuité : si l'éditeur disparaît ou double ses prix, les flux peuvent continuer tant que vous tenez l'infra (avec une licence à vie²⁵ ou du code possédé).
• Audit : plus simple à documenter pour un RSSI⁹ ou un DPO¹⁰ interne. Pas de boîte noire SaaS⁵ complète.

Ce que l'on-premise ne fait pas : garantir le RGPD⁴ tout seul, supprimer le besoin de compétences, ou éliminer la responsabilité du responsable de traitement.

RGPD : l'hébergement n'est qu'une couche

Le RGPD⁴ s'intéresse au traitement des données personnelles : finalité, minimisation, durée, droits des personnes, sous-traitance. Héberger en France aide sur la résidence et les clauses contractuelles. Ça ne remplace pas :

• Un registre des traitements à jour incluant les flux d'intégration.
• Des accords de sous-traitance (DPA¹¹) si un éditeur ou un cloud tiers touche les données.
• Des procédures d'effacement et d'accès quand un flux copie des données personnelles entre systèmes.
• Une analyse d'impact quand le volume ou la sensibilité le justifie.

Une plateforme d'intégration, on-premise¹ ou SaaS⁵, voit souvent beaucoup de données. C'est une zone à risque opérationnel pour le DPO¹⁰, pas un détail technique.

SaaS français : ce que la promesse couvre

De plus en plus d'éditeurs affichent hébergement France / UE et support en français. Points à vérifier sans prendre le marketing pour argent comptant :

• Sous-traitants : hébergeur, CDN¹², monitoring. Où vont les métadonnées et les logs ?
• Stack technique : un SaaS⁵ « français » sur AWS US reste exposé aux contraintes du fournisseur cloud.
• CLOUD Act¹³ et éditeurs US : même avec datacenter UE, la maison mère peut compter.
• Export et sortie : pouvez-vous récupérer vos mappings et votre logique en format exploitable ?
• Schéma de facturation : le coût grimpe avec les flux. Effet pervers sur la minimisation des copies de données.

Un iPaaS⁶ français peut être le bon compromis pour du SaaS⁵-to-SaaS⁵ non critique. Pour la tranche commandes / stock / facturation, beaucoup de DSI françaises préfèrent reprendre la main, pas par patriotisme, par calcul de risque.

Self-hosted vs SaaS français, côte à côte

• Résidence des données. Self-hosted : vous fixez la zone. SaaS⁵ FR : contractuel, à auditer (sous-traitants).
• Contrôle en incident. Self-hosted : vous isolez, vous rejeuez. SaaS⁵ : ticket éditeur, dépendance SLA¹⁴.
• Coût long terme. Self-hosted : CapEx¹⁵ + run interne. SaaS⁵ : OpEx¹⁶ récurrent, coût de sortie possible.
• Compétences. Self-hosted : ops + dev (Python possible). SaaS⁵ : experts plateforme (Workato, Boomi).
• Souveraineté opérationnelle. Self-hosted : élevée si code possédé. SaaS⁵ : limitée par le modèle.
• Time-to-market. Self-hosted : plus lent au départ. SaaS⁵ : rapide sur connecteurs²⁴ catalogue.

Pourquoi la couche d'intégration est sensible

Ce n'est pas le CRM²⁰ de vente seul. L'intégration touche souvent tout : clients, commandes, coordonnées, parfois santé ou finance selon le secteur. Un flux mal configuré duplique ou expose plus que prévu. Un éditeur SaaS⁵ voit les métadonnées des connexions, parfois le contenu des messages selon l'architecture.

• Concentration : un point qui lit tout le SI.
• Logs : souvent riches en données personnelles si mal paramétrés.
• Sous-traitance : l'intégrateur devient sous-traitant au sens RGPD⁴.
• Sortie : exporter vers un autre pays ou un autre cloud lors d'une migration.

Mettre cette couche on-premise¹ n'est pas une lubie souverainiste. C'est aligner l'architecture avec ce que le RSSI⁹ et le DPO¹⁰ demandent déjà sur le papier.

ETI française : profil type et contraintes

• Pas de cloud team à 15 personnes. Le self-hosted² doit rester opérable.
• ERP¹⁹ souvent on-premise¹ ou hébergé chez un infogéreur français.
• Pression fournisseurs : secteur public, industrie, santé. Questions de résidence et d'audit.
• Budget : moins de marge qu'un grand groupe pour absorber un lock-in²² long.
• Héritage : suites ESB²¹ déjà là. Coexistence plus réaliste que big bang.

Pour ces profils, l'objectif réaliste est souvent hybride : SaaS⁵ pour le périphérique, self-hosted² ou possédé pour la sync critique. Pas tout migrer d'un coup.

Checklist opérationnelle (pas juridique)

• Cartographier quels flux transportent des données personnelles.
• Savoir où tournent runtime, files, logs, sauvegardes.
• Lister qui est responsable de traitement vs sous-traitant (éditeur, hébergeur, ESN¹⁸).
• Vérifier contrat de sortie : export, délai, format.
• Mesurer bus factor²³ sur la compétence (voir compétence de niche).
• Comparer TCO¹⁷ 5 ans self-hosted² vs SaaS⁵, pas la ligne mensuelle seule.

Quand le SaaS français suffit

• Flux non sensibles, volumes faibles, pas de données personnelles critiques.
• Pas d'équipe pour opérer une plateforme, et pas de projet pour en créer une.
• Contrat DPA¹¹ solide, sous-traitants UE, audit récent acceptable.
• Besoin court ou périmètre qui changera avant que le lock-in²² ne morde.

Quand l'on-premise (ou possédé) mérite le débat

• Flux cœur métier (commandes, stock, facturation, clients).
• Exigences secteur ou clients grands comptes sur la résidence.
• Volonté de réduire la dépendance à un éditeur US ou à un abonnement sans plafond.
• Suite legacy surdimensionnée : extraire la sync vers un moteur léger (voir garder sa suite ESB).

Portlane dans ce paysage

Portlane est conçu pour les ETI³ qui veulent exécuter la synchronisation de données chez eux : Python versionné, licence à vie²⁵, pas d'abonnement pour que les flux tournent. Ce n'est pas un label « souverain » marketing. C'est un choix d'architecture : vos données, votre run, votre code.

Limites assumées : pas BPM, pas MDM, pas iPaaS⁶ catalogue. Encore en développement actif. Pourquoi nous construisons Portlane. Si vous comparez des modèles : posséder vs louer, alternatives Blueway.

Consultez votre DPO¹⁰ ou votre avocat pour la conformité réglementaire. Cet article aide à cadrer une discussion technique et économique, pas à signer un registre RGPD⁴ à votre place.

Questions fréquentes

L'on-premise garantit-il la conformité RGPD ?

Non. Le RGPD⁴ concerne le traitement des données personnelles, pas seulement l'hébergement. Self-hosted² peut faciliter le contrôle opérationnel (qui accède, où sont les logs, comment on efface), mais ce n'est pas une case magique. Cet article n'est pas un avis juridique.

Un SaaS français est-il « souverain » ?

« Hébergé en France » ou « éditeur français » réduit certains risques géopolitiques et simplifie parfois les échanges avec la DSI. Ça ne remplace pas un audit contractuel (sous-traitants, CLOUD Act¹³ américain si stack US, clauses de sortie). Souveraineté est un spectre, pas un label unique.

Une ETI doit-elle tout self-hoster ?

Rarement. La question utile : quelles données et quels traitements doivent rester sous contrôle direct ? La couche qui synchronise commandes, stock et facturation est souvent plus sensible qu'un outil de sondage RH.

Portlane est-il une réponse « souveraine » ?

Portlane vise l'exécution dans votre infrastructure, code Python chez vous, licence à vie²⁵. Ça adresse la souveraineté opérationnelle sur la tranche intégration, pas la conformité juridique à votre place. Produit encore en développement actif.

Faut-il fuir tous les iPaaS américains ?

Pas par défaut. Il faut regarder le contrat, les sous-traitants, la localisation effective des données et des métadonnées, et le coût de sortie. Parfois un iPaaS⁶ tient le job ; parfois la couche critique mérite d'être possédée.

Glossaire

• ¹ On-premise : logiciel exécuté sur l'infrastructure de l'organisation.
• ² Self-hosted : même idée. Vous hébergez et opérez l'instance.
• ³ ETI : entreprise de taille intermédiaire.
• ⁴ RGPD : règlement général sur la protection des données (UE).
• ⁵ SaaS : logiciel en abonnement, hébergé par l'éditeur.
• ⁶ iPaaS : plateforme d'intégration en mode service.
• ⁷ VM : machine virtuelle.
• ⁸ IAM : gestion des identités et des accès.
• ⁹ RSSI : responsable de la sécurité des systèmes d'information.
• ¹⁰ DPO : délégué à la protection des données.
• ¹¹ DPA : accord de traitement des données (Data Processing Agreement).
• ¹² CDN : réseau de diffusion de contenu.
• ¹³ CLOUD Act : loi US permettant aux autorités d'accéder à certaines données détenues par des entreprises US.
• ¹⁴ SLA : engagement de niveau de service.
• ¹⁵ CapEx : dépense d'investissement.
• ¹⁶ OpEx : dépense opérationnelle récurrente.
• ¹⁷ TCO : coût total de possession.
• ¹⁸ ESN : entreprise de services du numérique.
• ¹⁹ ERP : progiciel de gestion intégré.
• ²⁰ CRM : gestion de la relation client.
• ²¹ ESB : bus de services d'entreprise.
• ²² Lock-in : dépendance fournisseur rendant la sortie coûteuse.
• ²³ Bus factor : risque lié au nombre de personnes maîtrisant un système.
• ²⁴ Connecteur : module pour brancher une application sur une plateforme.
• ²⁵ Licence à vie : achat du droit d'utilisation sans abonnement obligatoire pour le déployé.
• ²⁶ File d'attente : stockage de messages en attente de traitement.
• ²⁷ Tenant : instance logique isolée chez un fournisseur multi-clients.