Implémentation Salesforce : Coût, Délais Et Échecs

Une implémentation Salesforce est validée comme une ligne de licence et livrée comme un programme. La ligne de licence est publique, par utilisateur, par mois, et facile à défendre en conseil d’administration. Tout ce qui transforme ces licences en système réellement utilisé se situe en dehors, et c’est cette part qui décide si le chiffre du business case survit au premier trimestre.

Salesforce publie ses tarifs britanniques en livres. Sales Cloud Enterprise est à £140 par utilisateur et par mois en facturation annuelle et Unlimited à £280. Cinquante utilisateurs Enterprise représentent £84 000 par an avant qu’un seul champ ait été configuré. Notre estimation maison pour les services qui mettent cet org en production va de une à trois fois la dépense de licence de la première année, et la position dans cette fourchette n’a rien d’aléatoire. Quatre facteurs la déplacent, et un seul est technique.

Le mot qui compte le plus dans ce qui suit est adoption, car un système techniquement correct que personne n’utilise n’est pas un succès partiel. C’est une perte sèche assortie d’une facture de maintenance.

Combien coûte une implémentation Salesforce ? La licence est le plus souvent la plus petite moitié. Salesforce affiche Sales Cloud Enterprise à £140 par utilisateur et par mois au Royaume-Uni, soit £84 000 par an pour cinquante utilisateurs, et notre estimation maison pour les services d’implémentation par-dessus va de une à trois fois cette dépense de licence de première année. Le multiplicateur dépend du nombre de systèmes intégrés, de l’état des données source, du degré de personnalisation des processus, et de la volonté de l’organisation d’adapter son processus au produit.

Ce que comprend réellement une implémentation Salesforce

Un programme Salesforce compte six postes de coût, et un seul figure sur une page tarifaire.

Le premier est la licence, par utilisateur et par mois, publiée. Le deuxième, les services d’implémentation: les consultants et les développeurs qui configurent l’org, construisent ce que la configuration ne peut pas faire, et pilotent le projet. Le troisième, la migration des données, chiffrée comme une tâche interne à l’implémentation et qui se comporte comme un projet à part entière. Le quatrième, l’intégration, c’est-à-dire le raccordement de Salesforce aux systèmes qui détiennent déjà vos données. Le cinquième, la formation et la conduite du changement. Le sixième, l’administration courante, qui n’apparaît dans aucun business case parce qu’elle commence une fois toutes les autres factures réglées.

Un business case qui ne cite que la licence ne se trompe pas d’un peu. Il se trompe couramment d’un facteur de deux à quatre, et l’écart tient presque entièrement aux postes trois, cinq et six.

La licence est le petit chiffre

La grille Sales Cloud de Salesforce pour le Royaume-Uni est publique et libellée en livres.

La Starter Suite est à £20 par utilisateur et par mois. Pro Suite est à £80 en facturation annuelle. Enterprise, l’édition sur laquelle atterrissent la plupart des acheteurs du marché intermédiaire britannique parce que c’est le premier palier doté d’une API web, est à £140. Unlimited est à £280 et inclut une sandbox Full ainsi que le Premier Success Plan. Agentforce 1 Sales est à £440. Acheté séparément, le Premier Success Plan est facturé 30% des frais nets de licence.

Deux conséquences. Le saut de Pro Suite à Enterprise vaut £60 par utilisateur et par mois, soit £36 000 par an pour 50 utilisateurs, et il est souvent imposé par une seule exigence d’intégration plutôt que par une fonction réclamée par les commerciaux. Et le plan de support est un pourcentage: il suit la facture de licence, pas le support que vous consommez.

Le ratio services sur licence, et ce qui le déplace

Le chiffre utile pour planifier n’est pas le taux journalier. C’est le ratio entre les services de la première année et la dépense de licence de la première année, parce que ce ratio est assez stable pour qu’on en discute.

Nos fourchettes maison, issues du marché intermédiaire britannique, sont les suivantes. Un déploiement quasi standard sur un seul cloud, avec des données propres et sans intégration, se situe autour de 0,5 à 1 fois la dépense de licence de première année. Une implémentation typique, avec deux ou trois intégrations et une dose modérée d’objets personnalisés et d’automatisation, se situe à 1 à 3 fois. Un programme multi-cloud avec des données héritées, cinq intégrations ou plus et une forte personnalisation des processus tourne à 3 à 5 fois, parfois davantage. Ce sont nos estimations, pas des chiffres publiés, et à un partenaire qui cite un ratio sectoriel figé, demandez d’où il sort.

