Combien de temps dure un projet Salesforce en ETI ? Les durées réelles par périmètre

La première question posée à un intégrateur est rarement le prix : c'est le délai. « Dans combien de temps mes équipes utiliseront-elles l'outil ? » Pour une ETI, la réponse dépend d'un nombre limité de facteurs — le périmètre fonctionnel, le nombre d'intégrations, la qualité des données existantes et la disponibilité des équipes internes. Cet article propose des fourchettes de durée réalistes par type de projet, et surtout les leviers qui expliquent pourquoi deux projets « équivalents » peuvent varier du simple au triple.

Ce qui détermine vraiment la durée d'un projet

Avant de donner des fourchettes, il faut comprendre que la durée d'un projet Salesforce n'est pas proportionnelle au nombre de licences. Une ETI de 400 salariés peut déployer plus vite qu'une PME de 60 personnes si son besoin est standard et ses données propres. Quatre variables pèsent l'essentiel :

• Le périmètre fonctionnel : un seul cloud (Sales, par exemple) avec des processus standard, ou plusieurs clouds interconnectés avec de fortes personnalisations.
• Le nombre et la complexité des intégrations : ERP, outil de facturation, marketing, téléphonie, chaque connexion ajoute du temps de conception et de recette.
• La qualité des données à reprendre : une reprise depuis un CRM propre est rapide ; une consolidation de plusieurs fichiers Excel et bases historiques peut à elle seule occuper plusieurs semaines.
• La disponibilité des équipes internes : c'est le facteur le plus sous-estimé. Un projet ralentit dès que les référents métier ne peuvent pas participer aux ateliers.

Les durées réelles par périmètre

Déploiement d'un cloud standard (Sales ou Service)

Il s'agit du cas le plus fréquent en ETI : mettre en place un CRM commercial ou un outil de gestion de tickets, avec des processus proches des standards Salesforce et peu de développements spécifiques. Sur ce périmètre, un cadrage rigoureux suivi d'une mise en production par lots permet généralement d'obtenir un outil utilisable en 2 à 4 mois. La reprise de données simple, la formation des utilisateurs et une ou deux intégrations légères tiennent dans cette fenêtre.

Déploiement avec personnalisation avancée

Dès que l'ETI a des processus métier spécifiques — un cycle de vente atypique, des règles d'affectation complexes, des objets personnalisés, des automatisations poussées — le temps de conception et de recette augmente. Comptez plutôt 4 à 8 mois. L'allongement vient moins du développement que des allers-retours de validation et des tests sur des cas de figure nombreux.

Projet multi-cloud ou transformation CRM

Interconnecter Sales, Service et Marketing Cloud, ou remplacer un système historique central relié à l'ERP, relève d'un programme plutôt que d'un projet ponctuel. Ces initiatives se déroulent souvent sur 9 à 18 mois, généralement découpées en phases livrées séparément. Le découpage en lots est ici une bonne pratique : il évite l'effet « tunnel » et met de la valeur entre les mains des utilisateurs plus tôt.

Intégrations lourdes avec le SI

Quand le cœur du projet est la connexion à un ERP, à un outil de facturation ou à une plateforme e-commerce, la durée dépend surtout de la maturité de ces systèmes tiers. Une API documentée et disponible accélère tout ; à l'inverse, un ERP ancien sans interface standard peut ajouter plusieurs mois. Le chantier d'intégration se chiffre le plus souvent en 2 à 6 mois, en parallèle ou après le déploiement fonctionnel.

Les phases d'un projet et leur poids dans le calendrier

Quelle que soit la taille, un projet Salesforce suit des étapes comparables. Comprendre leur poids relatif aide à situer où le temps est réellement consommé :

• Cadrage et conception : formaliser les besoins, prioriser, concevoir le modèle de données. Souvent 15 à 25 % du temps total, mais déterminant pour la suite.
• Configuration et développement : la part visible, mais rarement la plus longue sur un périmètre standard.
• Reprise et migration des données : régulièrement sous-estimée, elle peut représenter une charge importante quand les sources sont multiples.
• Recette et tests : les allers-retours de validation métier s'étirent quand les référents ne sont pas disponibles.
• Formation et déploiement : la mise en production n'est pas la fin ; l'adoption se joue dans les semaines qui suivent.

Pourquoi les délais annoncés dérapent

Les dépassements de calendrier viennent rarement de la technique. Les causes les plus fréquentes sont organisationnelles :

• Un périmètre qui gonfle en cours de route : chaque nouvelle demande « tant qu'on y est » repousse la mise en production. Un périmètre gelé pour la première version protège le planning.
• Des équipes internes indisponibles : sans référents métier mobilisés, les décisions traînent et la recette s'allonge.
• Une gouvernance floue : sans sponsor clairement identifié et sans décisionnaire, les arbitrages s'éternisent.
• Une reprise de données mal anticipée : voir l'alerte ci-dessus.

À l'inverse, les projets qui tiennent leurs délais partagent souvent la même approche : un premier périmètre volontairement resserré, mis en production rapidement, puis enrichi par itérations. Cette logique de lots met de la valeur entre les mains des utilisateurs plus tôt et sécurise l'adoption.

Comment estimer la durée de votre projet

Pour obtenir une fourchette fiable avant même de consulter un intégrateur, quelques questions structurent l'estimation :

• Combien de clouds ou de modules sont concernés dans la première version ?
• Combien de systèmes tiers faut-il connecter, et disposent-ils d'API standard ?
• Dans quel état sont les données à reprendre, et depuis combien de sources ?
• Quels référents métier seront disponibles, et à quelle fréquence ?
• Le projet peut-il être découpé en lots livrables indépendamment ?

Ces réponses valent plus qu'une estimation au doigt mouillé. Elles permettent aussi de comparer objectivement les propositions de plusieurs intégrateurs : un prestataire qui annonce un délai très inférieur aux autres sur un même périmètre doit pouvoir expliquer précisément comment il y parvient.

Un planning réaliste plutôt qu'optimiste

Un projet Salesforce en ETI se mesure donc en mois, pas en semaines dès que le périmètre dépasse un cloud standard. La bonne question n'est pas « combien de temps au minimum ? » mais « quel premier périmètre peut apporter de la valeur rapidement, sans hypothéquer la suite ? ». Un cadrage honnête, qui identifie tôt les risques liés aux données et à la disponibilité des équipes, vaut mieux qu'un calendrier flatteur qui dérapera de toute façon.

Chez INTEGREER, le point de départ est la qualification de votre besoin à partir de données publiques et de vos contraintes réelles, pour vous orienter vers des intégrateurs capables de tenir un délai crédible sur votre périmètre — et non celui qui promet le plus court.