Applications métierles enjeux de la reprise et du transfert de code
Quand une PME récupère une application métier d'un prestataire précédent, elle hérite souvent bien plus que du code : dépendances obsolètes, secrets laissés en clair, accès non révoqués, absence de versionnement. Ce dossier identifie les risques techniques et de sécurité les plus courants lors d'un transfert de code, et explique comment auditer ce que vous recevez avant d'y toucher.
Ce contenu est fourni à titre informatif et ne remplace pas un conseil professionnel adapté à votre situation.
Vérifiez les sources officielles à jour avant toute décision.
Reprendre une application métier développée par un prestataire précédent place le dirigeant face à une réalité rarement anticipée : le code livré n'est pas un point de départ neutre. Il concentre des risques techniques et de sécurité accumulés pendant toute la durée de développement, parfois sur plusieurs années, sans que personne ne les ait inventoriés. Les dépendances tierces obsolètes constituent la première zone d'ombre : bibliothèques JavaScript, modules PHP, frameworks Python, chacun pouvant porter des vulnérabilités référencées dans les bases CVE et classées parmi les risques prioritaires de l'OWASP Top 10. La présence de secrets codés en dur, clés API, identifiants de bases de données ou tokens de services cloud, représente une menace immédiate dès lors que le code change de mains, car ces informations restent accessibles à toute personne qui consulte les fichiers sources. L'absence de versionnement Git prive le repreneur de tout historique et rend impossible la compréhension des choix passés. Les droits d'accès résiduels de l'ancien prestataire sur les environnements de production ou les bases de données constituent enfin un vecteur d'exposition souvent ignoré jusqu'à un incident. Avant de confier l'évolution de l'application à une nouvelle équipe, un audit structuré de ces quatre dimensions permet de décider en connaissance de cause, de chiffrer les travaux de mise en conformité et d'éviter une reprise à l'aveugle qui reproduirait les mêmes fragilités.
Ce que contient réellement le code que vous recevez
Une application web ou métier moderne repose sur un empilement de composants : le langage de programmation (PHP, Python, JavaScript, Java), un ou plusieurs frameworks structurants (Laravel, Symfony, Django, Node.js), des bibliothèques utilitaires pour gérer les formulaires, les exports PDF, les envois d'e‑mail, les connexions à des API tierces, et parfois des modules complets achetés ou téléchargés librement. Chacun de ces composants a sa propre histoire de sécurité.
Quand vous récupérez le code source, vous récupérez aussi toutes ces dépendances, dans l'état où elles ont été laissées. Si le prestataire n'a pas maintenu ses mises à jour de sécurité, il est courant de trouver des bibliothèques dont les versions datent de plusieurs années et dont les vulnérabilités sont publiquement connues, référencées et exploitables.
En pratique, un fichier package.json, composer.json ou requirements.txt liste toutes les dépendances déclarées du projet. La première chose à vérifier est que ce fichier existe, qu'il est à jour et qu'il correspond à ce qui est réellement installé en production.
Les secrets laissés en clair dans le code : un risque immédiat
Un secret, au sens technique, désigne toute information permettant d'accéder à un service ou à une ressource : clé API d'un prestataire de paiement, identifiant et mot de passe de connexion à la base de données, token d'accès à un service cloud, clé de chiffrement utilisée pour les données sensibles, identifiants SMTP pour l'envoi d'e‑mails. Ces informations existent dans toute application ; le problème survient quand elles sont inscrites directement dans le code source plutôt que stockées dans des variables d'environnement ou un gestionnaire de secrets. *
Quand le code change de mains, deux situations à risque se présentent :
- Le nouveau prestataire reçoit des secrets actifs pointant vers les services de production. Même s'il n'en fait pas usage intentionnellement, ces informations transitent désormais dans d'autres environnements, boîtes mail, dépôts de code, outils de partage.
- L'ancien prestataire a pu archiver ou conserver des copies du code. Les secrets qu'il contenait restent valides jusqu'à leur révocation explicite.
La directive la plus claire sur ce point vient de Microsoft Azure Security : intégrer des secrets directement dans le code ou les fichiers de configuration crée un risque de sécurité important, car si les attaquants compromettent la base de code, ils compromettent aussi les secrets. *
Accès non révoqués : ce que l'ancien prestataire conserve sans que vous le sachiez
Pendant la durée du projet, votre prestataire a dû accéder à de nombreux environnements : serveur de production, base de données, dépôt de code, interfaces d'administration, outils de monitoring, services cloud, panel d'hébergement. Ces accès ont été ouverts pour les besoins du développement. Ont‑ils été fermés à la fin de la relation contractuelle ? La réponse honnête est : rarement de façon systématique, et encore plus rarement sans rappel explicite du client.
Les droits résiduels les plus fréquemment oubliés sont :
- Comptes utilisateur dans les outils d'administration (cPanel, Plesk, interfaces cloud)
- Accès SSH avec clé publique encore autorisée sur le serveur
- Utilisateurs de base de données avec des droits étendus, créés pour les phases de développement
- Tokens d'accès API générés au nom de l'ancien prestataire, toujours actifs
- Comptes dans des services tiers connectés à l'application (Stripe, SendGrid, AWS, Twilio, etc.)
- Accès à des dépôts de code partagés ou à des outils de gestion de projet
Ces accès non révoqués ne constituent pas seulement un risque lié à l'intention : un compte oublié est un compte dont les identifiants peuvent être exposés lors d'une fuite de données affectant le prestataire lui‑même. Votre sécurité dépend alors de celle d'une entité avec laquelle vous n'avez plus de relation contractuelle.
La procédure de révocation doit être traitée comme une étape formelle de la passation, pas comme une formalité administrative secondaire.
L'absence de versionnement : quand le code n'a pas de mémoire
Quand vous recevez un code sans dépôt Git ou avec un historique incomplet, votre nouveau prestataire hérite d'une boîte noire. Il ne sait pas quelles modifications ont été apportées récemment, quelles fonctionnalités ont été désactivées temporairement, quels correctifs de sécurité ont déjà été appliqués ou, au contraire, revertis. Cette opacité a des conséquences directes :
Risque de régression
Sans historique, le développeur ne peut pas identifier les parties du code qui ont récemment changé. Il travaille à partir d'un état figé, sans contexte, et risque d'introduire des régressions en modifiant du code dont il ne comprend pas la genèse.
Traçabilité impossible
En cas d'incident de sécurité, l'absence d'historique rend impossible de déterminer à quelle date une vulnérabilité a été introduite, si elle est ancienne ou récente, et si d'autres modifications récentes ont aggravé ou atténué l'exposition.
La norme dans tout projet sérieux est le versionnement continu via Git, avec des commits réguliers, des messages descriptifs et une branche de production distincte des branches de développement. Si vous recevez un code sans dépôt, la première action du nouveau prestataire devrait être d'en créer un, avec un commit initial documentant l'état de reprise. Cela fixe un point de départ, auditable dans le futur.
Demandez aussi si un fichier CHANGELOG ou une documentation des versions existe. Son absence est un signal : elle indique que les évolutions n'ont pas été suivies de façon structurée.
Comment auditer les dépendances : méthode et outils
La plupart des gestionnaires de paquets modernes intègrent nativement une commande d'audit. Elle analyse le fichier de dépendances, interroge les bases de vulnérabilités connues et produit un rapport classé par niveau de criticité.
| Écosystème | Fichier de dépendances | Commande d'audit |
|---|---|---|
| JavaScript / Node.js | package.json |
npm audit |
| PHP / Composer | composer.json |
composer audit |
| Python / pip | requirements.txt |
pip‑audit |
| Ruby / Bundler | Gemfile.lock |
bundle audit |
Ces commandes croisent les versions installées avec les bases CVE et les advisory publiés par les éditeurs des bibliothèques concernées.
Le rapport produit classe les vulnérabilités selon leur niveau de criticité : critique, haute, moyenne, faible. Les vulnérabilités critiques ou hautes doivent être traitées en priorité, avant tout développement de nouvelles fonctionnalités. Une bibliothèque vulnérable reste vulnérable même si votre application fonctionne parfaitement par ailleurs.
Au‑delà de la commande d'audit, il est utile de vérifier que les dépendances déclarées correspondent à celles effectivement installées en production. Un prestataire peut avoir installé des modules manuellement sans les référencer dans le fichier de dépendances : ces composants fantômes n'apparaissent pas dans l'audit automatique.
Checklist dirigeant : que vérifier avant de confier l'application à un nouveau prestataire
- 1Demandez le fichier de dépendances complet
Obtenez
package.json,composer.json,requirements.txtou l'équivalent selon l'écosystème. Vérifiez qu'il correspond à ce qui est réellement en production. Si ce fichier n'existe pas, considérez‑le comme un signal d'alarme. - 2Lancez un audit des vulnérabilités connues
Demandez à votre nouveau prestataire d'exécuter la commande d'audit adaptée à l'écosystème dès réception du code. Obtenez le rapport et faites‑vous expliquer les vulnérabilités de niveau critique ou haut avant d'aller plus loin.
- 3Recherchez les secrets codés en dur
Demandez une recherche textuelle sur les termes caractéristiques (
password,api_key,token,secret) dans l'ensemble des fichiers sources, y compris les fichiers de configuration. Toute occurrence doit être traitée avant que le code ne soit partagé ou déployé dans un nouvel environnement. - 4Révoquez tous les accès de l'ancien prestataire
Dressez la liste de tous les services auxquels il avait accès : hébergement, base de données, services cloud, outils tiers connectés à l'application. Révoquez chaque accès explicitement, changez les mots de passe de comptes partagés et désactivez les clés API créées pendant le projet précédent.
- 5Vérifiez la présence d'un dépôt Git et de son historique
Un dépôt Git avec un historique cohérent est le signe d'un travail structuré. Son absence ou son incomplétude est un signal qu'il faut initialiser un versionnement dès la prise en main, avant le premier changement du nouveau prestataire.
- 6Documentez l'état de reprise
Faites rédiger un rapport d'entrée par le nouveau prestataire : état des dépendances, liste des vulnérabilités identifiées, secrets trouvés et déplacés, accès révoqués, structure du code. Ce document devient la référence de départ et protège les deux parties en cas de litige ultérieur.
Ce que les lecteurs demandent souvent
Dois‑je faire auditer le code avant ou après avoir signé avec le nouveau prestataire ?
Idéalement, l'audit intervient avant la signature du bon de commande pour la suite du projet. Il permet de chiffrer les travaux de mise en conformité et d'intégrer ce coût dans la négociation. En pratique, si le code n'a pas été transmis à temps, l'audit doit être la toute première prestation confiée au nouveau prestataire, avant tout développement de nouvelles fonctionnalités.
Un prestataire peu scrupuleux peut‑il utiliser des secrets récupérés dans le code ?
Oui, c'est techniquement possible. Un secret codé en dur dans le code source reste valide tant qu'il n'est pas révoqué, indépendamment de la relation contractuelle. La bonne pratique consiste à révoquer systématiquement tous les credentials et tokens dès le changement de prestataire, et à ne jamais transmettre de code contenant des secrets actifs sans les avoir d'abord neutralisés ou déplacés dans un gestionnaire de secrets.
Que faire si le prestataire précédent refuse de transmettre le code source ?
Ce dossier ne traite pas des aspects contractuels et relationnels avec le prestataire précédent. La question de la propriété du code et des recours en cas de refus de transmission relève d'un conseil juridique. Ce qu'il faut retenir sur le plan technique : tant que vous n'avez pas le code source complet, vous ne pouvez pas auditer les risques ni planifier sereinement la reprise.
Mon application fonctionne bien, pourquoi m'inquiéter de dépendances obsolètes ?
Une application peut fonctionner parfaitement du point de vue fonctionnel tout en présentant des vulnérabilités actives. Les failles de sécurité dans des bibliothèques obsolètes ne perturbent pas le fonctionnement quotidien : elles créent une porte d'entrée pour des attaquants. Le risque est invisible jusqu'à l'incident. C'est précisément ce que l'OWASP appelle les composants vulnérables et obsolètes : des failles exploitables que l'application elle‑même ne signale pas.
Combien de temps prend un audit de sécurité sur une application métier reprise ?
Un audit de premier niveau, couvrant les dépendances, la recherche de secrets et la vérification des accès, peut être réalisé en quelques heures sur une application de taille moyenne. Un audit approfondi, incluant la revue de la logique applicative et des droits de base de données, demande généralement une à trois journées selon la complexité du projet. Ce travail est à prévoir dans le budget de reprise, pas à reporter à plus tard.
L'absence de Git est‑elle vraiment un problème si l'application tourne en production ?
Oui, pour deux raisons pratiques. D'abord, sans historique, le nouveau prestataire ignore quelles modifications récentes ont été apportées, ce qui augmente le risque de régressions lors des premières interventions. Ensuite, en cas d'incident de sécurité, l'absence de traçabilité rend impossible de déterminer à quelle date une vulnérabilité a été introduite et si d'autres changements l'ont aggravée. Initialiser un dépôt Git au moment de la reprise est une mesure de protection minimale.
Doit‑on refaire l'application de zéro si les problèmes identifiés sont nombreux ?
Pas nécessairement. La décision dépend de la nature des problèmes identifiés. Des dépendances obsolètes se mettent à jour. Des secrets en clair se déplacent dans des variables d'environnement. Des accès résiduels se révoquent. En revanche, si l'architecture de base est fondamentalement défaillante ou si la dette technique dépasse largement le coût d'une réécriture, la refonte devient une option à considérer. Un diagnostic honnête par le nouveau prestataire doit précéder cette décision.
Auditer avant d'agir : une décision, pas une formalité
Reprendre une application métier sans en auditer le contenu technique revient à racheter un véhicule sans passer par un contrôle technique : l'objet fonctionne au moment de la transaction, mais les fragilités cachées se révèlent au pire moment. Les quatre dimensions abordées dans ce dossier, dépendances obsolètes, secrets en clair, accès non révoqués et absence de versionnement, sont documentées, mesurables et traitables. Elles ne requièrent pas des semaines d'investigation, mais elles exigent d'être posées explicitement comme condition préalable à toute nouvelle phase de développement. Un dirigeant qui commande un audit de reprise avant le premier développement ne dépense pas plus : il évite de payer deux fois.
Sources
- Meilleures pratiques pour un audit cybersécurité ISO 27001 en PME SaaS
- Audit Cybersécurité PME : Guide, Checklist et Tarifs 2026
- Audit sécurité informatique PME : méthode, coûts et checklist 2026 | ALTEZIA Blog
- Audit cybersécurité PME : guide complet 2026 - VDI Partenaire Technologique
- Audit de sécurité informatique PME : la méthode qui révèle ...
- Audit cybersécurité PME : prix, étapes et rapport 2026
- Audit Sécurité Informatique PME : Guide Complet 2026 | Sicollab
Vous reprenez une application existante ?
Avant de confier l'évolution de votre application à une nouvelle équipe, un diagnostic de reprise permet d'identifier les risques réels et de planifier les travaux dans l'ordre de priorité. Nous pouvons accompagner cette phase d'audit technique, de la vérification des dépendances à la révocation des accès résiduels. Discutons de votre projet : nous trouverons ensemble la démarche adaptée à votre situation.