Sur l’exemple à £84 000, cela donne £42 000 en bas, £84 000 à £252 000 au milieu, et £252 000 et plus en haut. L’écart est toute l’histoire. L’acheteur qui a seulement entendu que ce serait à peu près le prix de la licence s’est ancré au milieu d’une fourchette dix fois plus large aux extrémités.

Les quatre variables qui déplacent le ratio

Seules quatre choses font passer un projet Salesforce d’une fourchette à la suivante, et tout cadrage devrait les établir toutes les quatre avant que quiconque produise un chiffre.

La première est le nombre de systèmes intégrés. Chacun est une conception distincte, un jeu d’identifiants distinct, un chemin d’erreur distinct et une chose de plus qui casse quand l’autre éditeur livre une version. Le coût des intégrations n’est pas additif, il est légèrement pire qu’additif, parce que les modes de défaillance se multiplient.

La deuxième est la qualité des données à la source. Pas le volume. La qualité. Elle est traitée en détail plus bas, parce que c’est le poste le plus systématiquement sous-estimé du programme.

La troisième est le degré de personnalisation des processus, c’est-à-dire l’écart entre la cible et ce que le produit fait dès l’installation.

La quatrième est de savoir si l’organisation modifiera son processus pour l’adapter au produit. C’est le meilleur prédicteur du coût comme du succès, et presque personne ne le cadre, parce que c’est une question sur les personnes posée pendant une évaluation technique.

La volonté de changer est une question de cadrage

Une organisation qui adapte son processus commercial au modèle d’opportunité de Salesforce obtient un système bon marché, upgradable et bien pris en charge. Celle qui exige que Salesforce reproduise son tableur existant obtient un système cher qui se bat contre chaque version.

Le signal, pendant la découverte, est le vocabulaire. Quand un interlocuteur dit qu’il faut que le système fonctionne comme nous travaillons, le budget de personnalisation est sur le point de doubler. Quand il dit montrez-moi comment c’est censé marcher et expliquez-moi pourquoi, il est sur le point d’être divisé par deux. Les deux phrases sont raisonnables. Une seule est bon marché.

La façon honnête de traiter cela est de le chiffrer. Mettez deux nombres dans la proposition, un pour le modèle standard et un pour le sur-mesure, et laissez l’écart faire l’argument. L’acheteur qui voit qu’une convention de nommage des étapes coûte £18 000 d’automatisation sur mesure et un risque permanent à chaque montée de version change généralement la convention. Celui à qui on répond que c’est faisable ne la change pas.

La découverte, et ce que produit une bonne découverte

La découverte est la phase la plus souvent rabotée pour gagner une affaire et la plus souvent accusée ensuite. Une découverte qui produit une présentation était un exercice commercial. Celle qui produit quatre livrables était un exercice d’ingénierie.

Le premier est une cartographie de processus: la séquence réelle des étapes par lesquelles un lead devient du chiffre d’affaires, avec les points de décision et les personnes qui en répondent, tirée de l’observation du travail plutôt que de la description qu’en donnent les managers.

Le deuxième est un modèle de données: objets, champs, relations, valeurs de picklist, et pour chaque champ une personne nommée qui l’entretiendra. Les champs sans propriétaire deviennent les champs que personne ne remplit.

Le troisième est un inventaire des intégrations: chaque système qui envoie des données à Salesforce ou en reçoit, avec le sens, le volume, la fréquence, l’identifiant qui joint les enregistrements, et ce qui se passe quand la connexion tombe.

Le quatrième est une définition du fini qui soit mesurable. Non pas que les commerciaux utilisent Salesforce, mais par exemple que 90% des opportunités closes dans le trimestre portent une date de clôture, un montant et une étape saisie par leur propriétaire, et que la revue de pipeline hebdomadaire se tienne depuis le tableau de bord Salesforce sans aucun tableur dans la salle.

En procédure concurrentielle, nos conseils sur l’appel d’offres logiciel s’appliquent directement: demandez à chaque candidat ce que produit sa découverte et écartez ceux qui ne savent pas nommer les livrables.

La migration des données est là où part le calendrier

La migration est vendue comme un pourcentage du build et consommée comme un multiple de celui-ci, à cause d’un seul malentendu: les équipes estiment à partir du nombre d’enregistrements, alors que l’effort de migration suit la qualité de la source.

Deux millions de lignes propres issues d’un système bien tenu, avec une clé primaire fiable, représentent une semaine de travail soigneux. Quarante mille lignes réparties entre un ancien CRM, trois tableurs régionaux et un logiciel comptable, sans identifiant commun et avec onze ans de texte libre dans le champ notes, représentent deux mois et seront encore fausses à la mise en production. Le second chantier a un cinquantième des enregistrements et huit fois la charge.

