Tech & architecture 
La réponse en bref
Les premiers jours d’une reprise servent à rendre l’application compréhensible et exploitable par la nouvelle équipe. Il faut organiser la continuité du service, vérifier les accès, relier le code à la version en ligne, examiner les données et les sauvegardes, puis établir les priorités. Une première modification peut ensuite être préparée avec des tests, des validations et une procédure de récupération adaptée.
Trois priorités pour prendre le relais
- 01Identifier qui assure le service et traite les incidents pendant la transmission.
- 02Vérifier les accès, la version en ligne et les conditions de restauration.
- 03Préparer une première intervention limitée, observable et validée.
01
Organiser la continuité avant de prendre le relais
La transmission commence par une question simple : qui intervient si l’application rencontre un problème aujourd’hui ? Identifiez l’interlocuteur métier, la personne qui peut agir sur le service et la façon de signaler un incident. Si l’équipe sortante reste impliquée, précisez ses responsabilités et la période de transition convenue.
Rassemblez les incidents ouverts, les changements en cours, les échéances connues et les traitements importants. Une mise à jour prévue, une expiration de service ou une opération de données peut modifier l’ordre des premières actions. Les utilisateurs doivent savoir à qui adresser leurs demandes pendant cette période.
Les étapes présentées dans cet article décrivent un ordre de travail à adapter. Elles ne constituent pas un engagement de délai : les accès disponibles, la complexité et l’état du service déterminent l’effort nécessaire. Un incident actif peut demander une prise en charge immédiate en parallèle de la transmission.
Les responsabilités à préciser au départ
- 01
Décision métier
Qui arbitre les priorités et valide les conséquences pour l’activité ?
- 02
Exploitation
Qui peut intervenir sur l’environnement en ligne et ses services ?
- 03
Transmission
Qui fournit le code, les accès, les documents et les explications disponibles ?
- 04
Communication
Qui informe les équipes concernées et centralise les incidents ?
02
Vérifier les accès et les comptes réellement utilisables
Faites l’inventaire des comptes nécessaires : dépôt de code, hébergement, bases de données, fichiers, domaine, DNS, services externes et outils de suivi. Pour une application mobile, incluez les comptes de publication et les éléments nécessaires à la préparation des versions. Identifiez le titulaire, l’administrateur et les personnes autorisées à intervenir.
Un accès annoncé doit être vérifié pour le rôle prévu. Pouvoir consulter un dépôt ne prouve pas que l’équipe peut préparer une version ou administrer l’environnement. Organisez des accès individuels et adaptés aux responsabilités, ainsi que les moyens de récupération. Les secrets doivent être transmis par un moyen approprié et séparés de la documentation générale.
Si un secret a été exposé dans un dépôt, GitHub recommande de le révoquer ou de le remplacer ; supprimer sa présence visible ne suffit pas à le rendre inutilisable. Attribuez cette action à la personne responsable et identifiez les services qui utilisent l’accès concerné. Une rotation doit tenir compte de leur configuration et de la vérification du fonctionnement.
Un inventaire d’accès exploitable
- Le service et sa fonction dans l’application
- Le compte titulaire et les administrateurs identifiés
- Les rôles accordés à la nouvelle équipe
- Le fonctionnement vérifié de chaque accès nécessaire
- La gestion des secrets et des moyens de récupération
- Les accès à retirer ou à modifier selon la transition convenue
Sources techniques
03
Relier le code à la version qui fonctionne en ligne
Repérez le dépôt, la branche ou la révision correspondant à la version en service, puis la façon dont elle a été construite et publiée. Le dernier code disponible peut différer de ce qui fonctionne réellement. Examinez aussi la configuration : variables d’environnement, versions des outils, dépendances et services attendus.
Préparez un environnement de travail distinct et vérifiez que l’application peut y être lancée avec des données adaptées. Les tests doivent tenir compte des effets externes : e-mails, paiements, notifications ou appels à d’autres systèmes. Prévoyez des réglages de test et des accès appropriés avant d’exécuter ces parcours.
Documentez les commandes, les prérequis et les étapes qui ont effectivement fonctionné. Si une partie de la préparation reste manuelle ou dépend d’une personne, rendez cette dépendance visible. L’objectif est qu’un autre membre de l’équipe puisse comprendre et reproduire le processus sans retrouver chaque réponse par essai successif.
Les éléments à relier entre eux
- 01
Code
Révision identifiée et historique des changements utiles.
- 02
Construction
Outils, dépendances et étapes nécessaires pour préparer une version.
- 03
Configuration
Paramètres et services attendus dans chaque environnement.
- 04
Publication
Version livrée, environnement ciblé et procédure suivie.
04
Comprendre les données et vérifier la restauration
Repérez où sont enregistrées les informations : bases, fichiers, stockage externe et outils connectés. Identifiez les relations importantes, les traitements automatiques et les responsables des échanges. Une application peut dépendre de documents ou de données qui ne figurent pas dans sa base principale.
Le cadre AWS Well-Architected recommande de restaurer périodiquement les sauvegardes et de vérifier que les données récupérées sont utilisables. Pour une reprise, examinez les sauvegardes existantes et réalisez un essai dans un environnement adapté, avec les autorisations et protections nécessaires. Les critères doivent porter sur les données et le service à retrouver.
Consignez ce qui a été restauré, les contrôles réalisés, les limites et le temps observé. Vérifiez aussi les éléments nécessaires autour de la base : fichiers, configuration et connexions. Si la récupération reste incertaine, cette incertitude doit peser sur les interventions envisagées avant toute modification importante des données.
Les preuves à conserver après un essai
- Origine, date et périmètre de la sauvegarde utilisée
- Environnement et procédure de restauration
- Vérification des informations, fichiers et relations utiles
- Résultat des parcours testés après récupération
- Durée observée et écarts avec les besoins de l’activité
- Limites, actions restantes et personne responsable
05
Parcourir le produit avec les personnes qui connaissent le métier
Faites décrire un petit ensemble de parcours essentiels : se connecter, créer une demande, la traiter, transmettre une information et retrouver son historique, selon le produit. Identifiez les rôles, les validations, les exceptions et les messages envoyés. Observez ce qui se passe dans l’application et dans les outils qui l’entourent.
Les règles importantes ne sont pas toujours écrites dans un document. Certaines se trouvent dans un calcul, un export, une tâche planifiée ou une habitude de l’équipe. Faites expliquer les situations particulières et les contournements connus. Distinguez le fonctionnement attendu, le comportement actuel et les problèmes déjà acceptés temporairement.
Le scénario fictif ci-dessous illustre un point de vigilance. Il ne décrit pas un incident ni un résultat client de Gaspa.
Décrire une dépendance sans ambiguïté
- 01
Déclenchement
Action, horaire ou événement à l’origine du traitement.
- 02
Informations
Données lues, créées ou modifiées, et système de référence.
- 03
Échange
Service, destinataire ou fichier impliqué dans le parcours.
- 04
Échec et reprise
Signal d’erreur, personne à prévenir et manière de reprendre le traitement.
06
Établir un état de référence et ordonner les priorités
Avant les premières modifications, rassemblez les informations disponibles sur le fonctionnement : incidents connus, erreurs, temps de réponse et traitements en attente, selon le service. Indiquez la période et les conditions observées. Si la visibilité est insuffisante, identifiez les premiers contrôles à mettre en place.
Google SRE présente la supervision comme un moyen d’évaluer l’état d’un service, d’enquêter sur les problèmes et de comparer son comportement avant et après un changement. Choisissez des signaux reliés aux usages importants et précisez qui les consulte. Un tableau de bord doit aider à décider d’une action.
Classez les actions avec votre équipe : incident à traiter, risque à réduire, élément manquant à obtenir ou évolution à préparer. Reliez chaque priorité à une conséquence pour le produit et à une prochaine action. Une dépendance ancienne et un défaut bloquant un parcours n’appellent pas nécessairement la même réponse.
Un registre de priorités compréhensible
- 01
Constat
Comportement ou élément manquant, avec sa preuve et son contexte.
- 02
Conséquence
Usagers, données, traitements ou capacité d’intervention concernés.
- 03
Action
Correction, vérification ou information nécessaire pour avancer.
- 04
Responsable
Personne chargée de la suite et condition de validation.
07
Préparer une première intervention limitée et vérifiable
Choisissez un changement dont le périmètre et l’utilité sont compris. Décrivez les parcours concernés, les parties à vérifier autour de lui et les critères d’acceptation. La première intervention sert aussi à confirmer que l’équipe sait préparer, tester et livrer une version dans les conditions prévues.
Précisez qui autorise la mise en service, comment observer le résultat et quand interrompre l’opération. Le retour à une version précédente doit être examiné avec les données et les traitements concernés. Si des informations ont changé entre-temps, il peut être nécessaire de les rapprocher ou de les reprendre plutôt que de restaurer aveuglément un état plus ancien.
Après la livraison, vérifiez les parcours et les signaux retenus, consignez les résultats et transmettez les informations à l’équipe métier. Les enseignements du premier lot permettent d’ajuster les interventions suivantes. Une décision plus large de refonte ou de réécriture se prépare à partir de ces constats et du besoin futur.
Les conditions à vérifier avant de livrer
- Périmètre, utilité et critères d’acceptation partagés
- Version actuelle identifiée et préparation de la nouvelle version comprise
- Tests des parcours et des effets sur les services connectés
- Données et possibilités de récupération examinées
- Autorisation, conditions d’arrêt et responsables identifiés
- Contrôles après livraison et information des personnes concernées
Choisir la trajectoire après la prise en main
08
Rendre la reprise exploitable pour la suite avec Gaspa
À l’issue de cette première phase, l’équipe doit pouvoir expliquer comment le service fonctionne, quels accès elle maîtrise et quelles limites restent ouvertes. Les livrables doivent relier les informations techniques aux décisions et aux responsabilités : inventaire, procédure de travail, parcours critiques, état de référence et plan d’action.
Gaspa accompagne l’audit UX et technique, la maintenance et la refonte d’applications. Notre méthode prévoit un interlocuteur principal, des échanges avec les experts concernés et des validations partagées. Les objectifs de la reprise, les éléments à transmettre et les modalités de suivi sont à préciser avec votre équipe avant les interventions.
La transmission se poursuit à mesure que le produit évolue. Faites mettre à jour la documentation, les accès et les procédures après les changements qui les affectent. Le résultat recherché est une capacité durable à comprendre, maintenir et faire évoluer l’application, avec des priorités compréhensibles par les équipes métier et technique.
Les livrables de la prise en main
- 01
Inventaire vérifié
Accès, comptes, code, données, services et responsables.
- 02
Procédures utilisables
Préparation d’un environnement, publication et récupération, avec leurs limites.
- 03
Parcours et état de référence
Scénarios essentiels, incidents connus et premiers signaux de suivi.
- 04
Plan de premières interventions
Priorités, vérifications restantes, responsabilités et critères de validation.