Le go-live est signé. Le prestataire a plié ses câbles. La direction a célébré la mise en production. Et dès le lendemain matin, les tickets arrivent. Un utilisateur ne trouve plus son bouton de validation. Un traitement nocturne a planté. La clôture du mois arrive dans deux semaines et personne ne sait comment la réaliser dans le nouveau système.
Bienvenue dans la phase hypercare.
Cette période, souvent sous-estimée dans les plannings projet, conditionne pourtant le succès réel de votre déploiement ERP. Les 45 jours qui suivent le go-live sont plus critiques que les 18 mois qui précèdent. Cet article vous donne une méthode opérationnelle pour traverser cette fenêtre de risque sans épuiser vos équipes ni exposer votre entreprise à une instabilité prolongée.
Qu’est-ce que la phase hypercare ERP et pourquoi elle est critique
Définition : hypercare, support normal et TMA
La phase hypercare est la période d’accompagnement intensif qui commence immédiatement après le go-live. Elle se distingue du support normal et de la TMA (Tierce Maintenance Applicative) par trois caractéristiques.
La présence de l’intégrateur est renforcée. En hypercare, les consultants qui ont construit l’ERP sont encore disponibles sur vos incidents. En TMA standard, vous traitez avec une équipe support qui peut n’avoir pas participé au déploiement initial.
Les délais sont contractuellement plus courts. Un incident P1 en hypercare doit être pris en charge en 30 minutes, pas en 4 heures. L’enjeu est différent : votre entreprise vient de basculer sur un système qu’elle ne maîtrise pas encore.
La durée est limitée et définie. L’hypercare ne dure pas indéfiniment. Elle a une date de fin, des critères de sortie mesurables et une transition formalisée vers le support normal. Ce n’est pas du support permanent déguisé sous une autre étiquette.
Les 3 semaines les plus à risque après le go-live
Les retours terrain convergent sur un constat : les trois premières semaines concentrent la grande majorité des incidents post go-live.
La semaine 1 est celle de la découverte réelle. Les utilisateurs rencontrent l’écart entre la formation théorique et la réalité opérationnelle. Les cas d’usage atypiques, jamais couverts en recette, remontent massivement. Les interfaces avec les systèmes tiers (banque, logistique, e-commerce) révèlent leurs fragilités au passage en volumétrie réelle.
La semaine 2 est celle des premiers cycles opérationnels complets. Les commandes du premier jour doivent être livrées, facturées, encaissées. Les flux qui n’ont pas été testés sous charge montrent leurs limites de performance.
La semaine 3 est celle de la fatigue. L’équipe projet a travaillé à plein régime depuis le go-live. Les key users sont sollicités à la fois pour supporter leurs collègues et assurer leurs propres responsabilités métier. C’est à ce moment que les raccourcis et les contournements s’installent, parfois durablement.
Ce qui se passe quand on saute l’hypercare
Ne pas prévoir de phase hypercare formelle n’empêche pas les incidents de se produire. Cela empêche seulement de les traiter efficacement.
Les conséquences sont prévisibles : l’équipe projet se dissout dans les jours qui suivent le go-live, les incidents critiques sont traités dans l’urgence sans traçabilité, les utilisateurs développent des contournements qui deviennent permanents, et l’intégrateur répond “dans les meilleurs délais” sans obligation contractuelle.
Résultat : six mois après le go-live, l’ERP est en production, mais son adoption réelle est partielle. Les bénéfices attendus tardent à se matérialiser, et personne ne comprend pourquoi.
Organiser l’équipe hypercare
Composition minimale : war room, point focal, escalade
La cellule hypercare repose sur trois piliers organisationnels.
La war room peut être physique ou virtuelle, selon la géographie de vos équipes. Un canal Teams ou Slack fermé avec les bonnes personnes remplit parfaitement ce rôle. La war room ne doit pas être le canal de support général : elle est réservée à la résolution des incidents actifs, pas aux questions d’utilisation courante.
Le point focal interne est le chef de projet ou l’AMOA qui centralise tous les incidents, arbitre les priorités et décide d’escalader ou non vers l’intégrateur. Ce rôle exige une disponibilité à 100 % pendant la période hypercare. Ne confiez pas ce rôle à quelqu’un qui a d’autres responsabilités opérationnelles en parallèle.
Le circuit d’escalade éditeur est le lien contractuel entre votre point focal et le support de l’éditeur ERP. Il doit être activé uniquement pour les incidents que l’intégrateur ne peut pas résoudre seul (bugs produit, anomalies cloud, incidents de disponibilité). Définissez ce circuit avant le go-live, pas pendant.
Rôles pendant l’hypercare
| Acteur | Rôle hypercare | Disponibilité attendue |
|---|---|---|
| Chef de projet client | Point focal, arbitrage des priorités | 100 % |
| Key users | Support de proximité niveau 1, remontée d’incidents | 50 à 70 % |
| Consultants intégrateurs | Résolution incidents N2, corrections paramétrage | Selon contrat (voir SLA) |
| DSI / équipe interne | Supervision infrastructure, accès systèmes | Astreinte disponible |
| Direction métier | Validation des décisions de paramétrage | Disponible sous 24h |
Le modèle en 3 niveaux de support
Une organisation hypercare efficace fonctionne sur 3 niveaux distincts.
Niveau 1 : support de proximité. Les key users répondent aux questions d’utilisation standard. Ils n’escaladent que ce qu’ils ne peuvent pas résoudre eux-mêmes. Ce niveau filtre la grande majorité des remontées et préserve la disponibilité des consultants pour les vrais incidents.
Niveau 2 : résolution. Les consultants intégrateurs traitent les incidents fonctionnels et techniques que les key users ne peuvent pas résoudre : paramétrage, workflows, interfaces avec les systèmes tiers.
Niveau 3 : escalade éditeur. Les bugs produit et anomalies de la couche cloud remontent vers le support éditeur. Ce niveau doit rester exceptionnel. Si vous vous retrouvez à l’activer régulièrement, c’est un signal que l’intégrateur n’a pas correctement qualifié les incidents avant escalade.
Durée recommandée : 30 jours standard, 45 jours pour ERP critique
Pour un déploiement standard (PME, 1 à 3 modules), une hypercare de 30 jours est généralement suffisante si les critères de sortie sont bien définis et atteints.
Pour un déploiement critique (ETI, multi-sites, modules finance et production activés simultanément, première clôture mensuelle à absorber dans la fenêtre), prévoyez 45 jours. Ce n’est pas une règle arbitraire : c’est le temps nécessaire pour traverser un premier cycle complet de clôture comptable sous l’ERP et valider la stabilité des processus de bout en bout.
Au-delà de 60 jours, une hypercare qui s’allonge est le signe d’un problème structurel : soit le go-live était prématuré, soit le scope projet a été sous-estimé. Prolonger l’hypercare ne règle pas le problème sous-jacent.
Définir les SLA de la phase hypercare
Niveaux de criticité et délais contractuels
Le tableau ci-dessous constitue le cadre de référence pour une hypercare ETI. Adaptez les délais à votre contexte, mais ne remontez pas au-dessus de ces seuils pour les niveaux P1 et P2.
| Niveau | Définition | Prise en charge | Résolution cible |
|---|---|---|---|
| P1 Bloquant | Processus métier critique à l’arrêt (commandes, facturation, paie) | 30 minutes | 4 heures ouvrées |
| P2 Majeur | Fonctionnalité impactée, contournement possible mais dégradé | 2 heures | 24 heures ouvrées |
| P3 Mineur | Gêne fonctionnelle sans impact sur la continuité opérationnelle | 4 heures | 5 jours ouvrés |
| P4 Amélioration | Demande d’évolution ou d’optimisation hors périmètre urgent | À planifier | Hors hypercare |
Ce qui doit figurer dans le contrat d’intégration
La majorité des litiges post go-live sur le support naissent de contrats d’intégration qui définissent l’hypercare de façon vague. Les clauses non négociables sont les suivantes.
La composition nominative de l’équipe hypercare. Pas “un consultant senior disponible”, mais le prénom et le rôle précis de la personne. Vous avez le droit de demander les personnes qui connaissent votre projet.
Les horaires de couverture. Un créneau 8h-18h en jours ouvrés ne couvre pas un go-live avec des utilisateurs en décalé ou une infrastructure cloud avec des traitements nocturnes. Négociez une astreinte P1 hors horaires si vos processus le nécessitent.
Les critères de sortie de l’hypercare. La fin de la phase hypercare ne doit pas être une date calendaire, mais le franchissement de seuils mesurables : volume de tickets P1 en dessous d’un palier pendant un nombre défini de jours consécutifs, taux de connexion utilisateur au-dessus d’un seuil, première clôture réalisée. Ce point est souvent absent des contrats et constitue la principale source de divergence au moment de la transition.
La procédure d’escalade éditeur. Identifiez contractuellement qui, chez l’intégrateur, porte la relation avec le support éditeur pendant l’hypercare. Vous ne devez pas avoir à négocier cet accès en urgence lors d’un incident P1.
Pénalités et clauses de performance
Des pénalités contractuelles sur les SLA hypercare sont légitimes pour les projets ETI. La modalité pratique : une pénalité fixe (en crédits de jours de service) par dépassement de SLA P1 ou P2, plafonnée à un pourcentage du montant du contrat de maintenance.
L’objectif n’est pas de sanctionner systématiquement l’intégrateur, mais de s’assurer que le SLA est un engagement réel, pas une déclaration d’intention sans conséquence.
Les 12 indicateurs à surveiller pendant l’hypercare
Indicateurs de stabilité technique
| # | Indicateur | Fréquence | Seuil d’alerte |
|---|---|---|---|
| 1 | Temps de réponse des transactions clés (commande, facture, stock) | Quotidien | > 3 secondes |
| 2 | Taux d’erreur applicative dans les logs serveur | Quotidien | > 1 % des transactions |
| 3 | Jobs batch en échec (clôtures nocturnes, interfaces) | Quotidien | Tout échec non corrigé sous 4h |
| 4 | Disponibilité système (uptime) | Continu | < 99,5 % sur 7 jours glissants |
Indicateurs d’adoption utilisateur
| # | Indicateur | Fréquence | Seuil d’alerte |
|---|---|---|---|
| 5 | Volume de tickets ouverts par semaine et par département | Hebdomadaire | Pas de baisse après semaine 3 |
| 6 | Taux de connexion quotidien par profil métier | Quotidien | < 75 % des utilisateurs cibles |
| 7 | Volume d’appels directs aux key users vs tickets formels | Hebdomadaire | > 2× le volume des tickets formels |
| 8 | Taux d’abandon de processus (sessions interrompues) | Hebdomadaire | > 15 % sur les processus clés |
Indicateurs métier
| # | Indicateur | Fréquence | Seuil d’alerte |
|---|---|---|---|
| 9 | Taux de saisie des commandes dans l’ERP vs volume réel | Hebdomadaire | < 85 % |
| 10 | Délai de traitement commande vs baseline pré-go-live | Hebdomadaire | > 120 % de la baseline |
| 11 | Conformité EDI et interfaces (rejets, erreurs de format) | Quotidien | Tout rejet non traité au-delà de 24h |
| 12 | Délai de clôture comptable mensuelle vs baseline | Mensuel | > 150 % de la baseline |
Les indicateurs 9 à 12 sont les plus importants pour la direction : ils mesurent si l’ERP génère de la valeur réelle, pas seulement s’il fonctionne techniquement. Un ERP disponible à 99,9 % mais dont les commandes continuent d’être saisies sur Excel est un échec d’adoption, pas un succès d’infrastructure.
La sortie de l’hypercare : critères de passage au support normal
Checklist de validation avant de passer en TMA
Ne fermez pas la phase hypercare par défaut calendaire. Chaque critère de cette checklist doit être validé avant la transition vers le support normal.
Stabilité technique
- Aucun incident P1 ouvert depuis 10 jours ouvrés consécutifs
- Taux d’erreur applicative inférieur à 0,5 % sur 2 semaines glissantes
- Tous les jobs batch s’exécutent sans intervention manuelle depuis 2 semaines
- Première clôture mensuelle réalisée dans l’ERP avec un écart comptable nul
Adoption utilisateur
- Taux de connexion supérieur à 80 % sur l’ensemble des profils actifs
- Volume de tickets hebdomadaire en baisse sur 3 semaines consécutives
- Key users autonomes sur les cas d’usage standards (validé en entretien)
- Procédures de support niveau 1 documentées et accessibles à l’équipe
Contractuel
- Procès-verbal de fin d’hypercare signé par le client et l’intégrateur
- Périmètre TMA post-hypercare confirmé par avenant ou contrat signé
- Équipe de support TMA présentée et opérationnelle
- Circuit d’escalade éditeur transféré sur le nouveau contrat de maintenance
Documenter les incidents pour enrichir la base de connaissance
La phase hypercare produit une base de connaissance précieuse si vous la tracez correctement. À la sortie de la période, compilez un rapport des incidents en indiquant pour chaque cas : la description, la cause racine identifiée, la solution appliquée et les modifications de paramétrage ou de procédure qui en découlent.
Ce document a trois usages. Il enrichit la base de connaissance du support. Il sert de référence lors des prochains incidents similaires. Il constitue la traçabilité des décisions de paramétrage prises en urgence pendant les 45 premiers jours, quand tout le monde était sous pression et les modifications peu documentées.
Ne remettez jamais ce travail à plus tard. À 3 mois du go-live, les personnes qui ont résolu les incidents ne se souviennent plus des détails.
Pour structurer la stabilisation et la montée en compétence dans les semaines qui suivent la fermeture de l’hypercare, notre checklist des 90 premiers jours post-go-live prend le relais avec une méthodologie phasée J31-J60 et J61-J90. Pour anticiper les résistances utilisateurs dès la phase hypercare, notre article sur le programme super-utilisateurs ERP détaille comment recruter, former et animer votre réseau de key users. Enfin, si vos indicateurs montrent des signaux de rejet silencieux malgré une hypercare bien pilotée, nos 8 KPI pour détecter le rejet silencieux post-go-live vous donnent le diagnostic et le plan de remédiation.