Profilez la source avant de promettre quoi que ce soit

Profiler, c’est compter avant d’accepter une date. Faites-le sur chaque source, et avant que la ligne migration de la proposition soit signée.

Comptez les valeurs nulles par champ. Comptez les valeurs distinctes de chaque champ destiné à devenir une picklist, car une colonne pays comportant 340 valeurs distinctes n’est pas une picklist, c’est un chantier de nettoyage. Comptez combien d’enregistrements partagent une clé candidate. Mesurez la cohérence de format des dates, des numéros de téléphone et des codes postaux. Comptez les enregistrements sans propriétaire, sans adresse e-mail et sans activité depuis trois ans, car personne ne les défendra quand vous proposerez de les laisser derrière.

Le profilage coûte deux à cinq jours sur un patrimoine de taille moyenne. C’est la réduction de risque la moins chère du programme, et son absence explique pourquoi les estimations de migration ne se trompent que dans un sens.

La déduplication, et les règles fournies par la plateforme

Salesforce dispose d’une gestion native des doublons, et ses limites façonnent la conception. Vous pouvez avoir jusqu’à cinq duplicate rules actives par objet et une matching rule active par objet, le plafond passant à cinq matching rules actives par objet lorsque vous utilisez plusieurs duplicate rules, chaque duplicate rule pouvant référencer jusqu’à trois matching rules.

Deux comportements comptent plus que ces compteurs. Les match keys réduisent la comparaison aux 100 doublons les plus probables avant l’application de l’équation de rapprochement: un enregistrement présentant plus de 100 quasi-correspondances réelles ne sera donc pas évalué complètement. Et les règles ne s’exécutent tout simplement pas sur plusieurs chemins courants, dont Quick Create et la conversion de Lead sans Apex lead convert activé, ce qui explique l’apparition de doublons dans un org où les duplicate rules sont pourtant actives.

La déduplication est donc une activité de migration, menée sur les données de staging avant chargement, et non une fonction d’exécution qu’on active puis qu’on oublie. Les règles natives sont la seconde ligne de défense.

Les external ID, et pourquoi upsert vaut mieux qu’insert

Chaque objet migré a besoin d’un external ID: un champ personnalisé indexé qui porte la clé primaire du système source. C’est la décision la plus rentable de la conception de migration, et elle ne coûte rien.

Avec un external ID, vous pouvez utiliser upsert, qui s’appuie sur ce champ pour décider de créer ou de mettre à jour un enregistrement. Si la valeur n’est pas trouvée, un enregistrement est créé; si elle l’est une fois, l’enregistrement est mis à jour; si elle l’est plusieurs fois, une erreur est renvoyée plutôt qu’un doublon. Chaque chargement devient idempotent, ce qui veut dire que vous pouvez le lancer deux fois sans doubler vos données, ce qui veut dire que vous pouvez répéter.

Deux détails mordent. Le rapprochement par external ID n’ignore la casse que si le champ porte l’attribut Unique et l’option correspondante, faute de quoi ABC123 et abc123 sont deux enregistrements distincts. Et si le champ est un external ID sans index unique, le compte qui charge a besoin de la permission View All Data.

Migrer l’historique ou migrer ce qui sert

La demande par défaut est de tout faire passer. Elle est presque toujours mauvaise, et elle coûte cher de trois manières distinctes.

Elle coûte en effort de migration, parce que les données les plus anciennes sont les plus sales et consomment du temps de nettoyage sans rapport avec leur valeur. Elle coûte en stockage, et le stockage est un poste réel: les orgs Enterprise, Professional et Unlimited disposent d’une allocation de 10 Go de stockage de données plus 20 Mo par licence utilisateur, donc 50 utilisateurs Enterprise font 11 Go au total, et non 11 Go par utilisateur. Et elle coûte en adoption, parce qu’un système plein d’enregistrements morts apprend aux utilisateurs à se méfier des résultats de recherche.

La position défendable consiste à migrer intégralement les enregistrements ouverts et récents, à migrer les enregistrements clos sur la période dont l’entreprise rend réellement compte, et à archiver le reste dans un endroit lisible. Conserver des données personnelles dont vous n’avez pas l’usage relève du passif plutôt que de l’actif: pour une fois, l’argument du stockage et celui de la conformité pointent dans le même sens.

Configuration contre code

Toute exigence dans Salesforce peut être satisfaite en déclaratif, en code, ou par un mélange, et ce choix détermine ce que le système coûtera à détenir pendant la décennie qui suit. La distinction mérite d’être tenue au clair même si vous n’ouvrez jamais un éditeur.

