Le client qui veut votre produit « chez lui » : pourquoi l’on-premise peut sauver un deal et casser votre startup

Le deal de l’année est sur la table. Un grand compte, un contrat à six chiffres, la référence qui crédibilise tout votre pipeline. Puis, à l’avant-dernière réunion, l’acheteur lâche la phrase qui change tout : « Nos données ne peuvent pas sortir de notre infrastructure. Il nous faut un déploiement dans notre environnement. » Votre SaaS multi-tenant, hébergé bien au chaud sur votre compte cloud, vient de rencontrer sa première demande d’on-premise. Et vous avez trois semaines pour répondre.

C’est un moment piège. Dire non, c’est peut-être perdre le contrat qui débloque votre série A. Dire oui trop vite, c’est signer sans savoir que vous venez peut-être de transformer une startup produit en cabinet d’intégration sur-mesure. La bonne réponse n’est ni l’un ni l’autre — elle dépend de ce que « chez lui » veut réellement dire, et de ce que votre architecture peut absorber sans se fracturer.

« On-premise » ne veut rien dire tant que vous n’avez pas creusé

La première erreur, c’est de traiter la demande comme un bloc. « Déployer chez le client » recouvre en réalité un spectre de contraintes très différentes, et le coût pour vous varie d’un facteur dix selon l’endroit où vous atterrissez.

À un extrême, il y a le client qui veut simplement la garantie que ses données restent en Europe, chez un hébergeur souverain, isolées des autres clients. Ce n’est pas de l’on-premise : c’est une exigence de résidence des données et d’isolation, souvent motivée par le RGPD, un DPO nerveux, ou un secteur régulé (santé, finance, secteur public). Vous pouvez y répondre avec un déploiement single-tenant dans une région dédiée, ou un hébergement chez un cloud qualifié SecNumCloud si le prospect est public. Votre code ne bouge pas ; c’est votre topologie de déploiement qui s’adapte.

Au milieu, il y a le VPC dédié : le client accepte le cloud, mais veut votre logiciel tournant dans son compte AWS ou son propre réseau, connecté à ses systèmes internes. Là, vous entrez dans le monde de la livraison d’un artefact déployable — une image, un chart Helm, un Terraform — que vous ne contrôlez plus directement.

À l’autre extrême, il y a le vrai on-premise : le logiciel tourne dans un datacenter physique du client, parfois sans accès Internet sortant (air-gapped). Ici, vous perdez tout : la télémétrie, les déploiements continus, la capacité à débugger en production, le contrôle des versions. Chaque mise à jour devient une livraison manuelle négociée.

Avant même de parler prix, votre premier travail commercial est de qualifier où sur ce spectre se situe la demande. Neuf fois sur dix, le prospect a écrit « on-premise » dans son cahier des charges par réflexe, alors qu’un single-tenant isolé en région française réglerait sa vraie préoccupation. Vous venez peut-être d’économiser six mois d’ingénierie avec une seule question : « Qu’est-ce qui, concrètement, ne peut pas quitter votre périmètre ? »

Le vrai coût n’est pas le déploiement, c’est la divergence

Supposons que la demande soit légitime et incompressible. Le piège classique n’est pas le premier déploiement — un ingénieur motivé peut faire tourner votre stack dans le VPC d’un client en quelques semaines. Le piège, c’est le deuxième mois, puis le sixième.

Un SaaS multi-tenant vit sur une hypothèse fondatrice : il n’existe qu’une seule version en production, celle que vous contrôlez. Vous déployez plusieurs fois par jour, vous mesurez tout, vous corrigez un bug pour tous les clients d’un coup. Le jour où vous livrez une instance dans l’environnement d’un client, vous cassez cette hypothèse. Ce client tourne désormais sur sa version, mise à jour quand il le veut bien, avec sa configuration, ses intégrations maison, son proxy réseau qui bloque un domaine dont vous dépendez sans le savoir.

Multipliez ça par trois grands comptes on-premise et vous obtenez ce que redoutent tous les éditeurs : le matrice de versions. Le client A tourne en v3.2 parce qu’il n’a pas validé la v4. Le client B a une v3.8 patchée à la main pour contourner un bug de son firewall. Votre équipe support doit reproduire des incidents dans des environnements qu’elle ne voit pas, sur des versions qu’elle ne fait plus tourner elle-même. Chaque nouvelle feature doit être testée contre chaque configuration client. Votre vélocité, l’atout numéro un d’une startup, s’effondre sous le poids de la compatibilité.

Ce coût est invisible au moment de signer. Il n’apparaît pas dans le devis. Il se paie en trimestres de roadmap ralentie, en burnout d’équipe, et en une vérité brutale : à partir d’un certain nombre d’instances déployées, vous n’êtes plus une startup produit, vous êtes un éditeur de logiciel packagé. Ce n’est pas déshonorant — mais ce n’est ni la même valorisation, ni le même métier, ni la même équipe.

