Aller au contenu
HPI Pro — Salesforce consulting and implementation
Langue

Support et amélioration continue

Salesforce ne s'arrête pas le jour du “go-live”.

L'organisation, les utilisateurs et les processus continuent d'évoluer. Notre modèle de maintenance continue permet de maintenir, d'améliorer et d'étendre le système de manière documentée, priorisée et mesurable, sans accumuler de nouvelle dette technique.

Cycle de contrôle opérationnel

Un cycle opérationnel, pas une liste de requêtes

La différence entre un support qui éteint les incendies et une maintenance qui génère de la valeur est un cycle fermé : chaque requête est mesurée, priorisée, livrée et vérifiée, et le résultat alimente le cycle suivant.

Cycle de contrôle opérationnel

  1. 01

    Réception

    Un canal unique de requêtes avec classification, responsable et statut visible.

  2. 02

    Priorisation

    Classification conjointe par impact commercial, risque et effort.

  3. 03

    Construction et test

    Construit dans un bac à sable, testé en acceptation et déployé de manière contrôlée.

  4. 04

    Mesure et apprentissage

    Rapport d'activité, métriques d'adoption et révision des exceptions.

↻ Le cycle se répète : chaque itération alimente la priorisation de la suivante

Le cycle fonctionne à une cadence fixe. Une requête qui n'y entre jamais n'existe pas pour les besoins du projet, et cette discipline est précisément ce qui évite le travail par des canaux informels.

Portée de la responsabilité

Ce que la maintenance continue peut inclure

  • Gestion des incidents
  • Support aux utilisateurs
  • Changements et ajustements
  • Flows et automatisation
  • Développement Apex et LWC
  • Rapports et tableaux de bord
  • Gestion des autorisations
  • Qualité des données
  • Surveillance des intégrations
  • Gestion des releases
  • Gestion du backlog
  • Formation et capacitation
  • Gouvernance et revue de conception
  • Feuille de route trimestrielle
  • Réduction de la dette technique
  • Préparation aux releases Salesforce

Modèles

Choisissez en fonction du besoin, pas du forfait

Banque d'heures

Quand cela s'applique
Besoins petits et variables
Ce que vous obtenez
Flexibilité totale pour choisir les tâches
Limite à considérer
Moins adapté à la planification à long terme

Forfait mensuel

Quand cela s'applique
Un flux constant d'améliorations et de support
Ce que vous obtenez
Capacité connue et priorisation mensuelle
Limite à considérer
Nécessite une discipline de priorisation de la part du client

Équipe de livraison continue

Quand cela s'applique
Un système central avec une utilisation étendue
Ce que vous obtenez
Support, développement et maintenance sous la même gestion
Limite à considérer
Un engagement plus large

Architecte à temps partiel

Quand cela s'applique
Une équipe interne existe, mais pas de décideur technique sénior
Ce que vous obtenez
Revue de conception, gouvernance et contrôle de la dette technique
Limite à considérer
Ne remplace pas la capacité de livraison

Projet d'amélioration délimité

Quand cela s'applique
Un objectif défini avec un début et une fin
Ce que vous obtenez
Portée et livrables clairs
Limite à considérer
Ne couvre pas le support continu

Les conditions de prix et de SLA sont discutées lors d'un appel et ne sont pas publiées sur le site Web.

Gouvernance

Quatre mécanismes qui maintiennent un système sain sur le long terme

Revue de conception pour les changements pertinents

Chaque changement qui affecte le modèle de données, les autorisations ou une intégration passe par une revue professionnelle avant d'être construit. Cette étape évite la majeure partie du retrabalho.

Contrôle de la dette technique

Les automatisations dupliquées, les champs non utilisés et les autorisations trop larges sont mesurés et gérés comme des éléments réels du backlog, avec une capacité dédiée allouée.

Préparation aux releases

Salesforce publie trois releases par an. Nous examinons à l'avance ce qui change, ce qui pourrait poser problème et ce qui vaut la peine d'être adopté.

Mesure de l'adoption

Les métriques d'utilisation par rôle révèlent où le processus ne fonctionne réellement pas, avant que les données des rapports ne deviennent peu fiables.

Foire aux questions

Support et maintenance continue — questions fréquentes

Quelle est la différence entre le support et la maintenance continue ?
Le support gère les incidents et les questions des utilisateurs et restaure le système à un état fonctionnel. La maintenance continue s'interroge également sur ce qui doit changer : prioriser les améliorations, contrôler la dette technique, revoir la conception de changements plus complexes et maintenir une feuille de route avec une vision à long terme. Une organisation qui ne fait qu'acheter du support se retrouve avec un système qui fonctionne, mais qui ne s'améliore jamais.
Qu'est-ce qui est considéré comme un incident urgent ?
Un événement qui bloque un processus métier pour un groupe d'utilisateurs sans alternative raisonnable : une défaillance dans la capture de leads, une automatisation clé qui cesse de fonctionner ou une intégration interrompue. Une demande pour un nouveau champ ou un nouveau rapport n'est pas un incident, aussi importante soit-elle. Cette distinction est convenue par écrit à l'avance.
Chaque changement passe-t-il par un environnement de test ?
Oui. Chaque changement pertinent est construit dans un bac à sable, testé par rapport à un scénario métier et seulement ensuite déployé en production dans une fenêtre définie. La seule exception est la correction d'un incident bloquant, et même dans ce cas, elle est documentée et réintègre le circuit standard lors du cycle suivant.
Comment la priorité est-elle décidée ?
Par l'impact sur l'entreprise, le nombre d'utilisateurs affectés, le risque et l'effort, lors d'une réunion de priorisation périodique avec le responsable du processus côté client. Nous ne priorisons pas seuls, car la priorisation est une décision métier, pas technique.
Qu'advient-il de la dette technique accumulée avant de commencer ?
Au début du projet, nous cartographions les automatisations en double, les champs non utilisés, le code non testé et les autorisations trop larges. Les découvertes entrent dans une liste priorisée, et une partie fixe de la capacité mensuelle est allouée pour réduire cette dette ; autrement, elle ne fait qu'augmenter.
Pouvons-nous commencer la maintenance continue même si vous n'avez pas implémenté le système ?
Oui, et c'est un cas courant. Dans cette situation, nous commençons par un bref examen du système qui cartographie l'état actuel, afin que le projet soit basé sur la connaissance et non sur des hypothèses.

Prochaine étape

Examiner un modèle de support

Nous analyserons la portée de l'utilisation, les besoins ouverts et le niveau de gouvernance nécessaire, et proposerons un modèle adapté à votre rythme.