Ce qui doit être déclaratif

Déclaratif veut dire construit par configuration: objets, champs, mises en page, règles de validation et Flow, l’atelier d’automatisation visuel de Salesforce. Cela se modifie par un administrateur, cela survit aux montées de version parce que Salesforce possède le moteur d’exécution, et cela reste visible pour quiconque a la bonne permission.

Le guide de décision sur l’automatisation déclenchée par enregistrement publié par Salesforce donne un seuil exploitable. Il mesure la densité d’automatisation sur trois axes: le nombre d’automatisations déclenchées par un même changement de donnée, le volume d’enregistrements par transaction, et la profondeur des mises à jour en cascade vers les objets liés. Une densité faible, soit moins de quinze automatisations, des lots de 1 à 200 enregistrements et au plus une écriture en aval, relève du Flow déclenché par enregistrement.

Le même guide donne une règle qui économise plus d’argent que toutes les autres de cette liste: un seul point d’entrée par objet. Mélanger Flow et triggers Apex sur le même objet, c’est ainsi que les bugs d’ordonnancement deviennent permanents.

Quand le code sur mesure a raison

La densité moyenne relève d’un hybride, où Flow orchestre et où de l’Apex invocable fait le gros du travail, de sorte que la séquence reste visible pendant que le calcul se loge dans quelque chose de testable. La densité forte relève franchement des triggers Apex, parce qu’à ce stade on emploie l’outillage déclaratif à bâtir un système pour lequel il n’a pas été conçu.

Le code a également raison quand la logique est réellement complexe, quand elle doit être testée unitairement pour de bon, et quand la même opération est appelée depuis plusieurs points d’entrée et ne devrait exister qu’une fois. Si vous commandez ce travail au lieu de le recruter, nos services de développement logiciel existent exactement pour cette frontière, là où la plateforme s’arrête et où l’ingénierie sur mesure commence.

Le vocabulaire bouge, et un vocabulaire périmé est un signal

Salesforce retire des outils, et une proposition écrite contre des outils retirés indique quand elle a réellement été rédigée. Salesforce a cessé de prendre en charge Workflow Rules et Process Builder le 31 décembre 2025. Les règles existantes continuent de tourner, mais il n’y a plus de support client ni de correctifs, et le chemin recommandé est la migration vers Flow Builder avec l’outil Migrate to Flow.

Le coût de long terme de chaque choix

Le déclaratif est moins cher à construire et moins cher à modifier, et son coût est la dilution: cent flows non documentés font un système où personne ne peut prévoir ce que déclenchera l’enregistrement d’une fiche.

Le code est plus cher à construire et bien moins cher à raisonner à l’échelle, parce qu’il se lit, se versionne et se teste. Son coût est qu’il réclame des développeurs, et une organisation sans développeur Salesforce et sans contrat de maintenance finira par ne plus pouvoir modifier son propre système.

L’échec le plus coûteux n’est ni l’un ni l’autre. C’est un système bâti entièrement en déclaratif par un partenaire qui s’en va ensuite, dans un org sans documentation et sans propriétaire nommé. Tout marche et rien ne peut être modifié sans risque, ce qui est la position d’un logiciel sur mesure laissé sans entretien, décrite longuement dans notre article sur ce que coûte vraiment la maintenance logicielle.

L’intégration, et pourquoi les limites changent l’architecture

L’intégration a son traitement à part dans notre article sur les limites d’intégration Salesforce et leur coût réel. Ce qui a sa place ici, c’est que les limites de la plateforme sont une donnée d’architecture, pas un détail d’exploitation découvert en semaine neuf.

Deux limites font l’essentiel de la mise en forme. Les allocations totales de requêtes API d’un org en Enterprise Edition sont de 100 000 appels par 24 heures, plus le nombre de licences multiplié par les appels que porte chaque type de licence, soit 1 000 pour une licence Salesforce, plus les add-ons achetés. L’exemple chiffré publié par Salesforce est un org Enterprise doté de 15 licences Salesforce qui obtient 115 000 requêtes. L’allocation vaut pour tout l’org et non par utilisateur, et les requêtes entrantes concurrentes qui durent 20 secondes ou plus sont plafonnées à 25 en production.

La seconde tient aux governor limits d’Apex, appliquées par transaction: 100 requêtes SOQL en synchrone et 200 en asynchrone, 50 000 enregistrements ramenés par SOQL, 150 instructions DML, 10 000 enregistrements traités par DML, 6 Mo de heap en synchrone et 12 Mo en asynchrone, et 10 000 millisecondes de temps CPU en synchrone contre 60 000 en asynchrone.

