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.
Le vrai enjeu n’est pas de transférer une application, mais de transférer la capacité de décider et d’agir lorsqu’elle se comporte autrement que prévu. Sans organisation, l’équipe projet reste sollicitée en urgence, le 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. Ce guide propose un dispositif, des seuils et des preuves dans une trajectoire de développement web sur mesure pensée jusqu’à l’exploitation.
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.
Deux signaux faibles apparaissent avant la bascule : les alertes ne sont lues que par les développeurs du projet, puis les scénarios de recette ne précisent jamais l’action du support. Le produit peut être fonctionnel et pourtant inexploitable par l’équipe censée le maintenir.
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.
La preuve utile est un exercice exécuté par le run : retrouver une commande, qualifier son état, appliquer un contournement autorisé et communiquer. Si l’équipe projet souffle chaque commande, le transfert n’est pas acquis, même lorsque la documentation est complète.
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.
Créez une matrice courte : impact, urgence, contournement, source de vérité et niveau d’escalade. Une erreur de libellé ne doit pas interrompre la même équipe qu’un blocage de facturation. La classification est corrigée après traitement si le diagnostic révèle une autre cause.
Le coût caché de la zone grise se trouve dans les transferts : un ticket passe du support au projet, puis au métier et revient sans décision. Mesurez le nombre de réaffectations et le délai avant première action utile. Une cible locale peut limiter à un seul transfert les incidents critiques.
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.
La durée dépend du cycle métier. Une application de clôture mensuelle ne peut pas être déclarée stable après dix jours calmes. Le dispositif doit traverser au moins un cycle représentatif, un pic de volume et une opération sensible avant de réduire la présence projet.
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.
Le journal de stabilisation conserve date, parcours, identifiant de corrélation, impact, cause, action et personne responsable. Les données sensibles restent masquées. Une revue quotidienne transforme les répétitions en amélioration d’écran, test, alerte ou fiche de support.
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 perturbe l’exploitation
Il réduit la qualité du service ou interrompt tout ou partie de l’exploitation. Sa priorité dépend de l’impact et de l’urgence ; son traitement associe 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.
Cas concret : des gestionnaires demandent un export supplémentaire le lendemain du lancement, tandis qu’un rapprochement comptable produit deux écritures sur un rejeu. L’export rejoint la feuille produit ; le double effet bloque l’extension et déclenche une correction avec test de reprise. La nouveauté de la demande ne définit pas sa priorité.
Contre-intuitivement, corriger immédiatement toutes les gênes peut ralentir la stabilisation. Chaque livraison ajoute un changement à observer et complique le diagnostic. Regroupez les améliorations réversibles dans une cadence connue, mais déployez séparément les corrections qui protègent argent, droits ou intégrité des données.
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.
La responsabilité technique couvre diagnostic, correction et rollback ; le produit arbitre les comportements ; le run gère l’incident et la communication ; le métier valide les modes dégradés. Un rôle peut être tenu par la même personne dans une petite équipe, mais chaque décision conserve un titulaire et un suppléant.
L’entrée d’un incident, sa sortie attendue, les dépendances, les seuils et la journalisation sont inscrits dans la procédure. Une seconde section précise l’instrumentation, les accès et le repli. Ces éléments évitent que l’escalade se limite à transmettre une capture sans contexte.
Pour rendre ces décisions explicites, appuyez-vous sur Répartir rôles et responsabilités entre client et intégrateur.
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.
Dans le cadre « Mettre à jour les runbooks », la ressource Transmettre la connaissance d’un logiciel interne à plusieurs personnes prolonge ce sujet.
Le transfert suit trois temps : le projet traite et explique, le run traite sous observation, puis le run agit seul avec le projet en appui. Utilisez de vrais tickets, y compris une question utilisateur et une erreur de données. La dernière étape se termine par une trace mise à jour par le run lui-même.
Organisez une simulation avant la sortie : couper une API, bloquer un worker ou interrompre une migration. Le run détecte, évalue l’impact, choisit le contournement et exécute le rollback. Le projet observe les zones de doute plutôt que de diriger l’exercice.
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.
Pour choisir le modèle de maintien après cette phase, appuyez-vous sur Faut-il internaliser la maintenance d’une application sur mesure ?.
Suivez le percentile de résolution plutôt qu’une moyenne, la part de réouverture, les reprises manuelles et les escalades sans preuve. Une baisse du volume peut cacher des utilisateurs qui ont renoncé. Croisez les tickets avec les événements du workflow, les appels au support et les données métier attendues.
Le seuil de sortie est convenu avant le lancement : aucun incident critique ouvert, reprise testée, moins de 10 % de tickets mal qualifiés sur deux semaines et autonomie du run sur les parcours fréquents, par exemple. Ces valeurs restent locales et doivent couvrir un cycle représentatif.
Pour qui le relais renforcé devient indispensable
Le dispositif est indispensable lorsque l’application pilote des commandes, des droits, une facturation, une production ou un portail client exposé. Il l’est aussi lorsqu’une migration de données, un changement d’équipe ou un partenaire externe augmentent le risque de perte de contexte.
Une petite évolution réversible sur un outil bien connu peut nécessiter une surveillance plus légère. Le même principe demeure : responsabilité, canal et procédure. La durée et le nombre de réunions s’adaptent au risque ; la capacité de retrouver et corriger un dossier ne se négocie pas.
Le sponsor protège la priorité de stabilisation, le produit tranche les comportements, le projet apporte le contexte et le run construit l’autonomie. Les utilisateurs clés qualifient les contournements acceptables. Sans sponsor disponible, les désaccords deviennent des incidents prolongés.
Erreurs fréquentes pendant le passage au run
Fermer le projet le soir du lancement
La disponibilité projet chute au moment où le terrain produit le plus de connaissances. Prévoyez une décroissance explicite et une capacité réservée. Le retrait dépend des critères de sortie, pas seulement d’une date budgétaire.
Mélanger correction et nouvelle feuille de route
Une période sans frontière absorbe toutes les attentes et multiplie les changements. Séparez la stabilisation, qui restaure la promesse, des évolutions, qui modifient le produit. Le même comité peut arbitrer, mais les files et les critères restent distincts.
Transmettre des documents sans faire pratiquer
Lire un schéma ne prouve pas que l’équipe sait réagir sous contrainte. Faites exécuter diagnostic, déploiement et reprise avec les droits réels. Chaque difficulté rencontrée améliore la procédure avant qu’un incident ne l’impose.
Conserver des canaux parallèles
Les messages directs accélèrent un cas et détruisent la vision collective. Toute demande reçoit un identifiant et une qualification, même si l’alerte initiale arrive par téléphone. La communication d’urgence ne remplace pas la trace.
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.
- D’abord, vérifier que le run qualifie seul les incidents et retrouve la source opposable.
- Ensuite, réduire la présence projet lorsque les reprises courantes suivent les seuils convenus.
- Puis, différer le retrait sur les domaines encore dépendants d’un accès ou d’une personne unique.
- Enfin, refuser la sortie si une opération critique ne possède aucun rollback testé.
Plan d’action de J-15 à J+30
Avant le lancement : fermer les responsabilités et les preuves
À J-15, inventoriez les parcours critiques, les alertes, les traitements planifiés, les intégrations et les procédures de reprise. Attribuez chaque signal à une personne, un suppléant et un délai. Le produit valide les états visibles et les contournements autorisés.
À J-7, le run exécute une répétition : recherche d’un dossier, coupure d’une dépendance, correction de donnée encadrée et retour arrière. Les entrées, sorties, droits, seuils et journaux sont vérifiés. Tout geste qui dépend d’une consigne orale bloque la préparation du domaine concerné.
Première semaine : observer sans disperser les décisions
Du lancement à J+7, utilisez un canal unique, une revue quotidienne et un tableau des incidents par impact. Le run conduit la qualification ; le projet apporte le contexte ; le produit tranche. Chaque correction précise le test, le déploiement, la surveillance et le rollback.
Le support communique avec un vocabulaire stable : connu, contourné, en correction ou résolu. L’instrumentation relie le frontend, l’API, les workers et les données par une corrélation. Une performance dégradée possède un seuil et un mode dégradé, pas seulement une alerte rouge.
J+8 à J+30 : inverser la conduite et décider la sortie
Le run traite progressivement seul les demandes courantes, met à jour les procédures et présente les indicateurs. Le projet n’intervient qu’après une escalade qualifiée. Une revue hebdomadaire transforme les récurrences en tests, améliorations de l’outil métier ou éléments de la prochaine feuille produit.
Décision de sortie. Réduisez l’équipe projet lorsque le run tient les délais, exécute les reprises et explique les états. Différez sur les domaines qui conservent une dépendance unique. Refusez une clôture globale si un incident critique, une migration ou une responsabilité restent sans preuve.
- D’abord, maintenir le binôme projet-run sur les parcours financiers ou irréversibles.
- Ensuite, confier au run les demandes fréquentes dont la procédure a déjà été éprouvée.
- Puis, différer le retrait si une alerte ou un accès dépend encore d’une personne unique.
- Enfin, refuser la clôture tant que le rollback d’un déploiement n’a pas été exécuté par le run.
Après J+30, conservez une revue mensuelle des incidents, performances, changements d’API et dettes de l’outil métier. Elle relie les données du support aux tests et à l’architecture, afin que le retour au rythme produit ne fasse pas disparaître les enseignements du lancement.
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
La frontière entre construction et exploitation est approfondie dans la méthode pour faire collaborer développeurs et opérations sans conflit permanent.
Clarifier les responsabilités
Pour fermer les zones grises du relais, la méthode pour répartir rôles et responsabilités entre client et intégrateur fournit un cadre de décision explicite.
Transmettre le savoir produit
La reprise par plusieurs acteurs se prépare avec la méthode pour transmettre la connaissance d’un logiciel interne à plusieurs personnes et vérifier les relais sur des cas réels.
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.
La période de stabilisation doit produire une équipe run capable, des procédures éprouvées et une feuille produit distincte. Ces preuves autorisent le retrait progressif du projet sans abandonner les utilisateurs au premier incident atypique.
Le bilan conserve enfin les incidents significatifs, les décisions, les seuils ajustés et les dettes acceptées. Cette mémoire permet au prochain déploiement de repartir d’un dispositif éprouvé, plutôt que de recréer une cellule de crise et de redécouvrir les mêmes dépendances.
Pour préparer cette continuité dans votre développement web sur mesure, Dawap peut vous accompagner pour organiser le lancement, les exercices de reprise, la stabilisation et le transfert de connaissance avec les équipes produit et exploitation.
