Reprendre une application sans audit revient à chiffrer des travaux dans un bâtiment dont personne ne possède les plans. Le code peut sembler lisible tout en cachant un déploiement manuel, une base impossible à restaurer ou une dépendance critique en fin de vie.
L’audit technique ne sert pas à dresser la liste la plus longue possible de défauts. Il doit permettre de décider, de prioriser et d’estimer le risque de la reprise.
Les informations à réunir avant l’audit
Demandez les dépôts, les accès aux environnements, les schémas d’architecture, le backlog, les incidents récents et les statistiques d’utilisation. Ajoutez les contrats des services externes et les coordonnées des personnes qui connaissent encore le produit.
L’absence d’un élément est déjà une information. Si personne ne sait où se trouvent les sauvegardes ou comment publier l’application mobile, l’audit doit le faire apparaître comme un risque prioritaire.
1. Vérifier que le projet peut être exécuté
La première preuve attendue est simple : un nouveau développeur doit pouvoir installer le projet, lancer les tests et obtenir une version fonctionnelle à partir du dépôt.
Vérifiez :
- les instructions d’installation ;
- les versions des langages et outils ;
- la gestion des variables d’environnement ;
- les dépendances privées ;
- les données de démonstration ;
- les commandes de test, de build et de migration.
Une documentation élégante n’a pas de valeur si ces opérations ne fonctionnent pas réellement.
2. Cartographier l’architecture
L’audit identifie les applications web et mobiles, API, bases, traitements planifiés, files de messages, stockages et services tiers. Pour chaque composant, il précise son rôle, son propriétaire, son environnement et ses dépendances.
Cette carte permet de repérer les points uniques de défaillance et les composants qui ne sont plus utilisés. Elle évite aussi de corriger un dépôt sans comprendre ses effets sur le reste du système.
3. Évaluer le code et les dépendances
La qualité ne se résume pas à une note automatique. L’auditeur examine les parties réellement critiques : authentification, droits, paiement, données personnelles, règles métier et échanges entre services.
Il vérifie notamment :
- la structure et la lisibilité du code ;
- la présence de tests utiles ;
- les duplications et zones trop couplées ;
- les bibliothèques obsolètes ou vulnérables ;
- la cohérence des pratiques entre dépôts ;
- les erreurs masquées et traitements non supervisés.
L’objectif est de distinguer la dette acceptable de celle qui bloquera les prochaines évolutions.
4. Contrôler les données et les sauvegardes
Une reprise peut réussir techniquement et échouer lors de la migration des données. Documentez le modèle, les volumes, les données sensibles, les tâches de nettoyage et les migrations déjà en attente.
Une sauvegarde ne doit pas seulement exister : sa restauration doit être testable. L’audit vérifie la fréquence, la rétention, le chiffrement, la séparation des droits et le temps nécessaire pour remettre le service en route.
5. Examiner la sécurité
Sans remplacer un audit de sécurité spécialisé, la reprise doit contrôler les fondamentaux : secrets présents dans le code, comptes partagés, droits excessifs, dépendances vulnérables, exposition des environnements, journalisation des accès sensibles et procédure de révocation.
Les traitements de données personnelles doivent également être reliés aux contraintes métier et réglementaires. Une liste de technologies ne suffit pas à évaluer les conséquences d’un incident.
6. Tester la chaîne DevOps
L’auditeur doit observer un déploiement ou le reproduire. Il vérifie la séparation des environnements, les contrôles automatiques, la gestion des secrets, les migrations de base, la supervision et la procédure de retour arrière.
Si une seule personne peut mettre en production depuis son ordinateur, la continuité du service n’est pas maîtrisée. Notre article sur les signes d’une dette DevOps dangereuse approfondit ce sujet.
7. Relier la technique au produit
Tous les défauts ne méritent pas d’être corrigés. Une partie complexe mais stable peut présenter moins de risque qu’un parcours simple modifié chaque semaine. Les incidents, les usages et la roadmap permettent de concentrer l’effort là où il protège réellement l’activité.
L’audit doit répondre à trois questions : que faut-il sécuriser maintenant, que faut-il améliorer pour livrer la roadmap et que peut-on laisser en l’état ?
Quels livrables attendre ?
Un audit exploitable produit au minimum :
- une cartographie lisible du système ;
- un registre des risques classés par impact et urgence ;
- les accès ou informations encore manquants ;
- plusieurs scénarios de reprise ;
- un backlog technique priorisé ;
- un ordre de grandeur des charges ;
- un plan des premières mises en production.
Évitez les rapports qui attribuent une note globale sans expliquer les décisions. La direction doit pouvoir comprendre les compromis et l’équipe doit savoir par où commencer.
Après l’audit : passer à la reprise
L’audit n’est pas une fin. Il doit déboucher sur une première livraison à faible risque qui valide toute la chaîne, puis sur un rythme régulier. Le guide faire reprendre une application existante présente cette trajectoire complète.
Chez MyTwiga, la cartographie de treize dépôts et des environnements a permis de réunir applications mobiles, API et DevOps dans un même plan. Consultez ce retour d’expérience.