Une conception qui les ignore passe la recette sur vingt enregistrements et échoue au premier vrai chargement de nuit. Ce n’est pas un bug. C’est une décision d’architecture prise par défaut.

Les environnements, et ce que détruit un rafraîchissement de sandbox

Salesforce vous donne quatre types de sandbox aux stockages et aux intervalles de rafraîchissement différents, et un mauvais choix est une erreur de planning qui se révèle tard.

Une sandbox Developer tient 200 Mo et se rafraîchit une fois par jour. Developer Pro tient 1 Go, également chaque jour. Partial Copy tient 5 Go, copie un échantillon des données de production défini par un modèle, et se rafraîchit tous les cinq jours. Full réplique la production et se rafraîchit tous les 29 jours. L’Enterprise Edition inclut 25 sandbox Developer et une Partial Copy; les sandbox Full arrivent avec Unlimited et Performance, ou s’achètent en add-on.

L’intervalle de 29 jours des sandbox Full est la contrainte autour de laquelle on planifie trop tard. Votre seul environnement réaliste de répétition de migration se rafraîchit une fois par mois: une répétition qui révèle un problème coûte donc un mois avant de pouvoir répéter proprement. Deux répétitions en sandbox Full font une fenêtre de neuf semaines, pas de quinze jours.

Les sandbox Developer et Developer Pro ne copient que les métadonnées: tout ce qu’un développeur y a chargé pour tester disparaît au rafraîchissement. Les données de test doivent être un script rejouable tenu en gestion de versions, sinon l’équipe perd une journée par rafraîchissement à les recréer à la main.

Gestion des livraisons: change sets ou pipeline

Vous ne pouvez pas développer d’Apex dans un org de production: chaque changement commence ailleurs et doit être déplacé. La façon dont il se déplace est une décision à longue traîne.

Les change sets sont le mécanisme intégré. Ils ne transportent que ce que vous pouvez modifier depuis Setup, jamais des enregistrements, ils exigent une connexion de déploiement entre orgs rattachés au même org de production, et un change set entrant se déploie d’un bloc plutôt que composant par composant. Ils s’assemblent en cliquant: ils ne sont donc ni diffables, ni relisables, ni reproductibles, et le même change set assemblé deux fois par deux personnes différera.

Cela fonctionne pour un petit org avec un seul administrateur et des livraisons mensuelles. Cela cesse de fonctionner dès que deux personnes modifient le même org, parce qu’il n’y a ni fusion ni historique, et que la trace de ce qui est parti vit dans la mémoire de quelqu’un.

L’alternative est une pipeline pilotée par les sources: métadonnées dans Git, changements relus sous forme de diffs, déploiements lancés depuis une branche. Cela coûte quelques jours à mettre en place et transforme la gestion des livraisons en exercice reproductible plutôt qu’en exercice de mémoire. À partir de deux personnes qui construisent, traitez-la comme une part du build et non comme une amélioration pour plus tard.

La règle des 75% de couverture n’est pas un critère de qualité

Déployer de l’Apex en production exige que les tests unitaires couvrent au moins 75% de votre code Apex et que ces tests passent. Salesforce dit explicitement que la couverture indique l’efficacité des tests sans la garantir, et que les tests doivent vérifier un comportement.

Lisez ce que cela signifie commercialement. 75%, c’est une barrière, et les barrières se contournent. Des classes de test écrites pour atteindre le chiffre plutôt que pour vérifier quoi que ce soit passeront, se déploieront et n’attraperont rien. Quand vous relisez le travail d’un partenaire, ne demandez pas le pourcentage de couverture. Demandez à voir trois méthodes de test et comptez les assertions.

Une implémentation Salesforce échoue à l’adoption, pas à la mise en production

Le système passe en production, le projet se clôt, la facture est payée, et huit mois plus tard le directeur commercial fait toujours son forecast dans un tableur. Rien n’a cassé. C’est l’issue la plus fréquente d’un programme Salesforce raté, et elle est invisible pour toute mesure technique.

L’économie est brutale parce que le coût de licence continue quoi qu’il arrive. Cinquante utilisateurs Enterprise à £140 par mois font £84 000 par an, que le système serve ou non: un taux d’adoption de 40% représente donc environ £50 000 par an de pur gaspillage sur la seule licence, avant même d’amortir le coût d’implémentation sur quoi que ce soit.

