Reprise de projet Salesforce : décider quoi garder, corriger et livrer

Mis à jour le 15 octobre 2026.

Le projet devait simplifier le travail. Pourtant, les équipes continuent à tenir leurs fichiers à côté du CRM, les demandes s’accumulent et chaque correction semble en déplacer une autre. La direction reçoit des comptes rendus, mais peine à savoir ce qui fonctionne, ce qui reste à faire et ce qu’il faut décider.

Une reprise de projet Salesforce commence par ces questions. Elle doit permettre au responsable CRM, au sponsor et aux utilisateurs de retrouver une vision commune du travail à accomplir. Changer de prestataire ou refaire une application peut faire partie des décisions ; il faut d’abord savoir ce que l’on conserve et pourquoi.

Ce guide présente notre méthode de préparation d’une reprise : préserver l’activité, examiner quelques parcours importants, comparer les options puis organiser des livraisons vérifiables. Les exemples sont fictifs. Ils montrent les décisions à prendre, sans présumer de l’état de votre organisation ni du budget nécessaire.

Déterminer ce qui relève vraiment d’une reprise

Un incident isolé ne justifie pas à lui seul un nouveau projet. Si un utilisateur rencontre un message d’erreur ou qu’une synchronisation vient de s’arrêter, commencez par qualifier le problème Salesforce. Cette première analyse vise à rétablir un fonctionnement précis.

La reprise devient un sujet plus large lorsque plusieurs difficultés se combinent : périmètre mal compris, livraisons non acceptées, dépendances inconnues, absence de pilote ou succession de corrections sans décision d’ensemble. Le problème peut concerner un processus, une intégration ou tout un programme. Il faut le délimiter avant de promettre un audit de l’intégralité du CRM.

Nous recommandons de commencer par trois questions :

• Quelles activités doivent continuer pendant les travaux ?
• Quels résultats attendus ne sont pas obtenus aujourd’hui ?
• Qui peut décider des priorités et accepter une livraison ?

Les réponses évitent de confondre une attente fonctionnelle, une anomalie et un désaccord sur le périmètre. Elles font aussi apparaître les décisions qui appartiennent au client. Un intégrateur peut expliquer les conséquences d’un choix ; il ne peut pas décider seul quel service doit passer en premier.

Préserver les accès et la continuité du service

Avant toute modification, identifiez les personnes et les systèmes qui font fonctionner l’organisation : administrateurs, utilisateurs d’intégration, comptes de service, applications connectées, dépôts de code et outils de déploiement. L’objectif est de savoir qui détient les accès, à quoi ils servent et qui pourra intervenir pendant la transition.

Organisez cette passation avec les personnes habilitées. Une suppression brutale du compte utilisé par une interface peut interrompre un flux qui fonctionne encore. À l’inverse, conserver indéfiniment tous les accès d’un ancien intervenant ne constitue pas une passation. Préparez leur transfert ou leur retrait avec un contrôle du fonctionnement attendu. Le référentiel de confiance Salesforce traite notamment la gestion des identités, les autorisations et les échanges entre systèmes.

Il faut aussi distinguer les données des métadonnées, c’est-à-dire la configuration et les développements. Une sauvegarde de l’un ne prouve pas que l’autre est couvert. Salesforce explique cette distinction et les possibilités de sauvegarde dans ses bonnes pratiques de protection des données. Avant une opération importante, vérifiez ce qui est sauvegardé, où se trouve la copie et comment une restauration serait réalisée.

Un environnement de test sert à préparer et vérifier les changements. Sa seule existence ne démontre pas que le plan de restauration est adapté. Demandez une réponse opérationnelle : en cas de problème, qui intervient, sur quel périmètre et avec quelles conséquences pour les équipes ?

Enfin, distinguez la disponibilité de la plateforme et celle de votre propre fonctionnement métier. Les responsabilités de fiabilité liées aux intégrations, à la récupération et au comportement de la solution sont décrites dans le guide Salesforce sur la fiabilité. Un CRM accessible peut néanmoins produire des données incorrectes si une interface ne fait plus son travail.

Diagnostiquer à partir des parcours métier

Une liste de composants techniques ne dit pas si le projet répond au besoin. Choisissez quelques parcours représentatifs et faites-les exécuter par les personnes qui travaillent réellement dans Salesforce. Par exemple : qualifier une demande, préparer un devis, affecter un dossier ou clôturer une intervention.

Pour chaque parcours, relevez l’attendu, le résultat observé et les étapes réalisées hors du CRM. Un fichier Excel n’est pas automatiquement un problème ; il peut révéler une information manquante, une règle mal comprise ou une fonction qui n’a jamais été livrée. Il faut comprendre son rôle avant de proposer de le supprimer.

Rapprochez ensuite ces observations des éléments disponibles : périmètre validé, comptes rendus, demandes de changement, démonstrations et résultats de recette. Un document ancien peut expliquer une décision ; il ne prouve pas que la configuration actuelle lui correspond encore. Quand une information manque, inscrivez la vérification nécessaire plutôt que de transformer une supposition en anomalie certaine.