Concevoir pour la portabilité coûte peu au début, très cher après

Voici la nuance technique qui change tout : la difficulté de l’on-premise dépend moins de la demande du client que des choix d’architecture que vous avez faits avant qu’elle n’arrive.

Une startup qui a bâti son produit en s’appuyant lourdement sur des services managés propriétaires — une base serverless spécifique, une file de messages maison du cloud provider, une fonction d’authentification liée à un fournisseur unique — découvre que son produit n’est pas déplaçable. La logique métier est correcte, mais elle est tissée dans un écosystème qu’on ne peut pas exporter dans le datacenter d’un client. Réoutiller ce produit pour le rendre portable, c’est un chantier de plusieurs mois qui touche l’infrastructure la plus critique.

À l’inverse, une startup qui a conteneurisé proprement, qui traite ses dépendances externes comme des interfaces remplaçables (un stockage objet compatible S3, une base de données standard, un broker qu’on peut auto-héberger), peut produire un artefact déployable sans réécrire son cœur. La portabilité n’était pas un objectif — c’était une conséquence de choix d’hygiène.

Cela ne veut pas dire qu’il faut tout rendre portable dès le pre-seed « au cas où ». Ce serait l’inverse du bon sens : au stade validation, chaque heure passée à éviter le lock-in est une heure volée au product-market fit, et les services managés sont précisément ce qui vous fait aller vite. Le bon arbitrage est temporel. Avant le PMF, optimisez la vitesse, assumez le couplage. Après les premiers signaux de traction B2B enterprise — les fameux « on-premise » qui reviennent dans les appels commerciaux — commencez à isoler les frontières les plus risquées derrière des abstractions, sans tout refactoriser. Vous ne construisez pas la portabilité ; vous vous laissez la porte ouverte pour la construire vite le jour où un contrat la finance.

Ce qu’il faut vraiment faire

Face à la demande, priorisez dans cet ordre.

Qualifiez avant de chiffrer. Déterminez sur le spectre où se situe le besoin réel. La majorité des « on-premise » sont des exigences de résidence et d’isolation des données qu’un déploiement single-tenant en région dédiée règle sans toucher au produit. Ne résolvez pas un problème que le client n’a pas.

Faites payer le vrai coût, y compris le coût futur. Si le déploiement dédié est incontournable, il ne se vend pas au tarif SaaS standard. Un contrat on-premise doit intégrer un setup fee qui couvre l’ingénierie, un abonnement plus élevé qui absorbe la maintenance de version, et surtout des clauses qui vous protègent : cadence de mise à jour imposée, fenêtre de support limitée aux N dernières versions, accès aux logs. Si le client refuse ces contreparties, c’est un signal que le deal coûtera plus qu’il ne rapporte.

Standardisez le déploiement dès la deuxième demande. Le premier déploiement peut être artisanal. Le deuxième doit être un artefact reproductible — chart Helm, images versionnées, playbook d’installation documenté. Vous n’avez pas les moyens de traiter chaque instance comme un projet. Si vous ne pouvez pas industrialiser, limitez volontairement le nombre de clients on-premise que vous acceptez.

Traitez la portabilité comme une option, pas comme un dogme. Isolez vos dépendances les plus enfermantes derrière des interfaces, progressivement, à partir du moment où la demande enterprise devient récurrente. Vous achetez de l’optionnalité, pas une réécriture.

Décidez si ce marché est le vôtre. La vraie question stratégique n’est pas technique : est-ce que la vente enterprise on-premise correspond à qui vous voulez devenir ? Elle allonge les cycles de vente, exige une équipe déploiement, ralentit la roadmap, et éloigne du modèle self-serve. Certaines startups y trouvent leur moteur de croissance et leurs plus belles marges. D’autres se laissent tirer, un gros deal après l’autre, vers un métier qu’elles n’ont pas choisi.

Le deal qui vous change

Un contrat on-premise n’est jamais qu’un contrat. C’est une décision qui reconfigure votre architecture, votre rythme de livraison, la composition de votre équipe et, à terme, votre positionnement. Les startups qui le gèrent bien ne sont pas celles qui savent déployer partout — ce sont celles qui savent quand ne pas le faire, et qui font payer le juste prix quand elles disent oui.

Avant de répondre à votre prochain grand compte, posez-vous la seule question qui compte vraiment : ce deal vous rapproche-t-il de la startup que vous voulez construire, ou vous transforme-t-il, un « oui » à la fois, en autre chose ? Si vous hésitez, c’est précisément le moment de mettre à plat votre architecture et votre stratégie de vente ensemble — parce que sur ce sujet, les deux ne se décident jamais séparément.