L’adoption est aussi le seul mode de défaillance que l’équipe technique ne peut pas réparer. Un partenaire peut construire exactement ce qui a été spécifié, satisfaire chaque critère de recette, et laisser derrière lui quelque chose que personne n’ouvre. C’est pourquoi la définition du fini, en découverte, doit porter sur l’usage, et pourquoi le projet ne devrait pas être considéré comme clos à la mise en production.

Les pratiques qui déplacent l’adoption

Quatre choses font bouger l’adoption de façon fiable, et aucune n’est une vidéo de formation.

Une formation par rôle, dispensée séparément. Un commercial et un directeur commercial utilisent des parties différentes du système pour des raisons différentes, et une session commune forme mal les deux. Formez chaque rôle sur son propre flux de travail, et sur rien d’autre.

Un petit jeu de champs obligatoires. Retenez le minimum de champs qui font fonctionner le reporting, rendez ceux-là obligatoires, et laissez tout le reste facultatif. Chaque champ obligatoire supplémentaire est une raison d’abandonner une fiche à mi-parcours, et un système qui punit la saisie en obtient moins.

Un reporting managérial qui dépend de la donnée. C’est la pratique qui marche. Si la revue de pipeline hebdomadaire se tient depuis un tableau de bord Salesforce, sans tableur dans la salle, la donnée est saisie, parce que l’alternative est d’être absent de la conversation. Si le manager garde un tableur privé, le CRM est facultatif et tout le monde le sait.

Un propriétaire nommé, avec du temps dans sa semaine. Pas un comité. Une personne qui possède l’org, détient les droits d’administration, est évaluée sur l’adoption et dispose d’heures pour cela. Les orgs qui n’en ont pas se dégradent dès le premier mois.

Les modes de défaillance et leurs signaux avancés

Six modes de défaillance expliquent l’essentiel des échecs d’implémentation Salesforce qu’on nous demande de réparer, et chacun se signale bien avant que le dommage n’apparaisse.

Reproduire un processus cassé. Le signal est un document d’exigences qui décrit le système actuel plutôt que le résultat voulu, avec les noms de champ de l’ancien système. Automatiser un mauvais processus le rend plus rapide et plus difficile à changer.

Une personnalisation sans bornes. Le signal est un journal de demandes de changement où rien n’a jamais été refusé. L’Enterprise Edition autorise 500 champs personnalisés par objet et 200 objets personnalisés, assez de marge pour construire une chose que personne ne peut maintenir bien avant d’atteindre une limite de plateforme.

Aucun propriétaire unique. Le signal est que la réponse à la question de savoir qui possède Salesforce contient le mot et.

Tout migrer. Le signal est un périmètre de migration défini par un nombre d’enregistrements au lieu d’une décision de rétention.

Aucune discipline d’environnement de test. Le signal est quelqu’un qui dit de faire le changement directement en production, puisque ce n’est qu’une valeur de picklist.

Mesurer la mise en production plutôt que l’usage. Le signal est un plan de projet dont le dernier jalon est une date et non un nombre.

Délais pour les implémentations petites, moyennes et complexes

La durée et la charge sont deux questions distinctes, que les acheteurs confondent. Voici nos fourchettes maison issues du marché intermédiaire britannique, et non des chiffres publiés.

Une petite implémentation, jusqu’à 25 utilisateurs sur un seul cloud, avec au plus une intégration et une source de données propre, tient en 6 à 10 semaines et 20 à 45 jours-consultant. Une implémentation moyenne, 25 à 150 utilisateurs sur un ou deux clouds, avec deux à quatre intégrations et une vraie migration, tient en 4 à 7 mois et 90 à 220 jours. Un programme complexe, plus de 150 utilisateurs, multi-cloud, cinq intégrations ou plus et plusieurs pays, tient en 9 à 18 mois et 400 jours et plus.

Dans ces totaux, la découverte pèse 10 à 15% de la charge, la configuration et le build 30 à 40%, la migration des données 20 à 30% et bien plus si la source est mauvaise, l’intégration 10 à 20%, et les tests, la formation et l’hypercare 15 à 20%. Le poste qui gonfle, à chaque fois, c’est la migration.

La durée dépasse la charge divisée par la taille de l’équipe pour des raisons étrangères à l’équipe: intervalles de rafraîchissement des sandbox, disponibilité des parties prenantes pour la recette, et attente du tiers dont vous consommez l’API. Qui porte ce risque relève du contrat, et c’est pourquoi la question du forfait face à la régie compte plus sur un projet CRM qu’ailleurs.

La protection des données britannique dans un programme CRM

Un CRM est une base de données de personnes: le UK GDPR s’applique donc à peu près à tout ce qu’il contient, et trois questions reviennent à chaque implémentation.

Faut-il une DPIA ?