L’examen technique suit les parcours retenus : objets et champs utilisés, règles d’accès, automatisations, développements, interfaces et dépendances. Notre page sur l’audit Salesforce présente ce travail d’analyse. Dans une reprise, la restitution doit surtout aider à décider de la suite : quels constats sont établis, quels risques demandent une action et quelles inconnues empêchent encore un chiffrage fiable ?

Réparer, refondre une partie ou revoir le besoin

Le choix mérite une comparaison explicite. Une refonte n’efface ni les données à reprendre, ni les interfaces à maintenir, ni le temps demandé aux utilisateurs. Une correction locale peut, de son côté, prolonger une organisation devenue difficile à faire évoluer.

Prenons un exemple fictif : les devis d’un éditeur de logiciels prennent trop de temps à produire. Il serait prématuré de refaire toute la chaîne commerciale. Le diagnostic peut montrer que les produits sont bien décrits, mais que les règles de validation et les modèles de documents se contredisent. Une première option serait alors de reprendre ce lot en conservant les comptes, les opportunités et les interfaces qui fonctionnent.

Dans un autre contexte, ces mêmes difficultés pourraient venir d’un modèle de données inadapté. Le résultat du diagnostic serait différent. Ce qui compte est de pouvoir expliquer l’option retenue, ses limites et les éléments qui pourraient conduire à la revoir.

Demandez une estimation qui sépare les travaux identifiés des investigations restantes. Un budget présenté avant l’examen des dépendances doit être traité selon son niveau de précision. Les conditions de réalisation doivent aussi nommer les validations et les disponibilités attendues du client.

Obtenir des livrables qui servent à travailler

Une reprise ne devrait pas laisser seulement un rapport. Les documents utiles sont ceux qui permettent de livrer, de vérifier ou de reprendre un sujet sans refaire toute l’enquête. Leur profondeur dépend du périmètre retenu.

Demandez des documents accessibles à votre équipe, avec une date et un responsable de mise à jour. Un inventaire généré automatiquement peut aider à collecter l’existant ; il faut encore relier les composants aux usages pour qu’il soit exploitable. Pour un traitement important, on doit pouvoir comprendre son déclenchement, les données utilisées, le résultat attendu et la personne à prévenir en cas d’échec.

Donner un ordre aux travaux

Le backlog rassemble les demandes, mais il ne décide pas à votre place. Commencez par distinguer les sujets qui empêchent l’activité, ceux qui créent un risque, ceux qui réduisent un travail répétitif et ceux qui améliorent le confort. Un responsable métier doit pouvoir arbitrer entre ces catégories.

Pour chaque lot, prévoyez une description du besoin, une estimation, les dépendances et les critères de validation. Le budget et le contenu sont approuvés avant la réalisation. Si la découverte d’une dépendance modifie l’effort, rendez cet écart visible avant d’engager les travaux supplémentaires.

Le planning doit montrer les validations autant que la réalisation. Une semaine pendant laquelle le client doit choisir une règle de gestion ne se confond pas avec une semaine de développement. Intégrez les disponibilités des décideurs, les congés connus et les échéances métier. La bibliothèque de feuilles de route Salesforce illustre notamment la représentation de l’ordre des fonctionnalités et de leurs dépendances.

Dans notre fonctionnement, un interlocuteur identifié suit les sujets avec le client. Le rythme des échanges dépend du projet. Chaque point doit permettre de savoir ce qui est terminé, ce qui attend une décision et ce qui peut être lancé ensuite. Multiplier les réunions sans tenir cette liste n’améliore pas la visibilité.

Accepter les livraisons et préparer l’autonomie

Une démonstration réussie ne suffit pas à prouver qu’une livraison convient. Faites vérifier les parcours importants avec les bons types d’utilisateurs et des données représentatives. Prévoyez aussi les refus attendus : accès à une information confidentielle, action hors périmètre ou opération répétée par erreur.

La recette doit produire un résultat : accepté, refusé avec une anomalie décrite, ou accepté avec des réserves clairement suivies. Le métier valide le résultat de son usage ; l’équipe de réalisation vérifie les composants et les conséquences sur l’existant. Les deux regards sont nécessaires. Salesforce recommande notamment de maîtriser les environnements, le versionnement et les déploiements dans son guide d’excellence opérationnelle.

Préparez ensuite la mise en production : créneau, responsable, contrôles après livraison et réponse à un éventuel problème. Une modification des données peut demander un traitement différent d’un retour à une configuration précédente. Le scénario doit être défini pour le lot concerné.

L’autonomie se prépare pendant la reprise. Votre équipe doit savoir où trouver la documentation, comment signaler un problème et quelles opérations elle peut réaliser elle-même. À la fin, vous devez pouvoir confier le suivi à une autre personne sans perdre les décisions prises. Une fois le projet stabilisé, la maintenance et le support Salesforce organisent les corrections et les évolutions récurrentes selon vos besoins.