☠Saaspocalypse
Salesforce · CRM

Vous louez une cathédrale CRM pour stocker une liste de contacts.

Salesforce facture comme une enterprise pour un produit dont votre équipe utilise 10 %. On rebâtit le pipeline, les contacts et le reporting dont vous avez vraiment besoin — et tout est à vous.

Votre contrat Salesforce

Vous payez aujourd'hui
£90,000 / an

Vous perdez jusqu'à £75,000 par an à louer un logiciel que vous pourriez posséder.

Économies estimées avec une refonte
£150,000
sur 3 ans
Sur 5 ans
£300,000
Rentabilisé en
12 mois

Sur la base d'une refonte one-shot à £75,000 plus £15,000/an d'hébergement & maintenance. Le chiffrage précis arrive après l'audit.

Recevez votre rapport d'économies détaillé & un devis forfaitaire.

Pourquoi Salesforce vous coûte cher

Ce qu'on entend vraiment sur Salesforce

Pour chaque grande fonctionnalité de Salesforce, on a remonté les irritants des vrais utilisateurs — et la façon dont on rebâtit la fonction sur mesure. Cliquez pour voir les sources et le détail.

Des équipes qui ont arrêté de louer

GitGuardianSidecare

“We were paying £108k a year for Salesforce and using a fraction of it. The rebuild paid for itself in under a year and our team finally enjoys using the CRM.”

VP Sales, 60-person SaaS company

Ne nous croyez pas sur parole

Illustratif
“On croulait sous les renouvellements par siège pour des outils qu'on utilisait à moitié. La refonte nous a donné exactement le workflow qu'il nous fallait — et maintenant on en est propriétaires.”
EF
Eric Fourrier
Co-fondateur · GitGuardian
Illustratif
“Ils ont taillé dans le gras, livré les 20 % sur lesquels on s'appuyait vraiment, et notre facture annuelle a arrêté de grimper à chaque renouvellement.”
AR
Anna Rossin
Opérations · Sidecare

À quoi ressemble une refonte

Le problème, la démarche, ce qu'on livre, comment on l'opère.

FintechFrance

Sortir une fintech parisienne du tapis Salesforce

Fintech B2B paiements, 120 personnes, Paris

Illustratif
≈ £180k économisés sur 3 ans · rentabilisé en 11 mois · plus de file d'admin
1Le problème

Sales, success et finance vivaient tous dans Salesforce Enterprise. Chaque nouveau siège déclenchait une refonte de Process Builder trimestrielle, et le seul admin certifié avait une file d'attente de 6 semaines. Les commerciaux exportaient vers des tableurs pour faire le travail que le CRM était censé faire.

2Ce qu'ils payaient en trop

60 sièges Sales Cloud Enterprise à 165 $/utilisateur/mois plus l'add-on Sales Engagement et un admin externe à temps partiel : environ 200 k€ tout compris. La hausse de prix d'août (+6 %) avait déjà ajouté 11 k€ au devis de renouvellement posé sur la table.

3Ce qu'ils n'utilisaient pas
  • ✕L'essentiel des fonctions « editions » de Sales Cloud (Forecasting, Territories, CPQ)
  • ✕Einstein Activity Capture — désactivé après revue conformité
  • ✕Salesforce Inbox / l'intégration Outlook (les commerciaux utilisaient Gmail directement)
  • ✕La plupart des règles de validation et flux d'approbation — contournés en silence par les commerciaux
  • ✕Les dashboards Tableau inclus dans le renouvellement
4Ce qu'on a livré

Un build de huit semaines : un schéma leads + opportunités + comptes sur Postgres, un pipeline Kanban à trois stades nommés, une synchro Gmail via l'API Google Workspace, et six dashboards fixes que la directrice commerciale ouvre vraiment. Le RBAC tient en trois rôles, définis dans le code. Salesforce est resté en lecture seule pendant 30 jours ; l'équipe a voté pour le tuer dès la semaine 2.

5Le résultat

≈ £180k économisés sur 3 ans · rentabilisé en 11 mois · plus de file d'admin

Comment on travaille

Un chemin balisé du SaaS surfacturé au logiciel qui vous appartient.