Les orientations de l’ICO sur les cas où une DPIA est requise posent la règle générale de l’article 35(1), selon laquelle une DPIA est nécessaire lorsque le traitement est susceptible d’engendrer un risque élevé pour les droits et libertés des personnes, et listent l’ensemble d’opérations propre à l’ICO au titre de l’article 35(4).

Deux d’entre elles tombent en plein sur une migration CRM typique. Le data matching, défini comme le fait de combiner, comparer ou rapprocher des données personnelles obtenues de plusieurs sources, est exactement ce que fait une migration de consolidation. Le profilage à grande échelle couvre le scoring des leads et des comptes. L’ICO note aussi que dans la plupart des cas la combinaison de deux des critères européens indique qu’une DPIA est nécessaire, sans que ce soit une règle stricte. Notez que ces orientations sont actuellement en cours de révision à la suite du Data (Use and Access) Act: consultez-les plutôt que de vous fier à un résumé.

Où se trouvent réellement les données ?

Salesforce est une plateforme mondiale, et l’instance sur laquelle tourne votre org relève du contrat, pas de la supposition. Le guide bref de l’ICO sur les transferts internationaux, mis à jour le 15 janvier 2026, propose un test en trois temps: le UK GDPR s’applique-t-il au traitement, êtes-vous à l’origine du transfert vers une organisation située hors du Royaume-Uni, et le destinataire est-il une entité juridique distincte. Trois oui en font un transfert restreint.

Les transferts restreints exigent des règles d’adéquation britanniques, des garanties appropriées telles que l’International Data Transfer Agreement, l’Addendum ou des règles d’entreprise contraignantes, ou bien une dérogation. Lorsque vous vous appuyez sur des garanties, l’ICO attend une évaluation des risques du transfert. C’est une revue contractuelle, pas une tâche d’ingénierie, et elle doit avoir lieu avant la migration plutôt qu’après.

Votre partenaire d’implémentation est un sous-traitant

Quand un partenaire configure votre org, charge vos données et détient des identifiants d’accès, il traite des données personnelles pour votre compte. Les orientations de l’ICO sur les responsables de traitement et les sous-traitants exposent ce qui en découle, et les conséquences pratiques sont contractuelles.

Il vous faut un accord écrit couvrant les instructions documentées, la confidentialité, la sécurité, les sous-traitants ultérieurs, les droits d’audit, et la suppression ou la restitution des données à la fin de la mission. C’est cette dernière clause qui manque le plus souvent. Un partenaire qui a détenu onze mois durant une copie complète de votre base clients dans une sandbox Full, et dont le contrat ne dit rien de sa suppression, est un passif ouvert de votre côté de la ligne, pas du sien.

Ce qu’il faut demander à un partenaire pressenti

Six questions, et les réponses qui devraient mettre fin à la conversation.

Demandez ce que produit la découverte. Si la réponse est une proposition plutôt qu’une cartographie de processus, un modèle de données, un inventaire des intégrations et une définition du fini mesurable, on vous vend quelque chose, on ne le cadre pas.

Demandez comment et quand ils profileront les données source. Si le profilage intervient après l’accord sur l’estimation de migration, l’estimation est une devinette.

Demandez quel est leur choix par défaut en automatisation, et écoutez s’ils parlent de densité. Un partenaire qui répond toujours Flow ou toujours Apex n’a qu’un outil. Un partenaire qui prévoit Process Builder en 2026 n’a pas lu un avis de retrait depuis trois ans.

Demandez comment les changements passent de la sandbox à la production. Les change sets sont acceptables pour un org à un seul administrateur, et un avertissement au-delà.

Demandez qui possède l’org après la mise en production et combien d’heures par semaine cela représente. S’ils ne savent pas répondre, l’adoption n’est le problème de personne.

Demandez ce qu’il advient de vos données dans leurs sandbox à la fin de la mission, et obtenez la réponse dans le contrat plutôt que dans un e-mail. La discipline exposée dans notre guide de la due diligence technique s’applique ici aussi: vérifiez l’affirmation au lieu d’accepter l’assurance.

Quand la réponse n’est pas Salesforce

Si vous avez moins d’une dizaine d’utilisateurs, aucune exigence d’intégration et un processus qui tient dans un pipeline à cinq étapes, la licence Enterprise et son implémentation sont toutes deux plus grandes que le problème. Un CRM moins cher, ou la Starter Suite à £20 par utilisateur, fait l’affaire et pourra être remplacé plus tard à un coût absorbable.

