Votre application a déjà des utilisateurs, des données enregistrées et un fonctionnement sur lequel les gens comptent. Quand vous faites appel à un développeur pour corriger un bug ou ajouter une fonctionnalité, ces engagements existants font partie du travail.
Je commence par comprendre le système actuel et le changement dont vous avez besoin. Vous pouvez m’aider avec un exemple clair, une carte des services concernés et la liste de ce qui doit continuer à fonctionner. Ce guide explique quoi préparer et ce que vous pouvez attendre de l’audit.
Décrivez le changement du point de vue des utilisateurs
« L’application est lente » est un point de départ utile. « Sur mobile, la page des commandes met plusieurs secondes à s’ouvrir quand un client a un long historique » nous donne quelque chose à examiner. Pour une nouvelle fonctionnalité, décrivez ce que l’utilisateur doit pouvoir faire et ce qu’il peut faire aujourd’hui.
Pour un bug, envoyez les étapes qui y mènent, ce que vous attendiez et ce qui s’est passé à la place. Précisez l’appareil ou le navigateur si cela semble jouer un rôle. Un court enregistrement d’écran peut aider ; retirez les informations clients et les messages privés avant de le partager.
Dites-moi à quelle fréquence le problème survient, qui il touche et s’il existe un contournement. Une panne au paiement qui touche des clients actifs n’appelle pas la même réponse qu’un défaut visuel sur une page interne.
Voici un rapport de bug imaginaire, assez détaillé pour commencer l’enquête :
Sur la page des commandes, choisissez « 30 derniers jours », puis ouvrez la deuxième page de résultats. Le filtre de date se réinitialise et des commandes plus anciennes apparaissent.
Attendu : le filtre de date reste sélectionné quand on passe d’une page à l’autre.
Cela se produit à chaque fois dans Chrome sur mon ordinateur portable. L’équipe peut contourner le problème en cherchant par numéro de commande, mais l’examen des commandes récentes prend plus de temps.
Donnez-moi une carte du système actuel
Vous n’avez pas besoin de connaître chaque détail technique. Commencez par ce que vous savez et dites-moi qui peut répondre aux questions sur le reste.
Où se trouve le code, à qui appartient le dépôt et quelle version est en production.
Où tourne l’application et comment les changements sont déployés aujourd’hui.
La base de données, le stockage de fichiers et les services externes utilisés.
Les instructions d’installation, les vérifications automatiques ou la documentation existante.
Les problèmes connus, le travail inachevé et les tentatives précédentes pour régler ce problème.
Si l’ancien développeur ou une autre équipe est disponible pour répondre aux questions.
Si vous avez un environnement de préproduction (une copie séparée pour tester les changements avant qu’ils n’atteignent les clients), dites-moi comment y accéder. Si vous n’en avez pas, nous le prévoirons quand le travail l’exigera.
Indiquez ce que le système actuel doit préserver : liens existants, données enregistrées, droits des utilisateurs, intégrations ou versions de l’application encore installées sur les téléphones de vos clients. On les oublie facilement quand on parle d’un seul nouvel écran.
Donnez les accès par invitation
Restez propriétaire de votre dépôt, de votre hébergement, de votre domaine et de vos comptes de paiement. Invitez le développeur avec la gestion des accès de chaque service, avec les droits nécessaires au travail. Quand le fournisseur le permet, un audit peut commencer avec un accès en lecture et un environnement de test.
Ne collez pas de mots de passe, de clés d’API de production, d’exports clients ni de fichier d’environnement complet dans un brief. Nous conviendrons de la manière de transmettre séparément les secrets nécessaires. Des comptes de test et des données d’exemple sont généralement plus utiles pour reproduire un problème qu’un accès sans restriction aux vraies données clients.
Comprenez l’audit avant le devis
Sur un code existant, je dois vérifier comment il tourne, suivre le comportement concerné et comprendre quelles parties un changement pourrait toucher. Une fonctionnalité qui semble isolée peut toucher les droits, la facturation ou une migration de base de données.
Nous convenons du périmètre et des conditions de l’audit avant qu’il commence. Son compte rendu écrit devrait expliquer :
Ce qui a été examiné, ce qui a pu être reproduit et les accès ou informations qui manquent encore.
Le changement recommandé, avec les alternatives qui méritent d’être envisagées.
Les fonctionnalités ou données existantes qui pourraient être touchées.
Comment le travail sera vérifié, mis en production et annulé en cas de problème.
Ce qui peut être estimé maintenant et ce qui demande une analyse plus poussée.
Demandez une raison avant une réécriture
Un code ancien peut encore très bien faire son travail. Un autre framework ou les préférences d’un nouveau développeur sont de mauvaises raisons de remplacer un système qui fonctionne. Souvent, le bon changement est une correction ciblée, un test manquant ou une mise à jour par étapes.
Parfois, un remplacement se justifie. Demandez quelles exigences le système actuel ne peut raisonnablement pas satisfaire, quelles parties pourraient être conservées et comment se ferait la transition. La comparaison doit inclure la migration des données et la préservation du comportement existant, en plus de l’écriture du nouveau système.
Convenez de la façon dont les changements arrivent aux utilisateurs
Avant le déploiement, nous devons savoir comment le changement sera testé, qui le relira et ce qui se passe si quelque chose tourne mal. Pour un produit en production, je veux un plan de mise en ligne validé et un moyen de revenir en arrière. Revenir à l’ancien code n’annule pas forcément un changement de données ; les migrations de base de données ont donc besoin de leur propre plan.
Pour l’exemple du filtre de date, nous vérifierions que la sélection tient d’une page à l’autre et que les autres filtres fonctionnent toujours correctement. Vous devriez pouvoir contrôler ce comportement dans un aperçu avant que la correction n’arrive sur le site en production.
À la livraison, vous devriez voir ce qui a changé, comment cela a été vérifié et ce qu’il reste à faire. Les nouvelles étapes d’installation, les changements de configuration et les limites connues ont leur place dans la documentation.
Ce qu’il faut m’envoyer en premier
Voici le produit et qui l’utilise : …
Voici la fonctionnalité ou le problème, avec un exemple : …
Voici ce qui doit continuer à fonctionner : …
Voici ce que je sais du code, de l’hébergement et du développeur actuel : …
Voici l’impact, la priorité et l’échéance éventuelle : …
Envoyez-moi ce contexte via leformulaire de contact. Inutile de faire le ménage dans tout le projet ou de rédiger une documentation technique avant de demander de l’aide.