Audit de code avant reprise de projet

Vous vous apprêtez à confier votre application à une équipe qui ne l’a pas écrite, et le montant qu’elle annoncera dépend d’abord d’une chose que personne n’a encore vérifiée : ce que vous détenez réellement. Ce que le prestataire sortant vous a remis constitue-t-il le projet, ou seulement une copie de ses fichiers ? Une équipe entrante y répond par une manipulation banale, en installant les sources sur une machine neuve pour tenter de les faire tourner, et l’échec de cette installation est déjà un résultat d’audit, obtenu avant d’avoir lu une ligne. L’examen commandé avant une reprise ne porte donc pas d’abord sur la valeur de ce qui est écrit. Il porte sur la reprenabilité, c’est-à-dire sur ce qu’il faut réunir pour qu’une autre équipe puisse travailler sur votre outil, et sur ce que cette remise en état coûtera avant la première évolution. Quatre vérifications l’ouvrent, un inventaire des composants la complète, et aucune ne demande un avis sur la qualité du code.

Juger la reprenabilité et juger la qualité sont deux examens distincts

Les deux examens se confondent facilement parce qu’ils se commandent au même moment, et que le même prestataire peut mener les deux. Ils ne répondent pourtant pas à la même question. Juger la qualité revient à mesurer ce que votre outil coûtera à modifier, demande après demande, une fois que tout fonctionne. Juger la reprenabilité revient à établir si une équipe qui n’a pas écrit ce code peut le remettre en marche, le modifier et le redéployer, et ce qui manque pour y arriver. Une application de bonne facture dont personne ne détient l’environnement de déploiement se reprend mal. Une application médiocre, complète et documentée, se reprend sans difficulté particulière, au prix d’une maintenance chère ensuite.

L’ordre compte pour votre budget. La qualité se règle par petites sommes, demande après demande, et vous pouvez la découvrir en cours de route. La reprenabilité, elle, se paie en une fois, au démarrage, et rien ne commence tant qu’elle n’est pas réglée. Un devis qui chiffre la qualité sans avoir vérifié la reprenabilité chiffre un travail dont personne ne connaît encore le point de départ. Le jugement sur le code, lui, garde toute son utilité, à condition de le commander pour ce qu’il est : un travail qui consiste à faire la part entre ce que votre outil calcule mal et ce qu’il coûte de le corriger, et les deux se prouvent par des pièces différentes.

Le périmètre déborde les fichiers de code

Ce que le mot audit de code laisse en dehors du cadre est précisément ce qui bloque une reprise. Le dépôt de code d’abord, c’est-à-dire l’endroit où le code est rangé avec la trace datée de chacune de ses modifications, qui ne se confond pas avec un dossier de fichiers. Les environnements ensuite, celui où l’application se construit et celui où elle tourne devant vos utilisateurs. La chaîne de déploiement, c’est-à-dire la suite d’opérations qui porte une modification du poste du développeur jusqu’à votre production. Les comptes enfin, hébergement, nom de domaine, services tiers facturés, et les clés d’accès qui vont avec.

Réclamez que le périmètre de l’audit nomme ces quatre ensembles par écrit avant de signer. Un prestataire qui n’annonce que la lecture du code vous rendra un document exact et incomplet, et vous découvrirez le reste au moment où la reprise aura déjà commencé.

Les vérifications qui précèdent toute lecture du code

Quatre vérifications ouvrent la mission et occupent en général ses premiers jours. Les trois premières portent sur ce que vous avez reçu, la quatrième sur le rythme que l’équipe entrante pourra tenir ensuite. Aucune ne demande d’outil coûteux ni de lecture approfondie, et toutes produisent des constats plutôt que des appréciations, vérifiables par le prestataire sortant comme par celui qui entre, là où un avis sur le code se discute.

Reconstruire l’application depuis les sources reçues