Si votre besoin réel est un flux de travail qu’aucun produit ne couvre et que tout le reste est déjà traité, vous achetez une plateforme pour héberger une seule application. C’est généralement un cas pour un système construit à dessein, et notre travail de développement logiciel sur mesure part de cette prémisse. La décision entre construire et acheter se joue sur la question de savoir si le processus différenciant est le coeur du métier ou un détail autour.

Si personne ne va posséder le système, ne l’achetez pas. C’est la chose la plus difficile à dire pendant un cycle de vente et le prédicteur de gaspillage le plus fiable. Un CRM sans propriétaire n’échoue pas bruyamment. Il devient discrètement une copie du tableur qu’il devait remplacer, à £140 par utilisateur et par mois.

Et si l’objectif est une couche d’agents IA plutôt qu’un CRM, elle se pose sur une implémentation qui fonctionne au lieu de la remplacer. L’économie en est traitée dans notre article sur ce que coûte réellement Agentforce.

Mettre le travail dans l’ordre

L’ordre qui fonctionne est: profiler les données, mener une découverte jusqu’à quatre livrables, convenir du modèle standard et chiffrer chaque écart, construire sur un seul point d’entrée d’automatisation par objet, répéter la migration deux fois en sandbox Full, former par rôle, et tenir le projet ouvert jusqu’à ce qu’un chiffre d’usage soit atteint plutôt qu’une date.

L’ordre qui échoue est: signer, configurer, migrer tard, former une fois, passer en production à la date prévue, clore le projet.

Mecanik travaille sur les parties de tout cela qui relèvent de l’ingénierie et non de l’administration de licences: conception d’intégration face aux vraies limites de la plateforme, profilage et outillage de migration, développement sur mesure là où la configuration s’arrête, et le travail front-end qui met les données CRM devant les clients. Nos pages services de développement logiciel et recrutement de développeur web expliquent comment nous intervenons. Si vous voulez un second avis sur l’estimation d’un partenaire avant de signer, vous pouvez recruter un développeur pour cette seule revue.

Questions fréquentes

Combien coûte une implémentation Salesforce au Royaume-Uni ? Salesforce affiche Sales Cloud Enterprise à £140 par utilisateur et par mois au Royaume-Uni en facturation annuelle, soit £84 000 par an de licences pour 50 utilisateurs. Notre estimation maison pour les services d’implémentation par-dessus va de 0,5 à 1 fois la dépense de licence de première année pour un déploiement quasi standard, de 1 à 3 fois pour un projet typique du marché intermédiaire, et de 3 à 5 fois pour un programme multi-cloud avec données héritées et forte personnalisation.

Combien de temps prend une implémentation Salesforce ? Nos fourchettes maison sont de 6 à 10 semaines et 20 à 45 jours-consultant jusqu’à 25 utilisateurs sur un seul cloud avec des données propres, de 4 à 7 mois et 90 à 220 jours pour 25 à 150 utilisateurs avec deux à quatre intégrations, et de 9 à 18 mois et 400 jours et plus pour un programme multi-cloud avec migration de données héritées. La migration est la phase qui gonfle, parce que sa charge suit la qualité des données source et non le nombre d’enregistrements.

Pourquoi les implémentations Salesforce échouent-elles ? Presque toujours à l’adoption plutôt qu’à la mise en production. Un système techniquement correct que personne n’utilise est une perte sèche assortie d’une facture de licence qui continue. Les causes courantes sont la reproduction d’un processus cassé, une personnalisation sans bornes, l’absence de propriétaire unique nommé, la migration de tout l’historique, l’absence de discipline sur les environnements de test, et la mesure de la mise en production au lieu de l’usage.

Faut-il construire Salesforce en configuration ou en code sur mesure ? Le guide de décision publié par Salesforce fixe le seuil par la densité d’automatisation. Moins de quinze automatisations sur un objet, des lots de 1 à 200 enregistrements et au plus une écriture en aval relèvent du Flow déclenché par enregistrement. La densité moyenne convient à un Flow qui orchestre de l’Apex invocable. La densité forte convient aux triggers Apex. Utilisez un seul point d’entrée par objet plutôt que de mélanger Flow et triggers Apex sur le même.

Avons-nous besoin d’une DPIA pour une implémentation Salesforce ? Souvent oui. L’ICO cite le data matching, c’est-à-dire la combinaison ou la comparaison de données personnelles issues de plusieurs sources, et le profilage à grande échelle parmi les opérations qui indiquent qu’une DPIA est requise, et une migration de consolidation avec scoring des leads fait les deux. Ces orientations sont en cours de révision à la suite du Data (Use and Access) Act: vérifiez la position actuelle de l’ICO plutôt qu’un résumé.