Voir le plan de migration pour Salesforce

  1. Atelier de découverte

    1 à 2 semaines

    On s'assied avec vos leads sales, ops et ingé, et on transforme le SaaS que vous payez en une liste des workflows que vous faites tourner. La plupart des équipes découvrent qu'elles utilisent 10 à 20 % de ce qui leur est facturé.

    ✓On shadow des utilisateurs réels sur des tâches réelles (Zoom + partage d'écran)
    ✓On tire un rapport d'usage 90 jours du SaaS (logins, fonctions touchées, intégrations appelées)
    ✓On cartographie le modèle de données : tables, custom fields, ce qui est réellement rempli
    ✓On identifie le shelfware — ce que vous payez et que personne n'utilise
    ✓On remonte les intégrations et exports dont votre équipe dépend
    ✓On documente les contraintes sécurité, conformité, audit
    Ce que vous repartez avec

    Un audit Usage & Périmètre de 6 à 10 pages nommant chaque workflow qui reste, chaque fonction qui saute, et la ligne de coût sur laquelle chacun vit aujourd'hui.

  2. Cadrage + devis forfaitaire

    1 semaine

    On transforme l'audit en cadrage forfaitaire. Pas de régie, pas de scope creep, pas de surprise au TJM. Vous voyez le prix du build, la maintenance annuelle et une projection d'économies à 3 et 5 ans avant de signer.

    ✓On traduit les workflows en liste de fonctions avec estimation d'effort
    ✓On choisit la stack (Next.js, Postgres, Inngest, Resend — ennuyeux exprès)
    ✓On modélise les économies face à votre contrat SaaS actuel + croissance projetée
    ✓On verrouille ce qui est dans le périmètre, ce qui n'y est pas, par écrit
    ✓On décide ce qui migre, ce qui s'archive, ce qu'on abandonne
    Ce que vous repartez avec

    Un Statement of Work signé, à prix forfaitaire, avec un calendrier de livraison et un TCO 5 ans comparé à votre contrat SaaS actuel.

  3. Architecture + DPA

    1 semaine

    Avant la première ligne de code, on cale les fondations. Région d'hébergement, propriété des données, chiffrement, RBAC et posture RGPD sont documentés et validés — exactement ce qu'on remettrait à votre auditeur dès le jour 1.

    ✓On choisit la région d'hébergement (UK ou UE — vous décidez)
    ✓On provisionne Postgres (Neon ou AWS RDS), le projet Vercel, le bucket S3 / R2
    ✓On met en place le SSO (Google / Microsoft) avec 2FA WebAuthn
    ✓On câble l'observabilité : Sentry, agrégation des logs, table d'audit
    ✓On signe le DPA et la liste des sous-traitants
    ✓On organise une session de threat-modeling sur les données du périmètre
    Ce que vous repartez avec

    Un Architecture Decision Record + un DPA signé + un questionnaire sécurité prêt à envoyer à votre CISO ou auditeur.

  4. Build avec démos hebdo

    4 à 12 semaines (selon périmètre)

    On livre du logiciel qui tourne chaque semaine, démontré le vendredi en appel. Votre équipe l'utilise, le casse, donne du feedback. À la fin, vous avez plus utilisé le nouveau produit que vous n'utilisiez le SaaS qu'on remplace.

    ✓Démo + rétro hebdo — chaque vendredi, 30 minutes
    ✓Déploiements continus vers un environnement de staging accessible à votre équipe
    ✓Le tracker d'issues est partagé — vous voyez le burn-down en temps réel
    ✓Code review en binôme avec un de vos ingés si vous voulez un vrai transfert
    ✓Pen-test fixtures intégrées dès le jour 1 (gitleaks, Dependabot, OWASP ASVS L2)
    Ce que vous repartez avec

    Une application de qualité production, sur votre propre infrastructure, avec votre organisation comme propriétaire GitHub. Pas de « c'est l'agence qui possède le code ».

  5. Migration des données + parallel run

    2 à 4 semaines

    On extrait votre historique du SaaS, on le mappe sur le nouveau schéma, et on fait tourner les deux systèmes en parallèle. Votre équipe travaille sur le nouveau produit ; l'ancien SaaS reste actif en lecture seule comme filet de sécurité pour une fenêtre définie.

    ✓On écrit les scripts d'extraction sur l'API du SaaS (on les garde — ils resservent à chaque renouvellement)
    ✓On mappe les clés et les IDs pour que la recherche historique continue de marcher
    ✓On migre les audit trails — « qui a changé quoi et quand » est préservé
    ✓Des rapports de réconciliation quotidiens comparent ancien et nouveau pendant le parallel run
    ✓On forme votre équipe en deux sessions de 60 minutes, enregistrées pour la suite
    Ce que vous repartez avec

    Un runbook de migration (rejouable), un dashboard de réconciliation, et une validation signée de chaque équipe : le nouveau système devient la source de vérité.

  6. Bascule

    1 journée

    Le jour J, le DNS bascule, le SSO redirige, le SaaS passe en lecture seule. On reste en war-room avec votre lead ops. La plupart des bascules sont sans relief — c'est exactement le but.

    ✓Bascule DNS + SSO avec une fenêtre de 5 minutes en double-write
    ✓Smoke tests sur chaque workflow critique
    ✓Notification de tous les utilisateurs via Slack + email avec le nouveau lien de login
    ✓Verrouillage du SaaS en lecture seule — gardé 90 jours comme filet de sécurité
    ✓Annulation du renouvellement automatique du SaaS (une joie discrète)
    Ce que vous repartez avec

    Un runbook de bascule + un rapport Jour 1 montrant chaque workflow au vert. Le SaaS reste en lecture seule pendant 90 jours, sans facturer le prix plein.

  7. Opérer, faire évoluer, posséder

    En continu

    On l'héberge, on le monitore, on le corrige. Vous gardez le code, les données, les clés. Les nouvelles fonctions partent en PR que votre équipe revoit ; les SLA sont des vrais chiffres dans un contrat ; les hausses au renouvellement sont à zéro, à vie.

    ✓Monitoring d'uptime 24/7 avec status page publique
    ✓Revue d'architecture trimestrielle + discussion roadmap à 6 mois
    ✓RPO ≤ 5 minutes, RTO ≤ 4 heures ; PRA testé deux fois par an
    ✓Pen-test annuel par un tiers, résultats partagés
    ✓Triage CVE Dependabot sous 72 heures ; critiques sous 24
    Ce que vous repartez avec

    Un SLA forfaitaire avec un ingé d'astreinte nommé, une roadmap produit trimestrielle, et zéro taxe par utilisateur, à vie. Le contrat est exit-friendly : vous gardez le code, votre repo, votre infra, vos clés.

L'équipe derrière le projet

Des ingés et designers seniors qui ont livré ce scénario des dizaines de fois.

David Geismar

David Geismar

Produit

Pilote le produit et la découverte — repère les 10 % de votre SaaS que vous utilisez vraiment, en sort une spec sobre que votre équipe va adopter.

LinkedIn
Jasbir Singh

Jasbir Singh

Ingénierie

Pilote le build — conçoit, livre et maintient le remplacement sur mesure : hébergement, sécurité, fiabilité inclus.

LinkedIn

Vos questions, nos réponses

Et nos données historiques ?+

On les migre via Bulk API 2.0 — comptes, opportunités, contacts, custom objects, activités, fichiers — dans votre nouveau schéma Postgres. L'historique de recherche fonctionne, et on garde Salesforce en lecture seule pendant 90 jours comme filet.

Et nos intégrations Stripe / Calendly / autres ?+

Elles continuent de fonctionner. On préserve les IDs Salesforce à 18 caractères en colonne, donc les webhooks entrants et les intégrations sortantes résolvent contre les nouveaux enregistrements sans modification côté éditeur tiers.

Combien de temps prend la refonte ?+

Typiquement 10 à 14 semaines : 1-2 semaines d'audit et cadrage, 1 semaine de schéma et stratégie d'IDs, 1-2 semaines d'extraction, 5-8 semaines de build avec démos hebdo, puis 2-3 semaines de parallel run avant la bascule.