C’est le test qui décide. Sur une machine neuve, où seuls le langage et son gestionnaire de paquets sont installés, votre application doit s’installer avec les seuls fichiers qui vous ont été remis, puis se construire et démarrer. La règle qui commande ce test est écrite depuis longtemps. Une application correctement tenue déclare toutes ses dépendances, complètement et exactement, dans un manifeste de dépendances, c’est-à-dire un fichier qui les liste toutes, et elle ne se repose jamais sur l’existence implicite de paquets déjà installés sur la machine. C’est le deuxième des douze facteurs d’Adam Wiggins, et le bénéfice qu’il annonce vise exactement votre situation : cette déclaration explicite simplifie l’installation pour un développeur qui arrive sur l’application, lequel n’a besoin au départ que du langage et de son gestionnaire de paquets.

Quand la reconstruction échoue, cherchez la cause dans ce qui vivait sur la machine du développeur précédent sans avoir été écrit nulle part : une version d’outil, un réglage, un fichier de configuration porteur de mots de passe. Vous détenez alors des fichiers et non un environnement de développement reproductible, c’est-à-dire un ensemble qui se réinstalle à l’identique chez n’importe qui, et la remise en état devient un poste de devis à part entière, chiffré en jours, avant la première évolution. Faites figurer cette réponse en tête du rapport, avec la liste de ce qui a manqué pour y parvenir.

L’historique du dépôt, ou son absence

Un projet se transfère parfois sous forme d’archive compressée. L’archive porte le code dans son dernier état et rien de plus, quand le dépôt porte en plus tout ce qui a mené à cet état. Cette suite datée d’enregistrements, que les développeurs appellent l’historique des commits, vous donne trois choses qu’aucune lecture ne remplace : la date à laquelle quelqu’un a touché ce code pour la dernière fois, la répartition des contributions entre les personnes intervenues, et les zones de l’application qui ont été reprises le plus souvent. Cette dernière indication désigne les parties instables mieux que ne le ferait une inspection, puisqu’elle enregistre des corrections réelles plutôt que des défauts supposés.

Un dépôt dont l’histoire commence par un versement unique et massif signale un transfert partiel. Le code est là, sa trace est restée chez celui qui l’a produit, et elle se réclame tant que la relation le permet encore, au même titre que ce que l’équipe sortante peut encore vous remettre. Cette demande se formule simplement, elle porte sur le dépôt complet et non sur une exportation.

Les accès qui ne se transfèrent pas avec le code

Une application remise dans son intégralité ne vous rend pas maître de ce qui la fait tourner. L’hébergement, le nom de domaine, les certificats, les comptes de services tiers facturés au mois et les clés qui autorisent votre outil à s’y connecter forment un ensemble distinct, et il arrive qu’ils aient été ouverts au nom du prestataire parce que c’était plus rapide au démarrage. Pour une reprise, une seule question compte sur chacun d’eux : qui peut y nommer un nouvel administrateur aujourd’hui, et sans l’accord de qui. Un compte dont personne chez vous ne peut rouvrir les droits arrête la reprise là, quelle que soit la qualité de ce qui a été développé.

Cet inventaire en prépare un second, qui relève du contrat plutôt que de la technique : détenir les fichiers ne dit pas qui détient les droits dessus, et la cession des droits sur le code se prouve par un écrit. Quand le prestataire ne répond plus, rien de tout cela n’avance tant que vous n’avez pas établi ce qu’est devenue la société qui a écrit votre code, parce que la voie à suivre dépend de son état juridique.

Modifier sans rien casser, ce que les tests automatisés changent

La quatrième vérification fixe le rythme de tout ce qui suivra. Votre application peut être accompagnée de tests automatisés, c’est-à-dire de programmes qui rejouent seuls les cas d’usage principaux et signalent qu’une modification vient d’en casser un. L’audit établit s’il en existe, sur quelles parties ils portent, et surtout s’ils passent encore aujourd’hui.

Cette réponse gouverne la vitesse d’une équipe entrante bien plus que la propreté du code. Sans ces tests, chaque modification demande une vérification manuelle sur vos écrans, et la prudence impose de limiter les changements à de petits lots. Avec eux, la même équipe touche à des parties qu’elle n’a pas relues sans avancer à l’aveugle. Une série de tests présente mais en échec constitue un cas à part : elle indique que l’application a divergé de ce que ces tests vérifiaient, et la remettre en état figure parmi les premiers travaux de la reprise. Faites chiffrer ce poste séparément, parce qu’il se rentabilise sur toutes les évolutions qui suivent.

