Première urgence : les accès
Tant que vous ne détenez pas les accès, vous ne possédez pas vraiment votre outil. Faites la liste, et vérifiez que chacun est à votre nom ou que vous en avez les identifiants :
le nom de domaine (chez quel registraire, à quel nom, quand expire-t-il ?) ; l'hébergement (serveur, compte de l'hébergeur, factures) ; la base de données ; le code source ; les comptes développeur Apple et Google pour une application mobile ; les services tiers (envoi d'emails, SMS, paiement, notifications).
Un nom de domaine qui expire sans que personne ne le renouvelle, c'est le site et la messagerie qui s'arrêtent le même jour. C'est le premier point à vérifier.
Deuxième urgence : une sauvegarde complète
Avant toute intervention, faites copier l'intégralité des fichiers et de la base de données, et conservez cette copie hors du serveur. Si quelque chose se passe mal ensuite, c'est votre filet.
L'erreur à éviter : tout supprimer dans l'urgence
En reprenant un serveur, on découvre souvent des dossiers dont personne ne connaît l'usage : anciennes versions, outils de test, modules abandonnés. La tentation est de tout effacer. Mieux vaut fermer leur accès depuis le web sans les supprimer : vous supprimez le risque immédiatement, et vous gardez la possibilité de revenir en arrière si un usage oublié se manifeste.
De même, après un piratage, les fichiers modifiés et les journaux du serveur permettent de comprendre par où l'attaquant est entré. Les effacer, c'est s'exposer à ce qu'il revienne par la même porte.
Ensuite : un audit
Un audit sérieux répond à trois questions. Qu'est-ce qui tourne ? Inventaire des applications, des versions, des tâches planifiées. Qu'est-ce qui est dangereux ? Failles connues, mots de passe en clair, fichiers exposés, composants obsolètes. Qu'est-ce qui va casser ? Versions de logiciels en fin de vie, certificats, composants abandonnés.
Le résultat doit être un rapport priorisé : ce qu'il faut corriger cette semaine, ce mois-ci, et ce qui peut attendre.
Faut-il tout réécrire ?
Presque jamais en premier. Une réécriture complète est longue, coûteuse, et fait perdre au passage des comportements que personne n'avait documentés mais dont quelqu'un dépend. La démarche raisonnable : corriger les failles, migrer vers des versions maintenues, documenter, puis remplacer progressivement les parties qui posent vraiment problème.
Quand d'autres programmes dépendent de l'outil — une application mobile installée chez vos utilisateurs qui interroge votre serveur, par exemple —, chaque modification doit préserver exactement ce qu'ils attendent. C'est un travail minutieux, mais c'est ce qui permet d'avancer sans rien casser.
Et pour la suite
Une fois l'outil repris, documenté et sécurisé, vous pouvez le faire évoluer sereinement — et vous assurer que la situation ne se reproduira pas : accès à votre nom, code source en votre possession, documentation à jour.
C'est un type de mission que nous menons régulièrement. Décrivez-nous votre situation : nous vous indiquerons les premières mesures à prendre.
Publié le 03/07/2025.