La Réponse Courte
Ces trois options ne se situent pas sur le même continuum. Le Repair (réparation) s'attaque au symptôme, le Refactor (refactorisation) modifie l'implémentation sans altérer le comportement, et le Rebuild (reconstruction) transforme le modèle sous-jacent. La décision est guidée par une question unique : le problème réside-t-il dans la manière dont les choses ont été implémentées, ou dans ce qui a été défini dès le départ ?
Si le modèle de données est sain et que la douleur provient d'automatisations complexes ou d'autorisations labyrinthiques, il s'agit d'un Refactor. Si le même objet est utilisé par trois processus contradictoires et qu'il est impossible de le rapporter, c'est un problème fondamental, et un Rebuild entre alors en considération.
Quatre Tests Décisionnels
| Test | Indique un Refactor | Indique un Rebuild |
|---|---|---|
| Modèle de Données | Sain, souffre d'un excès de champs | Objets servant des intentions contradictoires |
| Source de la Douleur | Performances, duplication d'automatisations | Impossibilité de rapporter ou d'étendre |
| Étendue des Utilisateurs Affectés | Partielle, peut être isolée | Horizontale à travers tous les processus |
| Coût des Tests Répétitifs | Zone unique testable | Tout changement nécessite une régression complète |
Trois indicateurs convergeant dans la même direction suffisent pour prendre une décision. Une divergence entre les indicateurs signifie généralement que le problème est plus localisé qu'il n'y paraît.
Pourquoi un Rebuild est Plus Coûteux que Prévu
L'estimation habituelle comptabilise la reconstruction elle-même. Elle ignore presque toujours quatre aspects : la migration des données historiques avec toutes leurs exceptions accumulées, la reconstruction des intégrations (chacune agréée avec une partie tierce), une période de fonctionnement parallèle où les deux systèmes coexistent, et une formation complète de tous les utilisateurs.
En réalité, ces quatre éléments représentent souvent plus de la moitié du coût. Une organisation qui envisage un Rebuild sans les avoir évalués compare une pomme à une demi-orange.
L'Approche Pragmatique : Remplacement Progressif
Même lorsque la décision est au Rebuild, l'exécution en tant que projet "arrêter et remplacer" est un risque en soi. L'approche qui fonctionne est le remplacement domaine par domaine :
- Construire le nouveau modèle en parallèle de l'ancien – de nouveaux objets, sans toucher à l'existant.
- Migrer un processus complet – avec ses utilisateurs, ses données et ses rapports.
- Désactiver l'équivalent ancien – c'est l'étape que la plupart des organisations repoussent, et c'est ce qui double le projet.
- Répéter jusqu'à ce que l'ancien système soit vide.
L'étape trois est le test décisif. Un système où l'ancien et le nouveau cohabitent pendant une année a généré des coûts supplémentaires sans réduire la dette technique.
Ce Qui Doit Changer en Tout Cas
Les deux approches échouent si le mécanisme de changement reste inchangé. Une gouvernance minimale – qui approuve une modification du modèle, quels tests obligatoires avant le déploiement, et qui est le propriétaire de chaque domaine – est la condition préalable pour éviter de revenir au point de départ. La priorisation spécifique de la dette est détaillée dans Priorisation de la dette technique Salesforce, et les signes avant-coureurs sont dans 8 signes d'une mise à niveau système Salesforce.
Résumé
Le choix n'est pas entre "réparer" et "recommencer à zéro", mais entre corriger une implémentation et corriger une définition. Dans la plupart des cas qui semblent exiger un Rebuild, se cache en réalité un modèle de données sain, enseveli sous une décennie d'automatisations – et cela se nettoie par vagues, pas par une suppression radicale.