La mise en production donne souvent l’impression que le projet est terminé. En réalité, c’est le moment où l’application rencontre les vrais utilisateurs, les vrais volumes, les vrais incidents et les vraies habitudes.
Si l’après go-live n’est pas organisé, l’équipe projet reste sollicitée en urgence, l’équipe run découvre les comportements trop tard et les métiers ne savent plus où remonter les problèmes.
Pour une application métier sur mesure, cette phase est critique : un défaut de support peut bloquer des opérations internes, des commandes, des validations, des exports ou des reprises.
Le bon passage de relais doit être préparé avant la mise en production, puis piloté pendant une période courte mais très structurée.
Pourquoi le go-live ne termine pas le projet
Le go-live marque le début de l’usage réel. Les tests ont réduit le risque, mais ils n’ont pas reproduit toutes les situations : données historiques, comportements utilisateurs, pics de charge, erreurs de saisie, contraintes support et exceptions métier.
L’équipe projet conserve souvent le contexte le plus riche, tandis que l’équipe run doit apprendre vite. Sans organisation, la responsabilité reste entre deux mondes.
Le premier mois révèle les angles morts
Les problèmes qui apparaissent après mise en production ne sont pas toujours des bugs. Ils peuvent révéler une règle mal comprise, une formation insuffisante, un usage inattendu ou une procédure support manquante.
Le run a besoin de contexte, pas seulement d’accès
Donner les accès aux outils ne suffit pas. L’équipe run doit comprendre les parcours critiques, les alertes, les décisions prises et les risques acceptés.
Identifier la zone grise entre projet et run
La zone grise apparaît quand personne ne sait si un sujet relève encore du projet, du support, de la maintenance ou d’un nouvel arbitrage métier.
Elle se voit dans des phrases simples : “ce n’est plus dans le projet”, “le support ne connaît pas”, “il faut demander aux développeurs”, “le métier doit trancher”.
Nommer les catégories de demandes
Il faut distinguer incident bloquant, bug, anomalie mineure, demande d’évolution, question utilisateur, problème de données, besoin de formation et dette à traiter plus tard.
Définir le canal de chaque catégorie
Un canal unique peut recevoir les demandes, mais la qualification doit être claire. Chaque catégorie doit avoir un responsable, un délai cible et un mode de décision.
Organiser le support des premières semaines
Les premières semaines doivent être traitées comme une période spécifique. L’équipe projet ne doit pas disparaître, mais elle ne doit pas non plus devenir le support permanent.
Créer un support renforcé temporaire
Pendant deux à six semaines, selon la criticité, un dispositif renforcé permet de traiter vite les retours, corriger les vrais blocages et enrichir les procédures.
Prévoir des points courts et fréquents
Des points quotidiens ou bihebdomadaires permettent de qualifier les retours, prioriser les actions et éviter que les demandes se dispersent dans les canaux informels.
Documenter pendant que les questions arrivent
Les questions utilisateurs et support sont une matière précieuse. Elles révèlent ce qui doit être clarifié dans l’interface, la formation ou les procédures.
Qualifier incidents, bugs et demandes d’évolution
Après mise en production, toutes les demandes semblent urgentes. Sans qualification, l’équipe traite ce qui fait le plus de bruit, pas ce qui protège le plus le produit.
Un incident bloque l’exploitation
Il doit être traité vite, avec diagnostic, contournement si possible, correction, vérification et communication aux personnes concernées.
Un bug doit être relié à un comportement attendu
La correction doit partir d’une règle claire. Sinon l’équipe risque de corriger un symptôme sans traiter la vraie cause.
Une évolution doit rejoindre la gouvernance produit
Une demande utile n’est pas forcément urgente. Elle doit être priorisée avec les autres besoins, pas absorbée dans la période de stabilisation par réflexe.
Clarifier qui décide quoi après mise en production
L’après go-live échoue souvent parce que les responsabilités étaient claires pendant le projet, mais floues dès que le produit est utilisé.
Qui priorise les corrections ?
Les corrections doivent être classées par impact utilisateur, risque métier, fréquence, contournement possible et risque technique.
Qui valide les changements rapides ?
Une correction peut sembler évidente mais modifier une règle métier. Le sponsor ou le responsable produit doit rester disponible pour les arbitrages sensibles.
Qui communique avec les utilisateurs ?
Le support ne doit pas improviser. Il lui faut des messages clairs : incident connu, contournement, délai, correction prévue, changement de comportement.
Le guide Répartir rôles et responsabilités entre client et intégrateur aide à rendre ces décisions explicites.
Transférer la connaissance sans couper trop tôt
Le transfert vers le run doit être progressif. Une documentation livrée en bloc ne remplace pas l’apprentissage par cas réels.
Faire traiter des tickets ensemble
Les premiers tickets doivent être qualifiés avec l’équipe projet et l’équipe run. Cela permet d’expliquer le raisonnement, pas seulement la réponse.
Mettre à jour les runbooks
Chaque incident ou question récurrente doit enrichir les procédures : symptômes, diagnostic, contournement, correction, escalade et communication.
Le guide Transmettre la connaissance d’un logiciel interne à plusieurs personnes prolonge ce sujet.
Définir une période de stabilisation
La stabilisation n’est pas une période floue où tout est accepté. Elle doit avoir une durée, des règles, des priorités et des indicateurs.
Fixer ce qui entre dans la stabilisation
Les incidents, anomalies critiques, corrections d’usage et ajustements indispensables peuvent entrer dans ce cadre. Les nouvelles envies doivent être traitées séparément.
Suivre des indicateurs simples
Nombre d’incidents, délai de résolution, types de demandes, retours utilisateurs, erreurs récurrentes et sujets escaladés permettent de voir si le produit se stabilise vraiment.
Le guide Faut-il internaliser la maintenance d’une application sur mesure ? aide à choisir le modèle de maintien après cette phase.
Savoir quand l’équipe projet peut se retirer
L’équipe projet peut se retirer quand le run sait qualifier les demandes, traiter les incidents courants, escalader les sujets complexes et maintenir les procédures.
Critère 1 : les incidents critiques baissent
Le produit ne sera jamais sans défaut, mais les incidents bloquants doivent devenir rares et compréhensibles.
Critère 2 : le support sait répondre
Si les questions courantes reviennent encore aux développeurs, le relais n’est pas terminé.
Critère 3 : les évolutions ont une file claire
Les demandes d’amélioration doivent rejoindre une gouvernance produit, pas rester mélangées aux incidents.
Guides complémentaires pour sécuriser le relais
Ces guides aident à organiser run, maintenance, responsabilités et transmission après mise en production.
Aligner développement et opérations
Le guide Faire collaborer développeurs et opérations sans conflit permanent détaille les responsabilités entre construction et exploitation.
Choisir le modèle de maintenance
Le guide Faut-il internaliser la maintenance d’une application sur mesure ? aide à décider du bon relais durable.
Clarifier les responsabilités
Le guide Répartir rôles et responsabilités entre client et intégrateur évite les zones grises après mise en production.
Transmettre le savoir produit
Le guide Transmettre la connaissance d’un logiciel interne à plusieurs personnes sécurise la reprise par plusieurs acteurs.
Conclusion : le run se prépare avant le go-live
L’après go-live ne doit pas être une improvisation. C’est une phase organisée, avec support renforcé, qualification des demandes, responsabilités claires, transfert de connaissance et critères de sortie.
Plus le relais est préparé tôt, moins l’équipe projet reste prisonnière du produit et plus l’équipe run peut agir avec confiance.
Dawap accompagne les projets de développement d’application métier sur mesure avec cadrage, mise en production, stabilisation, organisation du run, maintenance et transfert de connaissance pour que le produit reste maîtrisé après son lancement.