L’inventaire des dépendances tierces, et ce qu’il fait remonter

Votre application contient une part de code qu’il n’a pas fallu écrire pour vous. Elle vient de composants publics que vos développeurs ont assemblés, et le repreneur hérite de leur état au jour où il arrive. Leur relevé ouvre le second temps de l’audit. Il s’obtient par des outils et non par un jugement, ce qui le rend vérifiable, mais la façon dont il est produit change beaucoup ce qu’il contient.

Ce relevé remonte à peu près toujours la même chose, et un ordre de grandeur publié aide à le lire. Sur 947 bases de code commerciales analysées dans 17 secteurs, 93 pour cent contenaient au moins un composant qu’aucun développement actif n’avait touché depuis plus de deux ans. Sur l’ensemble des composants relevés, 7 pour cent seulement tournaient sur leur dernière version disponible, et 41 pour cent accusaient dix versions de retard ou davantage. Ces relevés ne disent rien de votre projet en particulier. Ils changent en revanche la lecture d’un devis de reprise : un repreneur qui n’a prévu aucune ligne pour la mise à niveau des composants n’a pas encore regardé ce qu’il reprend. Les trois chiffres viennent du rapport 2026 Open Source Security and Risk Analysis de Black Duck, établi sur des audits menés entre novembre 2024 et octobre 2025.

Les licences, le blocage que personne n’anticipe

Chaque composant public arrive avec une licence, et toutes ne se combinent pas. Certaines obligent à publier le code qui les incorpore, ce qui entre en contradiction directe avec l’usage privé d’un outil que vous financez pour votre entreprise. Sur les mêmes bases de code, 68 pour cent contenaient un conflit de licence, c’est-à-dire au moins deux licences dont les conditions ne tiennent pas ensemble, contre 56 pour cent l’année précédente, la plus forte progression d’une année sur l’autre que ce rapport ait enregistrée. Ses auteurs y voient d’abord un effet de nombre : plus une application assemble de composants, plus les combinaisons de licences à vérifier se multiplient.

Un risque de licence échappe par construction à cet inventaire dès lors qu’il est bâti sur les seules dépendances déclarées. Un assistant de génération de code peut produire un fragment dérivé d’une source soumise à une licence contraignante et le restituer sans l’information de licence d’origine, ce que le rapport appelle le blanchiment de licence et décrit comme invisible aux outils qui ne lisent que les dépendances déclarées. Il mesure par ailleurs ce que cette lecture laisse passer. 16 pour cent des composants qu’il recense ne sont trouvés ni dans les gestionnaires de paquets ni dans les manifestes, mais par une analyse plus profonde, parce qu’ils sont entrés autrement, par fragments recopiés ou engendrés par un assistant, par inclusion directe d’une bibliothèque, ou sous forme de composants livrés sans leur source.

Cette réserve a une conséquence pratique sur ce que vous commandez. Un inventaire bâti sur le seul manifeste sous-estime ce que contient réellement votre application, et la différence porte précisément sur les composants les plus difficiles à retrouver ensuite. Demandez que le relevé soit produit par une analyse du code lui-même, en plus de ses fichiers de déclaration, et que le rapport le dise explicitement.

Ce point se traite avant la reprise, pour une raison simple : le retrait d’un composant dont la licence pose problème se paie d’autant plus cher qu’il est ancré profond dans l’application. Demandez que le rapport liste les composants par licence, et qu’il isole ceux dont les conditions imposent une obligation de publication. Cette liste écrite une fois vous évite une question sans réponse le jour où vous voudrez vendre l’outil ou le faire auditer par un client.

La nomenclature logicielle se demande par son nom

Ce relevé porte un nom et obéit à un format normalisé, ce qui vous dispense d’accepter la liste maison que chaque prestataire construit à sa façon. Ce format s’appelle SPDX. Il est normalisé depuis 2021, dans sa version 2.2.1, sous la référence ISO/IEC 5962:2021, et il fixe la manière d’échanger la nomenclature logicielle d’un ensemble de fichiers : les composants qui le constituent, leurs licences et les droits d’auteur attachés.

