Le lancement rend un logiciel disponible. L’exploiter signifie savoir qui intervient en cas de problème, comment les changements atteignent les utilisateurs et ce que la personne suivante doit comprendre. Ces responsabilités se discutent avant la première version.
Ce guide présente les questions à régler avec un partenaire de développement pour une application web, un produit mobile ou un backend. Le modèle de support dépend de l’application et de l’accord.
Identifier qui contrôle les comptes essentiels
Inventoriez dépôt de code, environnement cloud, domaine, comptes des boutiques, services tiers et fichiers de conception. Notez propriétaires et besoins d’accès. Évitez qu’un compte personnel soit le seul moyen d’accéder à un système critique.
L’accord doit aborder propriété, composants tiers et transfert. Une passation utile explique déploiement, configuration et exploitation. Les identifiants doivent être transférés par un processus sécurisé adapté, plutôt que copiés dans un document général.
Définir le support avant un incident
Convenez du canal de signalement, des informations nécessaires et du responsable de la gravité. Un service indisponible et un défaut visuel demandent des réponses différentes. Objectifs de réponse et horaires doivent figurer dans l’accord de support.
La supervision doit aider l’équipe responsable à repérer le problème et le parcours touché. Un tableau de bord sans responsable ne constitue pas un processus d’incident. Décidez qui traite les alertes, informe les utilisateurs et autorise un retour arrière.
Maintenir le système, pas seulement les écrans
Dépendances, exigences des plateformes, intégrations et usages évoluent. Prévoyez l’évaluation et les tests des mises à jour. Pour les données persistantes, attribuez les sauvegardes et définissez comment vérifier leur restauration.
L’examen de l’infrastructure doit couvrir coûts et performances. Tâches de fond, médias stockés, appels d’API et hausse d’usage peuvent modifier la facture. Notez les hypothèses et réexaminez-les lorsque le produit change.
Faciliter la prochaine version
Gardez une trace courte des décisions : pourquoi choisir un service, quelles limites accepter et quels changements différer. Ajoutez une liste de problèmes compréhensible et un processus de livraison répétable.
Chez Brainbaby Labs, les discussions de livraison incluent les responsabilités après lancement. Construction, hébergement, maintenance et nouvelles fonctions peuvent avoir des périmètres différents. L’objectif est de les clarifier avant le début du travail.
Pour un nouveau projet, décrivez résultat, systèmes existants et équipe d’exploitation dans le brief. Pour un produit existant, présentez problèmes récurrents et informations opérationnelles disponibles.