Réclamez ce livrable dans ce format, pas une capture d’écran d’outil ni un tableur reconstitué. Vous gagnez trois choses à l’exiger ainsi. Le document se relit par n’importe quelle équipe, y compris celle que vous ne retiendrez pas. Il se recompare à l’identique une fois la remise à niveau faite, et la différence se lit ligne à ligne. Et il ne dépend d’aucun outil précis, donc personne ne peut vous le refuser au motif que sa chaîne ne le produit pas.

Les cinq réponses qu’un devis de reprise exige

Le même rapport sert à interroger plusieurs candidats sur des bases identiques, et c’est sa principale qualité pratique dans une consultation. Demandez à celui qui le produit ce qu’il advient du document si vous confiez la reprise à quelqu’un d’autre. La réponse vous dit si vous achetez un constat ou une entrée en matière commerciale.

Sa durée se calcule sur quatre éléments que vous connaissez déjà, et il vaut mieux les annoncer que les laisser découvrir. La disponibilité des accès pèse en premier, puisqu’un compte à retrouver chez un ancien prestataire occupe des jours entiers. Des tests automatisés la raccourcissent, puisqu’une partie des vérifications tourne alors sans intervention. Des composants et un langage anciens l’allongent, parce qu’il faut alors reconstituer un environnement qui n’est plus celui d’aujourd’hui. L’état de votre production tranche le reste, selon que l’outil tourne encore normalement ou qu’il est arrêté. Un prestataire qui annonce un délai sans s’être renseigné sur ces quatre points ne l’a pas calculé.

Un rapport d’audit utile ici tient en cinq réponses, et aucune ne demande d’interprétation. La reconstruction depuis les sources remises a réussi ou non, et la liste de ce qui a manqué figure au rapport. Le dépôt a été transmis avec son historique ou sans. Les tests automatisés existent ou non, et le rapport dit s’ils passent encore. L’inventaire des composants est joint, licences comprises, avec les conflits isolés. Les comptes et les accès sont recensés, et ceux que vous ne pouvez pas rouvrir seul apparaissent à part. Un score de santé global ne vous sert à rien, puisqu’il mélange ces cinq réponses avec des appréciations, et qu’aucun devis ne se construit dessus.

Deux sujets restent volontairement en dehors de ce document. Le prix de la remise à niveau suppose d’arbitrer ce que vous remettez à niveau et ce que vous laissez en l’état, arbitrage qui demande de connaître vos évolutions déjà prévues. La recherche de failles relève d’un examen qui se commande à part, avec ses propres méthodes et son propre périmètre. Les commander ensemble reste possible, les confondre dans un forfait unique vous empêche de savoir ce que vous avez payé.

Ce que cet état des lieux change à votre consultation

L’ordre que nous recommandons tient en une phrase : l’état des lieux d’abord, le choix du repreneur ensuite. Il vous met en position de comparer des propositions qui répondent au même constat, au lieu de comparer des devis dont chacun repose sur ce que son auteur a cru comprendre de votre projet. Chez nous, le code et les données de votre outil restent intégralement les vôtres, avant cet état des lieux comme après.

Quand le besoin dépasse le seul code et porte aussi sur les performances ou sur la sécurité, les six points d’un audit technique couvrent ces volets dans une même mission. Et lorsque les cinq réponses sont posées et que la décision est prise, vient le chantier qui remet l’application entre vos mains : la redémarrer, la documenter, puis reprendre les évolutions, avant de basculer en maintenance régulière confiée à une équipe extérieure, ce que le métier appelle la tierce maintenance applicative.

Sources

The Twelve-Factor App, facteur II, Dependencies, Adam Wiggins, dernière mise à jour 2017, https://12factor.net/dependencies

2026 Open Source Security and Risk Analysis Report, Black Duck, audits menés de novembre 2024 à octobre 2025, https://www.blackduck.com/resources/analyst-reports/open-source-security-risk-analysis.html

ISO/IEC 5962:2021, Information technology, SPDX Specification V2.2.1, 2021, https://www.iso.org/standard/81870.html